RFC 2833
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
RFC 2833 💖 (Part 1 of 6)
okay so this is RFC 2833, titled RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals 🎀. It's a Standards Track doc from May 2000, written by H. Schulzrinne (Columbia University) and S. Petrack (MetaTel). The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨
Status of this Memo ✨
bestie, this part is the official "what is this doc and how official is it" section 🙈 It says this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of the protocol, you check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it wherever 🌸
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 💅
Abstract
so the whole point is this: the doc explains how to carry dual-tone multifrequency (DTMF) signaling, other tone signals, and telephony events inside RTP packets 📞🦋
1 Introduction
okay so this memo defines two payload formats 👑 The first one carries DTMF digits plus other line and trunk signals (that's Section 3). The second one carries general multi-frequency tones in RTP [1] packets (that's Section 4). Why two? Because low-rate voice codecs can't be guaranteed to reproduce these tones accurately enough for automatic recognition 😭 Separate formats also let you use higher redundancy and still keep the bit rate low. main character energy ✨
the payload formats here could be useful in at least three applications: DTMF handling for gateways and end systems, and "RTP trunks" 🧚 In the first one, the Internet telephony gateway detects DTMF on the incoming circuits and sends this RTP payload instead of regular audio packets. The gateway probably has the digital signal processors and algorithms it needs, since it often has to detect DTMF anyway, e.g., for two-stage dialing 💅 Letting the gateway detect tones saves the receiving Internet end system from doing that work, and it stops low bit-rate codecs like G.723.1 from making DTMF tones unintelligible 🙈 The second way is an end system like an "Internet phone" that can fake DTMF functionality without worrying about making precise tone pairs or making the receiver do tone recognition. iconic 🫶
in the "RTP trunk" application, RTP replaces a normal circuit-switched trunk between two nodes. This is a big deal in a telephone network that's still mostly circuit-switched 🌈 Here, each end of the RTP trunk encodes audio channels into an appropriate encoding, like G.723.1 or G.729. But ngl, that encoding process destroys in-band signaling info carried in the least-significant bit ("robbed bit signaling"), and it can also mess with in-band signaling tones like the MF digit tones 😭 Tone properties like the phase reversals in the ANSam tone won't survive speech coding either. So the gateway has to strip the in-band signaling info out of the bit stream. It can carry that info out-of-band in a signaling transport mechanism that isn't defined yet, or it can use the mechanism in this memorandum. (If the two trunk end points are within reach of the same media gateway controller, that controller can handle the signaling too.) Carrying it in-band can make it easier to line up audio packets with the tone or signal info in time, which matters a lot when duration and timing count, like with DTMF signals ⭐
1.1 Terminology
in this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [2]. They show the requirement levels for compliant implementations 📚🔥
2 Events vs. Tones
so a gateway has two options for handling DTMF digits and events 🦋 Option one: it measures the frequency components of the voice band signals and sends that info to the RTP receiver (Section 4). In this mode the gateway doesn't try to figure out what the tones mean. It just tells tones apart from speech 🌸
all tone signals in the PSTN that are meant for human ears are sequences of simple combos of sine waves, either added together or modulated 🎀 (There's at least one exception, the ANSam tone [3], which is used to signal data transmission over voice lines and uses periodic phase reversals.)
option two: a gateway can recognize the tones and translate them into a name, like ringing or busy tone. The receiver then makes a tone signal or some other indication that fits the signal 💖
recognizing signals often depends on their on/off pattern or the sequence of several tones, so this can take several seconds, bestie 😭 BUT the gateway might have access to the actual signaling info that generates the tones, which means it can create the RTP packet right away without going through acoustic signals first ✨
in the phone network, tones get generated in different places depending on the switching tech and what kind of tone it is 🧚 This decides things like whether someone calling a foreign country hears the local tones they're used to, or the tones used in the country they called 👑
for analog lines, the local switch always generates dial tone 💅 ISDN terminals can make dial tone locally and then send a Q.931 SETUP message with the dialed digits. If the terminal only sends a SETUP message with no Called Party digits, the switch does digit collection (the digits come from the terminal as KEYPAD messages) and provides dial tone over the B-channel. The terminal can either use the audio signal on the B-channel, or use the Q.931 messages to trigger locally generated dial tone 🫶
ringing tone (also called ringback tone) is generated by the local switch at the callee's end, and a one-way voice path opens up as soon as the callee's phone rings 🌈 (This cuts down the chance of 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 a ringing tone, or instead of one.) Congestion tone and special information tones can be generated by any of the switches along the way, and the caller's switch may generate them based on ISUP messages it gets. Busy tone is generated by the caller's switch, triggered by the right ISUP message, for analog instruments or the ISDN terminal 💀
gateways that send signaling events via RTP MAY send both the named signals (Section 3) and the tone representation (Section 4) as a single RTP session. They use the redundancy mechanism from Section 3.7 to interleave the two representations. It's generally a good idea to send both, since that lets the receiver pick whichever rendering it wants 🍓
if a gateway can't present a tone representation, it SHOULD send the audio tones as regular RTP audio packets (e.g., with payload format PCMU), in addition to the named signals 🌸
3 RTP Payload Format for Named Telephone Events
3.1 Introduction
the named telephone event payload format is good for both gateway and end-to-end setups 🦋 In the gateway setup, an Internet telephony gateway that connects a packet voice network to the PSTN recreates the DTMF tones or other telephony events and injects them into the PSTN. DTMF digit recognition takes several tens of milliseconds, so the first few milliseconds of a digit arrive as regular audio packets 😭 That means careful time and power (volume) alignment between the audio samples and the events is needed, or the receiver might generate spurious digits 🙈
DTMF digits and named telephone events are carried as part of the audio stream. They MUST use the same sequence number and time-stamp base as the regular audio channel, which makes it easier for a gateway to generate audio waveforms 🎀 The default clock frequency is 8,000 Hz, but you can redefine the clock frequency when you assign the dynamic payload type 💜
this payload format gets higher redundancy than the method proposed in the Voice over Frame Relay Implementation Agreement [4], even when packet loss is sustained 🔥
if an end system is connected directly to the Internet and doesn't need to generate tone signals again, time alignment and power levels don't matter 💅 These systems rely on PSTN gateways or Internet end systems to generate DTMF events, and they don't do their own audio waveform analysis. An Internet interactive voice-response (IVR) system is one example 🧚
when exact timing alignment between the audio stream and the DTMF digits or other events isn't important, and the data is sent unicast (like the IVR example above), a reliable control protocol may be preferable to RTP packets. In that case, this payload format wouldn't be used 🌈
3.2 Simultaneous Generation of Audio and Events
a source MAY send events and coded audio packets for the same time instants, using the events as the redundant encoding for the audio stream. Or it MAY block outgoing audio while event tones are active, and only send named events as both the primary and redundant encodings 🫶
note that a period covered by an encoded tone may overlap in time with a period of audio encoded some other way 👑 This is likely at the onset of a tone, and it's needed to avoid possible errors in how the far end interprets the reproduced tone. Implementations that support this payload format must be prepared to handle the overlap ⭐ It is RECOMMENDED that gateways only render the encoded tone, since the audio may contain spurious tones introduced by the audio compression algorithm 💀 Still, these extra tones should generally not interfere with recognition at the far end ✨
3.3 Event Types ✨
Okay so this payload format covers five kinds of signals, bestie 💅
- DTMF tones (Section 3.10);
- fax-related tones (Section 3.11);
- standard subscriber line tones (Section 3.12);
- country-specific subscriber line tones (Section 3.13); and
- trunk events (Section 3.14).
A compliant implementation MUST support the events listed in Table 1 with the exception of "flash" 🔥 If it uses some other, out-of-band mechanism for signaling line conditions, it does not have to implement the other events.
Sometimes an implementation can just ignore certain events, like fax tones, when they don't make sense in its environment 🙈 Section 3.9 explains how an implementation can use the SDP "fmtp" parameter inside an SDP description to say it can't understand a particular event or range of events. Main character energy for saying "not me" 💖
Depending on the user interfaces available, an implementation MAY render all tones in Table 5 the same, or, preferably, use the tones carried by the concurrent "tone" payload or another RTP audio payload 🎀 Or it could give a textual representation instead.
Note that end systems that emulate telephones only need to support the events in Sections 3.10 and 3.12, while systems that receive trunk signaling need to handle those in Sections 3.10, 3.11, 3.12 and 3.14, since MF trunks also carry most of the "line" signals 📞 Systems that don't do fax or modem stuff don't need to render the fax-related events from Section 3.11 🌸
The RTP payload format is called "telephone-event", and the MIME type is "audio/telephone-event" 🦋 The default timestamp rate is 8000 Hz, but other rates may be defined. Following current practice, this format doesn't get a static payload type number. Instead, it uses an RTP payload type number that's established dynamically and out-of-band ✨
3.4 Use of RTP Header Fields 🧚
Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 3.5 extends forwards from that time. The receiver calculates jitter for RTCP receiver reports based on all packets with a given timestamp. Note: The jitter value should primarily be used as a means for comparing the reception quality between two users or two time-periods, not as an absolute measure. (Compare, don't treat it as gospel, okay 💅)
Marker bit: The RTP marker bit indicates the beginning of a new event 🚩
3.5 Payload Format 💜
Here's the payload format, shown in Fig. 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 Eventsevents: The events are encoded as shown in Sections 3.10 through 3.14 🍓
volume: For DTMF digits and other events that can be represented as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); anything lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A). So, bigger numbers mean quieter volume 🔇 This value is only defined for DTMF digits. For other events, the sender sets it to zero and the receiver ignores it.
duration: Duration of this digit, in timestamp units. So the event began at the instant identified by the RTP timestamp, and it has lasted as long as this parameter says so far. The event may or may not have ended 🤷♀️
For a sampling rate of 8000 Hz, this field is enough to express event durations of up to about 8 seconds. Plan accordingly, bestie ⏰
E: If set to one, the "end" bit tells you this packet contains the end of the event. So the duration parameter measures the complete duration of the event 🎬
A sender MAY delay setting the end bit until it retransmits the last packet for a tone, instead of doing it on the first transmission. That way it doesn't have to wait around to find out whether the tone has actually ended 🫶
Receiver implementations MAY use different algorithms to create tones, including the two described here 😭 In the first one, the receiver just places a tone of the given duration into the audio playout buffer at the location the timestamp points to. As more packets come in that extend the same tone, the waveform in the playout buffer gets extended to match. (Be careful if audio gets mixed, meaning summed, in the playout buffer instead of just copied.) So if a packet in a tone that lasts longer than the packet interarrival time gets lost and the playout delay is short, you might get a gap in the tone. In the second one, the receiver starts a tone and keeps playing it until it gets a packet with the "E" bit set, the next tone (which has a different timestamp value), or until a given time period runs out. This is more robust against packet loss, but it might extend the tone if every retransmission of the last packet in an event gets lost. Limiting how long the tone can be extended is necessary so it doesn't get "stuck" 🔁 No matter which algorithm is used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight stretch of tone durations and shortening of pauses is generally harmless 🌈
R: This field is reserved for future use. The sender MUST set it to zero, and the receiver MUST ignore it 🎀
3.6 Sending Event Packets 📦
An audio source SHOULD start transmitting event packets as soon as it recognizes an event, and then every 50 ms after that, or at the packet interval for the audio codec used in this session, if that's known. (The sender doesn't need to keep precise time intervals between event packets in order to keep precise inter-event times, since the timing info lives in the timestamp 🧠)
Q.24 [5], Table A-1, indicates that all administrations surveyed use a minimum signal duration of 40 ms, with a signaling velocity (tone and pause) of no less than 93 ms.
If an event keeps going for more than one period, the source generating the events should send a new event packet with the RTP timestamp value for the beginning of the event, and the duration increased to match. (The RTP sequence number goes up by one for each packet 🔢) If there hasn't been a new event in the last interval, the event SHOULD be retransmitted three times, or until the next event is recognized. This makes sure the duration can be recognized correctly even if the last packet for an event gets lost 💪
DTMF digits and events are sent incrementally, so the receiver doesn't have to wait for the whole event to finish 🏃♀️ Some tones are two seconds long, and waiting for those would add a seriously big delay 😩 The transmitter doesn't know whether event length matters, so it has to send immediately and incrementally. If the receiver application doesn't care about event length, incremental transmission avoids the delay. But some applications, like gateways into the PSTN, care about both the delay and the event duration 📞
3.7 Reliability 🛡️
During an event, the RTP event payload format gives incremental updates on the event. How resilient it is depends on the playout delay at the receiver. For example, with a playout delay of 120 ms and a packet gap of 50 ms, two packets in a row can get lost without causing a gap in the tones the receiver generates 🎶
The audio redundancy mechanism described in RFC 2198 [6] MAY be used to recover from packet loss across events. The effective data rate is r times 64 bits (32 bits for the redundancy header and 32 bits for the telephone-event payload) every 50 ms, or r times 1280 bits/second, where r is the number of redundant events carried in each packet. The value of r is an implementation trade-off, and a value of 5 is suggested ⚖️
The timestamp offset in this redundancy scheme has 14 bits, so a single packet can "cover" 2.048 seconds of telephone events at a sampling rate of 8000 Hz 🦋 Including the starting time of previous events lets a gateway rebuild the tone sequence precisely. The scheme holds up against consecutive packet losses spanning that 2.048-second interval or r digits, whichever is less. Just note that for previous digits, only an average loudness can be represented 🔉
An encoder MAY treat the event payload as a highly compressed version of the current audio frame 🗜️ In that mode, each RTP packet during an event would carry the current audio codec rendition (say, G.723.1 or G.729) of this digit, plus the representation described in Section 3.5, plus any previous events seen earlier.
This approach lets "dumb" gateways that don't understand this format keep working 💅 See also the discussion in Section 1.
3.8 Example 📱
Here's a typical RTP packet, where the user is just dialing the last digit of the DTMF sequence "911" 🚨 The first digit was 200 ms long (1600 timestamp units) and started at time 0. The second digit lasted 250 ms (2000 timestamp units) and started at time 800 ms (6400 timestamp units). The third digit was pressed at time 1.4 s (11,200 timestamp units), and the packet shown was sent at 1.45 s (11,600 timestamp units). The frame duration is 50 ms. To make the parts recognizable, the figure below ignores byte alignment. Timestamp and sequence number are assumed to have been zero at the beginning of the first digit. In this example, the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone event payload, respectively ✨
3.9 Indication of Receiver Capabilities using SDP ✨
Okay so bestie, here's the main idea 💖 Receivers can say which named events they can handle, and the usual way to do that is with the Session Description Protocol (RFC 2327 [7]). It's giving organized. 🎀 Here's an example packet, so you can see how the pieces fit together 🦋
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| 96 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 11200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 11200 - 6400 = 4800 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 9 |1 0| 7 | 1600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |1 0| 10 | 2000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digit |E R| volume | duration |
| 1 |0 0| 20 | 400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example RTP packet after dialing "911"Receivers MAY tell the other side which named events they can handle, for example with the Session Description Protocol (RFC 2327 [7]). The payload formats use this fmtp format to list the event values they can receive:
a=fmtp:<format> <list of values>The list is made of comma-separated elements. Each element is either one decimal number or two decimal numbers joined by a hyphen (dash), where the second number is bigger than the first. No whitespace is allowed between numbers or hyphens. The list doesn't have to be sorted, so you're free to vibe 🌈
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. It would put this in its SDP message:
a=fmtp:100 0-15,66,70Since all implementations MUST be able to receive events 0 through 15, listing these events in the a=fmtp line is OPTIONAL. Bestie, you don't have to flex them 🙈
The matching MIME parameter is "events". So the sample media type definition below lines up with the SDP example above 🧚
audio/telephone-event;events="0-11,66,67";rate="8000"3.10 DTMF Events
Table 1 is the cheat sheet for the DTMF-related named events in the telephone-event payload format 📋
Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16
Table 1: DTMF named events3.11 Data Modem and Fax Events
Table 3.11 covers the events and tones that can show up on a subscriber line serving a fax machine or modem. The tones get explained below, and there's more detail in Table 7 if you're curious 🌸
ANS: This 2100 +/- 15 Hz tone is used to disable echo suppression for data transmission [8,9]. For fax machines, Recommendation T.30 [9] calls this tone the called terminal identification (CED) answer tone. 📞
/ANS: This one is the same signal as ANS, except it reverses phase at an interval of 450 +/- 25 ms. It disables both echo cancellers and echo suppressors. (In the ITU Recommendation V.25 [8], this signal is written as ANS with a bar on top. 🙃)
ANSam: The modified answer tone (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz with no phase reversals, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. Modems send this one when network echo canceller disabling isn't required. ✨
/ANSam: The modified answer tone with phase reversals (ANSam) [3] is a sinewave signal at 2100 +/- 1 Hz with phase reversals at intervals of 450 +/- 25 ms, amplitude-modulated by a sinewave at 15 +/- 0.1 Hz. This tone [10,8] is sent by modems [11] and faxes to disable echo suppressors. 💅
CNG: After dialing the called fax machine's number (and before it answers), the calling Group III fax machine (optionally) starts sending a CalliNG tone (CNG). That's an interrupted tone of 1100 Hz. [9] 🎀
CRdi: Capabilities Request (CRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRdi is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to a CRe or MRe." 🫶
CRdr: CRdr is the response tone to CRdi (see above). It's a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1900 Hz for 100 ms. 🦋
CRe: Capabilities Request (CRe) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 400 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a capabilities list message by the remote station. In particular, CRe is sent by an automatic answering station at call establishment." 🌈
CT: "The calling tone [8] consists of a series of interrupted bursts of binary 1 signal or 1300 Hz, on for a duration of not less than 0.5 s and not more than 0.7 s and off for a duration of not less than 1.5 s and not more than 2.0 s." Modems that don't start with the V.8 call initiation tone often use this one. 🍓
ESi: Escape Signal (ESi) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 980 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode. signal ESi is sent by the initiating station." 🧚
ESr: Escape Signal (ESr) [12] is a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1650 Hz for 100 ms. It's the same as ESi, but the responding station sends it. 💜
MRdi: Mode Request (MRd), initiating side, [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 1150 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRd is sent by the initiating station during the course of a call, or by the calling station at call establishment in response to an MRe." [12] 👑
MRdr: MRdr is the response tone to MRdi (see above). It's a dual-tone signal with tones at 1529 Hz and 2225 Hz for 400 ms, followed by a single tone at 1150 Hz for 100 ms. ⭐
MRe: Mode Request (MRe) [12] is a dual-tone signal with tones at 1375 Hz and 2002 Hz for 400 ms, followed by a single tone at 650 Hz for 100 ms. "This signal requests the remote station transition from telephony mode to an information transfer mode and requests the transmission of a mode select message by the remote station. In particular, signal MRe is sent by an automatic answering station at call establishment." [12] 🔥
V.21: V.21 describes a 300 b/s full-duplex modem that uses frequency shift keying (FSK). Group 3 fax machines use it to exchange T.30 information. The calling side transmits on channel 1 and receives on channel 2, and the answering modem transmits on channel 2 and receives on channel 1. Each bit value has its own tone, so V.21 signaling has four distinct tones in total. 🌸
So here's the summary of which procedures get used 💅 The table below shows them:
Procedure indications
___________________________________________________
V.25 and V.8 ANS
V.25, echo canceller disabled ANS, /ANS, ANS, /ANS
V.8 ANSam
V.8, echo canceller disabled /ANSam
Table 2: Use of ANS, ANSam and /ANSam in V.x recommendationsAnd here's the encoding for each of these named events 🎀
Event encoding (decimal)
___________________________________________________
Answer tone (ANS) 32
/ANS 33
ANSam 34
/ANSam 35
Calling tone (CNG) 36
V.21 channel 1, "0" bit 37
V.21 channel 1, "1" bit 38
V.21 channel 2, "0" bit 39
V.21 channel 2, "1" bit 40
CRdi 41
CRdr 42
CRe 43
ESi 44
ESr 45
MRdi 46
MRdr 47
MRe 48
CT 49
Table 3: Data and fax named events3.12 Line Events
Okay so Table 4 is basically the cheat sheet for every event and tone that can pop up on a subscriber line 📞✨
ITU Recommendation E.182 [13] is the one that decides when certain tones should be used. It lists the standard tones the caller hears 👂
- Dial tone: the exchange is ready to take address info 💅
- PABX internal dial tone: the PABX is ready to take address info 🏢
- Special dial tone: same as dial tone, but something's up with the caller's line, like call diversion or voice mail being available (think "stutter dial tone") 🎙️
- Second dial tone: the network accepted the address info but wants more 🙄
- Ring: this named signal tells the recipient to make an alerting signal ("ring"). How that actually gets rendered is up to the receiver 🔔 (This differs from the ringing tone, below, heard by the caller.)
- Ringing tone: the call went out to the callee and a calling signal (ringing) is being sent to them. Also called "ringback" 📲
- Special ringing tone: a special service, like call forwarding or call waiting, is active on the called number 🪄
- Busy tone: the called number is busy 🚫
- Congestion tone: the facilities needed for the call are temporarily unavailable 🚧
- Calling card service tone: 60 ms of the sum of 941 Hz and 1477 Hz tones (DTMF '#'), then 940 ms of 350 Hz and 440 Hz (U.S. dial tone), decaying exponentially with a time constant of 200 ms 💳
- Special information tone: the callee can't be reached, but it's neither "busy" nor "congestion". This tone should be used before all call failure announcements, for the benefit of automatic equipment 🤖
- Comfort tone: the call is being processed. This tone may be used during long post-dial delays, e.g., in international connections 🫶
- Hold tone: the caller has been put on hold ⏸️
- Record tone: the caller has been connected to an automatic answering device and is asked to start talking 🎤
- Caller waiting tone: the called station is busy, but it has call waiting service 🌸
- Pay tone: the caller at a payphone is reminded to drop in more coins 🪙
- Positive indication tone: the supplementary service got activated ✅
- Negative indication tone: the supplementary service couldn't be activated ❌
- Off-hook warning tone: the caller has left the handset off-hook for way too long 😭
The following tones can be heard by either the calling or the called party during a conversation 🗣️
- Call waiting tone: another party wants to reach the subscriber 💜
- Warning tone: the call is being recorded. This tone is not required in all jurisdictions 🎙️
- Intrusion tone: the call is being monitored, e.g., by an operator 👀
- CPE alerting signal: a tone that alerts a device to an incoming in-band FSK data transmission. It's a combined 2130 and 2750 Hz tone, both with tolerances of 0.5%, lasting 80 to. 80 ms. It's used with ADSI services and Call Waiting ID services [14] 🔊
The following tones are heard by operators 🎧
- Payphone recognition tone: the person making the call or being called is on a payphone (so it's ill-advised to allow collect calls to them) 🚩
Here's the full event-to-number mapping for those, in one place ✨
Event encoding (decimal)
_____________________________________________
Off Hook 64
On Hook 65
Dial tone 66
PABX internal dial tone 67
Special dial tone 68
Second dial tone 69
Ringing tone 70
Special ringing tone 71
Busy tone 72
Congestion tone 73
Special information tone 74
Comfort tone 75
Hold tone 76
Record tone 77
Caller waiting tone 78
Call waiting tone 79
Pay tone 80
Positive indication tone 81
Negative indication tone 82
Warning tone 83
Intrusion tone 84
Calling card service tone 85
Payphone recognition tone 86
CPE alerting signal (CAS) 87
Off-hook warning tone 88
Ring 89
Table 4: E.182 line events3.13 Extended Line Events
Table 5 is where the country-specific events and tones that can show up on a subscriber line live 🌍💫
3.14 Trunk Events
Table 6 rounds up the events and tones that can appear on a trunk 🚆 Heads up: a trunk can also carry line events (Section 3.12), because MF signaling doesn't include backward signals [15] 🔁
- ABCD transitional: 4-bit signaling used by digital trunks. For N-state signaling, the first N values are used 🔢
Event encoding (decimal)
___________________________________________________
Acceptance tone 96
Confirmation tone 97
Dial tone, recall 98
End of three party service tone 99
Facilities tone 100
Line lockout tone 101
Number unobtainable tone 102
Offering tone 103
Permanent signal tone 104
Preemption tone 105
Queue tone 106
Refusal tone 107
Route tone 108
Valid tone 109
Waiting tone 110
Warning tone (end of period) 111
Warning Tone (PIP tone) 112
Table 5: Country-specific Line eventsThe T1 ESF (extended super frame format) supports 2, 4, and 16 state signaling bit options. Those signaling bits are named A, B, C, and D. Signaling info gets sent as robbed bits in frames 6, 12, 18, and 24 when you're using ESF T1 framing. A D4 superframe only carries 4-state signaling, with A and B bits. On the CEPT E1 frame, all signaling rides in timeslot 16, and two channels of 16-state (ABCD) signaling go out per frame 🧠✨
Since this info is a state rather than a changing signal, implementations SHOULD use the triple-redundancy mechanism similar to the one in ITU-T Rec. I.366.2 [16], Annex L 🛡️ When a transition happens, the same ABCD info is sent 3 times, 5 ms apart. If another transition happens during that window, the pattern just keeps going. After a stretch with no change, the ABCD info gets sent every 5 seconds 💖
- Wink: a brief transition, typically 120-290 ms, from on-hook (unseized) to off-hook (seized) and back to onhook. The incoming exchange uses it to say the call address signaling can go ahead 😉
- Incoming seizure: incoming indication of a call attempt (off-hook) 📥
Event encoding (decimal)
__________________________________________________
MF 0... 9 128...137
MF K0 or KP (start-of-pulsing) 138
MF K1 139
MF K2 140
MF S0 to ST (end-of-pulsing) 141
MF S1... S3 142...143
ABCD signaling (see below) 144...159
Wink 160
Wink off 161
Incoming seizure 162
Seizure 163
Unseize circuit 164
Continuity test 165
Default continuity tone 166
Continuity tone (single tone) 167
Continuity test send 168
Continuity verified 170
Loopback 171
Old milliwatt tone (1000 Hz) 172
New milliwatt tone (1004 Hz) 173
Table 6: Trunk events- Seizure: seizure by the answering exchange, in response to an outgoing seizure 🤝
- Unseize circuit: the circuit goes from off-hook to on-hook at the end of a call 📴
- Wink off: a brief transition, typically 100-350 ms, from off-hook (seized) to on-hook (unseized) and back to off-hook (seized). Used on operator services trunks 🎀
- Continuity tone send: a tone of 2010 Hz 🎶
- Continuity tone detect: a tone of 2010 Hz 👂
- Continuity test send: a tone of 1780 Hz is sent by the calling exchange. If the called exchange receives it, it sends back a "continuity verified" tone 🔁
- Continuity verified: a tone of 2010 Hz. It's a response tone, used in dual-tone procedures 💅
4 RTP Payload Format for Telephony Tones 🌈✨
4.1 Introduction ✨
Okay so, instead of naming tones and events like we did in Section 3, sometimes it's way better to describe them by their waveform properties 🌊. Recognition is faster this way because it doesn't depend on figuring out durations or pauses. Main character energy 💅
There's no single international standard for telephone tones, like dial tone, ringing (ringback), busy, congestion ("fast-busy"), special announcement tones, or some of the other special ones such as payphone recognition, call waiting, or record tone. Even so, across all countries these tones share a few characteristics [17] 🌍:
- Telephony tones are made 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. 🎶
- Tones for telephony events sit in the range of 25 (ringing tone in Angola) to 1800 Hz. CED is the highest used tone at 2100 Hz. The telephone frequency range is limited to 3,400 Hz. (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. (These fractional frequencies appear to be derived from older AC power grid frequencies.) ⚡
- 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 7 summarizes some common tones 📋. The rows labeled "ITU ..." refer to the general recommendation of Recommendation E.180 [18]. Note that there are no specific guidelines for these tones. In the table, the symbol "+" indicates addition of the tones, without modulation, while "*" indicates amplitude modulation. The meaning of some of the tones is described in Section 3.12 or Section 3.11 (for V.21).
Tone name frequency on period off period
______________________________________________________
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 "0" bit, ch. 1 1180 0.00333
V.21 "1" bit, ch. 1 980 0.00333
V.21 "0" bit, ch. 2 1850 0.00333
V.21 "1" bit, ch. 2 1650 0.00333
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
U.S. busy tone 480+620 0.5 0.5
______________________________________________________
ITU congestion tone 425
U.S. congestion tone 480+620 0.25 0.25
Table 7: Examples of telephony tones4.3 Use of RTP Header Fields
- Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 3.5 extends forwards from that time. ⏰
4.4 Payload Format
Based on the characteristics we just covered, this document defines an RTP payload format called "tone" 🔊 that can represent tones made of one or more frequencies. (The corresponding MIME type is "audio/tone".) The default timestamp rate is 8,000 Hz, but other rates may be defined. Note that the timestamp rate does not affect the interpretation of the frequency, just the durations. ✨
In accordance with current practice, this payload format does not have a static payload type number. Instead it uses an RTP payload type number that gets established dynamically and out-of-band. 🤝
Here's the layout, shown in Fig. 3 💖:
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 3: Payload format for tonesThe payload contains the following fields 🧩:
- modulation: The modulation frequency, in Hz. The field is a 9-bit unsigned integer, allowing modulation frequencies up to 511 Hz. If there is no modulation, this field has a value of zero.
- T: If the "T" bit is set (one), the modulation frequency is to be divided by three. Otherwise, the modulation frequency is taken as is.
- This bit allows frequencies accurate to 1/3 Hz, since modulation frequencies such as 16 2/3 Hz are in practical use. 🎀
- volume: The power level of the tone, expressed in dBm0 after dropping the sign, with range from 0 to -63 dBm0. (Note: A preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.) 🔉
- duration: The duration of the tone, measured in timestamp units. The tone begins at the instant identified by the RTP timestamp and lasts for the duration value.
- The definition of duration corresponds to that for sample-based codecs, where the timestamp represents the sampling point for the first sample. 🧠
- frequency: The frequencies of the tones to be added, measured in Hz and represented as a 12-bit unsigned integer. The field size is sufficient to represent frequencies up to 4095 Hz, which exceeds the range of telephone systems. A value of zero indicates silence. A single tone can contain any number of frequencies. 🎵
- R: This field is reserved for future use. The sender MUST set it to zero, the receiver MUST ignore it. 🔒
4.5 Reliability
This payload format uses the reliability mechanism described in Section 3.7 🛡️.
5 Combining Tones and Named Events
The payload formats in Sections 3 and 4 can be combined into a single payload using the method specified in RFC 2198 🧃. Fig. 4 shows an example. In that example, the RTP packet combines two "tone" and one "telephone-event" payloads. The payload types are chosen arbitrarily as 97 and 98, respectively, with a sample rate of 8000 Hz. Here, the redundancy format has the dynamic payload type 96.
The packet is a snapshot of U.S. ringing tone, 1.5 seconds (12,000 timestamp units) into the second "on" part of the 2.0/4.0 second cadence, i.e., a total of 7.5 seconds (60,000 timestamp units) into the ring cycle. The 440 + 480 Hz tone of this second cadence started at RTP timestamp 48,000. Four seconds of silence preceded it, but since RFC 2198 only has a fourteen-bit offset, only 2.05 seconds (16383 timestamp units) can be represented. Even though the tone sequence is not complete, the sender was able to determine that this is indeed ringback, and thus includes the corresponding named event. 📞✨
6 MIME Registration
6.1 audio/telephone-event
- MIME media type name: audio
- MIME subtype name: telephone-event
- Required parameters: none.
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 |P|X| CC |M| PT | sequence number |
| 2 |0|0| 0 |0| 96 | 31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
| 48000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 0x5234a8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 98 | 16383 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| block PT | timestamp offset | block length |
|1| 97 | 16383 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Block PT |
|0| 97 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event=ring |0|0| volume=0 | duration=28383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=63 | duration=16383 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=0 |0 0 0 0| frequency=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modulation=0 |0| volume=5 | duration=12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| frequency=440 |0 0 0 0| frequency=480 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Combining tones and events in a single RTP packet- Optional parameters: The "events" parameter lists the events supported by the implementation. Events are listed as one or more comma-separated elements. Each element can either be a single integer or two integers separated by a hyphen. No white space is allowed in the argument. The integers designate the event numbers supported by the implementation. All implementations MUST support events 0 through 15, so that the parameter can be omitted if the implementation only supports these events. 🌈
- The "rate" parameter describes the sampling rate, in Hertz. The number is written as a floating point number or as an integer. If omitted, the default value is 8000 Hz. 💜
- Encoding considerations: This type is only defined for transfer via RTP [1]. 📦
- Security considerations: See the "Security Considerations" (Section 7) section 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. 🌐
- Additional information:
- Magic number(s): N/A
- File extension(s): N/A
- Macintosh file type code: N/A
6.2. audio/tone 🎀
okay so this one is for pure composite tones, the call-progress beeps you've heard a million times 🦋
- MIME media type name:
audio - MIME subtype name:
tone - Required parameters: none
- Optional parameters: there's one optional
"rate"parameter for the sampling rate in Hertz. You can write it as a floating point number or as an integer. If you leave it out, it defaults to 8000 Hz ✨ - Encoding considerations: this type is only defined for transfer via RTP [1] 📡
- Security considerations: see the "Security Considerations" (Section 7) section in this document 🔒
- Interoperability considerations: none
- Published specification: this document 📖
- Applications which use this media: the tone subtype carries pure composite tones, like the ones the telephone system has long used to signal call progress 📞
- Additional information:
- Magic number(s): N/A
- File extension(s): N/A
- Macintosh file type code: N/A
7 Security Considerations 🔒
okay security time, and this part is serious bestie 😭
RTP packets using the payload format from this spec are subject to the security considerations in the RTP spec (RFC 1889 [1]), plus any RTP profile that applies (for example RFC 1890 [19]). That basically means confidentiality of the media streams comes from encryption. The compression used with this payload format is applied end-to-end, so encryption can happen after compression without the two clashing 🔐
This payload type doesn't have any real non-uniformity in receiver-side computational complexity for packet processing, so it doesn't open up a denial-of-service threat 🛡️
⚠️ In older networks that use in-band signaling and don't have appropriate tone filters, the tones in Section 3.14 may be used to commit toll fraud. Please be careful with this one!!
Additional security considerations are described in RFC 2198 [6] 💅
8 IANA Considerations 📋
this document defines two new RTP payload formats, named telephone-event and tone, plus the MIME types audio/telephone-event and audio/tone ✨
Within the audio/telephone-event type, additional events MUST be registered with IANA. Registrations are subject to approval by the current chair of the IETF audio/video transport working group, or by an expert designated by the transport area director if the AVT group has closed 🫶
The meaning of new events MUST be documented either as an RFC or as an equivalent standards document from another standardization body, such as ITU-T 📚
9 Acknowledgements 🌷
huge thanks to the Megaco working group for their suggestions 💖 and to Fred Burg, Steve Casner, Fatih Erdin, Bill Foster, Mike Fox, Gunnar Hellstrom, Terry Lyons, Steve Magnell, Vern Paxson and Colin Perkins for the detailed advice and comments 🙌
10 Authors' Addresses 🗺️
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Scott Petrack
MetaTel
45 Rumford Avenue
Waltham, MA 02453
USA
EMail: scott.petrack@metatel.com11 Bibliography 📚
these are all the refs, verbatim so nothing gets lost 🦋
[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] International Telecommunication Union, "Procedures for starting
sessions of data transmission over the public switched telephone
network," Recommendation V.8, Telecommunication Standardization
Sector of ITU, Geneva, Switzerland, Feb. 1998.
[4] R. Kocen and T. Hatala, "Voice over frame relay implementation
agreement", Implementation Agreement FRF.11, Frame Relay Forum,
Foster City, California, Jan. 1997.
[5] International Telecommunication Union, "Multifrequency push-
button signal reception," Recommendation Q.24, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1988.
[6] 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.
[7] Handley M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[8] International Telecommunication Union, "Automatic answering
equipment and general procedures for automatic calling equipment
on the general switched telephone network including procedures
for disabling of echo control devices for both manually and
automatically established calls," Recommendation V.25,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Oct. 1996.
[9] International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network," Recommendation T.30, Telecommunication Standardization
Sector of ITU, Geneva, Switzerland, July 1996.
[10] International Telecommunication Union, "Echo cancellers,"
Recommendation G.165, Telecommunication Standardization Sector
of ITU, Geneva, Switzerland, Mar. 1993.
[11] International Telecommunication Union, "A modem operating at
data signaling rates of up to 33 600 bit/s for use on the
general switched telephone network and on leased point-to-point
2-wire telephone-type circuits," Recommendation V.34,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Feb. 1998.
[12] International Telecommunication Union, "Procedures for the
identification and selection of common modes of operation
between data circuit-terminating equipments (DCEs) and between
data terminal equipments (DTEs) over the public switched
telephone network and on leased point-to-point telephone-type
circuits," Recommendation V.8bis, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Sept. 1998.
[13] International Telecommunication Union, "Application of tones and
recorded announcements in telephone services," Recommendation
E.182, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Mar. 1998.
[14] Bellcore, "Functional criteria for digital loop carrier
systems," Technical Requirement TR-NWT-000057, Telcordia
(formerly Bellcore), Morristown, New Jersey, Jan. 1993.
[15] J. G. van Bosse, Signaling in Telecommunications Networks
Telecommunications and Signal Processing, New York, New York:
Wiley, 1998.
[16] International Telecommunication Union, "AAL type 2 service
specific convergence sublayer for trunking," Recommendation
I.366.2, Telecommunication Standardization Sector of ITU,
Geneva, Switzerland, Feb. 1999.
[17] International Telecommunication Union, "Various tones used in
national networks," Recommendation Supplement 2 to
Recommendation E.180, Telecommunication Standardization Sector
of ITU, Geneva, Switzerland, Jan. 1994.
[18] International Telecommunication Union, "Technical
characteristics of tones for telephone service," Recommendation
Supplement 2 to Recommendation E.180, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Jan. 1994.
[19] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.12 Full Copyright Statement ⚖️
okay legal bit, read it all, it matters 🧚
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc2833 2000-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms