Udostępnij za pośrednictwem

Users unable to join Lync hosted conferences from Cisco Unified Communications Manager 8.5

  • Artykuł

In the past couple of months we have seen increase in DTMF issue relating to Cisco Call Manager v8.5 connecting to Lync Server 2010 (Lync). I worked on a few of these issues giving me an opportunity to dive deep into this integration. Cisco Unified Communication Manager (CUCM) v8.5 is supported with Lync Server 2010 only on minor build version 8.5.1.12900-7 as noted on Unified Communications Open Interoperability Program – Lync Server.

 

Symptom

Cisco phones and conference room endpoints, SIP Trunk terminating on CUCM en-route to Lync would not be able to join conferences hosted by Lync MCU's. You may experience that the user keeps getting prompted for entering the conference ID. Some of the phones which have a capability of RFC 2833 DTMF MTP Passthrough work just fine when that feature is turned on.

 

Cause

After code level investigation we found that CUCM, when transcoding DTMF digits does not send the digits in right format. 

To identify the issue, you need to collect a network trace from the MediationServer of your Lync deployment. Then trace the attempt to login to a Lync hosted conference room. Below is one such trace (obfuscated from customer environment since I do not have a CUCM here), to see the packets of interest I set the wireshark filter to (udp.length != 24 && rtpevent && rtp.marker==1)

The lower window highlighted digits show the raw data captured for RFC 2833 RTP event. 

I also captured a trace when a endpoint coming from CUCM was successfully able to login to Lync MCU. To trace these DTMF digits I set up the wireshark filter to (udp.length == 24 && rtpevent && rtp.marker==1)

Again I have highlighted the RTPEvent.

 

Basically we are capturing UDP packets with length not equal to 24, that are RTPEVENT’s (meaning DTMF) and have RTP marker bit set to 1 - meaning the first packet in the DTMF digit - which has all the information we need.

 

Event Duration 800 is signified by hex 03 20 raw data - the data 00 00 after that is basically Trailer for Ethernet II as you can see above. Similarly in the bad snapshot above the duration zero should have been represented by 00 00.
However, in that place we see some data after that –

We found that we could isolate all the good packets from bad packets by filtering for the right length. In this case udp length 24. So Why length 24?

A DTMF packet is – UDP header (8 octets) + RTP header (12 octets) + RTP Payload (RTPEVENT=DTMF) (4 octets) = 24 octets.

Here is what we should have for DTMF payload (RTP Payload) RFC 4733 –  

Here is what we should have for RTP header (assuming no CSRC) RFC 1189 –

Here is what we should have for UDP header RFC 768 –

So the hex data beyond 24 octets is something that should not have been received by Lync in a DTMF digit. This is what causes Lync to ignore these digits.

 

Resolution

To resolve this issue upgrade to the supported CUCM version 8.5.1.12900-7.

Comments

  • Anonymous
    May 10, 2014
    The comment has been removed