DTMF tones are used during a call to signal to a far-end device; these signals is for navigating a menu system, entering data, or for other types of manipulation. They are processed differently from the DTMF tones that are sent during the call setup as part of the call control. TDM interfaces on Cisco devices support DTMF by default. Cisco VoIP dial-peers do not support DTMF relay by default and require DTMF relay capabilities to be enabled.

Note	DTMF tones sent by phones do not traverse the CUBE.

Dual-Tone Multifrequency (DTMF) relay is the mechanism for sending DTMF digits over IP. The VoIP dial peer can pass the DTMF digits either in a band or out of band.

In-band DTMF-Relay passes the DTMF digits using the RTP media stream and uses a special payload type identifier in the RTP header to distinguish DTMF digits from voice communication. This method is more likely to work on lossless codecs, such as G.711.

Note

The main advantage of DTMF relay is that low-bandwidth codecs like G.729 and G.723 is sent with greater fidelity when sent using in-band DTMF relay. Without the use of DTMF relay, calls established with low-bandwidth codecs may have trouble accessing automated DTMF-based systems, such as voicemail, menu-based Automatic Call Distributor (ACD) systems, and automated banking systems.

Out-of-band DTMF-Relay passes DTMF digits using a signaling protocol (SIP) instead of using the RTP media stream.

DTMF relay prevents loss of integrity of DTMF digits that are caused by VoIP compressed codecs. The relayed DTMF is then regenerated transparently on the peer side.

DTMF relay mechanisms that are supported on VoIP dial-peers are listed below based on the keywords used to configure them. The DTMF relay mechanism can be either out-of-band (SIP) or in-band (RTP).

• sip-notify —This method is available on SIP dial peers only. This is a Cisco proprietary out-of-band DTMF relay mechanism that transports DTMF signals using SIP-Notify message. The SIP Call-Info header indicates the use of the SIP-Notify DTMF relay mechanism. The message is acknowledged with a 18x or 200 response message containing a similar SIP Call-Info header.

  The Call-Info header for a NOTIFY-based out-of-band relay is as follows:

  Call-Info: <sip: address>; method="NOTIFY;Event=telephone-event;Duration=msec"

  DTMF relay digits are sent as 4 bytes in a binary encoded format.

  This mechanism is useful for communicating with SCCP IP phones that do not support in-band DTMF digits and analog phones that are attached to analog voice ports (FXS) on the router.

  If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence.

• sip-kpml — This is an out-of-band DTMF relay mechanism that is defined by RFC 4730 that registers the DTMF signals using SIP-Subscribe messages and transports the DTMF signals using SIP-Notify messages containing an XML-encoded body. This method is also known as Key Press Markup Language.

  If you configure KPML on the dial peer, the gateway sends INVITE messages with KPML in the Allow-Events header.

  The use of this method is to register SIP endpoints to Cisco Unified Communications Manager(CUCM) or Cisco Unified Communications Manager Express(CME). This method is useful for nonconferencing calls and for interoperability between SIP products and SIP phones.

  If you configure rtp-nte, sip-notify, and sip-kpml, the outgoing INVITE contains an SDP with rtp-nte payload, a SIP Call-Info header, and an Allow-Events header with KPML.

  The following SIP-Notify message is a sample that is taken after the subscription has taken place. The endpoints transmit digits using SIP-Notify messages with KPML events through XML. In the following example, the digit “1” is being transmitted:

  NOTIFY  sip:192.168.105.25:5060 SIP/2.0
  Event: kpml 
  <?xml version="1.0" encoding="UTF-8"?>
  <kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/> 

• sip-info —The sip-info method is available only on SIP dial peers. This is an out-of-band DTMF relay mechanism that registers the DTMF signals using SIP-Info messages. The body of the SIP message consists of signaling information and uses the Content-Type application/dtmf-relay.

  The method is always enabled for SIP dial peers, and is invoked when a SIP INFO message is received with DTMF relay content.

  This following sample message shows that a SIP INFO message received with specifics about the DTMF tone to be generated. The combination of the From, To, and Call-ID headers identifies the call leg. The signal and duration headers specify the digit, in this case 1, and duration, 160 milliseconds in the example, for DTMF tone play.

  INFO sip:2143302100@172.17.2.33 SIP/2.0
  Via: SIP/2.0/UDP 172.80.2.100:5060
  From: <sip:9724401003@172.80.2.100>;tag=43
  To: <sip:2143302100@172.17.2.33>;tag=9753.0207
  Call-ID: 984072_15401962@172.80.2.100
  CSeq: 25634 INFO
  Supported: 100rel
  Supported: timer
  Content-Length: 26
  Content-Type: application/dtmf-relay
  Signal= 1
  Duration= 160

• rtp-nte —Real-Time Transport Protocol (RTP) Named phone Events (NTE). This is an in-band DTMF relay mechanism that is defined by RFC2833. RFC2833 defines formats of NTE-RTP packets that are used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. DTMF tones are sent as packet data after call media has been established using the RTP stream and are distinguished from the audio by the RTP payload type field, preventing compression of DTMF-based RTP packets. For example, the audio of a call is sent on a session with an RTP payload type that identifies it as G.711 data, and the DTMF packets are sent with an RTP payload type that identifies them as NTEs. The consumer of the stream utilizes the G.711 packets and the NTE packets separately.

  The SIP NTE DTMF relay feature provides reliable digit relay.

  Note

  Payload type 96 and 97 is used for fax by default in Cisco devices. A third-party device may use payload type 96 and 97 for DTMF. In such scenarios, we recommend you to perform one of the following: Change the payload type for fax in both incoming and outgoing dial-peers using rtp payload-type command Use assymetric payload dtmf command For more information on configuring rtp payload-type and asymmetric payload DTMF, see Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls.

  Payload types and attributes of this method are negotiated between the two ends at call setup using the Session Description Protocol (SDP) within the body section of the SIP message.

  Note

  This method should not be confused with the “Voice in-band audio/G711” transport because the latter is just the audible tones is passed as normal audio without any relay signaling method being “aware” or involved in the process. This is plain audio passing through end-to-end using the G711Ulaw/Alaw codec.

• cisco-rtp —This is an in-band DTMF relay mechanism that is Cisco proprietary, where the DTMF digits are encoded differently from the audio and are identified as a payload type 121. The DTMF digits are part of the RTP data stream and distinguished from the audio by the RTP payload type field. This method is not supported by CUCM and its use has been discontinued.

• G711 audio —This is an in-band DTMF relay mechanism that is enabled by default and requires no configuration. Digits are transmitted within the audio of the phone conversation, that is, it is audible to the conversation partners; therefore, only uncompressed codecs like g711 alaw or ulaw can carry in-band DTMF reliably. Female voices are known to, sometimes, trigger the recognition of a DTMF tone.

  Digits are passed along just like the rest of your voice as normal audio tones with no special coding or markers using the same codec as your voice does and are generated by your phone.

This table provides the DTMF interoperability information between various DTMF relay types in different call flow scenarios. For instance, if you need to configure sip-kpml on an inbound dial peer and RTP-NTE on an outbound dial peer in an RTP-RTP Flow through configuration, refer table 3 to see that the combination is supported. The call scenarios provided are as follows:

• RTP-RTP Flow-Through

• RTP-RTP with transcoder Flow-Through

• RTP-RTP Flow Around

• SRTP-RTP Flow Through

* Media resource is required (Transcoder) for Cisco IOS and IOS XE versions.

* Media resource is required (Transcoder) for Cisco IOS and IOS XE versions. CUBE falls back to flow-through mode if media resource is unavailable.

Note

For calls sent from an in-band (RTP-NTE) to an out-of band method, configure the dtmf-relay rtp-nte digit-drop command on the inbound dial-peer and the desired out-of-band method on the outgoing dial-peer. Otherwise, the same digit is sent in OOB as well as in-band, and gets interpreted as duplicate digits by the receiving end. When the digit-drop option is configured on the inbound leg, CUBE suppresses NTE packets and only relay digits using the OOB method configured on the outbound leg.