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” »
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” »
Applications built using the Managed SIP Application API can be a bit tricky to troubleshoot. If your managed SIP application fails on startup with an UnauthorizedException or a SecurityException, make sure that the user account that the application is running under is a member of both the RTCComponentUniversalServices domain group and the RTC Server Applications local group (on the Lync Front End Server). If you’re running it as a console application, you’ll need to make sure your own user account is in both groups; if it’s a Windows service, make sure the service is using a domain account that belongs to the two groups. This should eliminate the exception.
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” »