If you want your UCMA application to handle some (but not all) incoming messages at the SIP level, it’s possible to split requests between the “signaling” and “collaboration” layers of UCMA. You can do this by using the InnerEndpoint property on your UserEndpoint or ApplicationEndpoint object. This property gives you access to an instance of RealTimeEndpoint, the alter ego of UserEndpoint or ApplicationEndpoint from the signaling layer. By subscribing to an event on this RealTimeEndpoint object, you can give your application an opportunity to handle calls on the signaling layer. Continue reading “Splitting incoming calls between the signaling and collaboration layers” »
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.
Although the title sounds very philosophical, I’m not going to talk in this post about an inward journey of discovery for your application endpoints. Instead, I want to talk about a way to access some parts of the signaling layer – the lower-level part of UCMA that allows you to work directly with SIP messages – from the collaboration layer, where most UCMA development takes place. Continue reading “Accessing the inner endpoint” »
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” »
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” »
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” »
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” »
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” »
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” »
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” »