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 customer support engineer in the Cisco Technical Assistance Centre in Bangalore. His current role includes configuring, troubleshooting, and designing gateways, gatekeepers, Cisco Unified Border Element Enterprise & SP Edition, and Cisco Unified Call Manager using his 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.