Information About DTMF Relay

Information About DTMF Relay


Dual-tone multifrequency (DTMF) is the tone generated on a touchtone phone when the keypad digits are pressed. During a call, DTMF may be entered to access interactive voice response (IVR) systems, such as voice mail and automated banking services.

Although DTMF is usually transported accurately when using high-bit-rate voice codecs such as G.711, low-bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns and tend to distort DTMF tones. As a result, IVR systems may not correctly recognize the tones.

DTMF relay solves the problem of DTMF distortion by transporting DTMF tones “out of band,” or separate from the encoded voice stream.

Relay Types

Cisco gateways currently support the following methods of DTMF relay:

Cisco-proprietary Real-Time Transport Protocol (RTP)—DTMF tones are sent in the same RTP channel as voice data. However, the DTMF tones are encoded differently from the voice samples and are identified by a different RTP payload type code. Use of this method accurately transports DTMF tones, but because it is proprietary, it requires the use of Cisco gateways at both the originating and terminating endpoints of the H.323 call.

H.245 signal or alphanumeric—These methods separate DTMF digits from the voice stream and send them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 User Input Indication messages. The H.245 signaling channel is a reliable channel, so the packets that transport the DTMF tones are guaranteed to be delivered. However, because of the overhead of using a reliable protocol, and depending on network congestion conditions, the DTMF tones may be slightly delayed. All H.323 version 2 compliant systems are required to support the “h245-alphanumeric” method, while support of the “h245-signal” method is optional.

Named Telephone Events (NTEs). Using NTE to relay DTMF tones provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, developed by the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF relay method. They also negotiate to determine the payload type value for the NTE RTP packets. User preference for DTMF relay types is not supported, and DTMF relay forking is not supported.

The ability of a gateway to receive DTMF digits in a particular format and the ability to send digits in that format are independent functions. No configuration is necessary to receive DTMF digits from another H.323 endpoint using any of the methods described. The Cisco gateway is capable of receiving DTMF tones transported by any of these methods at all times.

Capabilities and Priorities

Cisco H.323 gateways advertise capabilities using H.245 capabilities messages. By default, they advertise that they can receive all DTMF relay modes. If the capabilities of the remote gateway do not match, the Cisco H.323 gateway transmits DTMF tones as in-band voice.

Configuring DTMF relay on the Cisco H.323 gateway sets preferences for how the gateway handles DTMF transmission. You can enable more than one DTMF relay option for a particular dial peer. If more than one option is enabled and if the peer indicates that it is capable of receiving DTMF in more than one of these formats, the gateway sends DTMF using the method among the supported formats that it considers to be the most preferred. If the remote device supports multiple formats, the gateway chooses the format according to the following priority:

1. cisco-rtp (highest priority)

2. h245-signal

3. h245-alphanumeric

4. rtp-nte

5. None—DTMF sent in-band

Payload Types

In addition, Cisco gateways provide support for asymmetrical payload types. Payload types can differ between local and remote endpoints. Therefore, the Cisco gateway can transmit one payload type value and receive a different payload type value.

The dtmf-relay h245-signal command relays a more accurate representation of a DTMF digit than does the dtmf-relay h245-alphanumeric command because tone duration information is included along with the digit value. This information is important for applications requiring that a key be pressed for a particular length of time. For example, one popular calling card feature allows the caller to terminate an existing call by pressing the # key for more than 2 seconds and then making a second call without having to hang up in between. This feature is beneficial because the access number and personal identification number (PIN) code do not need to be dialed again. Outside-line access charges, which are common at hotels, may also be avoided.

The dtmf-relay h245-alphanumeric command simply relays DTMF tones as ASCII characters. For instance, the DTMF digit 1 is transported as the ASCII character 1. There is no duration information associated with tones in this mode. When the Cisco H.323 gateway receives a DTMF tone using this method, the gateway generates the tone on the PSTN interface of the call using a fixed duration of 500 ms. All systems that are H.323 Version 2-compliant are required to support the dtmf-relay h245-alphanumeric command, but support of the dtmf-relay h245-signal command is optional.

H.245 Tunneling of DTMF Relay in Conjunction with Fast Connect

Through H.245 tunneling, H.245 messages are encapsulated within H.225 messages without using a separate H.245 TCP connection. When tunneling is enabled, one or more H.245 messages can be encapsulated in any H.225 message. H.245 tunneling is not supported as a stand-alone feature; initiation of H.245 tunneling procedures can be initiated only by using the dtmf-relay command and only from an active fast connect call. Furthermore, if dtmf-relay is configured on a Version 2 VoIP dial peer and the active call has been established by using fast connect, tunneling procedures initiated by the opposite endpoint are accepted and supported.

H.245 tunneling is backward compatible with H.323 Version 1 configurations.

This entry was posted in CallManager and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s