Introduction

This document describes identifying Dual-Tone Multi-Frequency (DTMF) events within a packet capture.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Webex Control Hub
• Calling in Webex (Unified CM)
• DTMF

Components Used

The information in this document is based on these software and hardware versions:

• Wireshark version 4.0.7 (v4.0.7-0-g0ad1823cc090)
• Webex Control Hub

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

This article outlines how to identify Dual-Tone Multi-Frequency (DTMF) events within a packet capture using Wireshark. DTMF events are being passed within a call while using Calling in Webex (Unified CM). The call does not show any abnormal behavior or error messages. During this test call, digits 6,7,8,9,1,2 and 3 are pressed in sequence as DTMF input.

What is DTMF?

Dual Tone Multi-Frequency (DTMF) is the sound/tone generated by a telephone when the numbers are pressed. DTMF is used to control automated equipment and signal user intent, such as the number they wish to dial. Each key has two tones at specific frequencies.

DTMF Flow Diagram

At its start, in the late 1970s to early 1980s, DTMF technology was a paradigm shift for contact centers. For the first time, callers could complete self-service by selecting the right menu option, reducing average handle times and misroutes.

In the late 1990s, speech directed dialogue was introduced. Now, callers could say "billing" or "one" instead of pressing a number. It was definitely a better, hands-free option for self-service.

But a lot has changed in the past few decades.

Businesses have evolved. For modern businesses, telephony is one of the many channels used to engage with you. They strive to deliver state of the art technology and your experience across all channels of communication – web, mobile, social media and telephony.

Today’s tech-savvy environment demands seamless experiences across all channels. Modern customers are far more vocal than their predecessors and take a lot of pride in the brands they associate themselves with. So a dated or bad customer experience has an immediate impact on brand loyalty.

Customer service has evolved. As a joint effect of these two shifts, customer service has transformed over the past decade. It is no longer an afterthought but ingrained in all aspects of the business. Customer obsession, a key differentiator for many leading businesses, is the new marketing.

Why Do Some Brands Still Use DTMF Technology?

DTMF directed dialogue and speech directed dialogue are still the primary choice of technology for call handling across industry verticals.

Call Handling Technology Across Industries

How Does DTMF Work?

DTMF technology works by having the handset generate tones at specific frequencies and playing them over the phone line when a button is pressed on the keypad. Equipment at the other end of the phone line listens to the specific sounds and decodes them into commands.

DTMF uses audio frequencies, so key presses can be used to play recognizable melodies. Since each button makes two tones and they do not directly line up to standard musical notes, it is not an exact correlation.

DTMF specifies eight different tones divided into a high group and a low group. Each key press corresponds to two tones -- hence the name dual tone -- one from the high group and one from the low group. This allows for 16 total keys.

These keys are specified as the numbers 0 through 9, * (asterisk or star), # (pound, hash or octothorpe) and the letters A through D. The letter keys are not generally used and are omitted from the majority of consumer telephones. The telecommunications industry chose two simultaneous tones for each key to eliminate the possibility of the human voice triggering the system.

DTMF Frequencies

In-Band and Out-of-Band Signaling

Traditional DTMF is an in-band signaling system, meaning the signals are transmitted using the same channel as the voice traffic. But in voice over IP, DTMF signals can be transmittedin-band (RFC2833) orout-of-band. Out-of-band VoIP DTMF signaling can be implemented using protocols like SIP and MGCP, whereby special message types are defined for the transmission of digits.

The standardin-bandmethod is to simply transmit the tones along with the audio, but this can result in unreliable signals due to codec compression, packet loss or audio interference. In-band DTMF transmission is usually only reliable when the uncompressed G.711 codec is used.  If G.729 or G.723 are used, signaling normally fails as a result of the compression.

The in-band DTMF relay mechanism is defined by RFC2833. The DTMF tones/sounds are sent using the RTP stream after establishing media. You could differentiate DTMF with audio by the payload type.

Most often than not, we see the payload type as 101 for in-band DTMF. The number must be within the range 96-127.

Out-of-Band DTMF

Out-of-band DTMF transmission involves sending DTMF tones separately from the main voice stream, typically using a separate signaling channel. This method offers reliability and can be more secure than in-band DTMF, as it separates the DTMF data from the voice stream.

Key Aspects of Out-of-Band DTMF

Separate Channel:
DTMF information is not mixed into the audio stream but transmitted via a separate signaling channel.

Signaling Protocols:
Out-of-band DTMF often relies on established signaling protocols like Session Initiation Protocol (SIP), H.323, etc to transmit DTMF events.

Reliable Transmission:
Out-of-band DTMF can provide more reliable transmission of DTMF tones, especially over compressed codecs or in network conditions that can affect audio quality.

Reduced Complexity:
It simplifies the processing of DTMF events, as the receiving end does not need to filter the DTMF tones from the audio stream.

There are situations where it is crucial to confirm whether the in-band DTMF digits are being transmitted within the RTP stream. Wireshark is an excellent tool for verifying this. Additionally, it allows you to check the payload type of specific packets.

Troubleshooting Steps

These are the steps to troubleshooting your issue:

1. Enable capturing the traffic with the help of Wireshark on the client PC.
2. Proceed to make a call to a destination number which you know has IVR configured so that DTMF can be used.
3. Once you have entered the DTMF digits corresponding to the prompts heard in the IVR, stop the packet capture and save the file.

During this test call, digits 6,7,8,9,1,2 and 3 are pressed in sequence as DTMF input.

4. Proceed to filter the DTMF packets within the packet capture.
5. Use the filter rtpevent to see the DTMF packets.

Packet Capture Analysis

1. You can see the digits 6,7,8,9,1,2 and 3 being pressed in sequence.

DTMF Events Seen in the Packet Capture

Since this is in-band DTMF, the events are sent inside the RTP stream, at which point you can see Protocol RTP EVENT. The payload type shows as RTP Event.

2. You can compare the payload value between a normalRTP packetand aDTMF packet.

Normal RTP Packet

The snippet depicts a normal RTP packet, highlighted in blue.

Normal RTP Packet

If you observe the additional details of this packet, you seePayload type: ITU-T G.711 PCMA (8)under Real-Time Transport Protocol.

RTP Details of the Packet

DTMF Packet

The snippet depicts a DTMF packet, highlighted in blue. You can see digit 6 was pressed as a DTMF input.

DTMF Event 6 Pressed

If you observe the additional details of this packet, you can seePayload type: telephone-event (96)under Real-Time Transport Protocol.

Payload Type of the Same Packet

96 is the payload for in-band DTMF. Range: 96-127.

Related Information

• DTMF Events Through SIP Signaling
• DTMF Commands For Video Device Enabled Webex Meetings
• Configure DTMF Relay on CUBE