UCMA application unexpectedly answering user’s calls

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.