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.
Trunk configuration:
![clip_image001[4]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8CdS70QkNh99C8ohcZf_STL_N0hccUW1qXU4_butYQ8pe1XLWHy343pXUbiA8947X7tawgRsrhPnRovYneBUd2n-8QEs_pt2uHhHyw2apK0iEonsGtFZZ5FjQmjx8YDyjd-vAofV9BRXp/s1600-h/clip_image001%5B4%5D%5B4%5D.png "clip_image001[4]")
Update to my route:
![clip_image001[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4wBU-RY0-b6Bfcacs-1-APjn4mwNcPIZBUam81KypUEtDvkgmEVmogeia0mgS7kAfPhg08ztRquklEyh-4puXPw7wpFwRXzPX84uegJaNVjxR0dSp8blOrcnjGYDu6OZvG6o5h0zdGI9_/s1600-h/clip_image001%5B6%5D%5B4%5D.png "clip_image001[6]")
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.
![clip_image001[11]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgi9mREkHRIS8O10mt77eQibjuKD_dF_xmiidRqHSqEIkzhNiHIc7E6o2bp_tTh_4hEJwBdvM38FNu3NmJZEO0Pm21uXEcp8hxt2ti-unlWF0r7MZuF8MCjraSiCxYhokg_N0g6kAr7K2_Q/s1600-h/clip_image001%5B11%5D%5B3%5D.png "clip_image001[11]"){kind=small}
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.
Comments welcomed.
VoIPNorm
In our environment the field that you have highlighted is empty. And all communication within Cisco OR OCS to Cisco happens on IP address.
ReplyDeleteIf we populate this field with domain name, does it break anything in Cisco or OCS to Cisco world as all the communication happens through IP address?
In your lab, did you have this field already populated before you started working on this issue?
The only effect is allowing SIP URI addresses in the to header that are not based on the server name or IP address.
ReplyDeleteI didnt have anything populated in this area before I entered the info above.
So you should be safe.
Thanks for your post and comments.
ReplyDeleteChris,
ReplyDeleteThis might not be the right question on this post, but its related.
I have read your blogs on Media bypass and read few technet articles related to it.
In my lab, I do have two sites HQ and BR. Both enabled for Media bypass. Media bypass is enabled for Regions and sites and Bandwith Policy is applied so that both sites gets different bypass id.
Subnet are associated to sites. So CUCM subnet, Client subnet at HQ and Server subnet at HQ is associated to HQ site and Client subnet at Br and SBS subnet at Br is associated with Br site.
CUCM Subcriber is the next hop for both this sites and MTP's are configured locally so that it can use local gateway and local resources.
I am noticing two issues in my wiresharks.
When HQ Client makes a call, media bypass works as expected coz HQ Client and HQ gateway is at same site. Expected result
However when Br client makes a call, even though media bypass is enabled it won't work. Which I probably believe is because next hop is CUCM Subscriber and CUCM subsciber in signalling is letting SBS know to talk to local gateway and hence Media bypass is failing at Br coz next hop is CUCM Sub.
Other test I ran was, I login as Br user on HQ subnet and this time media bypass worked (not expected result) but since next hop is CUCM and now on same subnet as Client it's making G 711 call across wan because of local gateway and local MTP's at Br.
confusing?????
Any feedback would be appreciated
It may be because your MTP is the next hop for media and not your subscriber. If you think about the intention of how media bypass is supposed to work is the gateway is the terminiation of your signaling and your media. But in your case you have the media going to your MTP and the signaling going to CUCM. ALthough I havent tested this you may want to try entering the alternate media ip address for the subscriber in topology builder and also ensuring that the MTP and gateway specific subnets are entered in your sites and subnet information. No supernetting as this doesnt sit well with Media Bypass. Be sure if a gateway subnet is /28 or something simlar thats what you enter for the subnet.
ReplyDeleteIf you think back to the inner workings of media bypass when a user makes a call to the PSTN, the Mediation Server compares the bypass ID of the client subnet with the bypass ID of the gateway subnet. So having the alternate media IP address will hopefully address this issue becuase now it knows the signaling and media are not the same.
Hopefully this will help.
I forgot to mention that I have specified local gateway subnet in sites and subnet. However I will try Alternate media IP address and see if that helps.
ReplyDeleteThanks
I think Aamer might have some more information he can share with you about this as well. But for now try the alternate IP address.
ReplyDeleteOk Alternate Media IP address helped. So CUCM Sub is the next hop with Alternate IP as local gateway in Topo. With this config media bypass results are now as expected.
ReplyDeleteThanks for your help.
No problem. Glad I can help out.
ReplyDeleteCheers
Chris
Norm, are you using a dedicated Mediation Server Pool or media bypass with co-located FE's with SIP trunk to CUCM. Planning a design now with this in mind.
ReplyDeleteThanks
Chris,
ReplyDeleteI am facing Inbound calling issue with my Cisco ASA. I am using dedicated Mediation server two Network cards. One facing Internal Network without Gateway & other facing my DMZ network with gateway.
I have added required routes on mediation server for Internal network traffic.
I do not have any issue with Outbound calling but inbound calling fails intermediately.
Do you have suggestion on the same.
Thanks in advance.
Hi Santosh, Have you run any logging on the mediation server?
Deletehttp://technet.microsoft.com/en-us/library/gg558599.aspx
Then use the Snooper tool to see what the SIP traffic is having issues with.
http://blogs.technet.com/b/drrez/archive/2011/01/17/microsoft-lync-server-2010-resource-kit-tool-snooper.aspx
This should help narrow down the issue. With out logs I would only be guessing.
Cheers
Chris
HI Chris,
ReplyDeleteI have run the log trace on Lync for SIPStack traffic but no luck, as its not showing any inbound calling traffic.
Is public IP required for the mediation server network interface which is facing to the Direct SIP trunk? e.g. CircuitID
Currently I am using static NAT, but inbound calling stops working after some time & start again. NO issues with outbound calling.
Thanks.
I am looking at a similar situation where I could in a failover scenario have a gateway in site B service mediation pools in both site A and site B. The idea of defining additional virtual gateways with the FQDN pointing to the same gateway IP presents a problem with the gateway presenting the correct certificate to the mediation pool. A lot of the gateways don't handle SAN certificates or multiple certificates very well.
ReplyDeleteOf course the secondary/virtual gateway could be using TCP only and just be defined by the IP address. I will sometimes nail up both type of trunks (looks like two gateways to Lync) to the same gateway just for troubleshooting purposes.