Dual-Tone Multi-Frequency | TelePresence Audio

Dual-Tone Multi-Frequency (DTMF) enables the user to interact with voice prompts using the touch-tone buttons on the telephone to enter digits, *, and # symbols. This enables the user to navigate IVR menus, enter conference numbers and passwords, check their voicemail, and so on. DTMF has been around throughout the history of telephony and has been adapted into the numerous protocols used in IP-based telephony. H.323, Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP) and others all incorporate support for DTMF using one or more methods.

Depending on the protocol in use, there are fundamentally two forms of DTMF signaling:

• In-band: Puts the DTMF tones inside the audio stream
• Out-of-band: Interprets the DTMF tones and converts them into messages carried over the signaling protocol

In the case of SIP, there are two predominant methods for incorporating DTMF support:

• RFC 2833: Defines the RTP payload type used for carrying DTMF tones in-band within the RTP audio stream
• Key-Pad Markup Language (KPML): Defines a method relaying DTMF tones through the SIP signaling protocol

Which method is used for a given call is negotiated through SIP during the session establishment phase and can be RFC 2833, KPML, or none, depending on what type of audio device the TelePresence system connects to.

RFC 2833

RFC 2833 is maintained by the Internet Engineering Task Force (IETF) and was standardized in 2000. It defines a method for carrying DTMF signaling events and other tones and telephony events within RTP packets.

RTP defines a variety of payload types and contains a payload type field within the RTP header to indicate what payload type the packet contains (audio, video, DTMF, and so on). Refer back to Figure 3-8 for details of the RTP header contents. The payload type for DTMF is referred to as a named event. RFC 2833 defines several different named event types; one of those is DTMF events. When a DTMF tone is identified, the encoder translates it into an RTP packet, setting the payload type (PT) field to the numerical number associated with DTMF payload events, and inserting the actual DTMF event into the body of the RTP payload. The numerical identifier used for DTMF events can be negotiated ahead of time during the session establishment period. For example, Cisco devices generally use payload type 97 for DTMF events, but this can be negotiated on a call-by-call basis.

Key-Pad Markup Language

Key-Pad Markup Language (KPML) is also maintained by the IETF and was converted from an IETF Internet draft to a published RFC (RFC 4730) in November 2006. It defines a method for carrying DTMF signaling events with SIP event packages within the SIP signaling protocol.

SIP RFC 3265 defines a method within SIP by which an application can SUBSCRIBE to specific event packages and receive NOTIFY messages whenever such an event occurs. RFC 4730 leverages this SUBSCRIBE/NOTIFY architecture to define a DTMF event package. During the SIP session establishment phase (through the INVITE, 180 TRYING, 183 SESSION PROGRESS, and 200 OK messages), the SIP User Agents advertise support for KPML in the Allowed-Events and Supported headers. After being advertised, the User Agent who wants to receive DTMF events sends a SUBSCRIBE message to the other User Agent indicating that it wants to subscribe to the KMPL event package. The User Agent receiving the SUBSCRIBE request sends a 200 OK acknowledgment to the subscriber. Thereafter, any DTMF event initiated by the User Agent who received the SUBSCRIBE request is sent in a NOTIFY message to the subscriber, contained as an XML document within the body of that NOTIFY message.

Other Protocols

Other protocols have similar approaches for DTMF support. H.323, for example, commonly uses RFC 2833, or H.245 Alpha-Numeric notation, among others. Media Gateway Control Protocol (MGCP) commonly uses RFC 2833, or MGCP-DTMF relay. In the case of Cisco TelePresence, the CUCM handles all the call signaling and deals with convertingbetween the various signaling protocols to enable end-to-end DTMF. For example, if a Cisco TelePresence system called a Cisco Webex audio conferencing bridging service, it would need to traverse an IP-PSTN gateway. For example, if that gateway were running MGCP, there are two ways that DTMF might be configured:

• RFC 2833: If the gateway advertises RFC 2833 support only, the Unified CM would advertise RFC 2833 to the Cisco TelePresence system.
• DTMF-relay: If the gateway advertised DTMF-relay, the CUCM would advertise KPML to the Cisco TelePresence system.

How DTMF Tones Are Processed in Cisco TelePresence

In the case of Cisco TelePresence, the user presses the buttons on the Cisco TelePresence IP Phone, but the Cisco TelePresence Primary (center) codec is the one doing all the SIP signaling and handling all the media; the IP Phone is just the user interface instrument to the system.

The first generation of Cisco TelePresence used the eXtensible Markup Language (XML) programming language as an interface between the Cisco IP Phone and the primary codec. When a user wanted to enter DTMF tones, they pressed the Tones softkey, which would bring up a page where the user could enter the digits they wanted to send and then press the Send softkey. That XML content was then sent to the primary codec over an HTTP session. The codec would read the XML contents and convert them into SIP-KPML messages, or RFC 2833 payloads.

At the time this book was written, Cisco TelePresence was moving away from XML to a newer, more robust method using Java MIDlets. With this method, a small Java application (called a MIDlet) runs on the IP Phone and intercepts the button presses. These button presses are then communicated over a TCP session between the Java MIDlet running on the IP Phone and the primary codec. The codec reads the Java TCP messages and converts them into SIP-KPML messages, or RFC 2833 payloads.

In both cases, the button presses are sent by the IP Phone to the primary codec, and the codec converts them and plays them out onto the network. If RFC 2833 is in use, the primary codec converts the XML or Java MIDlet event into an RTP DTMF event and multiplexes it into the audio RTP stream. If KPML is in use during the SIP session establishment phase, the Unified CM would send a SUBSCRIBE request to the primary codec subscribing to the KPML event package. The primary codec, therefore, converts the XML or Java MIDlet event into an XML document and sends it in a NOTIFY message to the CUCM.