Troubleshooting DTMF in MGCP and PRI

WHAT IS DTMF?

DTMF (Dual Tone Multiple Frequency ) is used to send to signals for button presses on
telephones. The data is typically sent over voice channels and so in order to distinguish from
human voice, when you hit a button the phone generates two tones of different frequencies -
one lower frequency and one high frequency.

HOW DTMF WORKS?

DTMF keypad is placed out on 4 cross 4 matrices, in which each row represents low frequency,
each column represents high frequency, with DTMF, each key passed on a phone generates two
tones of the specific frequencies. So that a voice can't imitate the tones, one tone is generated
from a high-frequency group of tones and the other from a low frequency group.

This document only contains DTMF troubleshooting of MGCP and PRI.

MGCP and DTMF

Before we discuss the types of DTMF-Relay methods, which can be used over MGCP, following
are some key-points that are to be kept in mind:

1. MGCP Gateway pulls XML configuration from the Cisco Unified Communications
Manager and configures itself after parsing the XML file downloaded into IOS CLIs.

2. Point 1 is valid only if following commands are present:

ccm-manager config

ccm-manager config server X.X.X.X

If the above commands are not present, the MGCP Gateway doesn’t download any
configuration file and operates based on the configuration manually put into IOS by the user.

3. If the system has been designed for the MGCP Gateway to download the configuration
file, we configure the DTMF-Relay method on the CUCM Gateway Configuration page
(default is ‘Current GW Config’).

4. If the system has been designed for the MGCP Gateway not to download the
configuration files, we configure the DTMF-Relay method on IOS CLI:
Router(config)#mgcp dtmf-relay voip codec all mode ?

cisco Set mgcp dtmf-relay mode to be cisco

disabled Set mgcp dtmf-relay mode to be disabled

nse Set mgcp dtmf-relay mode to be nse

nte-ca Set mgcp dtmf-relay mode to be nte-ca

nte-gw Set mgcp dtmf-relay mode to be nte-gw

out-of-band Set mgcp dtmf-relay mode to be out-of-band

Router(config)#mgcp package-capability fm-package

Router(config)#mgcp package-capability dtmf-package

This point is also applicable if we have selected “Current GW Config” in the dropdown for “Type
of DTMF Relay” on the CUCM Gateway Configuration page (Point 3).

mgcp dtmf-relay mode to be cisco

Real-time Transport Protocol (RTP) digit events are encoded using a proprietary format similar to
Frame Relay as described in the FRF.11 specification. The events are transmitted in the same
RTP stream as nondigit voice samples, using payload type 121. This is Cisco proprietary.

What can be seen in debugs?

015222: Jan 15 12:14:33.924: Pt:121 Evt:1 Pkt:01 03 20 <Snd>>>

015223: Jan 15 12:14:33.948: s=DSP d=VoIP payload 0x79 ssrc 0x1E74 sequence 0x4B5B
timestamp 0xAE738050

015224: Jan 15 12:14:33.948: Pt:121 Evt:1 Pkt:02 03 20 <Snd>>>

015252: Jan 15 12:14:33.964: s=DSP d=VoIP payload 0x79 ssrc 0x1E74 sequence 0x4B5C
timestamp 0xAE7380F0

015226: Jan 15 12:14:33.964: Pt:121 Evt:1 Pkt:03 03 20 <Snd>>>

015227: Jan 15 12:14:33.984: s=DSP d=VoIP payload 0x79 ssrc 0x1E74 sequence 0x4B5D
timestamp 0xAE738190

015228: Jan 15 12:14:33.984: Pt:121 Evt:1 Pkt:04 03 20 <Snd>>>

015229: Jan 15 12:14:34.008: s=DSP d=VoIP payload 0x79 ssrc 0x1E74 sequence 0x4B5E
timestamp 0xAE738230

015230: Jan 15 12:14:34.008: Pt:121 Evt:1 Pkt:05 03 20 <Snd>>>

015231: Jan 15 12:14:34.024: s=DSP d=VoIP payload 0x79 ssrc 0x1E74 sequence 0x4B5F
timestamp 0xAE7382D0

015232: Jan 15 12:14:34.024: Pt:121 Evt:1 Pkt:06 03 20 <Snd>>>

mgcp dtmf-relay mode to be nse

Named signaling event (NSE) RTP digit events are encoded using the format specified in RFC
2833, Section 3.0, and are transmitted in the same RTP stream as nondigit voice samples, using
the payload type that is configured using the mgcp tse payload command. This method is also
Cisco proprietary. Payload type (PT) = 100 by default.

What can be seen in debugs?

014905: Jan 15 11:53:56.324: s=DSP d=VoIP payload 0x63 ssrc 0x1E88 sequence 0x52B1
timestamp 0xB1A870B1

014906: Jan 15 11:53:56.324: Pt:99 Evt:1 Pkt:03 00 50 <Snd>>>

014907: Jan 15 11:53:56.372: s=DSP d=VoIP payload 0x63 ssrc 0x1E88 sequence 0x52D6
timestamp 0xB1A870B1

014908: Jan 15 11:53:56.372: Pt:99 Evt:1 Pkt:03 01 90 <Snd>>>

014909: Jan 15 11:53:56.428: s=DSP d=VoIP payload 0x63 ssrc 0x1E88 sequence 0x52D7
timestamp 0xB1A870B1

014910: Jan 15 11:53:56.428: Pt:99 Evt:1 Pkt:03 03 20 <Snd>>>

014911: Jan 15 11:53:56.476: s=DSP d=VoIP payload 0x63 ssrc 0x1E88 sequence 0x52D8
timestamp 0xB1A870B1

014912: Jan 15 11:53:56.476: Pt:99 Evt:1 Pkt:03 04 B0 <Snd>>>

014917: Jan 15 11:53:56.524: s=DSP d=VoIP payload 0x63 ssrc 0x1E88 sequence 0x52D9
timestamp 0xB1A870B1

014918: Jan 15 11:53:56.524: Pt:99 Evt:1 Pkt:03 06 40 <Snd>>>

mgcp dtmf-relay mode to be nte-ca

Identical to the nte-gw keyword behaviour except that the call agent's local connection options
a: line is used to enable or disable DTMF relay.

CA will negotiate DTMF relay capabilities on behalf of the gateways (SDP messages are sent to
CA). This is required in a setup where the other GW/Endpoint is non-MGCP. After negotiation,
CA instructs the MGCP gateway to use the negotiated PT values.

What can be seen in debugs?

003283: Jan 14 18:15:04.909: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA26
timestamp 0xB1D350B0

003284: Jan 14 18:15:04.909: Pt:101 Evt:1 Pkt:03 00 50 <Snd>>>

003285: Jan 14 18:15:04.957: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA27
timestamp 0xB1D350B0

003286: Jan 14 18:15:04.957: Pt:101 Evt:1 Pkt:03 01 90 <Snd>>>

003287: Jan 14 18:15:05.009: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA28
timestamp 0xB1D350B0
003288: Jan 14 18:15:05.009: Pt:101 Evt:1 Pkt:03 03 20 <Snd>>>

003289: Jan 14 18:15:05.057: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA29
timestamp 0xB1D350B0

003290: Jan 14 18:15:05.057: Pt:101 Evt:1 Pkt:03 04 B0 <Snd>>>

003295: Jan 14 18:15:05.109: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA2A
timestamp 0xB1D350B0

003296: Jan 14 18:15:05.109: Pt:101 Evt:1 Pkt:03 06 40 <Snd>>>

003297: Jan 14 18:15:05.109: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA2B
timestamp 0xB1D350B0

003298: Jan 14 18:15:05.109: Pt:101 Evt:1 Pkt:83 06 40 <Snd>>>

003299: Jan 14 18:15:05.117: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xM4B
timestamp 0xB1D350B0

003300: Jan 14 18:15:05.117: Pt:101 Evt:1 Pkt:83 06 40 <Snd>>>

mgcp dtmf-relay mode to be nte-gw

RTP digit events are encoded using the named telephony event (NTE) format specified in RFC
2833, Section 3.0, and are transmitted in the same RTP stream as nondigit voice samples. The
payload type is negotiated by the gateways before use. The configured value for payload type is
presented as the preferred choice at the beginning of the negotiation.

What can be seen in debugs?

011793: Jan 15 10:30:45.909: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA26
timestamp 0xB1D350B0

011794: Jan 15 10:30:45.909: Pt:101 Evt:1 Pkt:03 00 50 <Snd>>>

011795: Jan 15 10:30:45.957: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA27
timestamp 0xB1D350B0

011796: Jan 15 10:30:45.957: Pt:101 Evt:1 Pkt:03 01 90 <Snd>>>

011797: Jan 15 10:30:45.009: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA28
timestamp 0xB1D350B0

011798: Jan 15 10:30:45.009: Pt:101 Evt:1 Pkt:03 03 20 <Snd>>>

011799: Jan 15 10:30:45.057: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA29
timestamp 0xB1D350B0

011800: Jan 15 10:30:45.057: Pt:101 Evt:1 Pkt:03 04 B0 <Snd>>>

011801: Jan 15 10:30:45.109: s=DSP d=VoIP payload 0x65 ssrc 0x1ED4 sequence 0xA2A
timestamp 0xB1D350B0

011802: Jan 15 10:30:45.109: Pt:101 Evt:1 Pkt:03 06 40 <Snd>>>

mgcp dtmf-relay mode to be out-of-band

In OOB method, DTMF events will be signalled to CUCM using MGCP protocol messages. To be
more specific MGCP NTFY messages will be sent to CA. After any digit is received by MGCP GW
and signalled to CUCM, CUCM will send RQNT message to the GW. This message will ask the
GW to monitor the events of DTMF Digits, Fax-Relay (FXR), and T.38 Relay.

What can be seen in debugs?

