Seems like an odd title for my post but I wasn’t quite sure what else to call it. So to break down the issue a little, below is a diagram of the situation. I have a Cisco Unified Communications Manager Subscriber at my main office connecting via direct SIP to my Lync Mediation Server Pool in my main office. I also have another Mediation Server (part of an SBA) in my branch that I want to have direct SIP connect to the same subscriber to have an extra layer of redundancy and also make better use of MTP resources located in my branch.
The issue here is as follows. I can only associate a defined gateway instance to one pool of Mediation Servers in topology builder.
The Lync documentation for supporting multiple gateways does give a clue on how to work around this limitation:
“To solve multiple Mediation Servers interacting with the same gateway peer entity, you need to configure multiple virtual gateways. Each gateway would be associated with a different FQDN, which DNS would resolve to the same IP address.”
That works. So for every instance you need to associate a gateway to a Mediation Server Pool as per our example you just need to use a different FQDN for the gateway. So lets try that.
Below is my SRV record that I configured for my lab. It is cucm.home.local that resolves to CUCMHome.home.local which is my CUCM VM Server running CUCM 7.0. Great.
After configuring my new gateway in topology builder I then configure my new gateway in Lync as shown below.
Update to my route:
Okay. That was easy but my first calls fail. Why?
In order for a CUCM subscriber server to accept a SIP URI with a destination of @cucm.home.local rather than @<servername>.home.local each parent DNS SRV records must be added to the Cluster FQDN list in Enterprise Parameters. If this step is not completed, expect to see SIP 404 Not Found errors. (Thanks to Ben’s thought’s blog)
In my case I cheated a little and used a wild card (*.home.local). This will help make administration and scalability a little easier if you have multiple sites and require a number of FQDN for each site that you want pointed at the same CUCM Subscriber. Below is a close up of the parameter.
Lastly I did restart my CUCM VM but I am not totally sure if this is required to have the change picked up across you CUCM cluster. It maybe a case of only having to restart certain services to have the change stick but I was a little lazy and it was only a lab.
This was an interesting issue that I have seen asked on my blog as well as some of team I work with, so I am happy this has an easy solution.