New MSPL function in Lync 2013: RetargetRequest

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.

In previous versions of MSPL, the way to change the destination of a SIP request in order to affect routing behaviour was to use the ProxyRequest method. You could do something like this, for example, to route a SIP message to a specific endpoint:

ProxyRequest("sip:appserver.domain.local@domain.local;gruu;opaque=srvr:interceptor:saLA7P02gZi2Ho78Ix_w2AA");

The trouble with this approach is that it skips all of the other server applications, some of which are actually built in to Lync, like Outbound Routing, which helps determine where outbound PSTN calls get sent, or the Intelligent IM Filter (the thing that filters URLs in instant messages). If you set up your MSPL script to run after these other applications, your script may never get hit at all; but if you set it up to run before, you may mess up features that are provided by these built-in applications or by others that are also installed on the servers.

RetargetRequest avoids this problem by changing the target of the SIP request without cutting short the processing of the message. The other MSPL applications on the server can then also process it and modify it or reroute it as necessary. So if you change the code above to

RetargetRequest("sip:appserver.domain.local@domain.local;gruu;opaque=srvr:interceptor:saLA7P02gZi2Ho78Ix_w2AA");

you can accomplish essentially the same change to the routing, but allow the other server applications to continue functioning normally.

This is definitely a useful addition to the SDK.