Microsoft Lync and Skype for Business have 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 those APIs.

Advanced BackToBackCall features

Posted: January 27th, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , , , | 4 Comments »

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” »


Protocols used by Lync

Posted: January 24th, 2013 | Author: | Filed under: Lync Development | Tags: , , , , , | No Comments »

Lync uses a number of different protocols to operate, and it can sometimes be confusing keeping track of which one does what. This is a short overview of the protocols in Lync and what they are for. Continue reading “Protocols used by Lync” »


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

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

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

Posted: January 17th, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , | No Comments »

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” »


Removing the plus sign on incoming PSTN calls

Posted: January 11th, 2013 | Author: | Filed under: MSPL | Tags: , , , | 1 Comment »

When calls come in to Lync from the PSTN, Lync normalizes the called phone number by applying the normalization rules from the global dial plan. However, if the number starts with a plus sign (+) when it arrives from the gateway, Lync assumes it is already correctly normalized in E.164 format and skips the normalization step. This means that there’s no way to apply further rules to the called number when it is already formatted with a plus sign by the gateway.

As it often does, the Lync Server SDK comes to the rescue here with a slightly complicated but functional way to remove that plus sign and get Lync to apply the normalization rules to those calls. Continue reading “Removing the plus sign on incoming PSTN calls” »


Sending INFO messages (or other messages) with UCMA

Posted: January 8th, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , , | 2 Comments »

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” »


Third-party manual audio routes: not possible

Posted: January 3rd, 2013 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , | 2 Comments »

A while ago, in a post about how “manual audio routes” work behind the scenes, I mentioned I was planning to see if it was possible to set manual audio routes for endpoints other than the “local” endpoint for the call, by sending INFO messages manually to the audio/video MCU. In other words, can I join a conference from my UCMA application as a trusted participant, and then send manually constructed INFO messages to create a manual audio route between two other participants in the conference? Continue reading “Third-party manual audio routes: not possible” »


Prevent Lync calls from going to voice mail

Posted: December 28th, 2012 | Author: | Filed under: Lync Development, UCMA 3.0, UCMA 4.0 | Tags: , , , , , , , | 1 Comment »

There are some instances where a call that is sent to a Lync user really shouldn’t be going to voice mail, or to the user’s cell phone, or anywhere like that. There’s nothing that screams “good customer service” to an agitated customer like being dropped into John Smith’s cell phone voice mail (“Hi, this is John. Leave a message”) after calling the tech support line. Response Group calls seem to magically ward off UM voice mail and call forwarding, and this has led to some questions: if Response Groups can do it, why can’t we do it in UCMA applications? Actually, you can. Continue reading “Prevent Lync calls from going to voice mail” »


Why so opaque?

Posted: December 21st, 2012 | Author: | Filed under: Lync Development, Uncategorized | Tags: , , , , | No Comments »

If you’ve done much sifting through Lync Server logs, you have probably noticed the SIP URIs that have an extra parameter tacked on the end named opaque. You may have wondered what all of this opaque stuff means, and what purpose it serves. This post will explain the opaque parameter, so that you can interpret it in Lync logs, use it in your applications, and impress your friends at parties (actually, maybe only at Lync user group meetings). Continue reading “Why so opaque?” »


RemotePresenceView and connectivity failures

Posted: December 19th, 2012 | Author: | Filed under: UCMA 3.0, UCMA 4.0 | Tags: , , , | No Comments »

Recently I’ve been doing some investigating on how presence subscriptions from UCMA applications are affected by losses of network connectivity. In some applications, having up to date presence information is critical to the proper functioning of the application, and it is important to be sure that the application can discover and react to interruptions to its notifications of presence updates. Various kinds of network connectivity disruptions can interfere with the delivery of presence notifications: Continue reading “RemotePresenceView and connectivity failures” »