< draft-ietf-avt-rfc2833bis-14.txt   draft-ietf-avt-rfc2833bis-15.txt >
Audio/Video Transport (avt) H. Schulzrinne Audio/Video Transport (avt) H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Obsoletes: 2833 (if approved) T. Taylor Obsoletes: 2833 (if approved) T. Taylor
Expires: December 7, 2006 Nortel Expires: December 17, 2006 Nortel
June 5, 2006 June 15, 2006
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
draft-ietf-avt-rfc2833bis-14 draft-ietf-avt-rfc2833bis-15
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2006. This Internet-Draft will expire on December 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo describes how to carry dual-tone multifrequency (DTMF) This memo describes how to carry dual-tone multifrequency (DTMF)
signaling, other tone signals and telephony events in RTP packets. signaling, other tone signals and telephony events in RTP packets.
It obsoletes RFC 2833. It obsoletes RFC 2833.
This memo captures and expands upon the basic framework defined in This memo captures and expands upon the basic framework defined in
RFC 2833, but retains only the most basic event codes. It sets up an RFC 2833, but retains only the most basic event codes. It sets up an
IANA registry to which other event code assignments may be added. IANA registry to which other event code assignments may be added.
Companion documents add event codes to this registry relating to Companion documents add event codes to this registry relating to
modem, fax, text telephony, and channel-associated signalling events. modem, fax, text telephony, and channel-associated signalling events.
The remainder of the event codes defined in RFC 2833 are available The remainder of the event codes defined in RFC 2833 are
for reassignment. See Appendix A for details, which include conditionally reserved in case other documents revive their use. See
reassignment of some event codes that apparently had no Section 7 and Appendix A for details.
implementation in the past and duplicated the meaning of other codes
that have been retained.
[RFC Editor: please change the Informative reference following RFC [RFC Editor: please change the Informative reference following RFC
4103 to the RFC number assigned to 4103 to the RFC number assigned to
draft-ietf-avt-rfc2833bisdata-07.txt, one of the "companion draft-ietf-avt-rfc2833bisdata-08.txt, one of the "companion
documents" referred to above.] documents" referred to above.]
In terms of procedure, this document provides a number of In terms of procedure, this document provides a number of
clarifications to the original document. However, it specifically clarifications to the original document. However, it specifically
differs from RFC 2833 by removing the requirement that all compliant differs from RFC 2833 by removing the requirement that all compliant
implementations support the DTMF events. Instead, compliant implementations support the DTMF events. Instead, compliant
implementations taking part in out-of-band negotiations of media implementations taking part in out-of-band negotiations of media
stream content indicate what events they support. As well, this memo stream content indicate what events they support. As well, this memo
adds three new procedures to the RFC 2833 framework: subdivision of adds three new procedures to the RFC 2833 framework: subdivision of
long events into segments, reporting of multiple events in a single long events into segments, reporting of multiple events in a single
skipping to change at page 3, line 51 skipping to change at page 3, line 51
4.3.2. Marker Bit . . . . . . . . . . . . . . . . . . . . . . 30 4.3.2. Marker Bit . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3. Payload Format . . . . . . . . . . . . . . . . . . . . 30 4.3.3. Payload Format . . . . . . . . . . . . . . . . . . . . 30
4.3.4. Optional media type Parameters . . . . . . . . . . . . 31 4.3.4. Optional media type Parameters . . . . . . . . . . . . 31
4.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1. Sending Procedures . . . . . . . . . . . . . . . . . . 32 4.4.1. Sending Procedures . . . . . . . . . . . . . . . . . . 32
4.4.2. Receiving Procedures . . . . . . . . . . . . . . . . . 32 4.4.2. Receiving Procedures . . . . . . . . . . . . . . . . . 32
4.4.3. Handling Of Congestion . . . . . . . . . . . . . . . . 32 4.4.3. Handling Of Congestion . . . . . . . . . . . . . . . . 32
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7.1. Media type registrations . . . . . . . . . . . . . . . . . 44 7.1. Media type registrations . . . . . . . . . . . . . . . . . 45
7.1.1. Registration of media type audio/telephone-event . . . 44 7.1.1. Registration of media type audio/telephone-event . . . 45
7.1.2. Registration of media type audio/tone . . . . . . . . 46 7.1.2. Registration of media type audio/tone . . . . . . . . 47
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . . 49 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Summary of Changes from RFC 2833 . . . . . . . . . . 52 Appendix A. Summary of Changes from RFC 2833 . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 57
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
This document uses the following abbreviations: This document uses the following abbreviations:
skipping to change at page 43, line 7 skipping to change at page 43, line 7
In some deployments it may be preferable to use other means to In some deployments it may be preferable to use other means to
provide protection equivalent to that provided by SRTP. provide protection equivalent to that provided by SRTP.
Provided that gateway design includes robust, low overhead tone Provided that gateway design includes robust, low overhead tone
generation, this payload type does not exhibit any significant non- generation, this payload type does not exhibit any significant non-
uniformity in the receiver side computational complexity for packet uniformity in the receiver side computational complexity for packet
processing to cause a potential denial-of-service threat. processing to cause a potential denial-of-service threat.
7. IANA Considerations 7. IANA Considerations
This document updates the descriptions of two new RTP payload This document updates the descriptions of two RTP payload formats,
formats, named telephone-event and tone, and associated Internet 'telephone-event' and 'tone', and associated Internet media types,
media types, audio/telephone-event and audio/tone. It also documents audio/telephone-event and audio/tone. It also documents the event
the event codes for DTMF tone events. codes for DTMF tone events.
Within the audio/telephone-event type, events MUST be registered with Within the audio/telephone-event type, events MUST be registered with
IANA. Registrations are subject to the policies "Specification IANA. Registrations are subject to the policies "Specification
Required" and "Expert Review" as defined in RFC 2434 [4]. The IETF- Required" and "Expert Review" as defined in RFC 2434 [4]. The IETF-
appointed expert must ensure that: appointed expert must ensure that:
a. the meaning and application of the proposed events is clearly a. the meaning and application of the proposed events is clearly
documented; documented;
b. the events cannot be represented by existing event codes, b. the events cannot be represented by existing event codes,
possibly with some minor modification of event definitions; possibly with some minor modification of event definitions;
c. the number of events is the minimum necessary to fulfil the c. the number of events is the minimum necessary to fulfil the
purpose of their application(s). purpose of their application(s).
The expert is further responsible for providing guidance on the
allocation of event codes to the proposed events. Specifically, the
expert must indicate whether the event appears to be the same as one
defined in RFC 2833 but not specified in any new document. In this
case the event code specified in RFC 2833 for that event SHOULD be
assigned to the proposed event. Otherwise event codes MUST be
assigned from the set of available event codes listed below. If this
set is exhausted, the criterion for assignment from the reserved set
of event codes is to first assign those that appear to have the
lowest probability of being revived in their RFC 2833 meaning in a
new specification.
The documentation for each event MUST indicate whether the event is a The documentation for each event MUST indicate whether the event is a
state, tone, or other type of event (e.g., an out-of-band electrical state, tone, or other type of event (e.g., an out-of-band electrical
event such as on-hook or an indication that will not itself be played event such as on-hook or an indication that will not itself be played
out as tones at the receiving end). For tone events, the out as tones at the receiving end). For tone events, the
documentation MUST indicate whether the volume field is applicable or documentation MUST indicate whether the volume field is applicable or
must be set to 0. must be set to 0.
In view of the tradeoffs between the different reliability mechanisms In view of the tradeoffs between the different reliability mechanisms
discussed in Section 2.6, documentation of specific events SHOULD discussed in Section 2.6, documentation of specific events SHOULD
include a discussion of the appropriate design decisions for the include a discussion of the appropriate design decisions for the
applications of those events. applications of those events.
Legal event codes range from 0 to 255. The initial registry content Legal event codes range from 0 to 255. The initial registry content
is shown in Table 7, and consists of the sixteen events defined in is shown in Table 7, and consists of the sixteen events defined in
Section 3 of this document. Codes 32-41, 43, 46, 48-49, and 52-68 Section 3 of this document. The remaining codes have the following
are reserved for events defined in [16]. Codes 128-142, 144-159, disposition:
167-168, and 174-205 are reserved for [17]. All remaining codes are
available for assignment as required. o codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
for assignment;
o codes 23-40, 49, and 52-63 are reserved for events defined in
[16];
o codes 121-137 and 174-205 are reserved for for events defined in
[17];
o codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
in the first instance for specifications reviving the
corresponding RFC 2833 events, and in the second instance for
general assignment after all other codes have been assigned.
+------------+--------------------------------+------------+ +------------+--------------------------------+------------+
| Event Code | Event Name | Reference | | Event Code | Event Name | Reference |
+------------+--------------------------------+------------+ +------------+--------------------------------+------------+
| 0 | DTMF digit "0" | <This RFC> | | 0 | DTMF digit "0" | <This RFC> |
| | | | | | | |
| 1 | DTMF digit "1" | <This RFC> | | 1 | DTMF digit "1" | <This RFC> |
| | | | | | | |
| 2 | DTMF digit "2" | <This RFC> | | 2 | DTMF digit "2" | <This RFC> |
| | | | | | | |
skipping to change at page 53, line 20 skipping to change at page 54, line 20
distribution. distribution.
Finally, this document establishes an IANA registry for event codes Finally, this document establishes an IANA registry for event codes
and establishes criteria for their documentation. This document and establishes criteria for their documentation. This document
provides an initial population for the new registry, consisting provides an initial population for the new registry, consisting
solely of the sixteen DTMF events. Two companion documents [16] and solely of the sixteen DTMF events. Two companion documents [16] and
[17] describe events related to modems, fax, and text telephony and [17] describe events related to modems, fax, and text telephony and
to channel-associated telephony signalling respectively. Some to channel-associated telephony signalling respectively. Some
changes were made to the latter because of errors and redundancies in changes were made to the latter because of errors and redundancies in
the RFC 2833 assignments. The remaining events defined in RFC 2833 the RFC 2833 assignments. The remaining events defined in RFC 2833
are deprecated and their codes made available for reassignment are deprecated because they do not appear to have been implemented,
because they do not appear to have been implemented, but the registry but their codes have been conditionally reserved in case any of them
remains open should any of them be needed in the future. Table 8 is needed in the future. Table 8 indicates the disposition of the
indicates the disposition of the event codes in detail. Event codes event codes in detail. Event codes not mentioned in this table were
not mentioned in this table were not allocated by RFC 2833 and not allocated by RFC 2833 and continue to be unused.
continue to be unused.
+---------+-----------------------+---------------------------------+ +------------+----------------------------------------+-------------+
| Event | RFC 2833 Description | Disposition | | Event | RFC 2833 Description | Disposition |
| Codes | | | | Codes | | |
+---------+-----------------------+---------------------------------+ +------------+----------------------------------------+-------------+
| 0-15 | DTMF digits | This RFC | | 0-15 | DTMF digits | This RFC |
| | | | | | | |
| 16 | Line flash | Code available for reassignment | | 16 | Line flash (deprecated) | Reserved |
| | (deprecated) | | | | | |
| | | | | 23-31 | Unused | [16] |
| 32-49 | Data and fax | [16], with some changes and 42, | | | | |
| | | 44, 45, 47 are now available | | 32-40 | Data and fax | [16] |
| | | | | | | |
| 50-63 | Unused | [16] | | 41-48 | Data and fax (V.8bis, deprecated) | Reserved |
| | | | | | | |
| 64-68 | E.182 line events | Codes reassigned in [16] | | 52-63 | Unused | [16] |
| | (deprecated) | | | | | |
| | | | | 64-89 | E.182 line events (deprecated) | Reserved |
| 69-89 | E.182 line events | Codes available for | | | | |
| | (deprecated) | reassignment | | 96-112 | Country-specific line events | Reserved |
| | | | | | (deprecated) | |
| 96-112 | Country-specific line | Codes available for | | | | |
| | events (deprecated) | reassignment | | 121-127 | Unused | [17] |
| | | | | | | |
| 128-137 | Trunks: MF 0-9 | [17] | | 128-137 | Trunks: MF 0-9 | [17] |
| | | | | | | |
| 138-142 | Trunks: other MF | [17], some changes | | 138-143 | Trunks: other MF (deprecated) | Reserved |
| | | | | | | |
| 143 | Trunks: MF S3 | Code available for reassignment | | 144-159 | Trunks: ABCD signalling | [17] |
| | (deprecated) | | | | | |
| | | | | 160-168 | Trunks: various (deprecated) | Reserved |
| 144-159 | Trunks: ABCD | [17] | | | | |
| | signalling | | | 170-173 | Trunks: various (deprecated) | Reserved |
| | | | | | | |
| 160-173 | Trunks: various | Codes available except for 167, | | 174-205 | Unused | [17] |
| | (mostly deprecated) | 168 | +------------+----------------------------------------+-------------+
| | | |
| 174-205 | Unused | [17] |
+---------+-----------------------+---------------------------------+
Table 8: Disposition of RFC 2833-defined event codes Table 8: Disposition of RFC 2833-defined event codes
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia U. Columbia U.
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
 End of changes. 11 change blocks. 
72 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/