Microsoft Lync has a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use them.

UCMA application unexpectedly answering user’s calls

Posted: March 14th, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , , , , , | 3 Comments »

This was an interesting scenario that had me completely confused at first. Audio calls and instant messages to real Lync users were mysteriously being answered by a totally unrelated UCMA application, without ever appearing in the users’ Lync clients, so you would try to call or IM someone and unexpectedly get a generic IVR menu.

After puzzling over this weird behavior for a while, I figured out that there are some interesting side effects you can run into if you use UserEndpoints and a default routing endpoint in the same UCMA application – specifically, within the same collaboration platform.

Let me start by pointing out a few things about the UserEndpoint class. First, regardless of what you are using the UserEndpoint for, when you establish a UserEndpoint with a specific user’s identity, your UCMA application registers with Lync Server as that user. Effectively it “signs in” to Lync Server under that user’s identity, much like a Lync client would. This means that any SIP traffic that would go to that user at a Lync client endpoint (like an audio call invite, or a presence update notification) will also go to the endpoint created by your UCMA application.

It’s common to establish UserEndpoints within a UCMA application for a very specific purpose, like publishing presence or sending an IM on behalf of a user. In cases like this, the UserEndpoint object often doesn’t have event handlers registered for all communication modalities. If there isn’t an event handler registered for a specific communication modality, like audio or instant messaging, the endpoint won’t accept incoming calls with that modality.

In a UCMA application that uses only UserEndpoints, this isn’t such a big deal. Let’s say you have a UserEndpoint set up for John Smith, and John is also signed into a Lync client somewhere. If you call John, Lync Server will “fork” that call to both the Lync client endpoint and the UserEndpoint that belongs to the UCMA application. The UserEndpoint, not having an event handler registered for audio calls, will decline the call, but it will continue to ring to John’s Lync client. No damage done.

If your UCMA application has a default routing endpoint, though, the default routing endpoint will grab the incoming SIP INVITE that the UserEndpoint can’t handle. (That’s why it’s called a “default routing endpoint” – it handles incoming SIP requests that can’t be handled by any other endpoints.) If the default routing endpoint DOES have an event handler for audio calls, it will go ahead and trigger the event handler, and whatever behavior is coded in the event handler will occur. If that code accepts the call, the application will likely have grabbed the call before the Lync client even has a chance to pop up a toast message to the “real” owner of that SIP URI, leading to the bizarre scenario I described at the beginning of this post.

The solution is simple: whenever you establish a UserEndpoint, make a habit of publishing presence information marking all communication modalities that you don’t have event handlers for as unsupported. This is as simple as adding a few lines of code when defining the settings for the UserEndpoint.

First, if you aren’t already doing so, set the AutomaticPresencePublicationEnabled property on UserEndpointSettings to true.

userEndpointSettings.AutomaticPresencePublicationEnabled = true;

Next, explicitly specify the capabilities the endpoint supports using the UserEndpointSettings.Presence.PreferredServiceCapabilities property:

userEndpointSettings.Presence.PreferredServiceCapabilities.AudioSupport = CapabilitySupport.UnSupported;

If you’ve ever seen someone marked in the Lync client with a message saying that the user is signed in on a device that cannot receive instant messages (often a Lync Phone Edition device), that’s another example of this capability support presence information.

By proactively marking your UserEndpoints with the modalities they don’t support, you can prevent your UCMA application from interfering with users’ normal communications through Lync when you use UserEndpoints to perform specific functions like presence publication.


3 Comments on “UCMA application unexpectedly answering user’s calls”

  1. 1 Lync MVP Article Roundup: March 2013 - NextHop - Site Home - TechNet Blogs said at 11:21 am on April 4th, 2013:

    [...] UCMA application unexpectedly answering user’s calls [...]

  2. 2 Madelaine Thor said at 9:31 am on October 25th, 2013:

    A complication that I discovered when setting endpoint capabilities is that it effects setting of presence.

    For example:
    A user A is logged in via a Lync client as well as via an application that has a UserEndpoint to the same Lync Server.
    User A sets “DoNotDisturb” in the Lync client.
    User A then changes presence to “Available” via the UserEndpoint.
    If the UserEndpoint does not have InstantMessagingSupport nor AudioSupport the presence change via the UserEndpoint will not effect these media.
    User A will appear available in the Lync-client as well as to other Lync users. But if another Lync user tries to call User A he/she will receive an error message saying that User A is in state “DoNotDisturb”.
    Maybe there is a way around this, but I have not found one…
    Best regards, Madelaine

  3. 3 Michael said at 1:33 pm on October 29th, 2013:

    That seems like how I’d expect it to work – if you disable IM and audio support then that endpoint won’t allow incoming calls of those media types.

    Is there a specific scenario you’re trying to create by doing this?


Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •