RFC 4733
RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals 📞✨
Okay bestie, this one is from the Network Working Group 🌸 and it was written by H. Schulzrinne (Columbia U.) and T. Taylor (Nortel) 💖. It's on the Standards Track and it was published in December 2006. It also obsoletes RFC 2833, which means it's the new version that replaces the old one 🦋.
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🎀
Copyright Notice
Copyright (C) The IETF Trust (2006). 💅
Abstract
Okay so this memo explains how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events inside RTP packets 📦. It obsoletes RFC 2833 🫶.
It takes the basic framework from RFC 2833 and builds on it, but only keeps the most basic event codes 🧚. It also sets up an IANA registry where other event code assignments can get added 🌈. Companion documents add event codes to that registry for modem, fax, text telephony, and channel-associated signalling events 📠. The rest of the event codes from RFC 2833 are conditionally reserved, in case other documents decide to bring them back 🔥.
This document has a bunch of clarifications for the original, but the big difference from RFC 2833 is that it removes the requirement that every compliant implementation supports the DTMF events 🙈. Instead, compliant implementations that take part in out-of-band negotiations of media stream content say which events they support 💜. This memo also adds three new procedures on top of the RFC 2833 framework: splitting long events into segments ✂️, reporting multiple events in a single packet 🍓, and the concept and reporting of state events 👑. Iconic. 😭
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Overview ...................................................4
1.3. Potential Applications .....................................5
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones .....6
2. RTP Payload Format for Named Telephone Events ...................8
2.1. Introduction ...............................................8
2.2. Use of RTP Header Fields ...................................8
2.2.1. Timestamp ...........................................8
2.2.2. Marker Bit ..........................................8
2.3. Payload Format .............................................8
2.3.1. Event Field .........................................9
2.3.2. E ("End") Bit .......................................9
2.3.3. R Bit ...............................................9
2.3.4. Volume Field ........................................9
2.3.5. Duration Field ......................................9
2.4. Optional Media Type Parameters ............................10
2.4.1. Relationship to SDP ................................10
2.5. Procedures ................................................11
2.5.1. Sending Procedures .................................11
2.5.2. Receiving Procedures ...............................16
2.6. Congestion and Performance ................................19
2.6.1. Performance Requirements ...........................20
2.6.2. Reliability Mechanisms .............................20
2.6.3. Adjusting to Congestion ............................22
3. Specification of Event Codes for DTMF Events ...................23
3.1. DTMF Applications .........................................23
3.2. DTMF Events ...............................................25
3.3. Congestion Considerations .................................25
4. RTP Payload Format for Telephony Tones .........................26
4.1. Introduction ..............................................26
4.2. Examples of Common Telephone Tone Signals .................27
4.3. Use of RTP Header Fields ..................................27
4.3.1. Timestamp ..........................................27
4.3.2. Marker Bit .........................................27
4.3.3. Payload Format .....................................28
4.3.4. Optional Media Type Parameters .....................29
4.4. Procedures ................................................29
4.4.1. Sending Procedures .................................29
4.4.2. Receiving Procedures ...............................30
4.4.3. Handling of Congestion .............................30
5. Examples .......................................................31
6. Security Considerations ........................................38
7. IANA Considerations ............................................38
7.1. Media Type Registrations ..................................40
7.1.1. Registration of Media Type audio/telephone-event ...40
7.1.2. Registration of Media Type audio/tone ..............42
8. Acknowledgements ...............................................43
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................44
Appendix A. Summary of Changes from RFC 2833 ......................461. Introduction ✨
1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. 🧠
This document uses the following abbreviations 📚:
ANSam Answer tone (amplitude modulated) [24]
DTMF Dual-Tone Multifrequency [10]
IVR Interactive Voice Response unit
PBX Private branch exchange (telephone system)
PSTN Public Switched (circuit) Telephone Network
RTP Real-time Transport Protocol [5]
SDP Session Description Protocol [9]1.2. Overview
Okay, so this memo defines two RTP [5] payload formats 🎀. The first one carries dual-tone multifrequency (DTMF) digits and other line and trunk signals as events (Section 2) 📞. The second one describes general multifrequency tones using only their frequency and cadence (Section 4) 🎶.
Why do we need separate formats for tone signals? Low-rate voice codecs can't be guaranteed to reproduce tones accurately enough for automatic recognition 😭. Tone properties like the phase reversals in the ANSam tone also don't survive speech coding 💀. Separate formats let you add more redundancy while keeping the bit rate low 🦋. And some telephony events, like "on-hook", happen out-of-band, so they can't be sent as tones at all 🙅♀️.
The rest of this section gives the motivation for the payload types in this document. Section 2 covers the payload format and procedures for named events 💖. Section 3 lists the events that get event codes in this document ✨. Section 4 covers the payload format and procedures for tone representations 🌈. Section 5 has some examples of encoded events, tones, and combined payloads 🍓. Section 6 handles security considerations 🔐. Section 7 sets out the IANA requirements for registering event codes for named telephone events, sets the initial content of that registry, and provides the media type registrations for the two payload formats 📋. Appendix A describes the changes from RFC 2833 [12] and especially shows what happened to the event codes defined in [12] 👑.
1.3. Potential Applications 📞
okay so the payload formats in this doc could be useful in a bunch of different situations 💅✨
on the sending side there are two main options. either the sender is an end system that creates the signals itself, or it's a gateway whose job is to pass incoming phone signals into the Internet 🌐
the receiving side has more going on. first, the receiver might need to pass tone signalling into the PSTN accurately so a machine can read it. a gateway passing DTMF tones to an IVR is a good example 🤖 here, frequencies, amplitudes, tone durations, and the gaps between tones all matter. each tone signal has to arrive reliably and in order, no exceptions 🫶
second, the receiver might need to play tones for a human to hear 🎧 usually this isn't a bunch of tones that each mean something different. it's more like one tone played nonstop, or one sequence of tones and maybe silence, looping for a while. the playout often stops when an event comes back the other way, either in-band or out-of-band. dial tone and busy tone are classic examples 📱
where the tone gets played depends on where you are in the network, and that makes this part messy 😭 in the phone network, tones get generated in different places depending on the switching tech and what kind of tone it is. for example, if you call a foreign country, you might hear your own local tones or the ones used in the country you called. kinda iconic 🌍
for analog lines, the local switch always makes dial tone 📞 ISDN terminals can make dial tone themselves and then send a Q.931 [22] SETUP message with the dialed digits. if the terminal just sends a SETUP message with no Called Party digits, the switch does the digit collection instead. the terminal gives those digits as KEYPAD key press digit information, inside Called Party or Keypad Facility Information Elements (IEs) of INFORMATION messages. then the switch provides dial tone over the B-channel 🎶 the terminal can either use the audio on the B-channel or use the Q.931 messages to trigger dial tone it makes locally 💖
ringing tone (also called ringback tone) is made by the local switch at the callee's end 🔔 a one-way voice path opens up as soon as the callee's phone rings. this cuts down on clipping the called party's response right after answer 🙈 it also lets pre-answer announcements or in-band call-progress indications reach the caller before the ringing tone, or instead of it. congestion tone and special information tones can come from any switch along the way, and the caller's switch can make them based on ISUP messages it gets. busy tone is made by the caller's switch, triggered by the right ISUP message, for analog phones or ISDN terminals 📟
the third scenario is an end system hooked straight up to the Internet that handles the incoming media stream directly 🖥️ there's no need to regenerate tones here, so time alignment and power levels don't matter. these systems count on the sending systems to create events in place of tones, and they don't do their own audio waveform analysis. an Internet interactive voice response (IVR) system is a good example of this one 🧚
when exact timing alignment between the audio stream and the DTMF digits or other events doesn't matter, and the data is sent unicast (like in the IVR example), a reliable control protocol may be a better pick than RTP packets 🌸 in those cases, this payload format wouldn't be used 🙅♀️
also, in a lot of these cases the gateway or end system can be both a sender and a receiver of phone signals 🔁 sometimes the same kind of signals go out the way they came in, like with "RTP trunking" or voice-band data. in other cases, like an end system serving analogue lines, the signals sent are a different class from the ones received ✨
1.4. Events, States, Tone Patterns, and Voice-Encoded Tones 🌈
this doc gives us a way to carry two big classes of signalling info in-band over the Internet 🦋 the first is in-band tones or tone sequences. the second is signals sent out-of-band in the PSTN. tone signals can ride along using any of the three methods below, and depending on the app, you might want to send the signalling in more than one form at once 💜
- the gateway or end system can switch to a higher-bandwidth codec like G.711 [19] when tone signals need to be carried. check out ITU-T Recommendation V.152 [26] for a formal take on this approach 📚 for fax, text, or modem signals, a specialized transport works instead, like T.38 [23], RFC 4103 [15], or V.150.1 modem relay [25]. and 64 kbit/s channels can be carried transparently with the RFC 4040 Clearmode payload type [14] 🎀 these methods are out of scope for this doc, but they can be used alongside the payload types defined here.
- the sending gateway can just measure the frequency components of the voice-band signals and send that info to the RTP receiver, using the tone representation defined in this doc (Section 4) 📊 in this mode, the gateway doesn't try to figure out what the tones mean. it just tells tones apart from speech 🗣️ an end system can do the same thing using configured frequencies instead of measured ones.
all tone signals in use in the PSTN that are meant for human ears are sequences of simple combos of sine waves, either added or modulated 🎵 (but some modem signals, like the ANSam tone [24] or systems that use phase shift keying, can't be carried that simply 😭)
- the third option is for a sending gateway to recognize tones like ringing, busy tone, or DTMF digit '0', and then send a code that identifies them using the telephone-event payload defined in this doc (Section 2) 🫧 the receiver then makes a tone or another indication that fits the signal. recognition at the sender often depends on the on/off pattern or the sequence of several tones, so it can take several seconds ⏳ on the flip side, the gateway might have access to the actual signalling info that makes the tones, so it can create the RTP packet right away, skipping the detour through acoustic signals ⚡
the third option (named events) is the only workable method for sending out-of-band PSTN signals as content inside RTP sessions 👑
2. RTP Payload Format for Named Telephone Events 🎀
2.1. Introduction 💖
the RTP payload format for named telephone events is called "telephone-event", and its media type is "audio/telephone-event". following current practice, this payload format doesn't get a static payload type number. instead, it uses an RTP payload type number that's set up dynamically and out-of-band 🧚 the default clock frequency is 8000 Hz, but you can redefine the clock frequency when you assign the dynamic payload type 🕰️
named telephone events are carried as part of the audio stream, and they MUST use the same sequence number and timestamp base as the regular audio channel. this makes it simpler to generate audio waveforms at a gateway 🔊 the named telephone-event payload type can be thought of as a super highly-compressed audio codec, and it's treated the same as other codecs 🫶
2.2. Use of RTP Header Fields 🧩
2.2.1. Timestamp ⏰
the event duration described in Section 2.5 starts at the time given by the RTP timestamp. for events that span multiple RTP packets, the RTP timestamp marks the beginning of the event, so several RTP packets can carry the same timestamp 👯 for long-lasting events that have to be split into segments (see below, Section 2.5.1.3), the timestamp marks the beginning of the segment 🍓
2.2.2. Marker Bit 🚩
the RTP marker bit marks the beginning of a new event 🏁 for long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the first segment has the marker bit set ✨
2.3. Payload Format 📦
the payload format for named telephone events is shown in Figure 1 👇
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E|R| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Payload Format for Named Events2.3.1. Event Field 🔢
the event field is a number from 0 to 255 that identifies a specific telephony event 📞 there's an IANA registry of event codes for this field (see IANA Considerations, Section 7). the registry starts out with the events defined in Section 3 📋
2.3.2. E ("End") Bit 🛑
if this bit is set to one, the "end" bit means this packet contains the end of the event. for long-lasting events that have to be split into segments (see below, Section 2.5.1.3), only the final packet of the final segment has the E bit set 🏁
2.3.3. R Bit 🫥
this field is reserved for future use. the sender MUST set it to zero, and the receiver MUST ignore it 🔒
2.3.4. Volume Field 🔉
for DTMF digits and other events that can be represented as tones, this field describes the power level of the tone, in dBm0 with the sign dropped. power levels range from 0 to -63 dBm0, so bigger values mean lower volume 📉 this value is only defined for events where the docs say volume applies. for other events, the sender MUST set volume to zero, and the receiver MUST ignore the value 🙅♀️
2.3.5. Duration Field ⏱️
the duration field shows how long the event or segment being reported has lasted, in timestamp units. it's an unsigned integer in network byte order 🧮 for a non-zero value, the event or segment started at the instant the RTP timestamp points to, and it has lasted this long so far. the event may or may not have ended yet 🌙 if the event's duration is bigger than the largest value the duration field can hold, the event gets split into several contiguous segments, as described below (Section 2.5.1.3) 🧩
the special duration value of zero is reserved for events that last "forever". in other words, it's a state, and it stays in effect until it gets updated ♾️ a sender MUST NOT transmit a zero duration for events other than ones defined as states 🚫 the receiver SHOULD ignore an event report with zero duration if the event isn't a state 🙈
events defined as states MAY contain a non-zero duration. that tells you the sender plans to refresh the state before that time runs out. this is called "soft state" 🫧
For a sampling rate of 8000 Hz, the duration field is enough to express event durations of up to approximately 8 seconds ⏳💜
2.4. Optional Media Type Parameters 🎀
okay so the telephone-event media type has two optional parameters, "events" and "rate" 💅 (Section 7.1.1 is where the media type registration lists them)
The "events" parameter is basically the guest list of which events your implementation can handle 💖. Each element is either a single integer (one event code) or an integer, a hyphen, and a bigger integer (a whole range of consecutive codes) 🦋. Elements are comma-separated, the list does not have to be sorted, and no white space is allowed in the argument. The union of all the single codes and ranges is the full set of event numbers your implementation supports ✨
The "rate" parameter is the sampling rate in Hertz 🌸 and it sets the units for the RTP timestamp and the event duration fields, so it matters a lot. It's written as an integer, and if you leave it out, the default is 8000 Hz ⏰
2.4.1. Relationship to SDP 🦋
The recommended way to map media type optional parameters into SDP lives in Section 3 of RFC 3555 [6]. The "rate" parameter for the named event payload type follows that convention, so it shows up as usual in the <clock rate> part of the a=rtpmap: attribute line 🧚
The "events" parameter is the rebel here 😭 it doesn't follow the RFC 3555 suggestion because it skips the string "events=" before the list. Instead the SDP looks like this:
a=fmtp:<format> <list of values>The list of values has the same format and meaning we just covered 💜
Here's a cute example. Say the payload format uses payload type number 100, and the implementation can handle the DTMF tones (events 0 through 15) plus the dial and ringing tones (pretend these were defined as events with codes 66 and 70 🙈). The SDP message would include this:
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70And this media type definition matches the SDP example above 💅
audio/telephone-event;events="0-15,66,70";rate="8000"2.5. Procedures 🌈
This section is where the rules for the named event payload type live 📜 Extra procedures might also be defined in the docs for specific event codes, so keep an eye out for those too 👀
2.5.1. Sending Procedures 🚀
2.5.1.1. Negotiation of Payloads 💌
Events usually travel together with, or taking turns with, other payload types 🎶 Payload negotiation can set up separate event and other payload streams, OR it can set up a combined stream that mixes other payloads with events using RFC 2198 [2] redundancy headers. A combined stream might be used for debugging, or to make the switch between general audio and events smoother 🧃
Sender and receiver negotiate payloads out-of-band, using SDP for example 📨
The sender SHOULD indicate which events it supports, using the optional "events" parameter that goes with the telephone-event media type 💖 If the sender gets an "events" parameter from the receiver, it MUST restrict what it sends to only the events listed in that received parameter 🚫 For backward compatibility, if no "events" parameter shows up, the sender SHOULD assume support for DTMF events 0-15 and nothing else 🎀
Events MAY be sent in combination with older events using RFC 2198 [2] redundancy 🔁 Section 2.5.1.4 explains how this avoids packet and RTP header overhead when retransmitting final event reports 💅 Section 2.6 talks about adding more levels of RFC 2198 redundancy so there's a better chance that at least one copy of the end-of-event report reaches the receiver 🫶 Here's an SDP example of that setup, with G.711 audio in its own stream and events as the primary part of the redundant payload:
m=audio 12344 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12346 RTP/AVP 100 101
a=rtpmap:100 red/8000/1
a=fmtp:100 101/101/101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15When you're using the offer-answer model (RFC 3264 [4]), the SDP a=ptime: attribute tells the other side the packetization period the session description's author expects to receive 🕰️ The two directions don't have to match 🙌 The right period depends on the application, because longer packetization periods mean longer end-to-end response times when one end reacts to events reported by the other 😭
Negotiating telephone-events sessions with SDP MAY set up differences like this by splitting events for different applications into different streams ✨ In the example below, events 0-15 are DTMF events, and they have pretty wide timing tolerance 💜 Events 32-49 and 52-60 are related to data transmission and care a lot about end-to-end response time, so they get a smaller packetization period than the DTMF events 🏃♀️
m=audio 12344 RTP/AVP 99
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:50
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 32-49,52-60
a=ptime:30For more on packetization periods, check out Section 2.6.3 🍓
2.5.1.2. Transmission of Event Packets 📦
DTMF digits and other named telephone events ride along as part of the audio stream 🎧 They MUST use the same sequence number and timestamp base as the regular audio channel, which makes it way easier for a gateway to generate audio waveforms 🪄
An audio source SHOULD start sending event packets as soon as it recognizes an event, and keep sending updates until the event ends 🚀 Each update packet MUST have the same RTP timestamp value as the first packet for that event, but its duration MUST grow to show the total cumulative duration since the event began ⏳
The first packet for an event MUST have the M bit set 🚩 The final packet for an event MUST have the E bit set, but setting the "E" bit MAY be put off until the final packet gets retransmitted (see Section 2.5.1.4) 🕊️ Intermediate packets MUST NOT have either the M bit or the E bit set 🙅♀️
Sending a packet with the E bit set is OPTIONAL if that packet reports two events defined as mutually exclusive states, OR if the final packet for one state is immediately followed by a packet reporting a mutually exclusive state 🤝 (For events defined as states, showing up of a mutually exclusive state means the previous state is over 🔚)
A source has lots of freedom with how often it sends event updates 💃 A natural choice is the spacing between non-event audio packets. (Remember, one RTP packet can hold multiple audio frames for frame-based codecs, and the packet interval can change during a session 🎞️) Or a source MAY pick a different spacing for event updates, and a value of 50 ms is RECOMMENDED ⏱️
Timing info lives in the RTP timestamp, so the receiver can precisely work out the gaps between events 🧠 That means the sender doesn't, in theory, need to keep precise or consistent intervals between event packets 🤓 Still, the sender SHOULD cut down on buffering at the receiving end by sending event reports at constant intervals 💖
DTMF digits and other tone events get sent incrementally so the receiver doesn't have to wait for the event to finish 😭 In some cases (like data session startup protocols), waiting until the end of a tone before reporting it would make the session fail 💀 In other cases, it just causes annoying playout delays at the receiving end 🙄
For robustness, the sender SHOULD retransmit "state" events periodically 🔁
2.5.1.3. Long-Duration Events ⏳
If an event lasts longer than the maximum duration the duration field can hold (0xFFFF), the sender MUST send a packet reporting that maximum duration, but MUST NOT set the E bit in that packet 🚫 Then the sender MUST start reporting a new "segment", with the RTP timestamp set to when the previous segment ended and the duration set to the cumulative duration of the new segment 🧩 The M bit of the first packet for the new segment MUST NOT be set 🙅♀️ The sender MUST keep repeating this procedure as needed until the whole event is over 🔄 The final packet for the complete event MUST have the E bit set, either on the first send or on a retransmission (more on that below) 🎀
2.5.1.3.1. Exceptional Procedure for Combined Payloads 🌀
If events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, the procedure above SHALL still apply, but with a maximum duration that makes sure the timestamp offset of the oldest generation of events in an RFC 2198 packet never goes past 0x3FFF 🧮 If the sender uses a constant packetization period, the maximum segment duration can be worked out with this formula:
maximum duration = 0x3FFF - (R-1)*(packetization period in
timestamp units)where R is the highest redundant layer number that consists of the event payload 🍰
The RFC 2198 redundancy header timestamp offset is only 14 bits, while the event payload duration field has 16 bits 🤏 Other payloads usually bump the RTP timestamp for every new sample, so the timestamp offset ends up being the thing that limits the reported event duration. It gets even tighter when older generations of events are also in the combined payload 😤
2.5.1.4. Retransmission of Final Packet 🔁
The final packet for each event and for each segment SHOULD be sent a total of three times at the interval the source uses for updates 💌 That way, the duration of the event or segment can still be recognized correctly even if one copy of the last packet gets lost 🛟
A sender MAY use RFC 2198 [2] with up to two levels of redundancy to combine retransmissions with reports of new events, which saves on header overhead 🧃 In this setup, the primary payload carries new event reports, while the first and (if needed) second redundancy levels carry the first and second retransmissions of final event reports 🔥 Within a session negotiated to allow this, packets containing the RFC 2198 payload SHOULD NOT be sent unless both primary and retransmitted reports are being included 🙅♀️ All other packets in the session SHOULD contain only the simple, non-redundant telephone-event payload 🫧 Also, the expected ratio of simple to redundant packets affects the order they should be listed in on an SDP m= line 📋
There's not much point in sending initial or interim event reports redundantly, because each new packet describes the event fully (apart from volume, which is usually irrelevant) 💁♀️
A sender MAY delay setting the E bit until it retransmits the last packet for a tone, instead of setting it on the first transmission 🕰️ That way, the sender doesn't have to wait to find out whether the tone has really ended 🙌 Once the sender has set the E bit on a packet, it MUST keep setting the E bit on any further retransmissions of that packet 🔒
2.5.1.5. Packing Multiple Events into One Packet
okay so you can pack multiple named events into one single RTP packet 📦✨ but ONLY if they're consecutive and contiguous, meaning no overlap and no pause in between them 🫶 and the last event in the packet has to happen fast enough that the receiver doesn't get stuck waiting forever 😭
this is lowkey like having multiple frames of frame-based audio stuffed into one RTP packet 🎀
bestie the no-overlap rule has a big consequence 💅 events marked as states can only be followed in a packet by other state events that are mutually exclusive with them. the whole point of the constraint is so the receiver can figure out when each event begins 🦋
in a packet with events packed like this, the RTP timestamp MUST identify the beginning of the first event or segment in the packet 💖 the M bit MUST be set if the packet records the beginning of at least one event. (this is true except when the packet carries the end of one segment and the beginning of the next segment of the same long-lasting event 🙈) and the E bit and duration for each event in the packet MUST be set using the same rules as if that event were the only event in the packet 👑
2.5.1.6. RTP Sequence Number
the RTP sequence number MUST be incremented by one in each successive RTP packet sent 🔥 and this counts for retransmitted event reports too, not just the first copies. that's how the receiver can spot lost packets for RTP Control Protocol (RTCP) receiver reports 🌸
2.5.2. Receiving Procedures
2.5.2.1. Indication of Receiver Capabilities Using SDP
receivers can say which named events they can handle, for example by using the Session Description Protocol (RFC 4566 [9]) ✨ SDP descriptions using the event payload MUST contain an fmtp format attribute that lists the event values the receiver can process 🎀
2.5.2.2. Playout of Tone Events
okay gateway moment 🧚 an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF or other tones and injects them into the PSTN. but DTMF digit recognition takes several tens of milliseconds, so the first few milliseconds of a digit arrive as regular audio packets 🙈 so careful time and power (volume) alignment between the audio samples and the events is needed, or you'll get spurious digits at the receiver 💀 the receiver may also choose to delay playout of the tones by a small interval after the preceding audio ends, so downstream equipment can tell the tones apart properly 💜
some implementations send events AND encoded audio packets (like PCMU or the speech codec) for the same time instant over the event's duration. it is RECOMMENDED that gateways render only the telephone-event payload once it's received, since the audio might have spurious tones from the audio compression algorithm 🫶 but it's anticipated these extra tones generally shouldn't interfere with recognition at the far end ✨
receiver implementations MAY use different algorithms to create tones, including the two described here 🌈 (not every implementation needs to re-create a tone. some only care about recognizing the events 💅) with either algorithm, a receiver may add a playout delay for robustness against packet loss or delay. the tradeoff between playout delay and other factors is discussed further in Section 2.6.3 🦋
in the first algorithm, the receiver just puts a tone of the given duration in the audio playout buffer at the location the timestamp indicates. when more packets extend the same tone, the waveform in the buffer gets extended too 🎀 (be careful if audio is mixed, i.e., summed, in the buffer instead of simply copied 👀) so if a packet in a tone lasting longer than the packet interarrival time gets lost and the playout delay is short, a gap in the tone can happen 😭
the alternative is that the receiver starts a tone and keeps playing it until one of these happens:
- it receives a packet with the E bit set;
- it receives the next tone, distinguished by a different timestamp value (noting that new segments of long-duration events also appear with a new timestamp value);
- it receives an alternative non-event media stream (assuming none was being received while the event stream was active); or
- a given time period elapses.
this is more robust against packet loss, but it may extend the tone past its original duration if all retransmissions of the last packet in an event are lost 🥹 limiting how long the tone can extend is necessary so the tone doesn't "get stuck" 🙃 this algorithm is NOT a license for senders to set the duration field to zero. it MUST be set to the current duration as described, since this is needed to create accurate events if the first event packet is lost, among other reasons 💅
regardless of the algorithm, the tone SHOULD NOT be extended by more than three packet interarrival times. a slight extension of tone durations and shortening of pauses is generally harmless ✨
a receiver SHOULD NOT restart a tone once playout has stopped 🙅♀️ it MAY do so if the tone is meant for human consumption or is one where interruptions won't cause confusion at the receiving device 🌸
if a receiver gets an event packet for an event it isn't currently playing out, and the packet doesn't have the M bit set, earlier packets for that event have evidently been lost 😭 you can confirm this by looking for gaps in the RTP sequence number 🔍 the receiver MAY use its retained history plus the timestamp and event code of the current packet to figure out that it matches an event that already played out and lapsed. in that case, further reports for the event MUST be ignored, as the previous paragraph said 🫶
if the event has NOT been played out at all, the receiver MAY try to play it out for the full duration in the event report 🎀 how that goes depends on the event type. it needs thinking about how the event relates to audio media flows and whether the correct event duration is essential to the media session working properly 🧠
a receiver SHOULD NOT rely on a particular event packet spacing. instead it MUST use the event timestamps and durations to determine the timing and duration of playout 💖
the receiver MUST calculate jitter for RTCP receiver reports based on all packets with a given timestamp. note: the jitter value should mainly be used to compare reception quality between two users or two time periods, not as an absolute measure 📊
if a zero volume is indicated for an event where the volume field is defined, the receiver MAY reconstruct the volume from the volume of non-event audio, or MAY use the nominal value specified by the ITU Recommendation or other document defining the tone 🌈 this keeps backwards compatibility with RFC 2833 [12], where the volume field was only defined for DTMF events 🍓
2.5.2.3. Long-Duration Events
if an event report arrives with a duration equal to the maximum expressible in the duration field (0xFFFF) and the E bit for the report is not set, the report may mark the end of a segment generated according to the procedures of Section 2.5.1.3 ✨ if another report for the same event type arrives, the receiver MUST compare the RTP timestamp for the new event with the sum of the RTP timestamp of the previous report plus the duration (0xFFFF) 🦋 the receiver uses the absence of a gap between the events to detect that it's receiving a single long-duration event 🔥
the total duration of a long-duration event is (obviously) the sum of the durations of the segments used to report it. that equals the duration of the final segment (as indicated in the final packet for that segment), plus 0xFFFF multiplied by the number of segments before the final segment 🧮👑
2.5.2.3.1. Exceptional Procedure for Combined Payloads
if events are combined as a redundant payload with another payload type using RFC 2198 [2] redundancy, segments are generated at intervals of 0x3FFF or less, instead of 0xFFFF, as required by the procedures of Section 2.5.1.3.1 in this case 🙈 if a receiver is using the events component of the payload, the event duration may only be an approximate hint for how it was split into segments. but the lack of an E bit and two reports with the same event code next to each other are strong signs in themselves 💅
2.5.2.4. Multiple Events in a Packet
the procedures of Section 2.5.1.5 require that if multiple events are reported in the same packet, they're contiguous and non-overlapping 🫶 so it's not strictly necessary for the receiver to know the start times of the events after the first one in order to play them out. it only needs to respect the duration reported for each event 🎀 still, if the start time of a given event after the first one is needed, it equals the start time of the preceding event plus the duration of the preceding event 🧠
2.5.2.5. Soft States
if the duration of a soft state event expires, the receiver SHOULD consider the value of the state to be "unknown" unless the event documentation says otherwise 🌸
2.6. Congestion and Performance
packet transmission through the Internet has occasional periods of congestion lasting on the order of seconds 😩 during these, network delay, jitter, and packet loss are all WAY higher than in between them. Reference [28] characterizes this phenomenon 📚 well-behaved applications are preferably expected to reduce their demands on the network during these periods of congestion. at the very least, they should not increase their demands 🙏 this section looks at both application performance and the ways to behave well in the face of congestion 💜
2.6.1. Performance Requirements
typically, an implementation of the telephone-event payload will aim to limit how often each of these impairments happens:
a. an event encoded at the sender fails to be played out at the receiver, either because the event report is lost or because it arrives after playout of later content has started;
b. the start of playout of an event at the receiver is delayed relative to other events or other media operating on the same timestamp base;
c. the duration of playout of a given event differs from the correct duration as detected at the sender by more than a given amount;
d. gaps occur in playout of a given event;
e. end-to-end delay for the media stream exceeds a given value.
the relative importance of these constraints varies between applications 🌈
2.6.2. Reliability Mechanisms 🛡️
okay so to make things more reliable, every payload type (telephone-events included) can use a jitter buffer 🧃, which just means the receiver imposes a playout delay. this handles the first four requirements listed above, but it costs you on the last one 😭
the named event procedures give you two complementary redundancy mechanisms for dealing with lost packets 💅
- a. Intra-event updates: events that last longer than one packetization period (e.g., 50 ms) get updated periodically, so the receiver can rebuild the event and its duration if it gets any of the update packets, just with some delay ⏳. during an event, the RTP event payload format gives incremental updates on the event. how resilient this is depends on whether the first or second algorithm in Section 2.5.2.2 is used and on the playout delay at the receiver. for example, if the receiver uses the first algorithm and only puts the current duration of tone signal in the playout buffer, with a playout delay of 120 ms and a packetization interval of 50 ms, two packets in a row can get lost without causing a premature end of the tone generated 🎶
- b. Repeat last event packet: as Section 2.5.1.4 describes, the last report for an event is transmitted a total of three times. this adds robustness to the reporting of the end of an event 🫶
it may be necessary to extend the level of redundancy to achieve requirement a) (in Section 2.6.1) in a specific network environment. taking the 25-30% loss rate during congestion periods illustrated in [28] as typical, and setting an objective that at least 99% of end-of-event reports will eventually get through to the receiver under these conditions, simple probability calculations indicate that each event completion has to be reported four times. that's one more level of redundancy than the basic "Repeat last event packet" algorithm requires. ngl the objective is probably unrealistically stringent 🙈 it was chosen to make a point.
where Section 2.5.1.4 indicates that it is appropriate to use the RFC 2198 [2] audio redundancy mechanism to carry retransmissions of final event reports, this mechanism MAY also be used to extend the number of final report retransmissions. this is done by using more than two levels of redundancy when necessary. the use of RFC 2198 helps mitigate the extra bandwidth demands that would be imposed simply by retransmitting final event packets more than three times 🧠✨
these two redundancy mechanisms clearly address requirement a) in the previous section. they also help meet requirement c), to the extent that the redundant packets arrive before playout of the events they report is due to expire. they're not helpful for the other requirements, although they don't directly cause impairments themselves the way a large jitter buffer increases end-to-end delay 💖
the playout algorithm is an additional mechanism for meeting the performance requirements. in particular, using the second algorithm in Section 2.5.2.2 will meet requirement d) of the previous section by preventing gaps in playout, but at the potential cost of increases in duration (requirement c)) 🌸
finally, there's an interaction between the packetization period a sender uses, the playout delay the receiver uses, and how vulnerable an event flow is to packet losses. assuming packet losses are independent, a shorter packetization interval means the receiver can use a smaller playout delay to recover from a given number of consecutive packet losses, at any stage of event playout. this improves end-to-end delays in applications where that matters 🦋
in view of the tradeoffs between the different reliability mechanisms, documentation of specific events SHOULD include a discussion of the appropriate design decisions for the applications of those events. this mandate is repeated in the section on IANA considerations 📋
2.6.3. Adjusting to Congestion 🚦
so far we've been talking about meeting performance requirements. but there's also the question of whether applications of events can adapt to congestion enough to reduce their demands on the network during congestion. in theory this can be done for events by increasing the packetization interval, so fewer packets get sent per second. this has to be accompanied by an increased playout delay at the receiving end. coordination between the two ends for this purpose is an interesting issue in itself. if it's done, though, the action implies a one-time gap or extended playout of an event when the packetization interval is first extended, plus increased end-to-end delay during the whole period of increased playout delay 😮💨
the benefit from such a measure depends mainly on the average duration of the events being handled. in the worst case, as a first example shows, the reduction in aggregate bandwidth usage due to an increased packetization interval may be pretty modest. suppose the average event duration is 3.33 ms (V.21 bits, for instance). suppose further that four transmissions in total are required for a given event report to meet the loss objective. Table 1 shows the impact of varying packetization intervals on the aggregate bit rate of the media stream 📊
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 2440 | 48800 |
| 33.3 | 30 | 1800 | 54000 |
| 25 | 40 | 1480 | 59200 |
| 20 | 50 | 1288 | 64400 |
+--------------------+-----------+---------------+------------------+
Table 1: Data Rate at the IP Level versus Packetization Interval
(three retransmissions, 3.33 ms per event)as you can see, doubling the interval (from 25 to 50 ms) drops the aggregate bit rate by about 20% 📉 while increasing end-to-end delay by 25 ms and causing a one-time gap of the same amount. (extending the playout of a specific V.21 tone event is out of the question, so the first algorithm of Section 2.5.2.2 must be used in this application 🙅♀️) the reduction in the number of packets per second with longer packetization periods gets countered by the increase in packet size due to the increase in number of events per packet.
for events of longer duration, the reduction in bandwidth is more proportional to the increase in packetization interval. the loss of final event reports may also be less critical, so lower redundancy levels are acceptable 🎀 Table 2 shows similar data to Table 1, but assumes 70-ms events separated by 50 ms of silence (as in an idealized DTMF-based text messaging session) with only the basic two retransmissions for event completions 💬
+--------------------+-----------+---------------+------------------+
| Packetization | Packets/s | IP Packet | Total IP Bit |
| Interval (ms) | | Size (bits) | Rate (bits/s) |
+--------------------+-----------+---------------+------------------+
| 50 | 20 | 448/520 | 10040 |
| 33.3 | 30 | 448/520 | 14280 |
| 25 | 40 | 448/520 | 18520 |
| 20 | 50 | 448 | 22400 |
+--------------------+-----------+---------------+------------------+
Table 2: Data Rate at the IP Level versus Packetization Interval
(two retransmissions, 70 ms per event, 50 ms between events)in the third column of the table, the packet size is 448 bits when only one event is being reported and 520 bits when the previous event is also included. no more than one level of redundancy is needed up to a packetization interval of 50 ms, although at that point most packets are reporting two events. longer intervals need a second level of redundancy in at least some packets 🔁
3. Specification of Event Codes for DTMF Events 📞
this document defines one class of named events: DTMF tones 🎹✨
3.1. DTMF Applications 🎀
okay so DTMF signalling [10] is usually generated by a telephone set, or possibly by a PBX (Private branch telephone exchange) 📞. DTMF digits can get consumed by things like gateways or application servers on the IP side, or by telephone switches or IVRs on the circuit switched side 💅.
At the sending end, the DTMF events support two possible applications ✨
- The Internet telephony gateway detects DTMF on the incoming circuits and sends the RTP payload described here instead of regular audio packets. The gateway likely has the digital signal processors and algorithms it needs, since it often has to detect DTMF anyway, e.g., for two-stage dialing. Having the gateway detect tones takes that work off the receiving Internet end system, and it also stops low bit-rate codecs like G.723.1 [20] from rendering DTMF tones unintelligible 🫶
- An Internet end system such as an "Internet phone" can emulate DTMF functionality without worrying about generating precise tone pairs, and without putting the burden of tone recognition on the receiver 🦋
A similar distinction shows up at the receiving end 👀
- In the gateway scenario, an Internet telephony gateway connecting a packet voice network to the PSTN re-creates the DTMF tones or other telephony events and injects them into the PSTN 🔥
- In the end system scenario, the DTMF events are consumed by the receiving entity itself 💜
In the most common application, DTMF tones are sent in one direction only, typically from the calling end, and the consuming device is most commonly an IVR. DTMF may alternate with voice from either end. In most cases, the only constraint on tone duration is that it exceeds a minimum value. However, in some cases a long-duration tone (in excess of 1-2 seconds) has special significance. 😭
ITU-T Recommendation Q.24 [11], Table A-1, indicates that the legacy switching equipment in the countries surveyed expects a minimum recognizable signal duration of 40 ms, a minimum pause between signals of 40 ms, and a maximum signalling rate of 8 to 10 digits per second depending on the country. Human-generated DTMF signals, of course, are generally longer with larger pauses between them. 💅
DTMF tones can also be used for text telephony 📱, which is documented in ITU-T Recommendation V.18 [27] Annex B. In this case, DTMF is sent alternately from either end (half-duplex mode), with a minimum 300-ms turn-around time. The only constraints on tone durations in this application are that they, and the pauses between them, must exceed specified minimum values. It is RECOMMENDED that a gateway at the sending end be capable of detecting DTMF signals as specified by V.18 Annex B (tones and pauses >=40 ms), but should send event durations matching a V.18 DTMF sender's (tones >=70 ms, pauses >=50 ms). This may occasionally mean some buffering of outgoing events, but if the source terminal conforms to V.18 Annex B, this should not get out of hand 🌸
Minor increases in tone duration are harmless for every DTMF application, but unintended breaks in playout of a DTMF digit can confuse the receiving endpoint by creating the appearance of extra digits. So receiving applications that convert DTMF events back to tones SHOULD use the second playout algorithm rather than the first one in Section 2.5.2.2. This gives some robustness against packet loss or congestion 🧚
3.2. DTMF Events 🍓
Table 3 shows the DTMF-related event codes within the telephone-event payload format. The DTMF digits 0-9 and * and # are commonly supported. DTMF digits A through D are less frequently encountered, typically in special applications such as military networks 🎖️
+-------+--------+------+---------+
| Event | Code | Type | Volume? |
+-------+--------+------+---------+
| 0--9 | 0--9 | tone | yes |
| * | 10 | tone | yes |
| # | 11 | tone | yes |
| A--D | 12--15 | tone | yes |
+-------+--------+------+---------+
Table 3: DTMF Named Events3.3. Congestion Considerations 🌈
The key considerations for delivering DTMF events are reliability and avoiding unintended breaks within the playout of a given tone. End-to-end round-trip delay is not a major consideration, except in the special case where DTMF tones are used for text telephony. Assuming that, as recommended in Section 3.1 above, the second playout algorithm of Section 2.5.2.2 is in use, a temporary increase in packetization interval to as much as 100 ms or double the normal interval, whichever is less, should be harmless 💖
4. RTP Payload Format for Telephony Tones ✨
4.1. Introduction 🦋
Instead of describing tones and events by name, as described in Section 2, it is sometimes preferable to describe them by their waveform properties. Recognition is faster this way than naming signals, since it doesn't depend on recognizing durations or pauses ⚡
There is no single international standard for telephone tones such as dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones, or some of the other special tones, like payphone recognition, call waiting or record tone. Still, ITU-T Recommendation E.180 [18] notes that across all countries, these tones share a number of characteristics 👑
- Telephony tones consist of either a single tone, the addition of two or three tones, or the modulation of two tones. (Almost all tones use two frequencies; only the Hungarian "special dial tone" has three.) Tones that are mixed have the same amplitude and do not decay.
- In-band tones for telephony events are in the range of 25 Hz (ringing tone in Angola) to 2600 Hz (the tone used for line signalling in SS No. 5 and R1). The in-band telephone frequency range is limited to 3400 Hz. R2 defines a 3825 Hz out-of-band tone for line signalling on analogue trunks. (The piano has a range from 27.5 to 4186 Hz.)
- Modulation frequencies range between 15 (ANSam tone) to 480 Hz (Jamaica). Non-integer frequencies are used only for frequencies of 16 2/3 and 33 1/3 Hz.
- Tones that are not continuous have durations of less than four seconds.
- ITU Recommendation E.180 [18] notes that different telephone companies require a tone accuracy of between 0.5 and 1.5%. The Recommendation suggests a frequency tolerance of 1%.
4.2. Examples of Common Telephone Tone Signals 🌸
As an aid to the implementor, Table 4 summarizes some common tones. The rows labeled "ITU ..." refer to ITU-T Recommendation E.180 [18]. In these rows, the on and off durations are suggested ranges within which local standards would set specific values. The symbol "+" in the table indicates addition of the tones, without modulation, while "*" indicates amplitude modulation 🧁
+-------------------------+-------------------+----------+----------+
| Tone Name | Frequency | On Time | Off Time |
| | | (s) | (s) |
+-------------------------+-------------------+----------+----------+
| CNG | 1100 | 0.5 | 3.0 |
| V.25 CT | 1300 | 0.5 | 2.0 |
| CED | 2100 | 3.3 | -- |
| ANS | 2100 | 3.3 | -- |
| ANSam | 2100*15 | 3.3 | -- |
| V.21 bit | 980 or 1180 or | 0.00333 | -- |
| | 1650 or 1850 | | |
| ------------- | ---------- | -------- | -------- |
| ITU dial tone | 425 | -- | -- |
| U.S. dial tone | 350+440 | -- | -- |
| ITU ringing tone | 425 | 0.67-1.5 | 3-5 |
| U.S. ringing tone | 440+480 | 2.0 | 4.0 |
| ITU busy tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. busy tone | 480+620 | 0.5 | 0.5 |
| ITU congestion tone | 425 | 0.1-0.6 | 0.1-0.7 |
| U.S. congestion tone | 480+620 | 0.25 | 0.25 |
+-------------------------+-------------------+----------+----------+
Table 4: Examples of Telephony Tones4.3. Use of RTP Header Fields 💅
4.3.1. Timestamp ⏰
The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 4.3.3 begins at that time 🕰️
4.3.2. Marker Bit 🚩
The tone payload type uses the marker bit to tell the first RTP packet reporting a given instance of a tone apart from the succeeding packets for that tone. The marker bit SHOULD be set to 1 for the first packet, and to 0 for all succeeding packets relating to the same tone 💜
4.3.3. Payload Format 💖
okay so based on everything we just covered 🫶 this doc defines an RTP payload format called "tone" that can represent tones made of one or more frequencies 🎶 (the matching media type is "audio/tone"). The default timestamp rate is 8000 Hz, but other rates can be defined. ngl this detail matters: the timestamp rate does not change how the frequency gets interpreted, only the durations ⏱️
per current practice, this payload format doesn't have a static payload type number 🙅♀️ instead it uses a payload type number that gets established dynamically and out-of-band 🎀
here's the layout in Figure 2 🌸
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation |T| volume | duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| frequency |R R R R| frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Payload Format for Tonesthe payload has these fields, and each one is a little piece of the puzzle 🧩
- modulation: the modulation frequency in Hz 🌈 it's a 9-bit unsigned integer, so modulation frequencies go up to 511 Hz. no modulation? then this field is zero. also heads up that the amplitude of the modulation isn't in the payload, so it must be figured out by out-of-band means 👀
- T: if the T bit is set (one), the modulation frequency gets divided by three. otherwise you take the modulation frequency as is. this bit is how we get accuracy to 1/3 Hz, because stuff like 16 2/3 Hz is actually used in the real world 🦋
- volume: the power level of the tone, written in dBm0 after you drop the sign, going from 0 to -63 dBm0. (quick aside: a preferred level range for digital tone generators is -8 dBm0 to -3 dBm0 💅)
- duration: the length of the tone, measured in timestamp units and sent in network byte order ⏳ the tone starts at the instant the RTP timestamp points to and lasts for the duration value. a value of zero is not permitted, and tones with that duration SHOULD be ignored 🙈 this definition lines up with sample-based codecs, where the timestamp is the sampling point for the first sample.
- frequency: the frequencies of the tones being added, measured in Hz and stored as a 12-bit unsigned integer 🎵 that goes up to 4095 Hz, which is way more than telephone systems need. a value of zero means silence. one tone can hold any number of frequencies, and if you specify none, the packet is reporting a period of silence 🤫
- R: reserved for future use 🔒 the sender MUST set it to zero, and the receiver MUST ignore it.
4.3.4. Optional Media Type Parameters 🧚
the "rate" parameter tells you the sampling rate in Hertz 🎀 it's written as an integer, and if you leave it out, the default is 8000 Hz.
4.4. Procedures 🌸
this section covers the procedures that go with the tone payload type ✨
4.4.1. Sending Procedures 📤
okay so the sender MAY send an initial tones packet the moment a tone gets recognized, or it MAY wait until a pre-negotiated packetization period has passed ⏰ the first RTP packet for a tone SHOULD have the marker bit set to 1 🚩
for longer tones, the sender SHOULD generate multiple RTP packets for the same tone instance 🔁 the RTP timestamp MUST be updated for every packet generated. this is different from telephone-event packets, which work differently here 👀 later packets for the same tone SHOULD have the marker bit set to 0, and the RTP timestamp in each one MUST equal the timestamp plus the duration from the packet before it 🧮
a final RTP packet MAY be generated as soon as the end of the tone gets detected, so you don't have to wait for the latest packetization period to run out 🏃♀️
now the telephone-event payload from Section 2 is inherently redundant, which is lowkey iconic 💜 later packets for the same event carry all the earlier history of the event, except for changes in volume. the tone payload is not like that at all 💀 each packet stands alone, so if one gets lost, that's a gap in what the receiving end knows. for better reliability, the sender SHOULD combine new and old tone reports in the same RTP packet using RFC 2198 [2] audio redundancy 🫶
4.4.2. Receiving Procedures 📥
receivers play out the tones as they come in, usually with a playout delay so they can handle lost packets 🎧 when you're playing successive tone reports for the same tone (the marker bit is zero, the RTP timestamp is contiguous with the previous RTP packet, and the payload content is identical), the receiver SHOULD keep the tone going without any change or break 🌈
4.4.3. Handling of Congestion 🚦
if the sender figures out that packets are getting lost because of congestion (for example, through RTCP receiver reports), it SHOULD increase the packetization interval for initial and interim tone reports so it sends less traffic to the receiver 📉 how far it can go without causing damage at the receiving end depends on the playout delay used there and on the specific application using the tones 🧠 that's why both the maximum packetization interval and the maximum increase at any one time are a matter of configuration or out-of-band negotiation ⚙️
5. Examples 🍓
let's do a DTMF dialling sequence 📞 where the user dials the digits "911" and a sending gateway detects them. the first digit is 200 ms long (1600 timestamp units) and starts at time 0. the second digit lasts 250 ms (2000 timestamp units) and starts at time 880 ms (7040 timestamp units). the third digit gets pressed at time 1.4 s (11,200 timestamp units) and lasts 220 ms (1760 timestamp units). the frame duration is 50 ms ⏱️
Table 5 shows the complete sequence of events, assuming only the telephone-event payload type is being reported. to keep it simple, the timestamp starts at 0, the RTP sequence number starts at 1, and the volume settings are left out 💖
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 7 | 1 | 400 | "0" |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | RTP | "0" | 7040 | 11 | 1 | 2000 | "0" |
| | packet 9 | | | | | | |
| | sent | | | | | | |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1180 | RTP | "0" | 7040 | 12 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1230 | RTP | "0" | 7040 | 13 | 1 | 2000 | "1" |
| | packet 9 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 14 | 1 | 400 | "0" |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 11200 | 18 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | sent | | | | | | |
| 1700 | RTP | "0" | 11200 | 19 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 1750 | RTP | "0" | 11200 | 20 | 1 | 1760 | "1" |
| | packet 14 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
+-------+-----------+------+--------+------+--------+--------+------+
Table 5: Example of Event ReportingOkay so Table 5 is the event-reporting version 💖 and it's giving full play-by-play ✨ Table 6 shows the exact same sequence, but only the tone payload type is being reported 🎀, so it looks totally different (bestie, same vibes, different outfit 💅). To keep things simple 🧚, we're assuming the timestamp begins at 0 and the sequence number begins at 1. Volume, the T bit, and the modulation frequency are left out, and the last two are always 0 🌸.
+-------+-----------+-----+--------+------+--------+-------+--------+
| Time | Event | M | Time- | Seq | Dura- | Freq 1| Freq 2 |
| (ms) | | bit | stamp | No | tion | (Hz) | (Hz) |
+-------+-----------+-----+--------+------+--------+-------+--------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 400 | 852 | 1477 |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 400 | 2 | 400 | 852 | 1477 |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 200 | RTP | "0" | 1200 | 4 | 400 | 852 | 1477 |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 880 | First "1" | | | | | | |
| | starts | | | | | | |
| 930 | RTP | "1" | 7040 | 5 | 400 | 697 | 1209 |
| | packet 5 | | | | | | |
| | sent | | | | | | |
| 980 | RTP | "0" | 7440 | 6 | 400 | 697 | 1209 |
| | packet 6 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1130 | First "1" | | | | | | |
| | ends | | | | | | |
| 1400 | Second | | | | | | |
| | "1" | | | | | | |
| | starts | | | | | | |
| 1450 | RTP | "1" | 11200 | 10 | 400 | 697 | 1209 |
| | packet 10 | | | | | | |
| | sent | | | | | | |
| ... | ... | ... | ... | ... | ... | ... | ... |
| 1620 | Second | | | | | | |
| | "1" ends | | | | | | |
| 1650 | RTP | "0" | 12800 | 14 | 160 | 697 | 1209 |
| | packet 14 | | | | | | |
| | sent | | | | | | |
+-------+-----------+-----+--------+------+--------+-------+--------+
Table 6: Example of Tone ReportingNow let's glow up with a combined payload 🦋: the tone payload is the primary payload type, and the event payload is treated as a redundant encoding (one level of redundancy). Because the primary payload is tones, the tone payload rules decide how the RTP header fields get set 👑. This means the RTP timestamp always advances ⭐, and as a corollary, the timestamp offset for the events payload in the RFC 2198 header goes up by the same amount 🌈.
One issue you have to think about in a combined payload is how to handle retransmissions of final event reports 🙈. The tone payload specification does not recommend retransmissions of final packets, so it's unclear what should go in the primary payload fields of the combined packet 💀. To keep things simple 🫶, it's suggested that the retransmitted packets copy the fields relating to the primary payload (including the RTP timestamp) from the original packet. The same principle can be applied if the packet includes multiple levels of event payload redundancy 🍓.
The figures below all illustrate "RTP packet 14" in the above tables 🎀. Figure 3 shows an event-only payload, corresponding to Table 5. Figure 4 shows a tone-only payload, corresponding to Table 6. Finally, Figure 5 shows a combined payload, with tones primary and events as a single redundant layer ✨. Note that the combined payload has the RTP sequence numbers shown in Table 5, because the transmitted sequence includes the retransmitted packets 🔥.
Figure 3 assumes that the following SDP specification was used. This session description provides for separate streams of G.729 [21] audio and events. Packets reported within the G.729 stream are not considered here 💅.
m=audio 12344 RTP/AVP 99
a=rtpmap:99 G729/8000
a=ptime:20
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:50
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 100 | 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event |E R| volume | duration |
| 1 |1 0| 20 | 1760 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example RTP Packet for Event PayloadFigure 4 assumes that an SDP specification similar to that of the previous case was used 🧚💜
6. Security Considerations 💀
okay so RTP packets using the payload formats in this spec are under the same security stuff from the RTP spec (RFC 3550 [5]) and whatever RTP profile applies, like RFC 3551 [13] 🔐. RFC 3550 is mostly about confidentiality. Extra implementation security stuff lives in RFC 2198 [2] 🧠.
the telephone-event payload is super compressed, so flipping just one bit can totally change what the receiver decodes 😭. that's why message integrity MUST be provided for the telephone-event payload type 🔒✨.
to cover both confidentiality AND integrity, compliant implementations SHOULD implement SRTP [7] 🫶.
Note that the right way to distribute SRTP keys may vary depending on the application. In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP.
and bestie, as long as gateway design has robust, low-overhead tone generation, this payload type doesn't have any big non-uniformity in receiver-side computational complexity during packet processing, so it won't become a denial-of-service threat 🛡️💅.
7. IANA Considerations 🦋
this doc updates the descriptions of two RTP payload formats, 'telephone-event' and 'tone' 🎀, plus their media types, audio/telephone-event and audio/tone 🌸. it also documents the event codes for DTMF tone events 🎹.
within the audio/telephone-event type, events MUST be registered with IANA 📋. registrations fall under the "Specification Required" and "Expert Review" policies, as defined in RFC 2434 [3] ✨. the IETF-appointed expert must make sure that:
a. the meaning and application of the proposed events are clearly documented;
b. the events cannot be represented by existing event codes, possibly with some minor modification of event definitions;
c. the number of events is the minimum necessary to fulfill the purpose of their application(s).
the expert is also in charge of guiding how event codes get allocated to the proposed events 🧚. specifically, the expert must say whether the event seems to be the same as one defined in RFC 2833 but not specified in any new document 👀. in that case, the event code RFC 2833 gives that event SHOULD be assigned to the proposed event 💖. otherwise, event codes MUST be assigned from the set of available event codes listed below 📜. if that set runs out, the criterion for taking from the reserved set is to first assign the ones that seem least likely to get revived with their RFC 2833 meaning in a new specification 🫠.
the documentation for each event MUST indicate whether the event is a state, tone, or some other type of event (for example, an out-of-band electrical event like on-hook, or an indication that won't itself be played out as tones at the receiving end) 📞. for tone events, the documentation MUST indicate whether the volume field is applicable or must be set to 0 🎚️.
with the tradeoffs between the different reliability mechanisms from Section 2.6 in mind 🧩, documentation of specific events SHOULD include a discussion of the right design decisions for those events' applications 🍓.
legal event codes run from 0 to 255 🔢. the initial registry content is shown in Table 7 and has the sixteen events defined in Section 3 of this document 💜. the remaining codes are handled like this:
- codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available for assignment;
- codes 23-40, 49, and 52-63 are reserved for events defined in [16];
- codes 121-137 and 174-205 are reserved for events defined in [17];
- codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved in the first instance for specifications reviving the corresponding RFC 2833 events, and in the second instance for general assignment after all other codes have been assigned.
+------------+--------------------------------+-----------+
| Event Code | Event Name | Reference |
+------------+--------------------------------+-----------+
| 0 | DTMF digit "0" | RFC 4733 |
| 1 | DTMF digit "1" | RFC 4733 |
| 2 | DTMF digit "2" | RFC 4733 |
| 3 | DTMF digit "3" | RFC 4733 |
| 4 | DTMF digit "4" | RFC 4733 |
| 5 | DTMF digit "5" | RFC 4733 |
| 6 | DTMF digit "6" | RFC 4733 |
| 7 | DTMF digit "7" | RFC 4733 |
| 8 | DTMF digit "8" | RFC 4733 |
| 9 | DTMF digit "9" | RFC 4733 |
| 10 | DTMF digit "*" | RFC 4733 |
| 11 | DTMF digit "#" | RFC 4733 |
| 12 | DTMF digit "A" | RFC 4733 |
| 13 | DTMF digit "B" | RFC 4733 |
| 14 | DTMF digit "C" | RFC 4733 |
| 15 | DTMF digit "D" | RFC 4733 |
+------------+--------------------------------+-----------+Table 7: audio/telephone-event Event Code Registry
7.1. Media Type Registrations 🎀
7.1.1. Registration of Media Type audio/telephone-event ✨
okay so this registration is done in accordance with [6] and [8] 💅
- Type name:
audio - Subtype name:
telephone-event - Required parameters: none.
- Optional parameters:
- The
eventsparameter lists the events supported by the implementation 🎀 Events are listed as one or more comma-separated elements. Each element can be either a single integer providing the value of an event code, or an integer followed by a hyphen and a larger integer, presenting a range of consecutive event code values. The list does not have to be sorted. No white space is allowed in the argument. The union of all of the individual event codes and event code ranges designates the complete set of event numbers supported by the implementation. If theeventsparameter is omitted, support for events 0-15 (the DTMF tones) is assumed. the DTMF tones are the main character here, bestie 📞 - The
rateparameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz. 🦋
- The
- Encoding considerations: In the terminology defined by [8] section 4.8, this type is framed and binary. 🧚
- Security considerations: See Section 6, "Security Considerations", in this document. 🔒
- Interoperability considerations: none.
- Published specification: this document.
- Applications which use this media: the telephone-event audio subtype supports the transport of events occurring in telephone systems over the Internet. it's giving phone calls, but make it IP ☎️
- Additional information:
- Magic number(s): N/A.
- File extension(s): N/A.
- Macintosh file type code(s): N/A.
- Person & email address to contact for further information: Tom Taylor, taylor@nortel.com. IETF AVT Working Group. 💌
- Intended usage: COMMON.
- Restrictions on usage: this type is defined only for transfer via RTP [5]. 🚫
- Author: IETF Audio/Video Transport Working Group.
- Change controller: IETF Audio/Video Transport Working Group as delegated from the IESG.
7.1.2. Registration of Media Type audio/tone 🌈
this registration is also done in accordance with [6] and [8] 🫶
- Type name:
audio - Subtype name:
tone - Required parameters: none
- Optional parameters:
- The
rateparameter describes the sampling rate, in Hertz. The number is written as an integer. If omitted, the default value is 8000 Hz. 🍓
- The
- Encoding considerations: In the terminology defined by [8] section 4.8, this type is framed and binary. 🧚
- Security considerations: See Section 6, "Security Considerations", in this document. 🔒
- Interoperability considerations: none
- Published specification: this document.
- Applications which use this media: the tone audio subtype supports the transport of pure composite tones, for example, those commonly used in the current telephone system to signal call progress. call progress tones, the iconic ones 📞✨
- Additional information:
- Magic number(s): N/A.
- File extension(s): N/A.
- Macintosh file type code(s): N/A.
- Person & email address to contact for further information: Tom Taylor, taylor@nortel.com. IETF AVT Working Group. 💌
- Intended usage: COMMON.
- Restrictions on usage: this type is defined only for transfer via RTP [5]. 🚫
- Author: IETF Audio/Video Transport Working Group.
- Change controller: IETF Audio/Video Transport Working Group as delegated from the IESG.
8. Acknowledgements 🙌
okay the shoutouts 🥹 Scott Petrack was the original author of RFC 2833. Henning Schulzrinne later loaned his expertise to complete the document, but Scott must be credited with the energy behind the idea of a compact encoding of tones over IP. 👑
In RFC 2833, the suggestions of the Megaco working group were acknowledged. Colin Perkins and Magnus Westerland, Chairs of the AVT Working Group, provided helpful advice in the formation of the present document. Over the years, detailed advice and comments for RFC 2833, this document, or both were provided by Hisham Abdelhamid, Flemming Andreasen, Fred Burg, Steve Casner, Dan Deliberato, Fatih Erdin, Bill Foster, Mike Fox, Mehryar Garakani, Gunnar Hellstrom, Rajesh Kumar, Terry Lyons, Steve Magnell, Zarko Markov, Tim Melanchuk, Kai Miao, Satish Mundra, Kevin Noll, Vern Paxson, Oren Peleg, Raghavendra Prabhu, Moshe Samoha, Todd Sherer, Adrian Soncodi, Yaakov Stein, Mira Stevanovic, Alex Urquizo, and Herb Wildfeur. 💜
9. References 📚
9.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
- [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [6] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
- [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
- [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [10] International Telecommunication Union, "Technical features of push-button telephone sets", ITU-T Recommendation Q.23, November 1988.
- [11] International Telecommunication Union, "Multifrequency push-button signal reception", ITU-T Recommendation Q.24, November 1988.
9.2. Informative References
- [12] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
- [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
- [14] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
- [15] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
- [16] Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.
- [17] Schulzrinne, H. and T. Taylor, "Definition of Events For Channel-Oriented Telephony Signalling", Work In Progress , November 2005.
- [18] International Telecommunication Union, "Technical characteristics of tones for the telephone service", ITU-T Recommendation E.180/Q.35, March 1998.
- [19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
- [20] International Telecommunication Union, "Speech coders : Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s", ITU-T Recommendation G.723.1, March 1996.
- [21] International Telecommunication Union, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP)", ITU-T Recommendation G.729, March 1996.
- [22] International Telecommunication Union, "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.
- [23] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
- [24] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000.
- [25] International Telecommunication Union, "Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs", ITU-T Recommendation V.150.1, January 2003.
- [26] International Telecommunication Union, "Procedures for supporting Voice-Band Data over IP Networks", ITU-T Recommendation V.152, January 2005.
- [27] International Telecommunication Union, "Operational and interworking requirements for {DCEs operating in the text telephone mode", ITU-T Recommendation V.18, November 2000. See also Recommendation V.18 Amendment 1, Nov. 2002.
- [28] VOIP Troubleshooter LLC, "Indepth: Packet Loss Burstiness", 2005,
http://www.voiptroubleshooter.com/indepth/burstloss.html.
Appendix A. Summary of Changes from RFC 2833 ✨
okay so this memo got a major glow-up 💅 It's been significantly restructured with a big pile of clarifications. Apart from the items called out below, the changes are meant to be backwards-compatible clarifications. Heads up though: because RFC 2833 [12] had inconsistencies and unclear definitions, some implementations probably read that memo in ways that differ from this version 🙈
RFC 2833 required every implementation to be able to receive the DTMF events (event codes 0-15). Now Section 2.5.1.1 says a sender has to transmit only the events the receiver can actually receive 🎀 If the sender doesn't know what the receiver can handle, it SHOULD assume support for the DTMF events and no other events. The sender SHOULD also indicate which events it can send. And Section 2.5.2.1 says a receiver that signals its capabilities using SDP MUST indicate which events it can receive. Main character energy for capability signalling 👑
In RFC 2833, non-zero values in the volume field only applied to DTMF tones. For every other event, the receiver had to ignore them. This memo says the definition of each event has to state whether the volume field applies to it 🦋 The last paragraph of Section 2.5.2.2 covers what a receiver may do if it gets zero-valued volumes for events where the volume field does apply. Together with the RFC 2833 receiver rule, this keeps things backward compatible in both directions 💖
Section 2.5.1.3 and Section 2.5.2.3 add a new procedure for reporting and playing out events that last longer than the payload duration field can hold 🧚 This can cause a little momentary confusion for an old (RFC 2833) receiver, since the timestamp gets updated without the E bit being set on the previous event report or the M bit being set on the new one.
Section 2.5.1.5 and Section 2.5.2.4 add a new procedure where a bunch of short-duration events can be packed into one event report 🍓 If an old (RFC 2833) receiver gets a report like that, it may throw the packet out as invalid, because the packet holds more content than it expected. Either way, the extra events in the packet will be lost 😭
Section 2.3.5 introduces "state" events and defines how to set the duration field for reports of those events ✨ Section 2.5.1.2 has special exemptions from setting the E bit for state events. Three more sections also mention procedures tied to these events.
The Security Considerations section now mentions the requirement to protect integrity 🔐 The bigger deal is that it makes SRTP [7] implementation mandatory for compliant implementations, but it doesn't specify a mandatory-to-implement key distribution method 🫶
Last but not least, this document creates an IANA registry for event codes and sets criteria for documenting them 📚 The registry starts out with just the sixteen DTMF events. Two companion documents, [16] and [17], describe events for modems, fax, and text telephony, and events for channel-associated telephony signalling. Some changes were made to the latter because of errors and redundancies in the RFC 2833 assignments 🙄 The remaining events defined in RFC 2833 are deprecated, since they don't seem to have been implemented. Their codes are only conditionally reserved, just in case one is needed later 🌈 Table 8 shows the disposition of each event code in detail. Any event code not mentioned in the table wasn't allocated by RFC 2833 and is still unused.
+-------------+---------------------------------------+-------------+
| Event Codes | RFC 2833 Description | Disposition |
+-------------+---------------------------------------+-------------+
| 0-15 | DTMF digits | RFC 4733 |
| 16 | Line flash (deprecated) | Reserved |
| 23-31 | Unused | [16] |
| 32-40 | Data and fax | [16] |
| 41-48 | Data and fax (V.8bis, deprecated) | Reserved |
| 52-63 | Unused | [16] |
| 64-89 | E.182 line events (deprecated) | Reserved |
| 96-112 | Country-specific line events | Reserved |
| | (deprecated) | |
| 121-127 | Unused | [17] |
| 128-137 | Trunks: MF 0-9 | [17] |
| 138-143 | Trunks: other MF (deprecated) | Reserved |
| 144-159 | Trunks: ABCD signalling | [17] |
| 160-168 | Trunks: various (deprecated) | Reserved |
| 170-173 | Trunks: various (deprecated) | Reserved |
| 174-205 | Unused | [17] |
+-------------+---------------------------------------+-------------+
Table 8: Disposition of RFC 2833-defined Event CodesAuthors' Addresses 🧑💻
Here's where you can find the authors 💌
Henning Schulzrinne
Columbia U.
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
US
EMail: schulzrinne@cs.columbia.edu
Tom Taylor
Nortel
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
EMail: taylor@nortel.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all of their rights.
This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧠
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the implementation or use of the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't claim to have independently looked for any such rights 🤷♀️ Info on how RFC documents handle rights can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use such proprietary rights for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr 📂
The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to the Internet Society for keeping the RFC Editor running 🫶✨
📦 where this page comes from
- ietf: rfc4733 2006-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms