In the past couple of months, we have seen an increase in dual tone multi-frequency (DTMF) issues generated when Cisco Unified Communications Manager v8.5 connects to Lync Server 2010. Lync uses DTMF to signal the conference ID that is required to join a conference. SIP trunk integration with Cisco Unified Communication Manager (CUCM) version 8.5.1.12900-7 is supported by Lync Server 2010. For additional information, see the article, Unified Communications Open Interoperability Program – Lync Server. This article addresses an issue encountered by attendees using CUCM v8.5 who are unable to join meetings hosted by Lync Server 2010.

Author: Jigar Dani

Publication date: November 2011

Product version: Lync Server 2010

Symptom

When users with Cisco phones and conference room endpoints connected to CUCM v8.5 try to join a Lync conference, they may receive multiple prompts to enter the conference ID. After entering a valid ID they may not be able to join the conference. IP phones that support RFC 2833 DTMF MTP pass-through will not experience this issue because DTMF encoding is not performed by CUCM.

Cause

After performing a code level investigation we discovered that when CUCM transcodes DTMF digits it does not send the digits in the proper format.

To troubleshoot the issue, collect a network trace from the Mediation Server connected to CUCM. Then, analyze a login attempt to join a Lync hosted conference. Figure 1 shows a network trace of a Lync client attempting to join a conference hosted on Lync Server 2010. Customer information was eliminated for privacy reasons. To filter only the network packets of interest, I set the Wireshark filter to: (udp.length != 24 && rtpevent && rtp.marker==1). I’ve highlighted the raw data that identifies the RFC 2833 RTP DTMF event. A detailed explanation of this raw data is provided later in this document.

Figure 1. Network trace: CUCM endpoint failing to join a Lync conference

Figure 2 captures a network trace of a CUCM endpoint that successfully joins a Lync conference. To filter the DTMF digits from the network trace, I set the Wireshark filter to: (udp.length == 24 && rtpevent && rtp.marker==1). I highlighted the RTP event (i.e. DTMF digit).

Figure 2 Network trace: CUCM endpoint successfully joining Lync conference.

Why am I using the filter udp.length == 24 && rtpevent && rtp.marker==1?- I want to filter packets that are exactly 24 bytes. This should be the length of DTMF digits. RTPEvent filter helps me identify packets that are DTMF digits. RTP Marker filter set to 1 helps identify just the first packet of a DTMF digit (5-8 packets make 1 DTMF digit). This first DMTF packet contains 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. In Figure 1, the duration zero should have been represented by 00 00. However, in its place we see the following data representing the event duration:

We found that we could isolate all the packets containing this garbage raw data by filtering for the right length, in this case udp length 24. So why length 24?

A DTMF packet, which is 24 octets, consists of a UDP header (8 octets) + RTP header (12 octets) + RTP Payload (RTPEVENT=DTMF) (4 octets).

The DTMF digit in RTP Payload as defined in RFC 4733 (obsoletes RFC 2833) is shown below:

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|     event     |E|R| volume    |          duration             |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The RTP header (assuming no CSRC) as defined in RFC 1189 is shown below:

0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The UDP header as defined in RFC 768 is shown below:

                  0      7 8     15 16    23 24    31 

                 +--------+--------+--------+--------+

                 |     Source      |   Destination   |

                 |      Port       |      Port       |

                 +--------+--------+--------+--------+

                 |                 |                 |

                 |     Length      |    Checksum     |

                 +--------+--------+--------+--------+

The hex data beyond 24 octets is something that should not be sent to 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.

Conclusion

This conference join issue due to garbage DTMF digits transmitted by CUCM has been identified by Cisco and a fix was provided in version 8.5.1.12900-7. This is also the first CUCM v8.5 that is supported for Lync. Please upgrade CUCM to this supported version to fix the above DTMF issue.

Additional Resources

Unified Communications Open Interoperability Program – Lync Server

Integrating Microsoft Lync Server 2010 and Cisco Unified Communications Manager

RFC 4733

RFC 1189

RFC 768

Lync Server Resources

We Want to Hear from You