This is one of those “long overdue” posts that inevitably comes back to rear its ugly head from time to time. If you are deploying Lync Server, Skype for Business Server, or Exchange Unified Messaging with Cisco Unified Communications Manager as the IP-PBX, then read on.
So What’s the Fuss?
In the Microsoft UC world, everything is defined as fully qualified domain names (FQDNs), such as server01.corp.domain.com. In a Lync\Skype topology, everything from pools to web services to trusted applications to SQL servers to file shares to…you get it…it’s all defined as an FQDN. Exchange UM is a bit of a two-headed beast in that you really only need FQDN when you have a SIP-based UM dial plan, for the other dial plan types there isn’t a requirement. Where this can wreak havoc is when you tie these two in with CUCM in specific configuration instances that result in SIP 404 Not Found call failures between the Microsoft UC stack and CUCM. Those specific instances are defined below.
Lync\Skype4B
Within Topology Builder, if you define a PSTN gateway with an FQDN and that gateway is a Cisco UCM publisher or subscriber, you may see call failures from Lync\Skype4B to Cisco UCM.
Exchange Online Unified Messaging
Within Exchange Online, you must define an IP Gateway as the FQDN of your Session Border Controller’s external DNS name. For call flows inbound to Office365 you likely will not see issues, but for any REFERs or outbound calls from Office365 to CUCM you will see call failures.
Understanding Root Cause
The larger root cause is the difference in how the Microsoft stack wants FQDN within SIP communications and how Cisco defaults to utilizing IP addresses within SIP communications. When a Microsoft UC component sends a call outbound to CUCM with an FQDN in the SIP headers, it results in Call Manager performing additional checks on the FQDN to be sure that it “owns” the FQDNs and domains being utilized. If Cisco isn’t configured to recognize the FQDNs and domains that may be in use, it ultimately responds with a SIP 404 Not Found.
A sample 404 failure for Exchange Online below:
REFER sip:[email protected]:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 207.46.198.124:5061;branch=z9hG4bKvvkpi32068ohrnv0d6e1sl0000g00.1 FROM: <sip:[email protected]>;tag=abe3165fe3 TO: <sip:XXXXXXXXXXXXXXXX@noam-us-tn-sbcext.widgets.com>;tag=1c1791622239 CSEQ: 1 REFER CALL-ID: [email protected] MAX-FORWARDS: 69 CONTACT: <sip:207.46.198.124:5061;ms-opaque=9a2ce5bced0e440e;transport=tls>;automata;text;audio;video;image CONTENT-LENGTH: 0 EXPIRES: 600 REFER-TO: <sip:81226511@noam-us-tn-sbcext.widgets.com;user=phone;phone-context=dialstring> REFERRED-BY: <sip:[email protected]>;ms-referee-uri="sip:[email protected]" USER-AGENT: RTCC/5.0.0.0 MSExchangeUM/15.00.0918.000 P-ASSERTED-IDENTITY: <sip:[email protected]>
NOTIFY sip:172.18.33.73:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.131.26.115:5060;branch=z9hG4bK4921365f8681 From: <sip:[email protected]>;tag=95235~22aa7d2d-0b7a-48e4-8665-567787f9955d-33592509 To: <sip:[email protected]>;tag=1c1785660217 Call-ID: [email protected] CSeq: 103 NOTIFY Max-Forwards: 70 Date: Tue, 15 Apr 2014 02:09:59 GMT User-Agent: Cisco-CUCM9.1 Event: refer Subscription-State: terminated Contact: <sip:[email protected]:5060;transport=tcp> P-Asserted-Identity: <sip:[email protected]> Content-Type: message/sipfrag;version=2.0 Content-Length: 23 SIP/2.0 404 Not Found
Workaround for Lync/Skype4B
The easiest workaround is to simply utilize IP addresses as the PSTN gateway name instead of using DNS names:
If you have already defined the PSTN gateway as an FQDN and utilized it in Voice Routes, you’ll need to add a new PSTN gateway to topology first. Then update your Voice Routes to add the new PSTN gateway and remove the original PSTN gateway. Then remove the original PSTN gateway from your topology.
Note: Using IP addresses, while easiest, may not be future proof as Microsoft changes and adapts Skype for Business. Additionally, utilizing IP addresses as PSTN gateway names impacts the ability to utilize SIP/TLS and SRTP with approved gateways in certain scenarios because you can’t issue a TLS certificate when the subject name is an IP address. Caveat emptor!
Workaround for Exchange Online
There really is no workaround. Exchange Online uses FQDN through and through and the only way would be to re-write SIP headers using your Session Border Controller so that the SBC sends IP addresses to Cisco whilst leaving FQDN on the call legs to Office365.
Global Workaround
To handle both scenarios without changing any existing Microsoft UC configurations, you can simply update the Cisco UCM configuration and bask gleefully in the fact that you can now use FQDN within SIP messaging.
In Cisco UCM, go to System>Parameters
Find the Clusterwide Domain Configuration section
In Organization Top Level Domain, enter your top level DNS domain – eg, widgets.com
In Cluster Fully Qualified Domain Name, enter your top level DNS domain or use a wildcard to specify your top level DNS domain plus any child domains – eg, *.widgets.com
Save the Changes
Restart Call Manager Cluster Services
Note: Restarting CUCM Cluster Services is production impacting. Be sure to have appropriate change requests and outage windows defined.
Paying It Forward
This information is actually out there on the interwebs already, but it is often difficult to find if you don’t really look for it. Some of the other articles out there that talk about this are below:
https://supportforums.cisco.com/discussion/11646656/sip-trunk-lync
http://voipnorm.blogspot.com/2011/08/using-lync-with-multiple-direct-sip.html
Also note that this may not be the only reason you get a 404 Not Found with Cisco integrations, but it is often a very strong starting point that will likely get you one step closer.