When handling Lync Server activity at a SIP level, it is often important to identify re-INVITE messages and ignore them or handle them differently. I recently found out about a better way of reliably identifying re-INVITEs than the ones I’ve recommended in the past, and wanted to share it here. Continue reading “Identifying re-INVITEs” »
Lync endpoints, including UCMA applications, are capable of communicating directly with non-Lync SIP endpoints under certain circumstances, without going through the Mediation Server. This can be advantageous for a few reasons. For one, the Mediation Server removes non-standard SIP headers when passing along messages, so any information you try to include in custom SIP headers when connecting to an endpoint through the Mediation Server will be lost. Also, you may need to communicate with other internal SIP systems — a voice mail system, for example — in an environment where the Mediation Server is not in use. Continue reading “Multi-part SDP and non-Lync endpoints” »
In getting your Lync Server 2010 applications working and tested against Lync Server 2013, you might occasionally be tempted to cut corners. You might look for ways to avoid supporting multiple code bases, one for Lync Server 2010 and another for Lync Server 2013. Specifically, it might occur to you that, since the Lync Server SDK has barely changed at all from the 2010 to the 2013 version, maybe you can just run the existing version of your Lync Server SDK application, compiled against the 2010 version of the ServerAgent DLL, on Lync Server 2013 Front End Servers. After all, UCMA 3.0 applications can register against Lync Server 2013 Front End Servers, and there are only a handful of additions to the SDK in 2013, which you may not even need anyway. It’s worth a try, right? Continue reading “Lync Server SDK, 2010 vs. 2013” »
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” »
Microsoft SIP Processing Language (or MSPL), a part of the Lync Server SDK, is a fantastic and currently underused tool for overriding or extending Lync routing behaviour to meet business needs. I’ve written about some of its capabilities and how to use it in previous blog posts. It’s handy for things like intercepting and blocking calls with certain characteristics, filtering messages, logging or monitoring communications, or rerouting calls to different destinations. It’s also probably the Lync API that has remained the most unchanged from version to version. In Lync 2013, it’s managed to hang on to this distinction, with only a couple of additions, but one of them is really quite interesting and potentially useful, and I wanted to bring it to everyone’s attention here. The new RetargetRequest method allows you to have an MSPL script change the destination a message is going to, but without bypassing the rest of the scripts that are installed on the Lync server. Continue reading “New MSPL function in Lync 2013: RetargetRequest” »
Recently I was answering a question about filtering instant messages between Lync users, and I decided that this would make a good topic for a post. It’s a fairly common use case, and one that is not too easy to implement because it requires the arcane and mysterious Lync Server SDK, which is written in hieroglyphics and can only be used by the light of a full moon.
Okay, that last part isn’t true, but it is true that the Lync Server SDK is one of the least well-known and most challenging APIs in the Lync development platform. It consists of two components, the Microsoft SIP Processing Language, a.k.a. MSPL, and the Managed SIP Application API. The latter of these is the one we’ll need to use to filter instant messages. Continue reading “Filtering instant messages with the Lync Server SDK” »
The Managed SIP Application API, which I discussed in the previous post, allows you to manipulate the content and routing of SIP messages in some potentially very useful ways by running an application on a Front End Server. However, when the volume of messages is very large, dispatching them to managed code can have a significant effect on performance. For managed code applications that simply monitor messages, and don’t modify them or change the routing, there is a way to mitigate this performance impact by sending the message details to the application from the MSPL script in a sort of “fire-and-forget” mode, using the DispatchNotification method. Continue reading “Minimizing performance impact from managed SIP applications” »
The Lync Server SDK includes an API, the Managed SIP Application API, which is essentially a more powerful and complex managed-code cousin of MSPL (Microsoft SIP Processing Language). It allows you to create applications that, much like MSPL scripts, reside on a Front End Server or one of the other Lync servers (Edge, Mediation, etc.). Unlike MSPL, however, these are created using managed code. The classes that make up the API, which are contained in the Microsoft.Rtc.Sip namespace, allow you to modify SIP messages and control message routing in a number of ways that are not possible with MSPL. Continue reading “Modifying SIP headers using the Managed SIP Application API” »