JEP-0181: Jingle DTMF

This document specifies an XML format for encapsulating DTMF data in informational messages sent within the context of Jingle audio interactions.

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Standards Track
Number: 0181
Version: 0.1
Last Updated: 2006-03-23
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0166
Supersedes: None
Superseded By: None
Short Name: jingle-dtmf
Wiki Page: < DTMF (JEP-0181)>

Author Information

Peter Saint-Andre


Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction
2. Format
3. Security Considerations
4. IANA Considerations
5. Jabber Registrar Considerations
5.1. Protocol Namespaces
6. XML Schema
Revision History

1. Introduction

Traditional telephony systems use Dual Tone Multi-Frequency (DTMF) for dialing and to issue commands such as those used in Interactive Voice Response (IVR) applications. Internet telephony systems also use DTMF tones for interoperability with the public switched telephone network (PSTN). XMPP clients that use Jingle [1] for voice chat (see Jingle Audio Media Description Format [2]) SHOULD use the native DTMF format for the relevant transport method, for example RFC 2833 [3] for Jingle RTP-ICE Transport Method [4] and the native IAX format for Jingle IAX Transport Method [5]. This document specifies an XML format for use as a fallback when transport-native DTMF formats are not available.

2. Format

The format for the XML DTMF format is as follows:

Example 1. Basic DTMF Format

<dtmf xmlns=''>
  <tone code='integer' duration='integer'/>
  <tone ... />

The <dtmf/> element MUST contain at least one <tone/> element and MAY contain more than one <tone/> element.

The <tone/> element MUST possess a 'code' attribute that specifies the tone(s) to be generated and MAY possess a 'duration' attribute that specifies the duration of each tone in milliseconds.

The value of the 'code' attribute MUST be one or more instances of the following characters: 1, 2, 3, 4, 5, 6, 7, 8, 9, *, 0, or #. [6]

The value of the 'duration' attribute MUST be a positive integer; the integer MUST be greater than 50 (in accordance with ANSI T1.401-1988), SHOULD be at least 70, and SHOULD NOT be significantly more than 120.

The <dtmf> element SHOULD be sent as the payload of a Jingle media-info message as illustrated in the following example.

Example 2. Entity Sends DTMF Message

<iq from=''
  <jingle xmlns=''
    <dtmf xmlns=''>
      <tone code='76636'/>

3. Security Considerations

This document introduces no known security vulnerabilities.

4. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

5. Jabber Registrar Considerations

5.1 Protocol Namespaces

The Jabber Registrar [8] shall include '' in its registry of protocol namespaces.

6. XML Schema

<?xml version='1.0' encoding='UTF-8'?>


  <xs:element name='dtmf'>
        <xs:element ref='tone' minOccurs='1' maxOccurs='unbounded'/>

  <xs:element name='tone'>
        <xs:extension base='empty'>
          <xs:attribute name='code' type='xs:string' use='required'/>
          <xs:attribute name='duration' type='xs:positiveInteger' use='optional'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>



1. JEP-0166: Jingle <>.

2. JEP-0167: Jingle Audio Media Description Format <>.

3. RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals <>.

4. JEP-0176: Jingle RTP-ICE Transport Method <>.

5. JEP-0179: Jingle IAX Transport Method <>.

6. Although the characters A, B, C, and D were originally defined as part of DTMF, they were never deployed to consumers and were used only for control purposes at private branch exchanges (PBXs) and central office operator stations; therefore they MUST NOT be sent.

7. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <>.

8. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <>.

Revision History

Version 0.1 (2006-03-23)

Initial JEP version.


Version 0.0.1 (2006-03-21)

First draft. (psa)