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” »
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” »
Some things are much easier to understand when you can see them in action. To add to my post on setting up MSPL scripts, I recorded a 12-minute video that shows the step-by-step process for installing an MSPL script on a Lync Front End Server and checking that it has started up properly. Let me know if this is a helpful format or if you have any questions or suggestions!
In previous blog posts on Microsoft SIP Processing Language (MSPL), I’ve explained how to essentially intercept SIP requests, such as the INVITE message that initiates a call, and pass them along to a UCMA application for handling by passing a parameter to the ProxyRequest method. In this post, I want to discuss what you can do if you want to “fork” a request, which means you are sending it to multiple endpoints simultaneously. Continue reading “Forking SIP requests in an MSPL script” »
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” »
Microsoft SIP Processing Language, a.k.a. MSPL, can be handy for changing Lync’s routing behavior, to do things like block or reroute calls based on their origin, or send all calls of a certain type to a UCMA application. In certain cases, when writing MSPL scripts, you may want your script to behave differently depending on whether it is dealing with an audio call or an instant messaging session. It’s not immediately obvious how to distinguish between these two types of calls in MSPL, so I wanted to write up a quick description of how you can do this. Continue reading “Distinguishing IM vs. audio calls in MSPL” »
One of the most useful (and most confusing) things you can do with Microsoft SIP Processing Language (MSPL) is change the routing behaviour of Lync Server. There are a variety of reasons why you might want to do this, but in this post I want to discuss a specific case: rerouting calls to a UCMA application. Continue reading “Rerouting requests to a UCMA application with MSPL” »
UCMA 3.0 introduced the concept of a “default routing endpoint.” To put it very generally, a default routing endpoint is a single application endpoint that receives any messages that have nowhere else to go. I’ll illustrate further in a moment. When I first heard about this new feature, I could not understand what use it could possibly have. Gradually, over a period of months, situations came up where default routing endpoints turned out to be very handy. Since I figure that other folks might have the same initial reaction of complete confusion when hearing about the default routing endpoint feature, I thought I would write up a bit of explanation on this odd but useful creature in the hope that it will help in others’ development efforts. Continue reading “Default routing endpoints in UCMA” »