WHAT IS DTMF?
DTMF (Dual Tone Multiple Frequency ) is used to send signals for button presses on telephones. The data is typically sent over voice channels and so in order to distinguish from a 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 when you have MGCP and PRI in the call flow.
MGCP and DTMF
Before we discuss the types of DTMF-Relay methods, which can be used over MGCP, the following are some key points that are to be kept in mind:
- MGCP Gateway pulls XML configuration from the Cisco Unified Communications Manager and configures itself after parsing the XML file downloaded into IOS CLIs.
- Point 1 is valid only if the 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.
- 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’).
- 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? (debug voip rtp session named-event command is used)
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 non-digit 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 the tone for every digit pressed by the 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 calls, 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 about 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 the Audacity tool to find the frequency of received tone on the VG.
Use the below steps:
- Collect the PCM on ISDN.
- Analyze the PCM using pcet.cisco.com and find the SIN, RIN, and SOUT tones.
- If it’s an incoming call, we have to analyze the SIN tone.
- Extract the SIN tone from PCM and use the Audacity tool to open it.
- You will see something like the below snippet. The 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 the below table. For 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”.
10. Repeat steps 6, 7, and 8 for all other rectangular bars/Audio tones.
NOTE: The above process for analyzing DTMF digits using PCM (and Audacity tool) can be used for FXOs as well.
I have experience of 6+ Years in Cisco VoIP. I have worked on most of the Cisco Voice products: CUCM, CUC, IM&P, Cisco VGs, CUBE, CME, CUE. I have also experience working on vCenter and UCS. I’m an ex Cisco TAC engineer and have expertise in working on Voice Gateways and CUBE. I’m certified in CCNA (R&S) and SIP School Certified Associate(SSCA). I also run a YT channel to share my knowledge on Cisco Voice Gateways.
