Dual-tone Multi-frequency (DTMF) is used for telephone call signaling over analog phone lines in voice frequency band. Dual-tone Multi-frequency (DTMF) Relay is the mechanism where a VoIP gateway listens for in-call tones, and relays them to the peer according to the negotiated method.
This document will cover generic steps to be followed for configuring and troubleshooting DTMF relay over MGCP on an IP-TDM gateway.
Basic knowledge on DTMF tones.
Basic knowledge of how to configure and use Cisco IOS for voice.
Basic knowledge of the signaling used by MGCP protocol.
Basic knowledge of how to debug MGCP VoIP protocol.
The information in this document is based on:
MGCP Gateway running on Cisco IOS 15.X.
Cisco Unified Communications Manager 8.x or later.
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, make sure that you understand the potential impact of any command.
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).
Cisco proprietary DTMF-Relay method uses payload type (PT) = 121. DTMF-Relay mechanism is not carried out in SDP messages and is not negotiated. Each GW uses its local configuration to make the decision of DTMF-Relay method and PT value. Thus both ends should be configured with the same parameters for the setup to work. This method is not very common and can't be considered as GW-Controlled or CA-Controlled since negotiation isn't present, neither directly nor through CA.
See Debugs_1 (attached)
NSE based DTMF-Relay method uses payload type (PT) = 100 by default. This method is also Cisco proprietary. Again, DTMF-Relay mechanism is not carried out in SDP messages and is not negotiated. Each GW uses its local configuration to make the decision of DTMF-Relay method and PT value. Thus both ends should be configured with the same parameters for the setup to work. This method also can't be considered as GW-Controlled or CA-Controlled since negotiation isn't present, neither directly nor through CA.
See Debugs_2 (attached)
MGCP RTP-NTE has two implementations, which are Call Agent (CA) Controlled and Gateway (GW) Controlled. In CA-controlled mode, 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.
See Debugs_3 (attached)
This is the other implementation of MGCP RTP-NTE. In GW-controlled mode, GWs negotiate DTMF transmission and RTP PT values by exchanging capability information in SDP messages. This transmission is transparent to the CA (Call Agent). This would work in a setup where both GWs are running MGCP and connected to the same CUCM.
See Debugs_4 (attached)
In OOB method, DTMF events will be signaled 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 signaled 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.
See Debugs_5 (attached)
1. In MGCP, dynamic PT values used to range from 98-119 (unlike RFC2833 (96-127)) till 12.4, after fix for CSCdt78583 this behavior was changed. We can use CLI “mgcp payload-type nse/nte <98-119>” to set the dynamic value for NSE & NTE events.
2. We have an option to enable DTMF relay for low-rate codecs (G729, iLBC, GSM, etc) only. In this case high bit-rate codecs such as G711 will send DTMF digits as in-band voice with PT value of the codec.
Router(config)#mgcp dtmf-relay voip codec ?
all Enable mgcp dtmf-relay for all codec
low-bit-rate Enable mgcp dtmf-relay for low-bit-rate codec
3. MGCP known common DTMF-Relay related defects:
About the Author
Karan Moudgil is a lead customer services engineer in the Cisco Technical Assistance Centre, Asia-Pacific. He has vast experience and knowledge in configuring, troubleshooting, and designing gateways, gatekeepers, Cisco Unified Border Element Enterprise & SP Edition, and Cisco Unified Call Manager and has deep knowledge of signalling protocols such as SIP, H.323, MGCP, SCCP and others. He has been involved in several bug fixes, escalations, and critical account cases in Asia Pacific region.
When doing multi-hop async BFD sessions on ASR9K, the following restrictions / caveats are noted:1. HW-offload is not supported2. LC CPU which hosts the session is randomized according to line cards listed under 'multipath include location X/X...
Hello,In previous post (https://community.cisco.com/t5/xr-os-and-platforms/asr9000-forwarding-latency/td-p/2708349) back in 2015, it was identified that Typhoon to Typhoon forwarding latency on ASR9K is estimated to be around 15usec. Is there such fi...
Hi, My question is regarding the Radius AVpair client-mac-address that is sent to a Radius server as part of the authentication process and accounting. Let me clarify first that we are NOT using the mac-address as part of the username at all. T...
Hallo on ios-xr is possible or not when we wan to disable prompt "Destination file name (control-c to abort): " when copy file cisco ios-xr to usb like file prompt quiet on ciso ios ? Thank you for help