MSPL (and its managed cousin, which goes by various names) is an extremely powerful tool for customizing Lync Server routing behavior. It can also, at times, be extremely frustrating to troubleshoot, partly because of the complexity of tinkering with the way Lync routes messages, and partly because the debugging tools we’re accustomed to for most .NET development are unavailable with MSPL. One of the most common frustrations I hear from people working with MSPL development is that messages that the script should be picking up and handling are just not going through the script at all. They’re visible in SIP logs, they’re obviously there, but your script somehow doesn’t see them. This post is my attempt to summarize a few of the most common reasons this can happen, and what you can do about it. Continue reading “Why is my MSPL application not seeing some messages?” »
MSPL, and its parent SDK, the Lync Server SDK, are some of the most powerful (and complex) tools for modifying Lync Server behavior. I have a number of posts about how to use the Lync Server SDK and what useful things you can do with it. But since my examples always show MSPL scripts being deployed on the Front End Servers, I wanted to briefly talk about what you can do with MSPL on the Edge Servers. Continue reading “MSPL on the Edge Server” »
One of the great things you can do with the Lync Server SDK is reroute calls to a UCMA application. Your MSPL script or managed SIP application can intercept any call that goes through the Front End Server (or any SIP request or response, more generally) and send it to a UCMA application you’ve written, rather than the originally intended recipient. Your application can then handle the request, and proxy it through to the destination, or block it, or do something else entirely. There are more uses for this than I can possibly describe here: recording, call filtering, auto-attendants, compliance, call billing, you name it.
Typically in a case like this the UCMA application has a default routing endpoint so that it will answer all of these calls that have a To SIP URI that doesn’t belong to the application. But what if you don’t want all rerouted calls to go to a single endpoint? What if you need to have a number of endpoints in your application – let’s say one for recording and another for call filtering – and your Lync Server SDK application needs to somehow specify which of the endpoints the rerouted call should go to? Continue reading “Getting rerouted messages to the right UCMA endpoint” »
Every so often I get a question about Response Groups – can you use the APIs to make it do this or that thing differently? Unfortunately, the answer to these questions is usually no; Response Group Services is not very customizable. But there is one feature of Response Groups that can be changed relatively easily using the development platform. By default, calls from Response Groups ignore call forwarding or simultaneous ring settings. If you receive a call from Response Groups, it will not ring your cell phone or any other phone number you have set up the Lync client to forward to. With a simple Lync Server SDK application, you can change this and allow Response Group calls to go to call forwarding numbers. Continue reading “Response Groups and call forwarding” »
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” »
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!