Background
I was recently working on an engagement where the customer was migrating from Exchange 2010 to Office 365 Exchange Online. The customer had been a long time Enterprise Voice customer (OCS, Lync 2010, and now Lync 2013). As the customer grew over the years, so had their Lync environment. The customer originally deployed OCS 2007 R2 for only internal use. The default SIP domain was based off their internal Active Directory namespace (corpnet.domain.com). When Lync 2010 was introduced, the publicly routable SIP domain was added to the Lync topology (domain.com) to clean things up and match their SMTP addresses. Fast forward to 2015, the customer is migrating to Office 365 Exchange Online, which means voicemail and auto attendants were also being migrated to Exchange Online Unified Messaging.
Note, this article will not walk through the actual steps necessary to configure Lync/Skype for Business with Exchange Online Unified Messaging. If you need guidance in this area, refer to this article.
Issue Overview
The issue encountered was internal Lync calls to Exchange Online Unified Messaging (voicemail, auto attendants, etc.) would complete successfully, but any call made from a PSTN caller to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) would fail. After reviewing traces of the call, it appeared that the default SIP domain was appended to the From/To fields in the SIP INVITE. It makes sense why a SIP domain would get appended to these types of calls (so Office 365 knows where to route traffic). The problem is, an administrator cannot control which SIP domain is appended in the INVITE. From my testing, the default SIP domain will always be the domain appended to the PSTNGateway FQDNs when egressing out to Office 365.
From the traces below, you can see that the cause of the failed calls was a result of Office 365 not being able to do a DNS SRV lookup for _sipfederationtls._tcp.corpnet.domain.com as the ms-diagnostics response from Office 365 mentions “Unable to resolve DNS SRV record.”
|
TL_INFO(TF_PROTOCOL) [0]1310.39E4::07/15/2015-21:38:44.259.007bfc6d (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[14230030] $$begin_record |
Here is where the problem took a turn for the worse…
- The customer did not have a public DNS subdomain for corpnet.domain.com. When asked if it was possible to add a public subdomain for corpnet, the admin quickly informed me that they had tried to get the subdomain created in the past, but the public DNS provider could not support the request.
- Out of curiosity, I attempted to change the PSTNGateway from an FQDN (gateway.corpnet.domain.com) to an IP address (192.168.123.10 in this example).
- Unfortunately, the default SIP domain was still added to the FROM/TO fields of the SIP INVITE. It was worth a shot, but not surprised by the result.
- I attempted to create a new PSTN Gateway in the Lync topology with 192.168.123.10@domain.com, but the topology does not allow the SIP domain name to be specified.
- It was worth a shot, but again, not surprised by the result.
After attempting the three scenarios above, we determined that the only option was to change the default SIP domain.
Changing the Default SIP Domain
Since the public SIP domain was added during the Lync 2010 upgrade, changing the default SIP domain was not as painful as it could have been. The certificate SAN entries were correct on all the servers (Front Ends, Edges, SBAs, etc.), users already were using the public SIP domain for their SIP addresses, etc.. All we had to do was to execute the set-cssipdomain command to change corpnet.domain.com from the default SIP domain to domain.com. The figure below is the output of both the get-cssipdomain and set-cssipdomain commands.
Repercussions from Changing the Default SIP Domain
If you read the set-cssipdomain TechNet article carefully, the article mentions “If you change the default SIP domain you will need to restart the RTCCAA and RTCCAS services.” This statement matches the yellow warnings that appeared after executing the set-cssipdomain command above. Great, things are moving right along… Oh no, hold on a minute…
Mediation Services
After waiting for the default SIP domain change to replicate, I started to review the Lync event logs on the Front Ends. There was one warning, one error, and three informational messages that caught my attention. The informational messages were expected and looked great. What caught me by surprise was the warning and error message. From the event logs below, it appeared the Mediation service(s) also had to be restarted as part of the default SIP domain change.
|
Log Name: Lync Server |
|
Log Name: Lync Server |
|
Log Name: Lync Server |
|
Log Name: Lync Server |
|
Log Name: Lync Server |
Exchange UM Auto Attendant Transfers
After the Mediation services were restarted, we proceeded with inbound and outbound PSTN testing. Calls made from the PSTN to Exchange Online Unified Messaging (subscriber access, auto attendants, voicemail) were now working correctly (yeah!).
We were preparing to migrate the auto attendants to the cloud, but with any Office 365 migration, the existing Exchange environment needs to support the workloads (Unified Messaging, etc.) until they are officially migrated to Office 365. After further testing, we discovered that the existing on-premises Exchange 2010 auto attendants were unable to complete their transfer requests to Lync. After reviewing snooper traces, it appeared the on-premises Exchange 2010 UM services processed the transfer request correctly. The SIP INVITE would get routed to Lync, but Lync would then attempt to route the request out the Lync Edge infrastructure. As you can see in the screenshots below, the operator transfer request was supposed to be routed to extension 7008 which was a Lync Response Group. After the default SIP domain change, we started receiving a “404 Not Found.”
Prior to the default SIP domain change, the format for the Exchange contacts were autoattendant.corpnet.domain.com@corpnet.domain.com. Using the OCSUMUtil utility, we left the Exchange contact FQDNs the same, but decided to update the SIP domain for the Exchange contacts to match the new default SIP domain. The modified format matched autoattendant.corpnet.domain.com@domain.com. After modifying the SIP domain for the Exchange Contacts, our transfers started to work again. As you can see in the screenshots below, the same INVITE came into Lync from the on-premises Exchange 2010 UM server, but this time Lync was able to perform a reverse number look up and locate the correct operator Response Group.
Summary
There are many items and tasks to consider when migrating from an on-premises environment to Office 365. Perficient has performed numerous Office 365 migrations where the default SIP domain was never an issue. Hopefully you never run into this issue or if you do, you have more flexibility with your public DNS provider. If you find yourself heading down the same path as this article, remember to:
- Restart the Conferencing Announcement service(s)
- Restart the Conferencing Attendant service(s)
- Restart the Mediation Service service(s)
- Update the SIP domain for all Exchange Contacts to match the new default SIP domain to support the on-premises Exchange Unified Messaging subscriber access and auto attendants during the transition to Office 365
Comments Welcomed.
