Presence updates and multiple application pools

In Lync development, as in many other areas of life, things get much more complicated when you have more than one application pool. You need to start thinking about scenarios that previously weren’t possible. One important case your application needs to account for if it may be deployed across more than one pool of servers is receiving presence updates from different pools of Front End servers. You can often get away with ignoring this effect, but you risk running into strange and seemingly inexplicable behaviour once in a while. This post explains the issue and what you can do about it. Continue reading “Presence updates and multiple application pools” »

Watching for conference recording in UCMA

In the Lync client, if you are participating in a conference and someone starts recording, you get notified: a red dot appears near the bottom of the window, and a message pops up letting you know that recording has started. How do you get the same kind of notification in a UCMA application?

Continue reading “Watching for conference recording in UCMA” »

Locating other application servers in a UCMA application

This post explains how you can access the Lync Server topology from within your UCMA application to find instances of other applications in the environment. In more complex UCMA applications that have multiple components spread across different servers, this is sometimes necessary in order for the various components to coordinate handling of calls, users, conferences, or other resources. By going directly to the topology, you avoid having to stick this information in a database table or configuration file where it can easily get out of date.

Continue reading “Locating other application servers in a UCMA application” »

Integrating with third-party SIP endpoints using static routes

One of the topics I get the most questions about is how to get UCMA applications to communicate with non-Lync SIP endpoints. Sometimes these UCMA applications are standalone, meaning they don’t register with Lync Server at all and answer calls directly from a SIP trunk, IP-PBX, or some other system. In other cases, UCMA applications that work with Lync Server also need to communicate with third-party SIP endpoints at the same time, possibly to bridge calls between Lync and another system or integrate Lync calls with functionality provided by another SIP-based platform. Continue reading “Integrating with third-party SIP endpoints using static routes” »

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. Continue reading “UCMA application unexpectedly answering user’s calls” »

Conference deactivation and UCMA trusted participants

UCMA allows you to join a Lync conference as a so-called “trusted participant,” which has several interesting effects. First, it hides the participant in the conference roster, so that participants can’t see that your application is joined to the conference. Second, it allows your application to perform a variety of privileged operations like changing how audio is routed within the conference. If your application keeps conferences around for a while with trusted participants connected, you may run into a situation where conferences get unexpectedly deactivated by Lync Server. This can lead to confusing state changes, or even cause external participants like PSTN callers to be ejected. Continue reading “Conference deactivation and UCMA trusted participants” »

Advanced BackToBackCall features

The BackToBackCall class is staple of more complex UCMA applications, especially those that perform some kind of third-party call control (brokering or providing services to calls between other users). In a nutshell, the BackToBackCall class allows a UCMA-controlled endpoint to keep a handle to a call that is going on between two other endpoints, rather than between a single remote endpoint and the UCMA application. But there are several features of the BackToBackCall class that you may not be aware of, that can be helpful in certain situations. Continue reading “Advanced BackToBackCall features” »

How to tell if a call is put on hold in UCMA

If your application handles audio calls with users, you may need to be notified when one of those users places the call on hold. It’s relatively easy to get these notifications in UCMA, but it can be a bit counterintuitive, because there is no event anywhere called HoldStateChanged or anything like that. Continue reading “How to tell if a call is put on hold in UCMA” »

How UCMA handles incoming messages

Based on some recent experiences, I wanted to write up a quick summary of how the UCMA runtime handles incoming SIP messages, which is somewhat different from how it works with the Lync client.  Continue reading “How UCMA handles incoming messages” »

Sending INFO messages (or other messages) with UCMA

This is one of those random things in UCMA that you almost never have to use under normal circumstances, but in that one very unusual case where you do have to use it, it can be very frustrating trying to figure out how it works in the API. Continue reading “Sending INFO messages (or other messages) with UCMA” »