Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
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 22.214.171.12400-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
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.
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
|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.
To resolve this issue, upgrade to the supported CUCM version 126.96.36.19900-7.
This conference join issue due to garbage DTMF digits transmitted by CUCM has been identified by Cisco and a fix was provided in version 188.8.131.5200-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.
Unified Communications Open Interoperability Program – Lync Server
Integrating Microsoft Lync Server 2010 and Cisco Unified Communications Manager