Microsoft Lync has a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use them.

Lync Server SDK, 2010 vs. 2013

Posted: May 3rd, 2013 | Author: | Filed under: MSPL | Tags: , , | 3 Comments »

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?

Having tested this myself recently, I can tell you that it is definitely NOT worth a try, and I strongly suggest using the Lync Server 2010 SDK only with 2010 Front End Servers and the Lync Server 2013 SDK only with 2013 Front End Servers. Even though the functionality in the SDK has changed very little between versions, you have to keep in mind that the architecture of the Front End Server itself changed quite significantly in Lync Server 2013, with state information being stored differently, and different relationships between users and Front Ends, among other things. I suspect that this is why, even though the API seems to be mostly the same on the surface, it is not as backwards compatible as the few changes might lead you to believe. In my experience, not only does using the SDK with a different version of Lync Server lead to problems, but it leads to the kind of sneaky, difficult to troubleshoot problems and erratic behaviour that is every Lync developer’s nightmare.

See, if you run a managed SIP application compiled with the 2010 DLLs on a 2013 Front End Server, the application will likely start up just fine, and successfully establish communication with the registrar service. You may not suspect that anything is amiss until you run into trouble later.

In one instance I saw, the application then received dispatched requests, and the appropriate method in the managed code was executed, but the Request property in the event arguments was empty, so the application had no access to the request that had been dispatched. There was no exception or any other indication of why this was happening, but switching to the 2013 version of the ServerAgent DLL fixed the problem.

In another case, certain functions in the MSPL script loaded by the managed SIP application mysteriously caused stack overflows. Again, switching to the newer version of ServerAgent.dll cured the problem.

I haven’t yet tested going in the other direction (using the Lync Server 2013 SDK with 2010 Front End Servers), but given my experiences so far and knowing how the Front End Server role has changed between versions, I wouldn’t recommend trying it unless it’s out of sheer curiosity. It seems the best approach is to have two separate versions of your application, one using the 2010 version of the SDK and another using the 2013 version. Most likely you won’t need to make any code changes, just substitute one referenced DLL for the other.


3 Comments on “Lync Server SDK, 2010 vs. 2013”

  1. 1 Aaron said at 1:52 am on August 27th, 2013:

    Hi Michael,

    Using the Managed SIP API to modify and manipulate the SIP/SDP content, do you know if there is a way to “coerce” internal client to intenal client Lync calls to use the Edge server for media communications (instead of direct host to host communication)?

    Thanks,
    Aaron

  2. 2 Michael said at 9:07 am on August 27th, 2013:

    Hi Aaron – not that I know of. That would require more than just SDP manipulation, since you’d have to get the Edge Server to accept and proxy the media from the two endpoints.

  3. 3 Chris Tart said at 10:53 am on August 28th, 2013:

    First I’m curious why someone would want to do that. If host to host fails, it should fall back to the edge anyway. Additionally making ALL calls go through the edge may strain the edge servers, so you would need to size them appropriately.

    In theory, removing the host entries from the SDP should achieve this.

    a=candidate:1 1 UDP 2130706431 10.210.11.200 5386 typ host
    a=candidate:1 2 UDP 2130705918 10.210.11.200 5387 typ host

    I’ve never tested this, so its possible the client will not like it, but if the client receives an SDP with only relay candidates, it should proceed to just attempt a connection via the edge.


Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •