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:

clip_image001

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.

clip_image002

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

clip_image003

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.

clip_image004

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:

clip_image005

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.

clip_image006

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.

Here

Recent content I've written for you—just for you!— to enjoy while you're here.

There

Quick commentary and links to other sources you'll find interesting. I promise.

Everywhere

Some personal background, links to related projects, and other ways to connect.

Hi there. My name is Tom Pacyk and this is my small home on the web. I love the intersection of design, technology, and communication, which is a combination that led me to a career in sales and marketing roles at places like Zoom and ServiceNow. They're a bit old now, but I also had the opportunity to publish a couple of books along the way.

Portland, Oregon is home for me, my wife Beth, and our three kids, but I'm actually a Midwestern transplant—I grew up in the Chicago suburbs and went to school at Purdue and Illinois. When I find some free time I'm probably going to concerts, rooting for the Portland Timbers, or working on my Sunshine Burn Photography project.