Introduction
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.
Prerequisites
- 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.
Components Used
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.
Refer to Cisco Technical Tips Conventions for information on document conventions.
Supported DTMF-Relay methods over MGCP
Key-Points
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’):
(click to enlarge image)
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).
DTMF-Relay Methods
Cisco
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
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)
NTE-CA
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)
NTE-GW
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)
OUT-OF-BAND
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)
Gotchas
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.
This article is featured in the October 2013 issue of the Cisco TS Newsletter. Are you subscribed?
2 Comments