Lync 2013 SIP trunk with a twist

Scenario

Maybe like me, you have a split environment with an Lync 2013 EE pool, with a Lync 2013 SE, and you want to get a SIP trunk installed so that you can play with pilot Dial in Conferencing and maybe some light Enterprise Voice?  The guidance on direct SIP trunks is to stand up a separate Lync 2013 Mediation Server.  You can read up on that right here.  The mediation server “strong recommendation” is here.   Be that as it may, you might decide that it would be a more efficient usage of resources, especially for a pilot, to use the Lync 2013 SE as your mediation server.  And using a internet-based SIP trunk provider will get you the most bang for the buck albeit at the expense (maybe) of reliability.  I personally have had great results using internet-based SIP trunks, YMMV.

After reading up a bit, you realize that you are going to need a non-routable IP added to the Lync 2013 SE to make things work.  Why would you need that?  In my case, the internal subnetting and security was such that the SE needed another subnet to work with – security would not allow an unsecure connection ( a SIP Trunk straight to a production network server with no SBC on-premises).

How to

As luck would have it, Intelepeer – for a wide variety of reasons, my first choice for net new SIP trunks in an environment – was willing to work on a semi-custom plan to get our pilot up and running.  SIP trunks in Lync 2013 did not change much since Lync 2010, so we can use this guide from MVP Brian Ricks to get the basics accomplished.  Another MVP, Curtis Johnstone, has another SIP trunk article that is well worth reading.

Before you start though, what about that need for a mediation server?  In our scenario, we need to arrange for another NIC/IP on that SE so the mediation server can have a separate subnet.

This blog entry from Norway will walk you through what to do for the second NIC/IP needed. The sharp-eyed reader will note that the NIC setup looks like an external interface for a Lync Edge server.  Moving forward, you will need make up some firewall rules to get the requisite SIP call setup (TCP) and media flow (UDP) between your new mediation server NIC and the service up in SIP trunk land.  Depending on the firewall, you may want to double check to make sure that the NAT you setup is taking your mediation server traffic and sending it out the correct address.

While you may not have an SBC on-premises, you can be assured that the SIP trunk provider is going to have one, and that SBC will not communicate with an IP that is doesn’t have defined in the trunk setup.  I strongly recommend creating a group in your firewall, and restricting your SIP trunk traffic (that leaves your firewall) to only communicate with the provider.  1:1 NAT may not be possible on your firewall (why I cannot imagine, but there you go) so that is something you may want to consider before getting started.

Here is what we need:

The Results

Right out of the box, setup using the given guidance, outbound calls work, but would never disconnect if/when the called party hung up.  Inbound calls just failed. Turns out that there were two things, one Lync and one Intelepeer.

Lync

Based on this bit of Lync 2013 documentation, the “Centralized media processing” needs clearing.  In our case, Intelepeer is using TCP on one IP and UDP on two others.  Hence, clear the box.  In this case, we were also doing no encryption and Intelepeer basically told me that support for “Refer” ain’t there yet.

Intelepeer

On the Intelepeer side, their SBC was looking into the packets, finding the IP of the outside of SE/Mediation server (10.10.10.62) and trying to send SIP signaling traffic to that IP.  Obviously, that would not work.  At any rate, the Intelepeer engineer (a most helpful fellow) twiddled some bit on his end, and wala! Instant telephony in and out.  Fabulous.

Conclusions

If you need a path through a network maze, you can come up with one.  In this case, we needed to allow for the Security Mavens to have their (understandable in this case) way, and still be able to provide Lync with a SIP trunk to pilot Dial-in Conferencing and EV.  Total time that involved actual network and Lync hands-on touching?  Maybe two hours total over several weeks.

YMMV