Adding CUCM Subscribers to Lync Topology Builder

I remember the OCS days when the Mediation Server would accept any inbound SIP session thrown at it. Those were the days. Okay, so maybe not really but it brings up an interesting item that I run across recently.

OCS and OCS R2 both had a similar restriction of, for every PSTN gateway you required a Mediation Server. There was a work around to this limitation though for inbound connections which was that the Mediation  Server would accept any inbound SIP connection on the gateway NIC. Although this wasn’t a supported work around I know many that took advantage of this loop hole.

Now why am I talking about this. Well if you where to configure a SIP trunk in Cisco’s Communications Manager to connect to OCS  you really only needed to define one of the CUCM subscribers in OCS as a outbound gateway (putting redundancy aside for a moment). Inbound all the CUCM subscribers that were a part of you CUCM group applied to your Device Pool for the trunk were able to send outbound connections to OCS and they would work. So basically you could kind of get away with only one Mediation Server and have some redundancy but only one way.

Fast forward to Lync 2010. The restriction of the one-to-one relationship of Mediation Server to PSTN Gateway is gone. So now you can have one-to-many but the work around of accepting inbound connections from random gateways is gone. This is a good thing. It greatly increases the security of Lync but at the same time means you must be aware of this when configuring your deployment to work with CUCM deployments.

When you configure CUCM for SIP trunking (direct SIP in Lync terms) you define a SIP trunk, including defining a Device Pool. The Device Pool sets up common resources for the trunk including the Communications Manager Group. The CUCM Group consists of up to three prioritized Communications Manager Servers. This is for failover, device registration etc. When registering devices this all makes sense and the server at the top of the list has all registered devices. SIP trunks on the other hand are a little different and outbound connections round robin between servers in the CUCM group. Basically the prioritization is not used in the case of SIP trunking, at least based on my experience.

Figure 1 : At the moment this device pool below is set at default but in a production configuration where you may have multiple CUCM groups a device pool specifically for you SIP trunk may be required.

For Lync this means that all CUCM servers in the Communications Manger group must be configured in your topology before Lync will accept inbound connections from each of the servers.  Whether you use FQDN or IP addresses really depends on your policies on what to use but all CUCM subscribers have to be added to your topology otherwise un-configured subscribers will be unable to connect inbound. How do you know when you have this issue? Either every other call will fail, or every third call will fail, or two out of three will fail, depending on how many Subscribers you have in your Group. Remember the max CUCM Servers is three. At least when you have this configuration issue your inbound call failure rate is consistent which makes it easy to diagnose. Basically the un-configured CUCM servers will never be able to establish a TCP connection to your Lync Mediation Server. CUCM RTMT tool will never show a SIP trace because the TCP connection never establishes.

Figure 2: Notice the three gateways added below correspond to CUCM subscribers in a group of three. Depending on your deployment this may only have two per CUCM group.

Figure 3:Virtually this is what you are setting up with a three subscriber CUCM group when configuring a SIP trunk to Lync.Although you may be only setting up one trunk all three servers take part in signaling to your Lync environment. Unless all three servers are part of your topology inbound signaling issues will occur.

I know this may sounds like Lync 101 but if you were used to OCS or new to Lync you may not be aware of this behavior.

Comments welcomed.

VoIPNorm