idnits 2.17.1 draft-ietf-avt-rfc2833bis-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2274. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 15, 2006) is 6526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '3') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3555 (ref. '7') (Obsoleted by RFC 4855, RFC 4856) ** Obsolete normative reference: RFC 4288 (ref. '9') (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '12') (Obsoleted by RFC 4733, RFC 4734) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport (avt) H. Schulzrinne 3 Internet-Draft Columbia U. 4 Obsoletes: 2833 (if approved) T. Taylor 5 Expires: December 17, 2006 Nortel 6 June 15, 2006 8 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 9 draft-ietf-avt-rfc2833bis-15 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 17, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo describes how to carry dual-tone multifrequency (DTMF) 43 signaling, other tone signals and telephony events in RTP packets. 44 It obsoletes RFC 2833. 46 This memo captures and expands upon the basic framework defined in 47 RFC 2833, but retains only the most basic event codes. It sets up an 48 IANA registry to which other event code assignments may be added. 50 Companion documents add event codes to this registry relating to 51 modem, fax, text telephony, and channel-associated signalling events. 52 The remainder of the event codes defined in RFC 2833 are 53 conditionally reserved in case other documents revive their use. See 54 Section 7 and Appendix A for details. 56 [RFC Editor: please change the Informative reference following RFC 57 4103 to the RFC number assigned to 58 draft-ietf-avt-rfc2833bisdata-08.txt, one of the "companion 59 documents" referred to above.] 61 In terms of procedure, this document provides a number of 62 clarifications to the original document. However, it specifically 63 differs from RFC 2833 by removing the requirement that all compliant 64 implementations support the DTMF events. Instead, compliant 65 implementations taking part in out-of-band negotiations of media 66 stream content indicate what events they support. As well, this memo 67 adds three new procedures to the RFC 2833 framework: subdivision of 68 long events into segments, reporting of multiple events in a single 69 packet, and the concept and reporting of state events. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.3. Potential Applications . . . . . . . . . . . . . . . . . . 6 77 1.4. Events, States, Tone Patterns, and Voice Encoded Tones . . 7 78 2. RTP Payload Format for Named Telephone Events . . . . . . . . 9 79 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 80 2.2. Use of RTP Header Fields . . . . . . . . . . . . . . . . . 9 81 2.2.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . 9 82 2.2.2. Marker Bit . . . . . . . . . . . . . . . . . . . . . . 9 83 2.3. Payload Format . . . . . . . . . . . . . . . . . . . . . . 9 84 2.3.1. Event Field . . . . . . . . . . . . . . . . . . . . . 10 85 2.3.2. E ("End") Bit . . . . . . . . . . . . . . . . . . . . 10 86 2.3.3. R Bit . . . . . . . . . . . . . . . . . . . . . . . . 10 87 2.3.4. Volume Field . . . . . . . . . . . . . . . . . . . . . 10 88 2.3.5. Duration Field . . . . . . . . . . . . . . . . . . . . 10 89 2.4. Optional media type Parameters . . . . . . . . . . . . . . 11 90 2.4.1. Relationship to SDP . . . . . . . . . . . . . . . . . 11 91 2.5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 12 92 2.5.1. Sending Procedures . . . . . . . . . . . . . . . . . . 12 93 2.5.2. Receiving Procedures . . . . . . . . . . . . . . . . . 16 94 2.6. Congestion and Performance . . . . . . . . . . . . . . . . 20 95 2.6.1. Performance Requirements . . . . . . . . . . . . . . . 20 96 2.6.2. Reliability Mechanisms . . . . . . . . . . . . . . . . 21 97 2.6.3. Adjusting To Congestion . . . . . . . . . . . . . . . 22 98 3. Specification of Event Codes For DTMF Events . . . . . . . . . 25 99 3.1. DTMF Applications . . . . . . . . . . . . . . . . . . . . 25 100 3.2. DTMF Events . . . . . . . . . . . . . . . . . . . . . . . 26 101 3.3. Congestion Considerations . . . . . . . . . . . . . . . . 27 102 4. RTP Payload Format for Telephony Tones . . . . . . . . . . . . 28 103 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 28 104 4.2. Examples of Common Telephone Tone Signals . . . . . . . . 28 105 4.3. Use of RTP Header Fields . . . . . . . . . . . . . . . . . 29 106 4.3.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . 29 107 4.3.2. Marker Bit . . . . . . . . . . . . . . . . . . . . . . 30 108 4.3.3. Payload Format . . . . . . . . . . . . . . . . . . . . 30 109 4.3.4. Optional media type Parameters . . . . . . . . . . . . 31 110 4.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 32 111 4.4.1. Sending Procedures . . . . . . . . . . . . . . . . . . 32 112 4.4.2. Receiving Procedures . . . . . . . . . . . . . . . . . 32 113 4.4.3. Handling Of Congestion . . . . . . . . . . . . . . . . 32 114 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 116 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 117 7.1. Media type registrations . . . . . . . . . . . . . . . . . 45 118 7.1.1. Registration of media type audio/telephone-event . . . 45 119 7.1.2. Registration of media type audio/tone . . . . . . . . 47 120 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 121 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 122 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50 123 9.2. Informative References . . . . . . . . . . . . . . . . . . 50 124 Appendix A. Summary of Changes from RFC 2833 . . . . . . . . . . 53 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 126 Intellectual Property and Copyright Statements . . . . . . . . . . 57 128 1. Introduction 130 1.1. Terminology 132 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 133 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 134 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 136 This document uses the following abbreviations: 138 ANSam Answer tone (amplitude modulated) [24] 140 DTMF Dual-Tone Multifrequency [10] 142 IVR Integrated Voice Response unit 144 PBX Private branch exchange (telephone system) 146 PSTN Public Switched (circuit) Telephone Network 148 RTP Real-time Transport Protocol [6] 150 SDP Session Description Protocol [3] 152 1.2. Overview 154 This memo defines two RTP [6] payload formats, one for carrying dual- 155 tone multifrequency (DTMF) digits and other line and trunk signals as 156 events (Section 2), and a second one to describe general multi- 157 frequency tones in terms only of their frequency and cadence 158 (Section 4). Separate RTP payload formats for telephony tone signals 159 are desirable since low-rate voice codecs cannot be guaranteed to 160 reproduce these tone signals accurately enough for automatic 161 recognition. In addition, tone properties such as the phase 162 reversals in the ANSam tone will not survive speech coding. Defining 163 separate payload formats also permits higher redundancy while 164 maintaining a low bit rate. Finally, some telephony events such as 165 "on-hook" occur out-of-band and cannot be transmitted as tones. 167 The remainder of this section provides the motivation for defining 168 the payload types described in this document. Section 2 defines the 169 payload format and associated procedures for use of named events. 170 Section 3 describes the events for which event codes are defined in 171 this document. Section 4 describes the payload format and associated 172 procedures for tone representations. Section 5 provides some 173 examples of encoded events, tones, and combined payloads. Section 6 174 deals with security considerations. Section 7 defines the IANA 175 requirements for registration of event codes for named telephone 176 events, establishes the initial content of that registry, and 177 provides the media type registrations for the two payload formats. 178 Appendix A describes the changes from RFC 2833 [12] and in particular 179 indicates the disposition of the event codes defined in [12]. 181 1.3. Potential Applications 183 The payload formats described here may be useful in a number of 184 different scenarios. 186 On the sending side, there are two basic possibilities: either the 187 sending side is an end system which originates the signals itself, or 188 it is a gateway with the task of propagating incoming telephone 189 signals into the Internet. 191 On the receiving side there are more possibilities. The first is 192 that the receiver must propagate tone signalling accurately into the 193 PSTN for machine consumption. One example of this is a gateway 194 passing DTMF tones to an IVR. In this scenario, frequencies, 195 amplitudes, tone durations, and the durations of pauses between tones 196 are all significant, and individual tone signals must be delivered 197 reliably and in order. 199 In a second receiving scenario, the receiver must play out tones for 200 human consumption. Typically, rather than a series of tone signals 201 each with its own meaning, the content will consist of a single tone 202 played out continuously or a single sequence of tones and possibly 203 silence, repeated cyclically for some period of time. Often the end 204 of the tone playout will be triggered by an event fed back in the 205 other direction, using either in- or out-of-band means. Examples of 206 this are dial tone or busy tone. 208 The relationship between position in the network and the tones to be 209 played out is a complicating factor in this scenario. In the phone 210 network, tones are generated at different places, depending on the 211 switching technology and the nature of the tone. This determines, 212 for example, whether a person making a call to a foreign country 213 hears her local tones she is familiar with or the tones as used in 214 the country called. 216 For analog lines, dial tone is always generated by the local switch. 217 ISDN terminals may generate dial tone locally and then send a Q.931 218 [22] SETUP message containing the dialed digits. If the terminal 219 just sends a SETUP message without any Called Party digits, then the 220 switch does digit collection (provided by the terminal as KEYPAD key 221 press digit information within Called Party or Keypad Facility IEs of 222 INFORMATION messages), and provides dial tone over the B-channel. 223 The terminal can either use the audio signal on the B-channel or can 224 use the Q.931 messages to trigger locally generated dial tone. 226 Ringing tone (also called ringback tone) is generated by the local 227 switch at the callee, with a one-way voice path opened up as soon as 228 the callee's phone rings. (This reduces the chance of clipping the 229 called party's response just after answer. It also permits pre- 230 answer announcements or in-band call-progress indications to reach 231 the caller before or in lieu of a ringing tone.) Congestion tone and 232 special information tones can be generated by any of the switches 233 along the way, and may be generated by the caller's switch based on 234 ISUP messages received. Busy tone is generated by the caller's 235 switch, triggered by the appropriate ISUP message, for analog 236 instruments, or the ISDN terminal. 238 In the third scenario, an end system is directly connected to the 239 Internet and processes the incoming media stream directly. There is 240 no need to regenerate tone signals, so that time alignment and power 241 levels are not relevant. These systems rely on sending systems to 242 generate events in place of tones and do not perform their own audio 243 waveform analysis. An example of such a system is an Internet 244 interactive voice-response (IVR) system. 246 In circumstances where exact timing alignment between the audio 247 stream and the DTMF digits or other events is not important and data 248 is sent unicast, as in the IVR example, it may be preferable to use a 249 reliable control protocol rather than RTP packets. In those 250 circumstances, this payload format would not be used. 252 Note that in a number of these cases it is possible that the gateway 253 or end system will be both a sender and receiver of telephone 254 signals. Sometimes the same class of signals will be sent as 255 received -- in the case of "RTP trunking" or voiceband data, for 256 instance. In other cases, such as that of an end system serving 257 analogue lines, the signals sent will be in a different class from 258 those received. 260 1.4. Events, States, Tone Patterns, and Voice Encoded Tones 262 This document provides the means for in-band transport over the 263 Internet of two broad classes of signalling information: in-band 264 tones or tone sequences, and signals sent out-of-band in the PSTN. 265 Tone signals can be carried using any of the three methods listed 266 below. Depending on the application, it may be desirable to carry 267 the signalling information in more than one form at once. 269 1. The gateway or end system can upspeed to a higher-bandwidth codec 270 such as G.711 [19] when tone signals are to be conveyed. See new 271 ITU-T Recommendation V.152 [26] for a formal treatment of this 272 approach. Alternatively, for FAX, text, or modem signals 273 respectively, a specialized transport such as T.38 [23], RFC 4103 274 [15], or V.150.1 modem relay [25] may be used. Finally, 64 275 kbit/s channels may be carried transparently using the RFC 4040 276 CLEARMODE payload type [14]. These methods are out of scope of 277 the present document, but may be used along with the payload 278 types defined here. 280 2. The sending gateway can simply measure the frequency components 281 of the voice band signals and transmit this information to the 282 RTP receiver using the tone representation defined in this 283 document (Section 4). In this mode, the gateway makes no attempt 284 to discern the meaning of the tones, but simply distinguishes 285 tones from speech signals. An end system may use the same 286 approach using configured rather than measured frequencies. 288 All tone signals in use in the PSTN and meant for human 289 consumption are sequences of simple combinations of sine waves, 290 either added or modulated. (However, some modem signals such as 291 the ANSam tone [24] or systems dependent on phase shift keying 292 cannot be conveyed so simply.) 294 3. As a third option, a sending gateway can recognize tones such as 295 ringing or busy tone or DTMF digit '0', and transmit a code which 296 identifies them using the telephone-event payload defined in this 297 document (Section 2). The receiver then produces a tone signal 298 or other indication appropriate to the signal. Generally, since 299 the recognition of signals at the sender often depends on their 300 on/off pattern or the sequence of several tones, this recognition 301 can take several seconds. On the other hand, the gateway may 302 have access to the actual signaling information that generates 303 the tones and thus can generate the RTP packet immediately, 304 without the detour through acoustic signals. 306 The third option (use of named events) is the only feasible method 307 for transmitting out-of-band PSTN signals as content within RTP 308 sessions. 310 2. RTP Payload Format for Named Telephone Events 312 2.1. Introduction 314 The RTP payload format for named telephone events is designated as 315 "telephone-event", the media type as "audio/telephone-event". In 316 accordance with current practice, this payload format does not have a 317 static payload type number, but uses a RTP payload type number 318 established dynamically and out-of-band. The default clock frequency 319 is 8000 Hz, but the clock frequency can be redefined when assigning 320 the dynamic payload type. 322 Named telephone events are carried as part of the audio stream, and 323 MUST use the same sequence number and time-stamp base as the regular 324 audio channel to simplify the generation of audio waveforms at a 325 gateway. The named telephone events payload type can be considered 326 to be a very highly-compressed audio codec, and is treated the same 327 as other codecs. 329 2.2. Use of RTP Header Fields 331 2.2.1. Timestamp 333 The event duration described in Section 2.5 extends forwards from the 334 time given by the RTP timestamp. For events that span multiple RTP 335 packets, the RTP timestamp identifies the beginning of the event, 336 i.e., several RTP packets may carry the same timestamp. For long- 337 lasting events that have to be split into segments (see below, 338 Section 2.5.1.3), the timestamp indicates the beginning of the 339 segment. 341 2.2.2. Marker Bit 343 The RTP marker bit indicates the beginning of a new event. For long- 344 lasting events that have to be split into segments (see below, 345 Section 2.5.1.3), only the first segment will have the marker bit 346 set. 348 2.3. Payload Format 350 The payload format for named telephone events is shown in Figure 1. 352 0 1 2 3 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | event |E|R| volume | duration | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 1: Payload Format for Named Events 359 2.3.1. Event Field 361 The event field is a number between 0 and 255 identifying a specific 362 telephony event. An IANA registry of event codes for this field has 363 been established (see IANA Considerations, Section 7). The initial 364 content of this registry consists of the events defined in Section 3. 366 2.3.2. E ("End") Bit 368 If set to a value of one, the "end" bit indicates that this packet 369 contains the end of the event. For long-lasting events that have to 370 be split into segments (see below, Section 2.5.1.3), only the final 371 packet for the final segment will have the "E" bit set. 373 2.3.3. R Bit 375 This field is reserved for future use. The sender MUST set it to 376 zero, the receiver MUST ignore it. 378 2.3.4. Volume Field 380 For DTMF digits and other events representable as tones, this field 381 describes the power level of the tone, expressed in dBm0 after 382 dropping the sign. Power levels range from 0 to -63 dBm0. Thus, 383 larger values denote lower volume. This value is defined only for 384 events for which the documentation indicates that volume is 385 applicable. For other events, the sender MUST set volume to zero and 386 the receiver MUST ignore the value. 388 2.3.5. Duration Field 390 The duration field indicates the duration of the event or segment 391 being reported, in timestamp units, expressed as an unsigned integer 392 in network byte order. For a non-zero value, the event or segment 393 began at the instant identified by the RTP timestamp and has so far 394 lasted as long as indicated by this parameter. The event may or may 395 not have ended. If the event duration exceeds the maximum 396 representable by the duration field, the event is split into several 397 contiguous segments as described below (Section 2.5.1.3). 399 The special duration value of zero is reserved to indicate that the 400 event lasts "forever", i.e., is a state and is considered to be 401 effective until updated. A sender MUST NOT transmit a zero duration 402 for events other than those defined as states. The receiver SHOULD 403 ignore an event report with zero duration if the event is not a 404 state. 406 Events defined as states MAY contain a non-zero duration, indicating 407 that the sender intends to refresh the state before the time duration 408 has elapsed ("soft state"). 410 For a sampling rate of 8000 Hz, the duration field is sufficient 411 to express event durations of up to approximately 8 seconds. 413 2.4. Optional media type Parameters 415 As indicated in the media type registration for named events in 416 Section 7.1.1, the telephone-event media type supports two optional 417 parameters: the "events" parameter, and the "rate" parameter. 419 The "events" parameter lists the events supported by the 420 implementation. Events are listed as one or more comma-separated 421 elements. Each element can either be a single integer providing the 422 value of an event code or an integer followed by a hyphen and a 423 larger integer, presenting a range of consecutive event code values. 424 The list does not have to be sorted. No white space is allowed in 425 the argument. The union of all of the individual event codes and 426 event code ranges designates the complete set of event numbers 427 supported by the implementation. 429 The "rate" parameter describes the sampling rate, in Hertz, and hence 430 the units for the RTP timestamp and event duration fields. The 431 number is written as an integer. If omitted, the default value is 432 8000 Hz. 434 2.4.1. Relationship to SDP 436 The recommended mapping of media type optional parameters to SDP is 437 given in section 3 of RFC 3555 [7]. The "rate" media type parameter 438 for the named event payload type follows this convention: it is 439 expressed as usual as the component of the a=rtpmap: 440 attribute line. 442 The "events" media type parameter deviates from the convention 443 suggested in RFC 3555 because it omits the string "events=" before 444 the list of supported events. 446 a=fmtp: 448 The list of values has the format and meaning described above. 450 For example, if the payload format uses the payload type number 100, 451 and the implementation can handle the DTMF tones (events 0 through 452 15) and the dial and ringing tones (assuming as an example that these 453 were defined as events with codes 66 and 70 respectively), it would 454 include the following description in its SDP message: 456 m=audio 12346 RTP/AVP 100 457 a=rtpmap:100 telephone-event/8000 458 a=fmtp:100 0-15,66,70 460 The following sample media type definition corresponds to the SDP 461 example above: 463 audio/telephone-event;events="0-15,66,70";rate="8000" 465 2.5. Procedures 467 This section defines the procedures associated with the named event 468 payload type. Additional procedures may be specified in the 469 documentation associated with specific event codes. 471 2.5.1. Sending Procedures 473 2.5.1.1. Negotiation of Payloads 475 Events are usually sent in combination with or alternating with other 476 payload types. Payload negotiation may specify separate event and 477 other payload streams, or may specify a combined stream that mixes 478 other payload types with events using RFC 2198 [2] redundancy 479 headers. The purpose of using a combined stream may be for debugging 480 or to ease the transition between general audio and events. 482 Negotiation of payloads between sender and receiver is achieved by 483 out-of-band means, using SDP, for example. 485 The sender SHOULD indicate what events it supports, using the 486 optional "events" parameter associated with the telephone-events 487 media type. If the sender receives an "events" parameter from the 488 receiver, it MUST restrict the set of events it sends to those listed 489 in the received "events" parameter. For backward compatibility, if 490 no "events" parameter is received, the sender SHOULD assume support 491 for the DTMF events 0-15 but for no other events. 493 Events MAY be sent in combination with older events using RFC 2198 494 [2] redundancy. Section 2.5.1.4 describes how this can be used to 495 avoid packet and RTP header overheads when retransmitting final event 496 reports. Section 2.6 discusses the use of additional levels of RFC 497 2198 redundancy to increase the probability that at least one copy of 498 the report of the end of an event reaches the receiver. The 499 following SDP shows an example of such usage, where G.711 audio 500 appears in a separate stream, and the primary component of the 501 redundant payload is events. 503 m=audio 12344 RTP/AVP 99 504 a=rtpmap:99 pcmu/8000 505 m=audio 12346 RTP/AVP 100 101 506 a=rtpmap:100 red/8000/1 507 a=fmtp:100 101/101/101 508 a=rtpmap:101 telephone-event/8000 509 a=fmtp:101 0-15 511 When used in accordance with the offer-answer model (RFC 3264 [5]), 512 the SDP a=ptime: attribute indicates the packetization period that 513 the author of the session description expects when receiving media. 514 This value does not have to be the same in both directions. The 515 appropriate period may vary with the application, since increased 516 packetization periods imply increased end-to-end response times in 517 instances where one end responds to events reported from the other. 519 Negotiation of telephone-events sessions using SDP MAY specify such 520 differences by separating events corresponding to different 521 applications into different streams. In the example below, events 522 0-15 are DTMF events, which have a fairly wide tolerance on timing. 523 Events 32-49 and 52-60 are events related to data transmission and 524 are subject to end-to-end response time considerations. As a result, 525 they are assigned a smaller packetization period than the DTMF 526 events. 528 m=audio 12344 RTP/AVP 99 529 a=rtpmap:99 telephone-event/8000 530 a=fmtp:99 0-15 531 a=ptime:50 532 m=audio 12346 RTP/AVP 100 533 a=rtpmap:100 telephone-event/8000 534 a=fmtp:100 32-49,52-60 535 a=ptime:30 537 For further discussion of packetization periods see Section 2.6.3. 539 2.5.1.2. Transmission of Event Packets 541 DTMF digits and other named telephone events are carried as part of 542 the audio stream, and MUST use the same sequence number and time- 543 stamp base as the regular audio channel to simplify the generation of 544 audio waveforms at a gateway. 546 An audio source SHOULD start transmitting event packets as soon as it 547 recognizes an event, and continue to send updates until the event has 548 ended. The update packets MUST have the same RTP timestamp value as 549 the initial packet for the event, but the duration MUST be increased 550 to reflect the total cumulative duration since the beginning of the 551 event. 553 The first packet for an event MUST have the "M" bit set. The final 554 packet for an event MUST have the "E" bit set, but setting of the "E" 555 bit MAY be deferred until the final packet is retransmitted (see 556 Section 2.5.1.4). Intermediate packets for an event MUST NOT have 557 either the "M" bit or the "E" bit set. 559 Sending of a packet with the "E" bit set is OPTIONAL if the packet 560 reports two events which are defined as mutually exclusive states, or 561 if the final packet for one state is immediately followed by a packet 562 reporting a mutually exclusive state. (For events defined as states, 563 the appearance of a mutually exclusive state implies the end of the 564 previous state.) 566 A source has wide latitude as to how often it sends event updates. A 567 natural interval is the spacing between non-event audio packets. 568 (Recall that a single RTP packet can contain multiple audio frames 569 for frame-based codecs and that the packet interval can vary during a 570 session.) Alternatively, a source MAY decide to use a different 571 spacing for event updates, with a value of 50 ms RECOMMENDED. 573 Timing information is contained in the RTP timestamp, allowing 574 precise recovery of inter-event times. Thus, the sender does not in 575 theory need to maintain precise or consistent time intervals between 576 event packets. However, the sender SHOULD minimize the need for 577 buffering at the receiving end by sending event reports at constant 578 intervals. 580 DTMF digits and other tone events are sent incrementally to avoid 581 having the receiver wait for the completion of the event. In some 582 cases (for example, data session startup protocols), waiting to 583 the end of a tone before reporting it will cause the session to 584 fail. In other cases, it will simply cause undesirable delays in 585 playout at the receiving end. 587 For robustness, the sender SHOULD retransmit "state" events 588 periodically. 590 2.5.1.3. Long Duration Events 592 If an event persists beyond the maximum duration expressible in the 593 duration field (0xFFFF), the sender MUST send a packet reporting this 594 maximum duration but MUST NOT set the "E" bit in this packet. The 595 sender MUST then begin reporting a new "segment" with the RTP 596 timestamp set to the time at which the previous segment ended and the 597 duration set to the cumulative duration of the new segment. The "M" 598 bit of the first packet reporting the new segment MUST NOT be set. 600 The sender MUST repeat this procedure as required until the end of 601 the complete event has been reached. The final packet for the 602 complete event MUST have the "E" bit set (either on initial 603 transmission or on retransmission as described below). 605 2.5.1.3.1. Exceptional Procedure For Combined Payloads 607 If events are combined as a redundant payload with another payload 608 type using RFC 2198 [2] redundancy, the above procedure SHALL be 609 applied, but using a maximum duration which ensures that the 610 timestamp offset of the oldest generation of events in an RFC 2198 611 packet never exceeds 0x3FFF. If the sender is using a constant 612 packetization period, the maximum segment duration can be calculated 613 from the following formula: 615 maximum duration = 0x3FFF - (R-1)*(packetization period in 616 timestamp units) 618 where R is the highest redundant layer number consisting of event 619 payload. 621 The RFC 2198 redundancy header timestamp offset value is only 14 622 bits, compared with the 16 bits in the event payload duration 623 field. Since with other payloads the RTP timestamp typically 624 increments for each new sample, the timestamp offset value becomes 625 limiting on reported event duration. The limit becomes more 626 constraining when older generations of events are also included in 627 the combined payload. 629 2.5.1.4. Retransmission of Final Packet 631 The final packet for each event and for each segment SHOULD be sent a 632 total of three times at the interval used by the source for updates. 633 This ensures that the duration of the event or segment can be 634 recognized correctly even if an instance of the last packet is lost. 636 A sender MAY use RFC 2198 [2] with up to two levels of redundancy to 637 combine retransmissions with reports of new events, thus saving on 638 header overheads. In this usage, the primary payload is new event 639 reports, while the first and (if necessary) second levels of 640 redundancy report first and second retransmissions of final event 641 reports. Within a session negotiated to allow such usage, packets 642 containing the RFC 2198 payload SHOULD NOT be sent except when both 643 primary and retransmitted reports are to be included. All other 644 packets of the session SHOULD contain only the simple, non-redundant 645 telephone-event payload. Note that the expected proportion of simple 646 versus redundant packets affects the order in which they should be 647 specified on an SDP m= line. 649 There is little point in sending initial or interim event reports 650 redundantly because each succeeding packet describes the event 651 fully (except for typically irrelevant variations in volume). 653 A sender MAY delay setting the "E" bit until retransmitting the last 654 packet for a tone, rather than setting the bit on its first 655 transmission. This avoids having to wait to detect whether the tone 656 has indeed ended. Once the sender has set the "E" bit for a packet, 657 it MUST continue to set the "E" bit for any further retransmissions 658 of that packet. 660 2.5.1.5. Packing Multiple Events Into One Packet 662 Multiple named events can be packed into a single RTP packet if and 663 only if the events are consecutive and contiguous, i.e., occur 664 without overlap and without pause between them, and if the last event 665 packed into a packet occurs quickly enough to avoid excessive delays 666 at the receiver. 668 This approach is similar to having multiple frames of frame-based 669 audio in one RTP packet. 671 The constraint that packed events not overlap implies that events 672 designated as states can be followed in a packet only by other state 673 events which are mutually exclusive to them. The constraint itself 674 is needed so that the beginning time of each event can be calculated 675 at the receiver. 677 In a packet containing events packed in this way, the RTP timestamp 678 MUST identify the beginning of the first event or segment in the 679 packet. The "M" bit MUST be set if the packet records the beginning 680 of at least one event. (This will be true except when the packet 681 carries the end of one segment and the beginning of the next segment 682 of the same long-lasting event.) The "E" bit and duration for each 683 event in the packet MUST be set using the same rules as if that event 684 were the only event contained in the packet. 686 2.5.1.6. RTP Sequence Number 688 The RTP sequence number MUST be incremented by one in each successive 689 RTP packet sent. Incrementing applies to retransmitted as well as 690 initial instances of event reports, to permit the receiver to detect 691 lost packets for RTCP receiver reports. 693 2.5.2. Receiving Procedures 694 2.5.2.1. Indication of Receiver Capabilities using SDP 696 Receivers can indicate which named events they can handle, for 697 example, by using the Session Description Protocol (RFC 2327 [3]). 698 SDP descriptions using the event payload MUST contain an fmtp format 699 attribute that lists the event values that the receiver can process. 701 2.5.2.2. Playout of Tone Events 703 In the gateway scenario, an Internet telephony gateway connecting a 704 packet voice network to the PSTN recreates the DTMF or other tones 705 and injects them into the PSTN. Since, for example, DTMF digit 706 recognition takes several tens of milliseconds, the first few 707 milliseconds of a digit will arrive as regular audio packets. Thus, 708 careful time and power (volume) alignment between the audio samples 709 and the events is needed to avoid generating spurious digits at the 710 receiver. The receiver may also choose to delay playout of the tones 711 by some small interval after playout of the preceding audio has 712 ended, to ensure that downstream equipment can discriminate the tones 713 properly. 715 Some implementations send events and encoded audio packets (e.g., 716 PCMU or the codec used for speech signals) for the same time instant 717 for the duration of the event. It is RECOMMENDED that gateways 718 render only the telephone-event payload once it is received, since 719 the audio may contain spurious tones introduced by the audio 720 compression algorithm. However, it is anticipated that these extra 721 tones in general should not interfere with recognition at the far 722 end. 724 Receiver implementations MAY use different algorithms to create 725 tones, including the two described here. (Note that not all 726 implementations have the need to recreate a tone; some may only care 727 about recognizing the events.) With either algorithm, a receiver may 728 impose a playout delay to provide robustness against packet loss or 729 delay. The tradeoff between playout delay and other factors is 730 discussed further in Section 2.6.3. 732 In the first algorithm, the receiver simply places a tone of the 733 given duration in the audio playout buffer at the location indicated 734 by the timestamp. As additional packets are received that extend the 735 same tone, the waveform in the playout buffer is extended 736 accordingly. (Care has to be taken if audio is mixed, i.e., summed, 737 in the playout buffer rather than simply copied.) Thus, if a packet 738 in a tone lasting longer than the packet interarrival time gets lost 739 and the playout delay is short, a gap in the tone may occur. 741 Alternatively, the receiver can start a tone and play it until one of 742 the following occurs: 744 o it receives a packet with the "E" bit set; 746 o it receives the next tone, distinguished by a different timestamp 747 value (noting that new segments of long-duration events also 748 appear with a new timestamp value); 750 o it receives an alternative non-event media stream (assuming none 751 was being received while the event stream was active); or 753 o a given time period elapses. 755 This is more robust against packet loss, but may extend the tone 756 beyond its original duration if all retransmissions of the last 757 packet in an event are lost. Limiting the time period of extending 758 the tone is necessary to avoid that a tone "gets stuck". This 759 algorithm is not a license for senders to set the duration field to 760 zero; it MUST be set to the current duration as described, since this 761 is needed to create accurate events if the first event packet is 762 lost, among other reasons. 764 Regardless of the algorithm used, the tone SHOULD NOT be extended by 765 more than three packet interarrival times. A slight extension of 766 tone durations and shortening of pauses is generally harmless. 768 A receiver SHOULD NOT restart a tone once playout has stopped. It 769 MAY do so if the tone is of a type meant for human consumption or is 770 one for which interruptions will not cause confusion at the receiving 771 device. 773 If a receiver receives an event packet for an event which it is not 774 currently playing out and the packet does not have the "M" bit set, 775 earlier packets for that event have evidently been lost. This can be 776 confirmed by gaps in the RTP sequence number. The receiver MAY 777 determine on the basis of retained history and the timestamp and 778 event code of the current packet that it corresponds to an event 779 already played out and lapsed. In that case further reports for the 780 event MUST be ignored, as indicated in the previous paragraph. 782 If, on the other hand, the event has not been played out at all, the 783 receiver MAY attempt to play the event out to the complete duration 784 indicated in the event report. The appropriate behaviour will depend 785 on the event type concerned, and requires consideration of the 786 relationship of the event to audio media flows and whether correct 787 event duration is essential to the correct operation of the media 788 session. 790 A receiver SHOULD NOT rely on a particular event packet spacing, but 791 instead MUST use the event timestamps and durations to determine 792 timing and duration of playout. 794 The receiver MUST calculate jitter for RTCP receiver reports based on 795 all packets with a given timestamp. Note: The jitter value should 796 primarily be used as a means for comparing the reception quality 797 between two users or two time-periods, not as an absolute measure. 799 If a zero volume is indicated for an event for which the volume field 800 is defined, then the receiver MAY reconstruct the volume from the 801 volume of non-event audio or MAY use the nominal value specified by 802 the ITU Recommendation or other document defining the tone. This 803 ensures backwards compatibility with RFC 2833 [12], where the volume 804 field was defined only for DTMF events. 806 2.5.2.3. Long Duration Events 808 If an event report is received with duration equal to the maximum 809 duration expressible in the duration field (0xFFFF) and the "E" bit 810 for the report is not set, the event report may mark the end of a 811 segment generated according to the procedures of Section 2.5.1.3. If 812 another report for the same event type is received, the receiver MUST 813 compare the RTP timestamp for the new event with the sum of the RTP 814 timestamp of the previous report plus the duration (0xFFFF). The 815 receiver uses the absence of a gap between the events to detect that 816 it is receiving a single long-duration event. 818 The total duration of a long duration event is (obviously) the sum of 819 the durations of the segments used to report it. This is equal to 820 the duration of the final segment (as indicated in the final packet 821 for that segment), plus 0xFFFF multiplied by the number of segments 822 preceding the final segment. 824 2.5.2.3.1. Exceptional Procedure For Combined Payloads 826 If events are combined as a redundant payload with another payload 827 type using RFC 2198 [2] redundancy, segments are generated at 828 intervals of 0x3FFF or less, rather than 0xFFFF, as required by the 829 procedures of Section 2.5.1.3.1 in this case. If a receiver is using 830 the events component of the payload, event duration may be only an 831 approximate indicator of division into segments, but the lack of an 832 E-bit and the adjacency of two reports with the same event code are 833 strong indicators in themselves. 835 2.5.2.4. Multiple Events In a Packet 837 The procedures of Section 2.5.1.5 require that if multiple events are 838 reported in the same packet, they are contiguous and non-overlapping. 839 As a result, it is not strictly necessary for the receiver to know 840 the start times of the events following the first one in order to 841 play them out -- it needs only to respect the duration reported for 842 each event. Nevertheless, if knowledge of the start time for a given 843 event after the first one is required, it is equal to the sum of the 844 start time of the preceding event plus the duration of the preceding 845 event. 847 2.5.2.5. Soft States 849 If the duration of a soft state event expires, the receiver SHOULD 850 consider the value of the state to be "unknown" unless otherwise 851 indicated in the event documentation. 853 2.6. Congestion and Performance 855 Packet transmission through the internet is marked by occasional 856 periods of congestion lasting in the order of seconds, during which 857 network delay, jitter, and packet loss are all much higher than they 858 are in between these periods. [28] provides a typical 859 characterization of this phenomenon. Well-behaved applications are 860 expected, preferably, to reduce their demands on the network during 861 such periods of congestion. At the least they should not increase 862 their demands. This section explores both application performance 863 and the possibilities for good behaviour in the face of congestion. 865 2.6.1. Performance Requirements 867 Typically an implementation of the telephone-events payload will aim 868 to limit the rate at which each of the following impairments occurs: 870 a. an event encoded at the sender fails to be played out at the 871 receiver, either because the event report is lost or because it 872 arrives after playout of later content has started; 874 b. the start of playout of an event at the receiver is delayed 875 relative to other events or other media operating on the same 876 timestamp base; 878 c. the duration of playout of a given event differs from the correct 879 duration as detected at the sender by more than a given amount; 881 d. gaps occur in playout of a given event; 883 e. end-to-end delay for the media stream exceeds a given value. 885 The relative importance of these constraints varies between 886 applications. 888 2.6.2. Reliability Mechanisms 890 One reliability mechanism is available to every payload type 891 including telephone-events. This is to use a jitter buffer (i.e., 892 impose a playout delay) at the receiving end. This mechanism 893 addresses the first four requirements listed above, but at the 894 expense of the last one. 896 The named event procedures provide two complementary redundancy 897 mechanisms to deal with lost packets: 899 a. Intra-event updates: 901 Events that last longer than one packetization period (e.g., 50 902 ms) are updated periodically, so that the receiver can 903 reconstruct the event and its duration if it receives any of the 904 update packets, albeit with delay. 906 During an event, the RTP event payload format provides 907 incremental updates on the event. The error resiliency afforded 908 by this mechanism depends on whether the first or second 909 algorithm in Section 2.5.2.2 is used and on the playout delay at 910 the receiver. For example, if the receiver uses the first 911 algorithm and only places the current duration of tone signal in 912 the playout buffer, for a playout delay of 120 ms and a 913 packetization interval of 50 ms, two packets in a row can get 914 lost without causing a premature end of the tone generated. 916 b. Repeat last event packet: 918 As described in Section 2.5.1.4, the last report for an event is 919 transmitted a total of three times. This mechanism adds 920 robustness to the reporting of the end of an event. 922 It may be necessary to extend the level of redundancy to achieve 923 objective a) in a specific network environment. Taking the 924 25-30% loss rate during congestion periods illustrated in [28] as 925 typical, and setting an objective that at least 99% of end-of- 926 event reports will eventually get through to the receiver under 927 these conditions, simple probability calculations indicate that 928 each event completion has to be reported four times. This is one 929 more level of redundancy than required by the basic "Repeat last 930 event packet" algorithm. Of course, the objective is probably 931 unrealistically stringent; it was chosen to make a point. 933 Where Section 2.5.1.4 indicates that it is appropriate to use the 934 RFC 2198 [2] audio redundancy mechanism to carry retransmissions 935 of final event reports, this mechanism MAY also be used to extend 936 the number of final report retransmissions. This is done by 937 using more than two levels of redundancy when necessary. The use 938 of RFC 2198 helps to mitigate the extra bandwidth demands that 939 would be imposed simply by retransmitting final event packets 940 more than three times. 942 These two redundancy mechanisms clearly address requirement a) in the 943 previous section. They also help meet requirement c), to the extent 944 that the redundant packets arrive before playout of the events they 945 report is due to expire. They are not helpful in meeting the other 946 requirements, although they do not directly cause impairments 947 themselves in the way that a large jitter buffer increases end-to-end 948 delay. 950 The playout algorithm is an additional mechanism for meeting the 951 performance requirements. In particular, using the second algorithm 952 in Section 2.5.2.2 will meet requirement d) of the previous section 953 by preventing gaps in playout, but at the potential cost of increases 954 in duration (requirement c)). 956 Finally, there is an interaction between the packetization period 957 used by a sender, the playout delay used by the receiver, and the 958 vulnerability of an event flow to packet losses. Assuming packet 959 losses are independent, a shorter packetization interval means that 960 the receiver can use a smaller playout delay to recover from a given 961 number of consecutive packet losses, at any stage of event playout. 962 This improves end-to-end delays in applications where that matters. 964 In view of the tradeoffs between the different reliability 965 mechanisms, documentation of specific events SHOULD include a 966 discussion of the appropriate design decisions for the applications 967 of those events. This mandate is repeated in the section on IANA 968 Considerations. 970 2.6.3. Adjusting To Congestion 972 So far the discussion has been about meeting performance 973 requirements. However, there is also the question of whether 974 applications of events can adapt to congestion to the point that they 975 reduce their demands on the networks during congestion. In theory 976 this can be done for events by increasing the packetization interval, 977 so that fewer packets are sent per second. This has to be 978 accompanied by an increased playout delay at the receiving end. 979 Coordination between the two ends for this purpose is an interesting 980 issue in itself. If it is done, however, such an action implies a 981 one-time gap or extended playout of an event when the packetization 982 interval is first extended, as well as increased end-to-end delay 983 during the whole period of increased playout delay. 985 The benefit from such a measure varies primarily depending on the 986 average duration of the events being handled. In the worst case, as 987 a first example shows, the reduction in aggregate bandwidth usage due 988 to an increased packetization interval may be quite modest. Suppose 989 the average event duration is 3.33 ms (V.21 bits, for instance). 990 Suppose further that four transmissions in total are required for a 991 given event report to meet the loss objective. Table 1 shows the 992 impact of varying packetization interval on the aggregate bit rate of 993 the media stream. 995 +-------------------+-----------+---------------+-------------------+ 996 | Packetization | Packets/s | IP Packet | Total IP Bit Rate | 997 | Interval (ms) | | Size (bits) | (bits/s) | 998 +-------------------+-----------+---------------+-------------------+ 999 | 50 | 20 | 2440 | 48800 | 1000 | | | | | 1001 | 33.3 | 30 | 1800 | 54000 | 1002 | | | | | 1003 | 25 | 40 | 1480 | 59200 | 1004 | | | | | 1005 | 20 | 50 | 1288 | 64400 | 1006 +-------------------+-----------+---------------+-------------------+ 1008 Table 1: Data Rate At the IP Level versus Packetization Interval 1009 (three retransmissions, 3.33 ms per event) 1011 As can be seen, a doubling of the interval (from 25 to 50 ms) drops 1012 aggregate bit rate by about 20% while increasing end-to-end delay by 1013 25 ms and causing a one-time gap of the same amount. (Extending the 1014 playout of a specific V.21 tone event is out of the question, so the 1015 first algorithm of Section 2.5.2.2 must be used in this application.) 1016 The reduction in number of packets per second with longer 1017 packetization periods is countered by the increase in packet size due 1018 to the increase in number of events per packet. 1020 For events of longer duration, the reduction in bandwidth is more 1021 proportional to the increase in packetization interval. The loss of 1022 final event reports may also be less critical, so that lower 1023 redundancy levels are acceptable. Table 2 shows similar data to 1024 Table 1, but assuming 70 ms events separated by 50 ms of silence (as 1025 in an idealized DTMF-based text messaging session) with only the 1026 basic two retransmissions for event completions. 1028 +-------------------+-----------+---------------+-------------------+ 1029 | Packetization | Packets/s | IP Packet | Total IP Bit Rate | 1030 | Interval (ms) | | Size (bits) | (bits/s) | 1031 +-------------------+-----------+---------------+-------------------+ 1032 | 50 | 20 | 448/520 | 10040 | 1033 | | | | | 1034 | 33.3 | 30 | 448/520 | 14280 | 1035 | | | | | 1036 | 25 | 40 | 448/520 | 18520 | 1037 | | | | | 1038 | 20 | 50 | 448 | 22400 | 1039 +-------------------+-----------+---------------+-------------------+ 1041 Table 2: Data Rate At the IP Level versus Packetization Interval (two 1042 retransmissions, 70 ms per event, 50 ms between events) 1044 In the third column of the table, packet size is 448 bits when only 1045 one event is being reported and 520 bits when the previous event is 1046 also included. No more than one level of redundancy is needed up to 1047 a packetization interval of 50 ms, although at that point most 1048 packets are reporting two events. Longer intervals require a second 1049 level of redundancy in at least some packets. 1051 3. Specification of Event Codes For DTMF Events 1053 This document defines one class of named events: DTMF tones. 1055 3.1. DTMF Applications 1057 DTMF signalling [10] is typically generated by a telephone set or 1058 possibly by a PBX (Private branch telephone exchange). DTMF digits 1059 may be consumed by entities such as gateways or application servers 1060 in the IP network, or by entities such as telephone switches or IVRs 1061 in the circuit switched network. 1063 The DTMF events support two possible applications at the sending end: 1065 1. the Internet telephony gateway detects DTMF on the incoming 1066 circuits and sends the RTP payload described here instead of 1067 regular audio packets. The gateway likely has the necessary 1068 digital signal processors and algorithms, as it often needs to 1069 detect DTMF, e.g., for two-stage dialing. Having the gateway 1070 detect tones relieves the receiving Internet end system from 1071 having to do this work and also avoids having low bit-rate codecs 1072 like G.723.1 [20] render DTMF tones unintelligible. 1074 2. an Internet end system such as an "Internet phone" can emulate 1075 DTMF functionality without concerning itself with generating 1076 precise tone pairs and without imposing the burden of tone 1077 recognition on the receiver. 1079 A similar distinction occurs at the receiving end. 1081 1. In the gateway scenario, an Internet telephony gateway connecting 1082 a packet voice network to the PSTN recreates the DTMF tones or 1083 other telephony events and injects them into the PSTN. 1085 2. In the end system scenario, the DTMF events are consumed by the 1086 receiving entity itself. 1088 In the most common application, DTMF tones are sent in one direction 1089 only, typically from the calling end. The consuming device is most 1090 commonly an IVR. DTMF may alternate with voice from either end. In 1091 most cases the only constraint on tone duration is that it exceed a 1092 minimum value. However, in some cases a long-duration tone (in 1093 excess of 1-2 seconds) has special significance. 1095 ITU-T Recommendation Q.24 [11], Table A-1, indicates that the 1096 legacy switching equipment in the countries surveyed expects a 1097 minimum recognizable signal duration of 40 ms, a minimum pause 1098 between signals of 40 ms, and a maximum signalling rate of 8 to 10 1099 digits per second depending on the country. Human-generated DTMF 1100 signals, of course, are generally longer with larger pauses 1101 between them. 1103 DTMF tones may also be used for text telephony. This application is 1104 documented in ITU-T Recommendation V.18 [27] Annex B. In this case, 1105 DTMF is sent alternately from either end (half-duplex mode), with a 1106 minimum 300 ms turn-around time. The only constraints on tone 1107 durations in this application are that they and the pauses between 1108 them must exceed specified minimum values. It is RECOMMENDED that a 1109 gateway at the sending end be capable of detecting DTMF signals as 1110 specified by V.18 Annex B (tones and pauses >=40 ms) but should send 1111 event durations corresponding to those of a V.18 DTMF sender (tones 1112 >=70 ms, pauses >=50 ms). This may occasionally imply some degree of 1113 buffering of outgoing events, but if the source terminal conforms to 1114 V.18 Annex B this should not get out of hand. 1116 Since minor increases in tone duration are harmless for all 1117 applications of DTMF, but unintended breaks in playout of a DTMF 1118 digit can confuse the receiving endpoint by creating the appearance 1119 of extra digits, receiving applications that are converting DTMF 1120 events back to tones SHOULD use the second playout algorithm rather 1121 than the first one in Section 2.5.2.2. This provides some robustness 1122 against packet loss or congestion. 1124 3.2. DTMF Events 1126 Table 3 shows the DTMF-related event codes within the telephone-event 1127 payload format. The DTMF digits 0-9 and * and # are commonly 1128 supported. DTMF digits A through D are less frequently encountered, 1129 typically in special applications such as military networks. 1131 +-------+--------+------+---------+ 1132 | Event | Code | Type | Volume? | 1133 +-------+--------+------+---------+ 1134 | 0--9 | 0--9 | tone | yes | 1135 | | | | | 1136 | * | 10 | tone | yes | 1137 | | | | | 1138 | # | 11 | tone | yes | 1139 | | | | | 1140 | A--D | 12--15 | tone | yes | 1141 +-------+--------+------+---------+ 1143 Table 3: DTMF named events 1145 3.3. Congestion Considerations 1147 The key considerations for the delivery of DTMF events are 1148 reliability and avoidance of unintended breaks within the playout of 1149 a given tone. End-to-end round-trip delay is not a major 1150 consideration except in the special case where DTMF tones are being 1151 used for text telephony. Assuming that, as recommended in 1152 Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is 1153 in use, a temporary increase in packetization interval to as much as 1154 100 ms or double the normal interval, whichever is less, should be 1155 harmless. 1157 4. RTP Payload Format for Telephony Tones 1159 4.1. Introduction 1161 As an alternative to describing tones and events by name, as 1162 described in Section 2, it is sometimes preferable to describe them 1163 by their waveform properties. In particular, recognition is faster 1164 than for naming signals since it does not depend on recognizing 1165 durations or pauses. 1167 There is no single international standard for telephone tones such as 1168 dial tone, ringing (ringback), busy, congestion ("fast-busy"), 1169 special announcement tones or some of the other special tones, such 1170 as payphone recognition, call waiting or record tone. However, ITU-T 1171 Recommendation E.180 [18] notes that across all countries, these 1172 tones share a number of characteristics: 1174 o Telephony tones consist of either a single tone, the addition of 1175 two or three tones or the modulation of two tones. (Almost all 1176 tones use two frequencies; only the Hungarian "special dial tone" 1177 has three.) Tones that are mixed have the same amplitude and do 1178 not decay. 1180 o In-band tones for telephony events are in the range of 25 Hz 1181 (ringing tone in Angola) to 2600 Hz (the tone used for line 1182 signalling in SS No. 5 and R1). The in-band telephone frequency 1183 range is limited to 3400 Hz. R2 defines a 3825 Hz out-of-band 1184 tone for line signalling on analogue trunks. (The piano has a 1185 range from 27.5 to 4186 Hz.) 1187 o Modulation frequencies range between 15 (ANSam tone) to 480 Hz 1188 (Jamaica). Non-integer frequencies are used only for frequencies 1189 of 16 2/3 and 33 1/3 Hz. 1191 o Tones that are not continuous have durations of less than four 1192 seconds. 1194 o ITU Recommendation E.180 [18] notes that different telephone 1195 companies require a tone accuracy of between 0.5 and 1.5%. The 1196 Recommendation suggests a frequency tolerance of 1%. 1198 4.2. Examples of Common Telephone Tone Signals 1200 As an aid to the implementor, Table 4 summarizes some common tones. 1201 The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18]. 1202 In these rows, the on and off durations are suggested ranges within 1203 which local standards would set specific values. The symbol "+" in 1204 the table indicates addition of the tones, without modulation, while 1205 "*" indicates amplitude modulation. 1207 +-------------------------+-------------------+----------+----------+ 1208 | Tone Name | Frequency | On Time | Off Time | 1209 | | | (s) | (s) | 1210 +-------------------------+-------------------+----------+----------+ 1211 | CNG | 1100 | 0.5 | 3.0 | 1212 | | | | | 1213 | V.25 CT | 1300 | 0.5 | 2.0 | 1214 | | | | | 1215 | CED | 2100 | 3.3 | -- | 1216 | | | | | 1217 | ANS | 2100 | 3.3 | -- | 1218 | | | | | 1219 | ANSam | 2100*15 | 3.3 | -- | 1220 | | | | | 1221 | V.21 bit | 980 or 1180 or | 0.00333 | -- | 1222 | | 1650 or 1850 | | | 1223 | | | | | 1224 | ------------- | ---------- | -------- | -------- | 1225 | | | | | 1226 | ITU dial tone | 425 | -- | -- | 1227 | | | | | 1228 | U.S. dial tone | 350+440 | -- | -- | 1229 | | | | | 1230 | ITU ringing tone | 425 | 0.67-1.5 | 3-5 | 1231 | | | | | 1232 | U.S. ringing tone | 440+480 | 2.0 | 4.0 | 1233 | | | | | 1234 | ITU busy tone | 425 | 0.1-0.6 | 0.1-0.7 | 1235 | | | | | 1236 | U.S. busy tone | 480+620 | 0.5 | 0.5 | 1237 | | | | | 1238 | ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 | 1239 | | | | | 1240 | U.S. congestion tone | 480+620 | 0.25 | 0.25 | 1241 +-------------------------+-------------------+----------+----------+ 1243 Table 4: Examples of telephony tones 1245 4.3. Use of RTP Header Fields 1247 4.3.1. Timestamp 1249 The RTP timestamp reflects the measurement point for the current 1250 packet. The event duration described in Section 4.3.3 extends 1251 forwards from that time. 1253 4.3.2. Marker Bit 1255 The tones payload type uses the marker bit to distinguish the first 1256 RTP packet reporting a given instance of a tone from succeeding 1257 packets for that tone. The marker bit SHOULD be set to 1 for the 1258 first packet, and to 0 for all succeeding packets relating to the 1259 same tone. 1261 4.3.3. Payload Format 1263 Based on the characteristics described above, this document defines 1264 an RTP payload format called "tone" that can represent tones 1265 consisting of one or more frequencies. (The corresponding media type 1266 is "audio/tone".) The default timestamp rate is 8000 Hz, but other 1267 rates may be defined. Note that the timestamp rate does not affect 1268 the interpretation of the frequency, just the durations. 1270 In accordance with current practice, this payload format does not 1271 have a static payload type number, but uses a RTP payload type number 1272 established dynamically and out-of-band. 1274 The payload format is shown in Figure 2. 1276 0 1 2 3 1277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | modulation |T| volume | duration | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 |R R R R| frequency |R R R R| frequency | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 |R R R R| frequency |R R R R| frequency | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 ...... 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 |R R R R| frequency |R R R R| frequency | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 Figure 2: Payload Format for Tones 1293 The payload contains the following fields: 1295 modulation: 1297 The modulation frequency, in Hz. The field is a 9-bit unsigned 1298 integer, allowing modulation frequencies up to 511 Hz. If there 1299 is no modulation, this field has a value of zero. Note that the 1300 amplitude of modulation is not indicated in the payload and must 1301 be determined by out-of-band means 1303 T: 1305 If the "T" bit is set (one), the modulation frequency is to be 1306 divided by three. Otherwise, the modulation frequency is taken as 1307 is. 1309 This bit allows frequencies accurate to 1/3 Hz, since modulation 1310 frequencies such as 16 2/3 Hz are in practical use. 1312 volume: 1314 The power level of the tone, expressed in dBm0 after dropping the 1315 sign, with range from 0 to -63 dBm0. (Note: A preferred level 1316 range for digital tone generators is -8 dBm0 to -3 dBm0.) 1318 duration: 1320 The duration of the tone, measured in timestamp units and 1321 presented in network byte order. The tone begins at the instant 1322 identified by the RTP timestamp and lasts for the duration value. 1323 The value of zero is not permitted and tones with such a duration 1324 SHOULD be ignored. 1326 The definition of duration corresponds to that for sample-based 1327 codecs, where the timestamp represents the sampling point for the 1328 first sample. 1330 frequency: 1332 The frequencies of the tones to be added, measured in Hz and 1333 represented as a 12-bit unsigned integer. The field size is 1334 sufficient to represent frequencies up to 4095 Hz, which exceeds 1335 the range of telephone systems. A value of zero indicates 1336 silence. A single tone can contain any number of frequencies. If 1337 no frequencies are specified, the packet reports a period of 1338 silence. 1340 R: 1342 This field is reserved for future use. The sender MUST set it to 1343 zero, the receiver MUST ignore it. 1345 4.3.4. Optional media type Parameters 1347 The "rate" parameter describes the sampling rate, in Hertz. The 1348 number is written as an integer. If omitted, the default value is 1349 8000 Hz. 1351 4.4. Procedures 1353 This section defines the procedures associated with the tones payload 1354 type. 1356 4.4.1. Sending Procedures 1358 The sender MAY send an initial tones packet as soon as a tone is 1359 recognized, or MAY wait until a pre-negotiated packetization period 1360 has elapsed. The first RTP packet for a tone SHOULD have the marker 1361 bit set to 1. 1363 In the case of longer-duration tones, the sender SHOULD generate 1364 multiple RTP packets for the same tone instance. The RTP timestamp 1365 MUST be updated for each packet generated (in contrast, for instance, 1366 to the timestamp for packets carrying telephone-events). Subsequent 1367 packets for the same tone SHOULD have the marker bit set to 0, and 1368 the RTP timestamp in each subsequent packet MUST equal the sum of the 1369 timestamp and the duration in the preceding packet. 1371 A final RTP packet MAY be generated as soon as the end of the tone is 1372 detected, without waiting for the latest packetization period to 1373 elapse. 1375 The telephone-event payload described in Section 2 is inherently 1376 redundant, in that later packets for the same event carry all of the 1377 earlier history of the event except for variations in volume. In 1378 contrast, each packet for the tone payload type stands alone; a lost 1379 packet means a gap in the information available at the receiving end. 1380 Thus, for increased reliability, the sender SHOULD combine new and 1381 old tone reports in the same RTP packet using RFC 2198 [2] audio 1382 redundancy. 1384 4.4.2. Receiving Procedures 1386 Receiving implementations play out the tones as received, typically 1387 with a playout delay to allow for lost packets. When playing out 1388 successive tone reports for the same tone (marker bit is zero, the 1389 RTP timestamp is contiguous with that of the previous RTP packet, and 1390 payload content is identical), the receiving implementation SHOULD 1391 continue the tone without change or a break. 1393 4.4.3. Handling Of Congestion 1395 If the sender determines that packets are being lost due to 1396 congestion (e.g., through RTCP receiver reports), it SHOULD increase 1397 the packetization interval for initial and interim tone reports so as 1398 to reduce traffic volume to the receiver. The degree to which this 1399 is possible without causing damaging consequences at the receiving 1400 end depends both upon the playout delay used at that end and upon the 1401 specific application associated with the tones. Both the maximum 1402 packetization interval and maximum increase in packetization interval 1403 at any one time are therefore a matter of configuration or out-of- 1404 band negotiation. 1406 5. Examples 1408 Consider a DTMF dialling sequence, where the user dials the digits 1409 "911" and a sending gateway detects them. The first digit is 200 ms 1410 long (1600 timestamp units) and starts at time 0; the second digit 1411 lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040 1412 timestamp units); the third digit is pressed at time 1.4 s (11,200 1413 timestamp units) and lasts 220 ms (1760 timestamp units). The frame 1414 duration is 50 ms. 1416 Table 5 shows the complete sequence of events assuming that only the 1417 telephone-events payload type is being reported. For simplicity: the 1418 timestamp is assumed to begin at 0, the RTP sequence number at 1, and 1419 volume settings are omitted. 1421 +-------+-----------+-----+--------+------+---------+--------+------+ 1422 | Time | Event | M | Time | Seq | Event | Dura | E | 1423 | (ms) | | bit | stamp | No | Code | tion | bit | 1424 +-------+-----------+-----+--------+------+---------+--------+------+ 1425 | 0 | "9" | | | | | | | 1426 | | starts | | | | | | | 1427 | | | | | | | | | 1428 | 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" | 1429 | | packet 1 | | | | | | | 1430 | | sent | | | | | | | 1431 | | | | | | | | | 1432 | 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" | 1433 | | packet 2 | | | | | | | 1434 | | sent | | | | | | | 1435 | | | | | | | | | 1436 | 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" | 1437 | | packet 3 | | | | | | | 1438 | | sent | | | | | | | 1439 | | | | | | | | | 1440 | 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" | 1441 | | packet 4 | | | | | | | 1442 | | sent | | | | | | | 1443 | | | | | | | | | 1444 | 200 | "9" ends | | | | | | | 1445 | | | | | | | | | 1446 | 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" | 1447 | | packet 4 | | | | | | | 1448 | | first | | | | | | | 1449 | | retrans | | | | | | | 1450 | | mission | | | | | | | 1451 | | | | | | | | | 1452 | 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" | 1453 | | packet 4 | | | | | | | 1454 | | second | | | | | | | 1455 | | retrans | | | | | | | 1456 | | mission | | | | | | | 1457 | | | | | | | | | 1458 | 880 | First "1" | | | | | | | 1459 | | starts | | | | | | | 1460 | | | | | | | | | 1461 | 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" | 1462 | | packet 5 | | | | | | | 1463 | | sent | | | | | | | 1464 | | | | | | | | | 1465 | ... | ... | ... | ... | ... | ... | ... | ... | 1466 | | | | | | | | | 1467 | 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" | 1468 | | packet 9 | | | | | | | 1469 | | sent | | | | | | | 1470 | | | | | | | | | 1471 | 1130 | First "1" | | | | | | | 1472 | | ends | | | | | | | 1473 | | | | | | | | | 1474 | 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" | 1475 | | packet 9 | | | | | | | 1476 | | first | | | | | | | 1477 | | retrans | | | | | | | 1478 | | mission | | | | | | | 1479 | | | | | | | | | 1480 | 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" | 1481 | | packet 9 | | | | | | | 1482 | | second | | | | | | | 1483 | | retrans | | | | | | | 1484 | | mission | | | | | | | 1485 | | | | | | | | | 1486 | 1400 | Second | | | | | | | 1487 | | "1" | | | | | | | 1488 | | starts | | | | | | | 1489 | | | | | | | | | 1490 | 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" | 1491 | | packet 10 | | | | | | | 1492 | | sent | | | | | | | 1493 | | | | | | | | | 1494 | ... | ... | ... | ... | ... | ... | ... | ... | 1495 | | | | | | | | | 1496 | 1620 | Second | | | | | | | 1497 | | "1" ends | | | | | | | 1498 | | | | | | | | | 1499 | 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" | 1500 | | packet 14 | | | | | | | 1501 | | sent | | | | | | | 1502 | | | | | | | | | 1503 | 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" | 1504 | | packet 14 | | | | | | | 1505 | | first | | | | | | | 1506 | | retrans | | | | | | | 1507 | | mission | | | | | | | 1508 | | | | | | | | | 1509 | 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" | 1510 | | packet 14 | | | | | | | 1511 | | second | | | | | | | 1512 | | retrans | | | | | | | 1513 | | mission | | | | | | | 1514 +-------+-----------+-----+--------+------+---------+--------+------+ 1516 Table 5: Example of Event Reporting 1518 Table 6 shows the same sequence assuming that only the tone payload 1519 type is being reported. This looks somewhat different. For 1520 simplicity: the timestamp is assumed to begin at 0, the sequence 1521 number at 1. Volume, the T bit, and the modulation frequency are 1522 omitted. The latter two are always 0. 1524 +-------+-----------+-----+-------+-----+-------+---------+---------+ 1525 | Time | Event | M | Time | Seq | Dura | Freq 1 | Freq 2 | 1526 | (ms) | | bit | stamp | No | tion | (Hz) | (Hz) | 1527 +-------+-----------+-----+-------+-----+-------+---------+---------+ 1528 | 0 | "9" | | | | | | | 1529 | | starts | | | | | | | 1530 | | | | | | | | | 1531 | 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 | 1532 | | packet 1 | | | | | | | 1533 | | sent | | | | | | | 1534 | | | | | | | | | 1535 | 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 | 1536 | | packet 2 | | | | | | | 1537 | | sent | | | | | | | 1538 | | | | | | | | | 1539 | ... | ... | ... | ... | ... | ... | ... | ... | 1540 | | | | | | | | | 1541 | 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 | 1542 | | packet 4 | | | | | | | 1543 | | sent | | | | | | | 1544 | | | | | | | | | 1545 | 200 | "9" ends | | | | | | | 1546 | | | | | | | | | 1547 | 880 | First "1" | | | | | | | 1548 | | starts | | | | | | | 1549 | | | | | | | | | 1550 | 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 | 1551 | | packet 5 | | | | | | | 1552 | | sent | | | | | | | 1553 | | | | | | | | | 1554 | 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 | 1555 | | packet 6 | | | | | | | 1556 | | sent | | | | | | | 1557 | | | | | | | | | 1558 | ... | ... | ... | ... | ... | ... | ... | ... | 1559 | | | | | | | | | 1560 | 1130 | First "1" | | | | | | | 1561 | | ends | | | | | | | 1562 | | | | | | | | | 1563 | 1400 | Second | | | | | | | 1564 | | "1" | | | | | | | 1565 | | starts | | | | | | | 1566 | | | | | | | | | 1567 | 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 | 1568 | | packet 10 | | | | | | | 1569 | | sent | | | | | | | 1570 | | | | | | | | | 1571 | ... | ... | ... | ... | ... | ... | ... | ... | 1572 | 1620 | Second | | | | | | | 1573 | | "1" ends | | | | | | | 1574 | | | | | | | | | 1575 | 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 | 1576 | | packet 14 | | | | | | | 1577 | | sent | | | | | | | 1578 +-------+-----------+-----+-------+-----+-------+---------+---------+ 1580 Table 6: Example of Tone Reporting 1582 Now consider a combined payload, where the tone payload is the 1583 primary payload type and the event payload is treated as a redundant 1584 encoding (one level of redundancy). Because the primary payload is 1585 tones, the tone payload rules determine the setting of the RTP header 1586 fields. This means that the RTP timestamp always advances. As a 1587 corollary, the timestamp offset for the events payload in the RFC 1588 2198 header increases by the same amount. 1590 One issue that has to be considered in a combined payload is how to 1591 handle retransmissions of final event reports. The tones payload 1592 specification does not recommend retransmissions of final packets, so 1593 it is unclear what to put in the primary payload fields of the 1594 combined packet. In the interests of simplicity it is suggested that 1595 the retransmitted packets copy the fields relating to the primary 1596 payload (including the RTP timestamp) from the original packet. The 1597 same principle can be applied if the packet includes multiple levels 1598 of event payload redundancy. 1600 The figures below all illustrate "RTP packet 14" in the above tables. 1601 Figure 3 shows an event-only payload, corresponding to Table 5. 1602 Figure 4 shows an event-only payload, corresponding to Table 6. 1603 Finally, Figure 5 shows a combined payload, with tones primary and 1604 events as a single redundant layer. Note that the combined payload 1605 has the RTP sequence numbers shown in Table 5, because the 1606 transmitted sequence includes the retransmitted packets. 1608 Figure 3 assumes that the following SDP specification was used. This 1609 session description provides for separate streams of G.729 [21] audio 1610 and events. Packets reported within the G.729 stream are not 1611 considered here. 1613 m=audio 12344 RTP/AVP 99 1614 a=rtpmap:99 G729/8000 1615 a=ptime:20 1616 m=audio 12346 RTP/AVP 100 1617 a=rtpmap:100 telephone-event/8000 1618 a=fmtp:100 0-15 1619 a=ptime:50 1620 0 1 2 3 1621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 |V=2|P|X| CC |M| PT | sequence number | 1624 | 2 |0|0| 0 |0| 100 | 18 | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | timestamp | 1627 | 11200 | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | synchronization source (SSRC) identifier | 1630 | 0x5234a8 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | event |E R| volume | duration | 1633 | 1 |1 0| 20 | 1760 | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 Figure 3: Example RTP Packet For Event Payload 1638 Figure 4 assumes that an SDP specification similar to that of the 1639 previous case was used. 1641 m=audio 12344 RTP/AVP 99 1642 a=rtpmap:99 G729/8000 1643 a=ptime:20 1644 m=audio 12346 RTP/AVP 101 1645 a=rtpmap:101 tone/8000 1646 a=ptime:50 1648 0 1 2 3 1649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 |V=2|P|X| CC |M| PT | sequence number | 1652 | 2 |0|0| 0 |0| 101 | 14 | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | timestamp | 1655 | 12800 | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | synchronization source (SSRC) identifier | 1658 | 0x5234a8 | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | modulation |T| volume | duration | 1661 | 0 |0| 20 | 160 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 |R R R R| frequency |R R R R| frequency | 1664 |0 0 0 0| 697 |0 0 0 0| 1209 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 Figure 4: Example RTP Packet For Tone Payload 1669 Figure 5, for the combined payload, assumes the following SDP session 1670 description: 1672 m=audio 12344 RTP/AVP 99 1673 a=rtpmap:99 G729/8000 1674 a=ptime:20 1675 m=audio 12346 RTP/AVP 102 101 100 1676 a=rtpmap:102 red/8000/1 1677 a=fmtp:102 101/100 1678 a=rtpmap:101 tone/8000 1679 a=rtpmap:100 telephone-event/8000 1680 a=fmtp:100 0-15 1681 a=ptime:50 1683 For ease of presentation, Figure 5 presents the actual payloads as if 1684 they began on 32-bit boundaries. In the actual packet, they follow 1685 immediately after the end of the RFC 2198 header, and thus are 1686 displaced one octet into successive words. 1688 0 1 2 3 1689 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 |V=2|P|X| CC |M| PT | sequence number | 1692 | 2 |0|0| 0 |0| 102 | 18 | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | timestamp | 1695 | 12800 | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | synchronization source (SSRC) identifier | 1698 | 0x5234a8 | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 |F| block PT | timestamp offset | block length | 1701 |1| 100 | 1600 | 4 | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 |F| block PT | event payload begins ... / 1704 |0| 101 | \ 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Event payload 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | event |E R| volume | duration | 1711 | 1 |1 0| 20 | 1760 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 Tone payload 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | modulation |T| volume | duration | 1718 | 0 |0| 20 | 160 | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 |R R R R| frequency |R R R R| frequency | 1721 |0 0 0 0| 697 |0 0 0 0| 1209 | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 Figure 5: Example RTP Packet For Combined Tone and Event Payloads 1726 6. Security Considerations 1728 RTP packets using the payload formats defined in this specification 1729 are subject to the security considerations discussed in the RTP 1730 specification (RFC 3550 [6]), and any appropriate RTP profile (for 1731 example RFC 3551 [13]). The RFC 3550 discussion focusses on 1732 requirements for confidentiality. Additional security considerations 1733 relating to implementation are described in RFC 2198 [2]. 1735 The telephony-event payload defined in this specification is highly 1736 compressed. A change in value of just one bit can result in a major 1737 change in meaning as decoded at the receiver. Thus message integrity 1738 MUST be provided for the telephony-event payload type. 1740 To meet the need for protection both of confidentiality and 1741 integrity, compliant implementations SHOULD implement the Secure 1742 Real-time Transport Protocol (SRTP) [8]. 1744 Note that the appropriate method of key distribution for SRTP may 1745 vary with the specific application. 1747 In some deployments it may be preferable to use other means to 1748 provide protection equivalent to that provided by SRTP. 1750 Provided that gateway design includes robust, low overhead tone 1751 generation, this payload type does not exhibit any significant non- 1752 uniformity in the receiver side computational complexity for packet 1753 processing to cause a potential denial-of-service threat. 1755 7. IANA Considerations 1757 This document updates the descriptions of two RTP payload formats, 1758 'telephone-event' and 'tone', and associated Internet media types, 1759 audio/telephone-event and audio/tone. It also documents the event 1760 codes for DTMF tone events. 1762 Within the audio/telephone-event type, events MUST be registered with 1763 IANA. Registrations are subject to the policies "Specification 1764 Required" and "Expert Review" as defined in RFC 2434 [4]. The IETF- 1765 appointed expert must ensure that: 1767 a. the meaning and application of the proposed events is clearly 1768 documented; 1770 b. the events cannot be represented by existing event codes, 1771 possibly with some minor modification of event definitions; 1773 c. the number of events is the minimum necessary to fulfil the 1774 purpose of their application(s). 1776 The expert is further responsible for providing guidance on the 1777 allocation of event codes to the proposed events. Specifically, the 1778 expert must indicate whether the event appears to be the same as one 1779 defined in RFC 2833 but not specified in any new document. In this 1780 case the event code specified in RFC 2833 for that event SHOULD be 1781 assigned to the proposed event. Otherwise event codes MUST be 1782 assigned from the set of available event codes listed below. If this 1783 set is exhausted, the criterion for assignment from the reserved set 1784 of event codes is to first assign those that appear to have the 1785 lowest probability of being revived in their RFC 2833 meaning in a 1786 new specification. 1788 The documentation for each event MUST indicate whether the event is a 1789 state, tone, or other type of event (e.g., an out-of-band electrical 1790 event such as on-hook or an indication that will not itself be played 1791 out as tones at the receiving end). For tone events, the 1792 documentation MUST indicate whether the volume field is applicable or 1793 must be set to 0. 1795 In view of the tradeoffs between the different reliability mechanisms 1796 discussed in Section 2.6, documentation of specific events SHOULD 1797 include a discussion of the appropriate design decisions for the 1798 applications of those events. 1800 Legal event codes range from 0 to 255. The initial registry content 1801 is shown in Table 7, and consists of the sixteen events defined in 1802 Section 3 of this document. The remaining codes have the following 1803 disposition: 1805 o codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available 1806 for assignment; 1808 o codes 23-40, 49, and 52-63 are reserved for events defined in 1809 [16]; 1811 o codes 121-137 and 174-205 are reserved for for events defined in 1812 [17]; 1814 o codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved 1815 in the first instance for specifications reviving the 1816 corresponding RFC 2833 events, and in the second instance for 1817 general assignment after all other codes have been assigned. 1819 +------------+--------------------------------+------------+ 1820 | Event Code | Event Name | Reference | 1821 +------------+--------------------------------+------------+ 1822 | 0 | DTMF digit "0" | | 1823 | | | | 1824 | 1 | DTMF digit "1" | | 1825 | | | | 1826 | 2 | DTMF digit "2" | | 1827 | | | | 1828 | 3 | DTMF digit "3" | | 1829 | | | | 1830 | 4 | DTMF digit "4" | | 1831 | | | | 1832 | 5 | DTMF digit "5" | | 1833 | | | | 1834 | 6 | DTMF digit "6" | | 1835 | | | | 1836 | 7 | DTMF digit "7" | | 1837 | | | | 1838 | 8 | DTMF digit "8" | | 1839 | | | | 1840 | 9 | DTMF digit "9" | | 1841 | | | | 1842 | 10 | DTMF digit "*" | | 1843 | | | | 1844 | 11 | DTMF digit "#" | | 1845 | | | | 1846 | 12 | DTMF digit "A" | | 1847 | | | | 1848 | 13 | DTMF digit "B" | | 1849 | | | | 1850 | 14 | DTMF digit "C" | | 1851 | | | | 1852 | 15 | DTMF digit "D" | | 1853 +------------+--------------------------------+------------+ 1855 Table 7: audio/telephone-event Event Code Registry 1857 7.1. Media type registrations 1859 7.1.1. Registration of media type audio/telephone-event 1861 This registration is done in accordance with [7] and [9]. 1863 Type name: audio 1865 Subtype name: telephone-event 1866 Required parameters: none. 1868 Optional parameters: 1870 The "events" parameter lists the events supported by the 1871 implementation. Events are listed as one or more comma-separated 1872 elements. Each element can either be a single integer providing 1873 the value of an event code or an integer followed by a hyphen and 1874 a larger integer, presenting a range of consecutive event code 1875 values. The list does not have to be sorted. No white space is 1876 allowed in the argument. The union of all of the individual event 1877 codes and event code ranges designates the complete set of event 1878 numbers supported by the implementation. If the "events" 1879 parameter is omitted, support for events 0-15 (the DTMF tones) is 1880 assumed. 1882 The "rate" parameter describes the sampling rate, in Hertz. The 1883 number is written as an integer. If omitted, the default value is 1884 8000 Hz. 1886 Encoding considerations: 1888 In the terminology defined by [9] section 4.8, this type is framed 1889 and binary. 1891 Security considerations: 1893 See the "Security Considerations" section (Section 6) in this 1894 document. 1896 Interoperability considerations: none. 1898 Published specification: this document. 1900 Applications which use this media: 1902 The telephone-event audio subtype supports the transport of events 1903 occuring in telephone systems over the Internet. 1905 Additional information: 1907 Magic number(s): N/A. 1909 File extension(s): N/A. 1911 Macintosh file type code(s): N/A. 1913 Person & email address to contact for further information: 1915 Tom Taylor, taylor@nortel.com. 1917 IETF AVT Working Group. 1919 Intended usage: COMMON. 1921 Restrictions on usage: 1923 This type is defined only for transfer via RTP [6]. 1925 Author: IETF Audio/Video Transport Working Group. 1927 Change controller: 1929 IETF Audio/Video Transport Working Group as delegated from the 1930 IESG. 1932 7.1.2. Registration of media type audio/tone 1934 This registration is done in accordance with [7] and [9]. 1936 Type name: audio 1938 Subtype name: tone 1940 Required parameters: none 1942 Optional parameters: 1944 The "rate" parameter describes the sampling rate, in Hertz. The 1945 number is written as an integer. If omitted, the default value is 1946 8000 Hz. 1948 Encoding considerations: 1950 In the terminology defined by [9] section 4.8, this type is framed 1951 and binary. 1953 Security considerations: 1955 See the "Security Considerations" section (Section 6) in this 1956 document. 1958 Interoperability considerations: none 1960 Published specification: this document. 1962 Applications which use this media: 1964 The tone audio subtype supports the transport of pure composite 1965 tones, for example those commonly used in the current telephone 1966 system to signal call progress. 1968 Additional information: 1970 Magic number(s): N/A. 1972 File extension(s): N/A. 1974 Macintosh file type code(s): N/A. 1976 Person & email address to contact for further information: 1978 Tom Taylor, taylor@nortel.com. 1980 IETF AVT Working Group. 1982 Intended usage: COMMON. 1984 Restrictions on usage: 1986 This type is defined only for transfer via RTP [6]. 1988 Author: IETF Audio/Video Transport Working Group. 1990 Change controller: 1992 IETF Audio/Video Transport Working Group as delegated from the 1993 IESG. 1995 8. Acknowledgements 1997 Scott Petrack was the original author of RFC 2833. Henning 1998 Schulzrinne later loaned his expertise to complete the document, but 1999 Scott must be credited with the energy behind the idea of a compact 2000 encoding of tones over IP. 2002 In RFC 2833, the suggestions of the Megaco working group were 2003 acknowledged. Colin Perkins and Magnus Westerland, Chairs of the AVT 2004 Working Group, provided helpful advice in the formation of the 2005 present document. Over the years, detailed advice and comments for 2006 RFC 2833, this document, or both were provided by Hisham Abdelhamid, 2007 Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih 2008 Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom, 2009 Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Kai Miao, 2010 Satish Mundra, Kevin Noll, Vern Paxson, Oren Peleg, Raghavendra 2011 Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi, Yaakov Stein, Mira 2012 Stevanovic, Tim Melanchuk, Alex Urquizo and Herb Wildfeur. 2014 9. References 2016 9.1. Normative References 2018 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2019 Levels", BCP 14, RFC 2119, March 1997. 2021 [2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, 2022 M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP 2023 Payload for Redundant Audio Data", RFC 2198, September 1997. 2025 [3] Handley, M. and V. Jacobson, "SDP: Session Description 2026 Protocol", RFC 2327, April 1998. 2028 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2029 Considerations Section in RFCs", BCP 26, RFC 2434, 2030 October 1998. 2032 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2033 Session Description Protocol (SDP)", RFC 3264, June 2002. 2035 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2036 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2037 RFC 3550, July 2003. 2039 [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 2040 Payload Formats", RFC 3555, July 2003. 2042 [8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2043 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2044 RFC 3711, March 2004. 2046 [9] Freed, N. and J. Klensin, "Media Type Specifications and 2047 Registration Procedures", BCP 13, RFC 4288, December 2005. 2049 [10] International Telecommunication Union, "Technical features of 2050 push-button telephone sets", ITU-T Recommendation Q.23, 2051 November 1988. 2053 [11] International Telecommunication Union, "Multifrequency push- 2054 button signal reception", ITU-T Recommendation Q.24, 2055 November 1988. 2057 9.2. Informative References 2059 [12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 2060 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 2062 [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 2063 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 2065 [14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent 2066 Call", RFC 4040, April 2005. 2068 [15] Hellstrom, G. and P. Jones, "RTP Payload for Text 2069 Conversation", RFC 4103, June 2005. 2071 [16] Schulzrinne, H. and T. Taylor, "Definition of Events For Modem, 2072 FAX, and Text Telephony Signals", RFC yyyy, June 2006. 2074 [17] Schulzrinne, H. and T. Taylor, "Definition of Events For 2075 Channel-Oriented Telephony Signalling", Work In Progress , 2076 November 2005. 2078 [18] International Telecommunication Union, "Technical 2079 characteristics of tones for the telephone service", ITU-T 2080 Recommendation E.180/Q.35, March 1998. 2082 [19] International Telecommunication Union, "Pulse code modulation 2083 (PCM) of voice frequencies", ITU-T Recommendation G.711, 2084 November 1988. 2086 [20] International Telecommunication Union, "Speech coders : Dual 2087 rate speech coder for multimedia communications transmitting at 2088 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996. 2090 [21] International Telecommunication Union, "Coding of speech at 8 2091 kbit/s using conjugate-structure algebraic-code-excited linear- 2092 prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996. 2094 [22] International Telecommunication Union, "ISDN user-network 2095 interface layer 3 specification for basic call control", ITU-T 2096 Recommendation Q.931, May 1998. 2098 [23] International Telecommunication Union, "Procedures for real- 2099 time Group 3 facsimile communication over IP networks", ITU-T 2100 Recommendation T.38, July 2003. 2102 [24] International Telecommunication Union, "Procedures for starting 2103 sessions of data transmission over the public switched 2104 telephone network", ITU-T Recommendation V.8, November 2000. 2106 [25] International Telecommunication Union, "Modem-over-IP networks: 2107 Procedures for the end-to-end connection of V-series DCEs", 2108 ITU-T Recommendation V.150.1, January 2003. 2110 [26] International Telecommunication Union, "Procedures for 2111 supporting Voice-Band Data over IP Networks", ITU-T 2112 Recommendation V.152, January 2005. 2114 [27] International Telecommunication Union, "Operational and 2115 interworking requirements for {DCEs operating in the text 2116 telephone mode", ITU-T Recommendation V.18, November 2000. 2118 See also Recommendation V.18 Amendment 1, Nov. 2002. 2120 [28] VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2121 2005, 2122 . 2124 Appendix A. Summary of Changes from RFC 2833 2126 The memo has been significantly restructured, incorporating a large 2127 number of clarifications to the specification. With the exception of 2128 those items noted below, the changes to the memo are intended to be 2129 backwards compatible clarifications. However, due to inconsistencies 2130 and unclear definitions in RFC 2833 [12] it is likely that some 2131 implementations interpreted that memo in ways that differ from this 2132 version. 2134 RFC 2833 required that all implementations be capable of receiving 2135 the DTMF events (event codes 0-15). Section 2.5.1.1 of the present 2136 document requires that a sender transmit only the events that the 2137 receiver is capable of receiving. In the absence of a knowledge of 2138 receiver capabilities, the sender SHOULD assume support of the DTMF 2139 events but of no other events. The sender SHOULD indicate what 2140 events it can send. Section 2.5.2.1 requires that a receiver 2141 signalling its capabilities using SDP MUST indicate which events it 2142 can receive. 2144 Non-zero values in the Volume field of the payload were applicable 2145 only to DTMF tones in RFC 2833, and for other events the receiver was 2146 required to ignore them. The present memo requires that the 2147 definition of each event indicate whether the Volume field is 2148 applicable to that event. The last paragraph of Section 2.5.2.2 2149 indicates what a receiver may do if it receives volumes with zero 2150 values for events to which the Volume field is applicable. Along 2151 with the RFC 2833 receiver rule, this ensures backward compatibility 2152 in both directions of transmission. 2154 Section 2.5.1.3 and Section 2.5.2.3 introduce a new procedure for 2155 reporting and playing out events whose duration exceeds the capacity 2156 of the payload Duration field. This procedure may cause momentary 2157 confusion at an old (RFC 2833) receiver, because the timestamp is 2158 updated without setting the E bit of the preceding event report and 2159 without setting the M bit of the new one. 2161 Section 2.5.1.5 and Section 2.5.2.4 introduce a new procedure whereby 2162 a sequence of short-duration events may be packed into a single event 2163 report. If an old (RFC 2833) receiver receives such a report, it may 2164 discard the packet as invalid, since the packet holds more content 2165 than the receiver was expecting. In any event, the additional events 2166 in the packet will be lost. 2168 Section 2.3.5 introduces the possibility of "state" events and 2169 defines procedures for setting the Duration field for reports of such 2170 events. Section 2.5.1.2 defines special exemptions from the setting 2171 of the E bit for state events. Three more sections mention 2172 procedures related to these events. 2174 The Security Considerations section is updated to mention the 2175 requirement for protection of integrity. More importantly, it makes 2176 implementation of SRTP [8] mandatory for compliant implementations, 2177 without specifying a mandatory-to-implement method of key 2178 distribution. 2180 Finally, this document establishes an IANA registry for event codes 2181 and establishes criteria for their documentation. This document 2182 provides an initial population for the new registry, consisting 2183 solely of the sixteen DTMF events. Two companion documents [16] and 2184 [17] describe events related to modems, fax, and text telephony and 2185 to channel-associated telephony signalling respectively. Some 2186 changes were made to the latter because of errors and redundancies in 2187 the RFC 2833 assignments. The remaining events defined in RFC 2833 2188 are deprecated because they do not appear to have been implemented, 2189 but their codes have been conditionally reserved in case any of them 2190 is needed in the future. Table 8 indicates the disposition of the 2191 event codes in detail. Event codes not mentioned in this table were 2192 not allocated by RFC 2833 and continue to be unused. 2194 +------------+----------------------------------------+-------------+ 2195 | Event | RFC 2833 Description | Disposition | 2196 | Codes | | | 2197 +------------+----------------------------------------+-------------+ 2198 | 0-15 | DTMF digits | This RFC | 2199 | | | | 2200 | 16 | Line flash (deprecated) | Reserved | 2201 | | | | 2202 | 23-31 | Unused | [16] | 2203 | | | | 2204 | 32-40 | Data and fax | [16] | 2205 | | | | 2206 | 41-48 | Data and fax (V.8bis, deprecated) | Reserved | 2207 | | | | 2208 | 52-63 | Unused | [16] | 2209 | | | | 2210 | 64-89 | E.182 line events (deprecated) | Reserved | 2211 | | | | 2212 | 96-112 | Country-specific line events | Reserved | 2213 | | (deprecated) | | 2214 | | | | 2215 | 121-127 | Unused | [17] | 2216 | | | | 2217 | 128-137 | Trunks: MF 0-9 | [17] | 2218 | | | | 2219 | 138-143 | Trunks: other MF (deprecated) | Reserved | 2220 | | | | 2221 | 144-159 | Trunks: ABCD signalling | [17] | 2222 | | | | 2223 | 160-168 | Trunks: various (deprecated) | Reserved | 2224 | | | | 2225 | 170-173 | Trunks: various (deprecated) | Reserved | 2226 | | | | 2227 | 174-205 | Unused | [17] | 2228 +------------+----------------------------------------+-------------+ 2230 Table 8: Disposition of RFC 2833-defined event codes 2232 Authors' Addresses 2234 Henning Schulzrinne 2235 Columbia U. 2236 Dept. of Computer Science 2237 Columbia University 2238 1214 Amsterdam Avenue 2239 New York, NY 10027 2240 US 2242 Email: schulzrinne@cs.columbia.edu 2244 Tom Taylor 2245 Nortel 2246 1852 Lorraine Ave 2247 Ottawa, Ontario K1H 6Z8 2248 CA 2250 Email: taylor@nortel.com 2252 Intellectual Property Statement 2254 The IETF takes no position regarding the validity or scope of any 2255 Intellectual Property Rights or other rights that might be claimed to 2256 pertain to the implementation or use of the technology described in 2257 this document or the extent to which any license under such rights 2258 might or might not be available; nor does it represent that it has 2259 made any independent effort to identify any such rights. Information 2260 on the procedures with respect to rights in RFC documents can be 2261 found in BCP 78 and BCP 79. 2263 Copies of IPR disclosures made to the IETF Secretariat and any 2264 assurances of licenses to be made available, or the result of an 2265 attempt made to obtain a general license or permission for the use of 2266 such proprietary rights by implementers or users of this 2267 specification can be obtained from the IETF on-line IPR repository at 2268 http://www.ietf.org/ipr. 2270 The IETF invites any interested party to bring to its attention any 2271 copyrights, patents or patent applications, or other proprietary 2272 rights that may cover technology that may be required to implement 2273 this standard. Please address the information to the IETF at 2274 ietf-ipr@ietf.org. 2276 Disclaimer of Validity 2278 This document and the information contained herein are provided on an 2279 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2280 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2281 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2282 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2283 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2284 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2286 Copyright Statement 2288 Copyright (C) The Internet Society (2006). This document is subject 2289 to the rights, licenses and restrictions contained in BCP 78, and 2290 except as set forth therein, the authors retain all their rights. 2292 Acknowledgment 2294 Funding for the RFC Editor function is currently provided by the 2295 Internet Society.