Showing results for 
Search instead for 
Did you mean: 
Julie Burruss


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.

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


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’):

Picture2.png    (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

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  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:

ScreenHunter_47 Oct. 16 12.55.jpg

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: