How The Default SIP Domain Impacts Exchange Online UM Connections - Perficient Blogs
Blog
  • Topics
  • Industries
  • Partners

Explore

Topics

Industries

Partners

How The Default SIP Domain Impacts Exchange Online UM Connections

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.”
image
image
image

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
Trace-Correlation-Id: 14230030
Instance-Id: 23DE984
Direction: incoming;source=”external edge”;destination=”internal edge”
Peer: exap.um.outlook.com:5061
Message-Type: response
Start-Line: SIP/2.0 504 Server time-out
From: <sip:xxxxxx3393;phone-context=PstnGateway_192.168.123.10@corpnet.domain.com;user=phone>;epid=D265383BDB;tag=8b389ba8eb
To: <sip:xxxxxx3521;phone-context=PstnGateway_192.168.123.10@corpnet.domain.com;user=phone>;tag=CDE1B0FAC62DC72928E90F5E8798E5D6
Call-ID: a162a2b6-2ce9-48ef-bf06-95424312dda3
CSeq: 6210 INVITE
Via: SIP/2.0/TLS 192.168.101.4:60657;branch=z9hG4bK492FF334.D6ADCD45DE09F913;branched=FALSE;ms-internal-info=”dsJgEGhK4D6vMZBWcKD9kGxA7pk1_EvyPw3a8sGe5c_kZFza3WcHCiNQAA”;received=207.46.5.9;ms-received-port=60657;ms-received-cid=6EED1A00
Via: SIP/2.0/TLS 10.0.0.66:57039;branch=z9hG4bKCE1C0FE6.5623B9D1F1CF7914;branched=TRUE;ms-received-port=57039;ms-received-cid=15893400
Via: SIP/2.0/TLS 192.168.123.11:56153;branch=z9hG4bKAE31EAAD.3C44495B35470915;branched=FALSE;ms-received-port=56153;ms-received-cid=12CD4100
Via: SIP/2.0/TLS 192.168.123.82:51202;branch=z9hG4bK272344cd;ms-received-port=51202;ms-received-cid=22F00
Content-Length: 0
ms-diagnostics: 1008;reason=””Unable to resolve DNS SRV record””
ms-split-domain-info: ms-traffic-type=SplitIntra
$$end_record

 
image
Here is where the problem took a turn for the worse…

  1. 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.
  2. 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.
  3. 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.
image

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.
clip_image012

Log Name: Lync Server
Source: LS Mediation Server
Date: 7/24/2015 6:02:21 PM
Event ID: 25031
Task Category: (1030)
Level: Warning
Keywords: Classic
User: N/A
Computer: GCR-LYNCSTDOBT.corpnet.domain.com
Description:
Mediation Server does not support changing these settings dynamically. The settings were ignored.
Setting Name: Mediation Server
Property Description: Gruu
Current Value: sip:gcr-lyncstdobt.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:MediationServer:NMa8UNqYEVyM7vqmWbCR7QAA
Ignored Value: sip:gcr-lyncstdobt.corpnet.domain.com@domain.com;gruu;opaque=srvr:MediationServer:NMa8UNqYEVyM7vqmWbCR7QAA
Cause: Changing certain settings dynamically is not supported.
Resolution:
Restart Mediation Server if you want the changes to take effect

 

Log Name: Lync Server
Source: LS Mediation Server
Date: 7/24/2015 6:02:21 PM
Event ID: 25057
Task Category: (1030)
Level: Error
Keywords: Classic
User: N/A
Computer: GCR-LYNCSTDOBT.corpnet.domain.com
Description:
The Mediation Server service has encountered a major problem with its configurations.
Cause: Check the following MOM alerts for more details. MEDIATIONSERVER_E_SETTING_INVALID_VALUE (Event ID: 25008), MEDIATIONSERVER_E_SETTING_INVALID_CERTIFICATE (Event ID: 25013), MEDIATIONSERVER_E_SETTING_CERTIFICATE_INVALID_SUBJECT (Event ID: 25037), MEDIATIONSERVER_E_SETTING_INVALID_LISTENING_ADDRESS_DATA (Event ID: 25012), MEDIATIONSERVER_WRN_SETTINGS_NOT_DYNAMIC (Event ID: 25031)
Resolution:
Modify the above specified configurations to clear the problem.

Log Name: Lync Server
Source: LS Mediation Server
Date: 7/24/2015 6:02:21 PM
Event ID: 25029
Task Category: (1030)
Level: Information
Keywords: Classic
User: N/A
Computer: GCR-LYNCSTDOBT.corpnet.domain.com
Description:
Mediation Server applied the settings changes
Setting Name: PDP
Property Description: ServiceGruu
Old Value: sip:gcr-lyncstdobt.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA
New Value: sip:gcr-lyncstdobt.corpnet.domain.com@domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.PDP:cT_X2URjIFW0ygzTE3iGYwAA

Log Name: Lync Server
Source: LS Mediation Server
Date: 7/24/2015 6:02:21 PM
Event ID: 25029
Task Category: (1030)
Level: Information
Keywords: Classic
User: N/A
Computer: GCR-LYNCSTDOBT.corpnet.domain.com
Description:
Mediation Server applied the settings changes
Setting Name: Mediation Server Topology
Property Description: DefaultDomain
Old Value: corpnet.domain.com
New Value: domain.com

Log Name: Lync Server
Source: LS Mediation Server
Date: 7/24/2015 6:02:21 PM
Event ID: 25029
Task Category: (1030)
Level: Information
Keywords: Classic
User: N/A
Computer: GCR-LYNCSTDOBT.corpnet.domain.com
Description:
Mediation Server applied the settings changes
Setting Name: MRAS
Property Description: ServiceGruu
Old Value: sip:gcr-lyncedgpool.corpnet.domain.com@corpnet.domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA

New Value: sip:gcr-lyncedgpool.corpnet.domain.com@domain.com;gruu;opaque=srvr:MRAS:WjJ6-s1PyFeipMlcPV0pwwAA

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.”

image

image

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.

image

image

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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up