0

we're currently working on the design for an UCMA application that should be able to subscribe to presence updates of up 15k users. Reading the (rather outdated) documentation we noted the following:

Lync Server 2013 also places a limit on the subscription response body length, so an application that subscribes to a large number of users (typically more than 1000 users) might receive an error response from Lync Server 2013.

Does anyone know if this still true for Skype for Business 2015/2019 or where to find current docs?

Further down the same doc states that, for a large number of subscriptions, it is recommended to limit the categories we subscribe to. We're only interested in the presence state, so that's a good workaround for us. However I can't find much information about what difference that makes, like if we subscribe to only the presence state, can we have 2x or 5x or 100x the number of subscriptions?

Searching around I found this post that seems to say we can subscribe to many more users if we create batches of a few hundreds. So does the above limit of 1000 users apply per BeginSubscription() call?

Many thanks in advance!

Tom Torggler
  • 1
  • 1

1 Answers1

2

Sounds like you are reading the UCMA 4 (Lync 2013) documentation. There is the UCMA 5 (SfB 2015) documentation but there are no real differences. UCMA 6 (SfB 2019) is available but there isn't any documentation.

From personal experience, you can use any of the UCMA versions to get the job done. The details haven't changed.

If you want to subscribe to SfB online accounts, you will have to use UCMA 5 on SfB 2015 or UCMA 6 on SfB 2019 as UCMA 4 on SfB 2015 / 2019 doesn't work for SfB online accounts. The is the only gotcha I have found.

I've gone up into a 100's of subscriptions and I think some of our customers are up to around the 1k mark using batch subscriptions. I use a batch size of 100 and it's working ok for me.

You are not going to know until you test it yourself to see how to performs with batch sizes you test with if it's to slow or fast enough.

At the 15k mark, it's getting to be a lot of subscriptions to take care of. This may start putting unwanted overhead onto the SfB system at that level of subscriptions due to the extra messages / subscription polling going on. You may need to look into splitting the subscriptions between applications / machines to load balance the work.

If you find that it's not working very well you may need to think about switching from a UCMA application to a Server App (sip proxy) application that runs on the FE machines and sniffs the sip traffic to view the presence change traffic as they happen. It's a lot more work but would not generate as much overhead as a UCMA application.

Shane Powell
  • 13,698
  • 2
  • 49
  • 61
  • Thanks for your comment, Shane! By Server App, do you refer to an MSPL script that forwards relevant messages to an application? Are user presence state updates available on that level? – Tom Torggler Feb 19 '20 at 10:16
  • Yes, a MSPL based application. And yes presence is done via SIP messages, see https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sip/17569f1f-91b5-44b3-a944-3f40adae08c7 – Shane Powell Feb 19 '20 at 15:56