Integrating with third-party SIP endpoints using static routes

One of the topics I get the most questions about is how to get UCMA applications to communicate with non-Lync SIP endpoints. Sometimes these UCMA applications are standalone, meaning they don’t register with Lync Server at all and answer calls directly from a SIP trunk, IP-PBX, or some other system. In other cases, UCMA applications that work with Lync Server also need to communicate with third-party SIP endpoints at the same time, possibly to bridge calls between Lync and another system or integrate Lync calls with functionality provided by another SIP-based platform.

To allow a UCMA application to receive (non-encrypted) calls from third-party endpoints is relatively easy, and just requires setting up a default routing endpoint in your application. Outbound calls can be a bit trickier. I’ve written before about placing outbound calls to non-Lync endpoints using the ConnectionContext class. There are a couple of disadvantages to this approach, however, when your application DOES need to register with Lync Server. First, the resulting calls don’t go through a Lync Front End Server at all. For standalone UCMA applications, this is a good thing, but if your application is registered with a Front End Server, it means that any Lync Server SDK applications running on the Front End Server can’t modify the messages, and other functionality that is based on the Front End Server, such as CDR records, won’t work for the call. Second, if your application registers with Lync Server using TLS, you can’t easily place an outbound call using TCP simply by changing the ConnectionContext properties.

There is an alternative way to route outbound calls from your UCMA application to third-party endpoints which avoids these two disadvantages. This approach uses static routes in your Lync topology, which you can set up with Lync Management Shell commands. These static routes essentially tell the Front End Servers that requests for a specific SIP URI, SIP domain, or SIP URIs that fit a certain pattern should be sent directly to a specific IP and port without Lync Server trying to match them to a registered Lync endpoint.

I won’t explain all of the details of creating static routes here, because Mike Stacy already has an excellent blog post on the subject. What I want to do is connect the dots on how you can use these static routes with UCMA applications. Once you have a static route in place, your UCMA application can establish a call to a SIP URI that matches that static route, and Lync Server will route the call directly to the specified IP and port, no questions asked.

Keep in mind that just getting the messages to the third-party endpoint won’t necessarily solve all of your problems. You need to make sure that the receiving endpoint supports SIP over TCP (Lync doesn’t support SIP over UDP, which is more common) as well as a codec such as G.711 that Lync endpoints support. Finally, you may run into issues with the multipart SDP generated by Lync.