000314: Jan 14 10:50:56.162: MGCP Packet sent to 10.106.118.68:2427--->

NTFY 197096098 S0/SU0/DS1-0/1@abc_G2 MGCP 0.1

N: [email protected]:2427

X: 1

O: D/1

<---

000315: Jan 14 10:50:56.162: MGCP Packet received from 10.106.118.68:2427--->

200 197096098

<---

000316: Jan 14 10:50:56.162: MGCP Packet received from 10.106.118.68:2427--->

RQNT 154 S0/SU0/DS1-0/1@abc_G2 MGCP 0.1

X: 1

R: D/[0-9ABCD*#], FXR/t38

Q: process,loop

<---

000317: Jan 14 10:50:56.162: MGCP Packet sent to 10.106.118.68:2427--->

200 154 OK

<---

000318: Jan 14 10:50:59.278: MGCP Packet received from 10.106.118.68:2427--->

RQNT 155 S0/SU0/DS1-0/1@abc_G2 MGCP 0.1

X: 1

R: D/[0-9ABCD*#], FXR/t38
S: D/9

Q: process,loop

<---

000319: Jan 14 10:50:59.278: MGCP Packet sent to 10.106.118.68:2427--->

200 155 OK

<---

Use “debug mgcp packets” to collect MGCP logs.

“At VoIP call leg, Packet Captures can also be used to troubleshoot DTMF issues.”

Troubleshooting DTMF on PRI

Important note: Telco does not send the DTMF digits but tone for every digit pressed by caller. It
is up to the VG to recognize the tones and convert the tones to appropriate digits.

Consider the following call flow:

Calling party ---- PSTN ---- ISDN PRI ---- Cisco VoiCE Gateway ---- CUCM----called party

Debugs to be collected: Debug isdn q931

Debug voip ccapi inout

Please go through my document to learn how to collect and read ISDN debugs:
https://community.cisco.com/t5/collaboration-voice-and-video/pri-troubleshooting/ta-
p/3959544

What to look for in debugs? (Below output shows when DTMF is working fine and digit is
received successfully)

In ISDN debugs Mark the call ID of ISDN leg.

967784: Jan 27 04:40:42: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0302

In CCAPI debugs mark the ccapi leg - 1562D298A8F3

967785: Jan 27 04:40:45: //613511/1562D298A8F3/CCAPI/cc_handle_inter_digit_timer:

Generate inter-digit timeout CC_EV_CALL_DIGIT_END event

967786: Jan 27 04:40:45: //613511/1562D298A8F3/CCAPI/cc_api_call_digit_begin:

Destination Interface=0x70C0A270, Destination Mask=0x3, Destination Call Id=613512,

Source Call Id=613511, Digit=1, DigitBeginFlags=0x1,

Rtp Timestamp=0xCC7C4850, Rtp Expiration=0x0

967787: Jan 27 04:40:45: //613511/1562D298A8F3/CCAPI/cc_api_call_digit_begin:

Consume mask is not set. Relaying Digit 1 to dstCallId 0x95C88

967788: Jan 27 04:40:45:

//613511/1562D298A8F3/CCAPI/cc_relay_digit_begin_for_3way_conference:

Check DTMF relay digit begin for 3way conf

967789: Jan 27 04:40:45: //613511/1562D298A8F3/CCAPI/cc_api_call_digit_end:

Destination Interface=0x70C0A270, Destination Mask=0x3, Destination Call Id=613512,

Source Call Id=613511, Digit=1, Duration=217,

For failed DTMF call, capture the above debugs and search for “cc_api_call_digit_begin”
and “cc_api_call_digit_end” events but you will notice there are no such events generated
that means DTMF is not being received.

If you still have doubts on DTMF digits being received, please collect PCM captures on ISDN.
Please go through my document to learn how to collect PCM captures.
https://community.cisco.com/t5/collaboration-voice-and-video/fxo-disconnect-issue-how-to-
configure-custom-cptone/ta-p/3926564

After collecting PCM captures, analyze the tones in Audacity tool to find the frequency of
received tone on the VG.

Use the below steps:

1. Collect the PCM on ISDN.

2. Analyze the PCM using pcet.cisco.com and find the SIN, RIN and SOUT tones.

3. If it’s an incoming call, we have to analyze the SIN tone.

4. Extract the SIN tone from PCM and use Audacity tool to open it.

5. You will see something like the below snippet. Rectangular bar represents the tone
pressed during the call.
 6. To analyze the frequency of the tone received, place the cursor on the top of rectangular bar.

7. Go to Analyze >>> Plot Spectrum, you will find the below output.

8. Place the pointer on top of the higher frequency first and note down the cursor value. Then
place the pointer on top of the lower frequency and note down the cursor value.
 9. Now, try to compare the combination of frequency using below table. For an example, if you
find the higher frequency cursor value as 1477 Hz (or near to 1477 Hz) and lower frequency
cursor value as 852 Hz (or near to 852 Hz), then DTMF digit would be “9”.