Lync Split-Domain & Static Route Conflicts

Something that is coming up more and more on Lync projects is the concept of integrating with newer video and collaboration services like Acano or Pexip. It's very important to understand that the deployment guides from these services request you create a static route from your Lync Front End pools to their MCUs. This in itself is not a red flag, especially since this is how some of the Polycom DMA or Cisco VCS integration has worked in the past.

However, this does pose a problem for organizations looking to leverage split-domain with Lync Online, or more commonly, Exchange Online being leveraged for voicemail while Lync Enterprise Voice remains on-premises. The issue here is that using your primary SIP domain as the Match URI in the static route to these video services prevents the signaling from getting to your federation Edge servers (at least, as of the latest Lync 2013 CUs.) The static routing configuration seems to kick in before the call is ever routed to the Edge, so the concept of the CsHostingProviders and the shared address space is never respected.

Let's walk through an example:

  • My primary SIP domain in Lync is
  • I migrate my mailboxes to O365 and enable the Exchange Online shared address space. My voicemail is hosted in O365.
  • I want to host large meetings in O365 so I also enable the Lync Online shared address space for hybrid. I have some users homed to O365.

Everything works fine at this point.

  • I now want to integrate with Acano or Pexip. I create a static route for which goes from my Lync FEs to their bridges.

This breaks both Exchange Online voicemail routing and communication to Lync Online users.

The real solution here is to use a different SIP domain for your video routing, which as undesirable as this may be to end users, has arguably been a best practice for a long time. Create the static route matching,, or Take your pick, or create your own variation. It just needs to be different from the SIP domain you actually assign to Lync users.

This is important to grasp if you're using Lync Online or Exchange Online today and looking to add video, but probably even more critical from a roadmap standpoint. Exchange Online Unified Messaging is a fairly common use-case today, and Lync Online hybrid is becoming more and more popular. Planning ahead for these scenarios and any potential video integration will help you avoid these issues.

Cisco and Lync One-Way Audio Troubleshooting

I had one case recently with Lync and Cisco UCM integration where the Cisco user would periodically be unable to hear the Lync user speaking. We were using media bypass with MTP required on the Cisco trunk, but the problem was fairly sporadic. The SIP Invite messages and SDP looked correct with the proper MTP for media, but the problem would continue to surface randomly. After checking all of the configs we got down to the point of needing a packet capture to determine the audio problem. We captured traces on both the Lync client and the Cisco phone, and compared the audio streams. The goal was to see if the Cisco phone was not actually receiving the Lync user's audio packets. The point of this post is to walk through the troubleshooting process we used to reconstruct the Lync and Cisco audio streams in Wireshark, which ultimately helped us pinpoint the problem location.

To get started, open your packet capture in Wireshark:


In the case of the capture collected on the Cisco phone we found the RTP packets were unable to be identified by Wireshark. They were purely UDP data as shown in the previous screen. In order to play these back we first needed to identify the RTP data. Highlight a UDP packet and then in the Wireshark menu click Analyze, Decode As, select RTP, and press OK.


You'll now see the same UDP data is identified as RTP traffic using the G.711 codec:


From the Wireshark menu now select Telephony, RTP, and Stream Analysis. You'll see the forward (sent) and reverse (received) audio RTP streams here. In this case we saw significant stream data bi-directionally from both capture points. This ruled out any kind of MTP problem and allowed us to validate the audio was being sent and received by both parties.


Press the Player button and click the View as time of day checkbox to listen to the audio stream. I typically select both the forward and reverse checkboxes and then press Play again to listen to both parties:


The interesting discovery was that we actually had two-way audio on both capture points. We could listen to the entire conversation on the trace collected at the Cisco phone port, which pointed us to the actual Cisco handset as the problem.

You can pull up call stats on a Cisco phone by pressing the ? button twice very rapidly. When we did this we found the codecs matched, but the RxDisc (Receive packets discarded) value was extremely high. This confirmed the handset itself was dropping the packets and not playing them back to the user.


After some more testing we isolated the problem to the Cisco 7940 series phones. The latest firmware updates did not resolve the issue and we have a Cisco TAC case still open on the subject. I'll update the post with any additional information we find.

Lync Music on Hold with Media Gateways

With the CU7 release Microsoft has added Music on Hold abilities to the Lync Phone Edition clients. Many organizations are starting to turn this feature on now, but it's possible that external PSTN callers still might not not hear any music on hold being played. If you're seeing (or not hearing) this behavior, there may be a gateway setting that's not passing the music on hold to PSTN callers.

On an AudioCodes MSBG 1000 this setting can be found under VOIP\GW and IP to IP\DTMF and Supplementary Services\Supplementary Services. Change the Hold Format parameter to "Send Only" if it is currently set to This parameter controls if the gateway should expect a SDP with fields set as a=sendonly and c= containing the client's IP address, or if it should expect a=inactive and c= Setting this value to Send Only allows the Lync PCs and phones to successfully pass music on hold to a PSTN caller.