Exchange UM and SDP 180\183

Standard

So, had a pretty funny (well, it started funny…) discovery a couple of weeks back:

I have a pretty simple environment that looks pretty much like this:

UM design

  • There’s a Lync 2013 pool.
  • There’s an Exchange 2010 UM server.
  • There’s an old QSIG PBX.
  • There’s an AudioCodes M1000 SBC to connect the above.

Users on Lync can dial users on the old PBX and vice versa via the AudioCodes SBC, voicemail works for users on both platforms; Lync and Exchange communicate directly over TLS, the old PBX and Exchange are communicating via the AudioCodes SBC over TCP, messages can be heard on the Outlook clients for both platforms, but one (apparently) critical feature is missing:
When users on the old PBX hit the “Play on Phone” button on their Outlook client to play their voicemail on their handset, the call rings, but we can’t hear any audio.
It works perfectly for Lync users, but users on the PBX’s UM dial plan can’t play their messages on the phones.

I immediately blames the SBC as there was no reason why any other call would connect, except for calls originating at the Exchange UM server.

Traces showed the following:

Trace

The gateway is doing everything you’d ask it to do, everything looks ok, but still, no audio could be heard.

Next I went to the Exchange UM server. Using Wireshark, I traced a one of the calls from the Exchange UM server to the user’s handset.
Using the Wireshark’s VoIP Calls player,  I could actually hear myself speaking on the handset, but there was nothing playing on the Exchange side.

Took me some time and some assistance from the nice guys at Microsoft to discover the following:

There’s a UCMA design limitation, where SDP can only be sent in 183 and in 200 OK.
If the “180 Ringing” contains SDP, UCMA will freak out.
My SBC was sending two provisional responses with SDP – 183 with SDP and 180 with SDP, before sending the 200 OK with SDP.
Apparently, we could send only 183 with SDP or 180 with SDP.
Sending both would cause the UCMA to get stuck and not initiate the Audio channel.

Who would have thought!

Once we suppressed the 183 packet, Exchange UM immediately started playing audio.

Advertisements