RFC 4734
Definition of Events for Modem, Fax, and Text Telephony Signals
RFC 4734 📼 Definition of Events for Modem, Fax, and Text Telephony Signals
Okay bestie, here's the tea 🫶 This one is a Standards Track doc from the Network Working Group, dated December 2006. The authors are Henning Schulzrinne (Columbia U.) and Tom Taylor (Nortel). It updates RFC 4733 and it obsoletes RFC 2833, but only the part that assigned event codes for this purpose 💅
Status of This Memo 📜
Okay so this one is an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and send in ideas for making it better 💬 For the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed with no limits, so share away 🦋
Copyright Notice ⚖️
Copyright (C) The IETF Trust (2006).
Abstract ✨
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when they're carried in the telephony event RTP payload. It replaces the event code assignments for this purpose in RFC 2833, so it obsoletes that part of RFC 2833. Iconic glow-up energy 🌸
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Overview ...................................................3
2. Definitions of Events for Control of Data, Fax, and Text
Telephony Sessions ..............................................5
2.1. V.8 bis Events .............................................5
2.1.1. Handling of Congestion ..............................9
2.2. V.21 Events ...............................................10
2.2.1. Handling of Congestion .............................11
2.3. V.8 Events ................................................12
2.3.1. Handling of Congestion .............................15
2.4. V.25 Events ...............................................15
2.4.1. Handling of Congestion .............................17
2.5. V.32/V.32bis Events .......................................18
2.5.1. Handling of Congestion .............................19
2.6. T.30 Events ...............................................19
2.6.1. Handling of Congestion .............................23
2.7. Events for Text Telephony .................................23
2.7.1. Signal Format Indicators for Text Telephony ........23
2.7.2. Use of Events with V.18 Modems .....................27
2.8. A Generic Indicator .......................................28
3. Strategies for Handling Fax and Modem Signals ..................29
4. Example of V.8 Negotiation .....................................30
4.1. Simultaneous Transmission of Events and
Retransmitted Events Using RFC 2198 Redundancy ............35
4.2. Simultaneous Transmission of Events and Voice-Band
Data Using RFC 2198 Redundancy ............................37
5. Security Considerations ........................................39
6. IANA Considerations ............................................40
7. Acknowledgements ...............................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................441. 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]. Those are the official vibe-check words, so pay attention to them 👀
Besides the terms defined for specific events, this document uses these abbreviations:
Fax facsimile
HDLC High-level Data Link Control
PSTN Public Switched (circuit) Telephone Network1.2. Overview 🦋
Okay so this doc extends the telephony events from RFC 4733 [5] to cover the control events and tones that can show up on a subscriber line serving a fax machine, a modem, or a text telephony device. The events are grouped by the ITU-T Recommendation they come from. Their whole purpose is to support negotiation, start-up and takedown of fax, modem, or text telephony sessions, plus switching between operating modes ⚡ The actual fax, modem, and text payload usually rides on other payload types, like V.150.1 [32] modem relay, voice-band data as formalized in ITU-T Rec. V.152 [33], Clearmode [17] for digital data, T.38 [21] for fax, or RFC 4103 [18] for character-mode text 💌
NOTE: implementers SHOULD NOT rely on the descriptions of the various modem protocols described below without consulting the original references (generally ITU-T Recommendations). These descriptions are here to give context for using the events defined in this doc. They often leave out important details needed for implementation, so don't be the one who skips the source material 🙈
The typical application of these events is letting the Internet act as a bridge between terminals operating on the PSTN. Here's how it's characterized:
- each gateway will act both as sender and as receiver;
- time constraints apply to the exchange of signals, making early identification and reporting of events desirable so that receiver playout can proceed in a timely fashion;
- the receiver must play out events in their proper order;
- transfer of the events must be reliable. Applications will vary in their ability to recover from missing events.
In some cases, an implementation may simply ignore certain events, such as fax tones, that don't make sense in a particular environment. Section 2.4.1 of RFC 4733 [5] explains how an implementation can use the Session Description Protocol (SDP) "fmtp" parameter within an SDP description [4] to indicate which events it is prepared to handle. Main character energy when it comes to picking what you actually handle 💅
Regardless of which events they support, implementations MUST be prepared to send and receive data signals using payload types other than telephone-event, at the same time as using the latter. This is discussed further in Section 3. Non-negotiable, bestie 🔥
In many cases, continuity of playout is critical. In principle, this is achieved through buffering at the receiving end. It's generally desirable to minimize that buffering to reduce round-trip response times. Keeping a constant packetization interval at the sending end while reporting events helps with this 🧚
A further word on time constraints is in order. Time constraints on how long tones last aren't a problem when using the telephone-event payload type, because the payload specifies the duration and the receiving gateway can play the tones out accordingly 🎀 Problems happen when there are time constraints on the duration of silence between tones. A silent period of "at least x ms" isn't a problem, since event notifications can arrive late and still be played out at their specified durations.
The problem shows up if silence must last for a specific duration or at most some specific period. The most general constraint of that second type comes from echo suppressors (ITU-T Rec. G.164 [6]) and echo cancellers (ITU-T Rec. G.165 [7]). These devices may re-activate after as little as 100 ms of no signal on the line 😭 So, in any situation where echo suppressors or cancellers must be disabled for signalling to work, tone events must be reported quickly enough that these devices don't get re-enabled. Full protective-bestie mode 🫶
2. Definitions of Events for Control of Data, Fax, and Text Telephony Sessions 👑
2.1. V.8 bis Events ✨
okay so V.8 bis [10] is basically the general procedure where two endpoints figure out each other's capabilities and switch between operating modes, both at call startup and after the call is already going 📞🫶. It works with many of the same terminals as V.8 [9] (Section 2.3 below), but it lets you negotiate way more detailed parameters. It doesn't support some of the older V-series modems from V.8, but it adds stuff for simultaneous or alternating voice and data, H.324 [20] multilink, and T.120 [23] conferencing. the main character of this section, fr 💅
Once V.8 bis capability negotiation is done, if the terminals agreed on a modem-based operating mode, they start the actual modem session using either V.8, a truncated version of V.8 (preferred), or V.25 start-up. V.25 gets its own section, Section 2.4 🌸
V.8 bis splits things into "signals" and "messages" 🦋. The V.8 bis signals (ESi/ESr, MRe/MRd, and CRe/CRd) are made of tones, which we'll get into in the next few paragraphs. The V.8 bis messages (MS, CL, CLR, ACK(1), ACK(2), NAK(1), NAK(2), NACK(3), and NACK(4)) are sequences of bits sent over V.21 [12] modulation.
Signals have to be understandable to the receiver even when voice is also going on, so they're built from two tone segments 🎀. The first segment is a dual-frequency tone held for 400 ms. Its job is to get the receiver and any in-line echo suppressor or canceller ready for what's coming ✨. The frequencies only depend on whether the signal comes from the initiator or the responder in the transaction. When you're using the telephone-event payload, the V8bISeg and V8bRSeg events in Table 1 stand for the first segment of any V.8 bis signal in the initiating and responding cases, respectively.
The full V.8 bis strategy for dealing with echo suppressors or cancellers is described in Rec. V.8 bis Appendix III. The only silent period constraints imposed are of the "at least" type, posing no difficulties for the use of the telephone-event payload.
The second segment comes right after the first and is one single tone held for 100 ms 🧚. The frequency used tells you which of the six signals it is. When you're using the telephone-event payload, the second segment is represented by whichever applicable event: CRdSeg, CReSeg, MRdSeg, MReSeg, ESiSeg, or ESrSeg, all defined in Table 1 💜. ESiSeg and ESrSeg use the exact same frequencies as the V.21 low and high channel '1' bits, respectively (see Table 2), so they get the same event codes. no cap, that's a lot of overlap lol 🙈
V.8 bis messages use V.21 [12] frequency-shift signalling to move message content around. V.21 is covered in the next section. V.8 bis runs V.21 in half-duplex mode at 300 bits/s, with the lower channel for the initiator and the upper channel for the responder 🍓.
Each V.8 bis message starts with a 100-ms preamble of continuous V.21 marking frequency, unless the message came right after an ESi or ESr signal (whose second segment is that same V.21 marking frequency already) 🌈. The sender SHALL NOT report this preamble tone using the ESiSeg or ESrSeg events. Those events are only for the V.8 bis signals they belong to, bestie, so don't mix them up 🚫.
Spelling it out: continuous V.21 marking tone right after V8bISeg and V8bRSeg gets reported as ESiSeg or ESrSeg, respectively. Continuous V.21 marking tone showing up in any other context, especially after CRdSeg, CReSeg, MRdSeg, or MReSeg, is reported by other means, like a different payload type or the V.21 '1' bit events from Section 2.2 💅
No events are defined for V.8 bis messages, but here's a quick rundown 📝:
- the V.8 bis CL message describes the sending terminal's capabilities;
- the CLR message also describes capabilities, but it says the sender wants to get a CL back in return;
- the MS establishes a particular operating mode;
- the ACK and NAK messages are used to wrap up the message transactions.
The V.8 bis messages are laid out as a sequence of octets 🧩. The first two to five octets are HDLC flags (0x7E). After that comes a message type identifier (four bits), a V.8 bis version identifier (four bits), zero to two more octets of identifying info, and then zero or more information field parameters in the form of bit maps. Each bit map is one to five octets long. Up to 64 octets of non-standard information can also show up. The information fields are followed by a checksum and one to three HDLC flags. Since there are limits on how big any one information field can be, V.8 bis defines segmentation procedures. Extra data gets sent in an additional message, but only after the receiving end prompts for it 🫶.
Applications that support V.8 bis signalling with the telephone-event payload MAY transfer V.8 bis messages as sequences of bits, using the V.21 bit events from the next section. If they do, the transmitted info MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, and the terminating HDLC flags 🎯.
Transmission MUST also include the extra '0' bits added following the procedures of Rec. V.8 bis, clause 7.2.8, so the receiver doesn't falsely recognize HDLC flags 🙅♀️. Implementers should note that these extra '0' bits mean V.8 bis messages on the wire usually won't come out to an even multiple of octets, which is kind of a plot twist 🌀. Sending implementations MAY choose to vary the packetization interval to include exactly one octet of information plus any extra '0' bits inserted into that octet. The resulting variation is basically insignificant compared to the buffering needed to guard against network delays in packet delivery to the receiver (see below) 🌸.
One reason for reporting the V.21 bits exactly as they appear on the wire is to match the corresponding content if it's also carried by other means, like voice-band data 🎀
The power levels of V.8 bis and V.21 signals are subject to national regulation, so it seems suitable to model V.8 bis events as tones whose volumes SHOULD be specified by the sender 📢. If the receiver is rendering the V.8 bis tones as audio content for onward transmission, the receiver MAY use the volumes contained in the event reports, or MAY modify the volumes to match downstream national requirements 🌍.
Table 1 sums up the event codes defined for V.8 bis signalling in this document. The individual events are described right after the table. Each event begins when the start of the tone segment is detected and ends when the tone is no longer detected ⏱️.
+---------+-------------+-----------+------------+------+---------+
| Event | Freq. (Hz) | Dur. (ms) | Event Code | Type | Volume? |
+---------+-------------+-----------+------------+------+---------+
| ESiSeg | 980 | 100 | 38 | tone | yes |
| | | | | | |
| ESrSeg | 1650 | 100 | 40 | tone | yes |
| | | | | | |
| CRdSeg | 1900 | 100 | 23 | tone | yes |
| | | | | | |
| CReSeg | 400 | 100 | 24 | tone | yes |
| | | | | | |
| MRdSeg | 1150 | 100 | 25 | tone | yes |
| | | | | | |
| MReSeg | 650 | 100 | 26 | tone | yes |
| | | | | | |
| V8bISeg | 1375 + 2002 | 400 | 28 | tone | yes |
| | | | | | |
| V8bRSeg | 1529 + 2225 | 400 | 29 | tone | yes |
+---------+-------------+-----------+------------+------+---------+
Table 1: Events for V.8 bis SignalsESiSeg: the second segment of a V.8 bis initiating Escape Signal (ESi). The complete ESi signal is represented by V8bISeg followed by ESiSeg. ESi will be followed by an MS, CL, or CLR message from the same terminal. A 1.5-s silent interval may come between the ESi signal and the transmission of the MS, CL, or CLR message, to accommodate network echo suppressors 🤫.
ESrSeg: the second segment of a V.8 bis responding Escape Signal (ESr). The complete ESr signal is represented by V8bRSeg followed by ESrSeg. ESr is always sent by the calling terminal in response to an MRe or CRe from an automatic answering station. It will be followed by an MS, CL, or CLR message. The ESr signal turns off any announcement being generated by the automatic answering station 📵.
CRdSeg: the second segment of a V.8 bis Capabilities Request signal (CRd). The first segment of the CRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a capabilities list (CL or CLR message) 📋.
CReSeg: the second segment of a V.8 bis Capabilities Request signal (CRe) initiated by an automatic answering terminal. The complete CRe signal is represented by V8bISeg followed by CReSeg. The calling terminal will respond with a CRd signal or a CL or CLR message 🔁.
MRdSeg: the second segment of a V.8 bis Mode Request signal (MRd). The first segment of the MRd signal is represented either by V8bISeg or V8bRSeg, depending on context. The other end will return a CRd signal or an MS message 🌷.
MReSeg: the second segment of a V.8 bis Mode Request signal (MRe) initiated by an automatic answering terminal. The complete MRe signal is represented by V8bISeg followed by MReSeg. The calling terminal will respond with an MRd or CRd signal or an MS message 💌.
V8bISeg: the first segment of an initiating V.8 bis signal, which may be one of ESi, CRd, CRe, MRd, or MRe 🚀.
V8bRSeg: the first segment of a responding V.8 bis signal, which may be one of ESr, CRd, or MRd 🌙.
2.1.1. Handling of Congestion 🌧️
V.8 bis implementations are unlikely to tolerate gaps or extensions in playout times caused by congestion-related packet delay 😬. At a minimum, the current transaction is liable to be reset when these playout defects happen. So careful management of the playout buffer is required at the receiver, to be more robust when packets get lost or delayed ✨. The playout algorithm should also avoid letting event playout exceed the nominal duration of the event.
V.8 bis doesn't appear to offer any opportunities for dynamic adaptation to congestion by manipulating the packetization interval 🫠.
2.2. V.21 Events
okay so V.21 is a modem protocol that does data transmission at a max rate of 300 bits/s 🦋 it has two channels, so full duplex is possible if you need it 💅 the low channel uses 980 Hz for '1' (mark) and 1180 Hz for '0' (space), and the high channel uses 1650 Hz for '1' and 1850 Hz for '0' 🎀 the modem can run synchronously or asynchronously, which is so flexible ✨
V.21 is used by other protocols (e.g., V.8 bis, V.18, T.30) to send control data, and it's also used on its own between text terminals 🌸 the V.21 events are summarized in Table 2 💜
Sending implementations SHOULD report a completed event for every bit transmitted (i.e., rather than at transitions between '0' and '1') 🫶 bit events are assumed to begin and end with the clock interval for the event, and the rise and fall times between bit transitions get ignored 🧚 so it's important for a gateway to figure out the actual bit rate in use before it starts reporting V.21 events, no cap 💀
Sometimes figuring out the bit rate isn't immediately possible, like with the 100-ms training signal at V.21 mark frequency that gets used before V.8 bis messages 🙈 sending one longer-duration V.21 event is reasonable in that situation, and it shouldn't cause any difficulties at the receiving end 🫶
Implementations SHOULD pack multiple events into one packet, using the procedures of Section 2.5.1.5 of RFC 4733 [5] 🍓 eight to ten bits is a reasonable packetization interval ✨
Reliable transmission of V.21 events is super important, bestie, because it's what stops data corruption 😭 reporting an event per bit instead of per transition adds reporting redundancy and so makes reporting more reliable, since each event completion gets sent three times as described in Section 2.5.1.4 of RFC 4733 [5] 🦋 to cut down on the number of packets needed for reporting, implementations SHOULD carry the retransmitted events using RFC 2198 [2] redundancy encoding 💅 this is shown in the example in Section 4.1 🌈
The time to send one V.21 bit at the nominal rate of 300 bits/s is 3.33 ms, or 26.67 timestamp units at the default 8000-Hz sampling rate for the telephone-event payload type 🧚 since that duration isn't a whole number of timestamp units, you literally can't get accurate reporting of the beginning of the event and the event duration 😭 sending gateways SHOULD round V.21 event starting times to the nearest whole timestamp unit 🎀
When you send multiple consecutive V.21 events across a bunch of packets, the sending gateway MUST make sure the reported event durations don't make the last event of one packet overlap with the first event of the next, taking the respective initial event timestamps into account 🔥 to do that, the sending gateway MUST derive each individual event duration as the succession of differences between the event starting times (so at 8000 Hz, every third event has a reported duration of 26 units, and the rest have 27 units) 👑
Where a receiving gateway recognizes that a packet reports a consecutive series of V.21 bit events, it SHOULD play them out at a uniform rate, even with the possible one-timestamp-unit discrepancies in their reported spacing and duration 🌸
+--------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------------------+----------------+------------+------+---------+
| V.21 channel 1, | 1180 | 37 | tone | yes |
|---|---|---|---|---|
| '0' bit | ||||
| V.21 channel 1, | 980 | 38 | tone | yes |
| '1' bit | ||||
| V.21 channel 2, | 1850 | 39 | tone | yes |
| '0' bit | ||||
| V.21 channel 2, | 1650 | 40 | tone | yes |
| '1' bit |
+--------------------+----------------+------------+------+---------+
Table 2: Events for V.21 Signals
Implementations that send V.21 content using a different payload type might want to use one of the indicator events defined in Table 7 🧚 that alerts the receiver to what kind of content it is 💖 it's not expected that an implementation will send both one of these indicator events and the V.21 bit events defined above for the same content 🙈
2.2.1. Handling of Congestion ✨
The duration of V.21 bits can't be extended from its nominal value, which depends on the transmission rate 😭 the playout algorithm at the receiver SHOULD take this constraint into account when compensating for delay or loss of packets caused by congestion 🫶
Other congestion-related considerations depend on the specific application the V.21 bit events are being used for 🦋
2.3. V.8 Events ✨
okay so V.8 💅 is an older general negotiation and control protocol, and it's the one that gets the whole call started for a bunch of terminals: H.324 [20] multimedia, V.18 [11] text, T.101 [22] videotext, T.30 [8] send or receive fax, and a long list of V-series modems including V.34 [28], V.90 [29], V.91 [30], and V.92 [31]. the big difference from V.8 bis [10] is that in V.8 only the calling terminal gets to decide the operating mode 👑 the answering one just goes along with it 🙈
V.8 doesn't use the same terminology as V.8 bis, bestie. instead it defines four signals made of bits sent by V.21 [12] at 300 bits/s: the call indicator signal (CI), the call menu signal (CM), the CM terminator (CJ), and the joint menu signal (JM) 🦋. it also uses tones from V.25 [13] and T.30 [8] (more on those below), plus one tone (ANSam) that's defined in V.8 itself ✨. the calling terminal sends on the V.21 low channel, and the answering terminal uses the high channel 🎀
the basic sequence has a bunch of variations depending on the terminal type, but a pure V.8 sequence goes like this 💖
- after a little silence, the calling terminal sends the V.8 CI signal. it repeats CI at least three times, with occasional pauses, until it detects ANSam tone 🌸 the CI tells everyone whether the caller wants to be H.324, V.18, T.30 send, T.30 receive, or a V-series modem.
- the answering terminal sends ANSam once it detects CI 🔥 ANSam will disable any G.164 [6] echo suppressors on the circuit after 400 ms, and any G.165 [7] echo cancellers after one second of ANSam playout.
- once the calling terminal detects ANSam, it pauses at least half a second and then starts sending CM to describe its detailed capabilities within the chosen mode 🧚
- after detecting at least two identical sequences of CM, the answering terminal starts sending JM to show its own capabilities (or offers a different terminal type if it can't support the one requested) 💜
- after detecting at least two identical sequences of JM, the calling terminal finishes the current octet of CM, then sends CJ to acknowledge JM. it pauses exactly 75 ms and then starts operating in the selected mode ⭐
- the answering terminal keeps sending JM until it has detected CJ. at that point it stops sending JM right away, pauses exactly 75 ms, and then starts operating in the selected mode 🫶
the CI, CM, and JM signals all share the same structure: a fixed run of ten '1' bits, then a signal-dependent pattern of ten synchronization bits, then one or more octets of variable info 🌈 each octet has a '0' start bit in front and a '1' stop bit at the back. the combo of the sync pattern and the V.21 channel uniquely identifies the message type, so it's basically a fingerprint 🍓 the CJ signal is three back-to-back octets of all zeros with start and stop bits, but it doesn't have the leading '1's or the sync pattern that the other signals have 💀
applications MAY report each instance of a CM, JM, and CJ signal as a series of V.21 bit events (Section 2.2), or they MAY use another payload type to carry this info 🎀 apps that support V.8 signalling with the telephone-event payload MAY report the sync part of the CI signal (ten '1's followed by '00000 00001') as a series of V.21 bit events and, once it's been recognised, as a single CI event ✨
Note that the CI event only covers the sync part of the CI signal. the remaining call function octet and its start and stop bits still need to be sent too, either as a series of V.21 bit events or in some other payload format. presumably, the calling end gateway will use the same format for the CM and CJ signals. 🙈
the overlapping nature of V.8 signalling means there's no risk of silence going over 100 ms once ANSam has turned off the echo control circuitry 🦋 the 75-ms pause before the selected data mode starts, though, means both the calling and answering gateways have to recognise when CJ is finished, so they can switch from playing out telephone-event to the data-bearing payload after that 75-ms period 💅
+--------+----------------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------+----------------------+------------+------+---------+
| ANSam | 2100 x 15 | 34 | tone | yes |
| | | | | |
| /ANSam | 2100 x 15 phase rev. | 35 | tone | yes |
| | | | | |
| CI | (V.21 bits) | 53 | tone | yes |
+--------+----------------------+------------+------+---------+
Table 3: Events for V.8 SignalsANSam:
the modified answer tone ANSam is a sinewave signal at 2100 Hz, amplitude-modulated by a sine wave at 15 Hz 🌸 the event starts at the beginning of the tone. it ends at whichever comes first: the end of the tone, or a phase reversal (which marks the start of a /ANSam event). phase reversals are used to turn off echo cancellation, and if they're being used, they happen every 450 ms 🔥
an ANSam event packet SHOULD NOT be sent until it's possible to tell an ANSam event apart from an ANS event (see the V.25 events, below) 💀
the modulated envelope for the ANSam tone ranges in amplitude between 0.8 and 1.2 times its average amplitude. the average transmitted power is governed by national regulations, so it makes sense to indicate the volume of the signal 🧚
/ANSam:
/ANSam reports the same physical signal as ANSam, but it's reported after the first phase reversal in that signal 🦋 it begins with the phase reversal and ends at the end of the tone. the receiver of /ANSam MUST reverse the phase of the tone at the beginning of /ANSam playout and every 450 ms after that, until the end of the tone is reached 👑
CI:
CI reports the occurrence of the V.21 bit pattern '11111 11111 00000 00001', which marks the beginning of a V.8 CI signal 🎀 the event begins at the start of the first bit and ends at the end of the last one. this event MUST NOT be reported except in a context where a V.8 CI signal might be expected (i.e., at the calling end during call setup) ✨ note that if the calling modem sends the CI signal at all, it will typically repeat the signal several times 💖
it's expected that the CI event will be most useful when the modem content is being sent mainly using another payload type. the event acts as a commentary on that content, letting the receiver recognise that V.8 signalling is in progress 🌈
2.3.1. Handling of Congestion 🫶
the tolerances built into V.8 suggest it may be pretty robust when it comes to packet losses or delays 💅 playout of ANSam and /ANSam can be extended over multiple packetization periods without harm, as long as phase reversals keep happening on schedule every 450 ms during /ANSam playout 🔥
to make the V.21-based signals more robust, sending applications using the V.21 events SHOULD include an integral number of octets, including start and stop bits, in each packet 🦋 the start and stop bits give receivers some hope of handling the unavoidable gaps in playout between octets 🍓 when a message is being repeated (which is possible for CI, CM, and JM), an even stronger robustness measure is for the receiver to keep a copy of the message when it's first received. then, if a packet is delayed or lost, it can keep playing out the current message instance and start a new repetition as if packets had kept arriving on schedule 💜
2.4. V.25 Events ✨
okay so V.25 is a start-up protocol that came before V.8 and V.8 bis 💅 (see [13], [9], [10]). It's all about swapping two tone signals: CT and ANS 🎀
CT (calling tone) is basically a series of interrupted bursts of 1300-Hz tone 🌸. Each burst is on for not less than 0.5 s and not more than 0.7 s, then off for not less than 1.5 s and not more than 2.0 s 🦋 [13]. Modems that don't start with the V.8 CI signal often use this tone 🙈
ANS (Answer tone) is a 2100-Hz tone used to disable echo suppression for data transmission 🔥 [13], [8]. For fax machines, Recommendation T.30 [8] calls this tone the called terminal identification (CED) answer tone 📠 ANS is different from V.8 ANSam because it has constant amplitude, while ANSam doesn't 💜
V.25 specifically includes procedures for disabling echo suppressors as defined by ITU-T Rec. G.164 [6] 👑 BUT, lowkey plot twist: G.164 echo suppressors have mostly been replaced by G.165 [7] echo cancellers 😭 These cancellers need phase reversals in the disabling tone (see ANSam above) 🔄 So in July 2001, Recommendation V.25 got updated to say that phase reversal in the ANS tone is required if echo cancellers are to be disabled ✨
Here's one possible V.25 sequence, bestie 🧚:
- The calling terminal starts generating CT as soon as the call is connected 📞
- The called terminal waits in silence for 1.8 to 2.5 s after answer, then starts transmitting ANS continuously 🌈 If echo cancellers are on the line, the phase of the ANS signal gets reversed every 450 ms 🔁 ANS won't reach the calling terminal until the echo control equipment has been disabled 😤 Since that takes about a second, it can only happen in the gap between one burst of CT and the next 🫶
- After detecting ANS, the calling terminal can stop generating CT immediately or wait until the end of the current burst 💅 Either way, it MUST wait at least 400 ms after stopping CT before it can generate the calling station response tone (or at least 1 s if phase reversal of ANS is being used to disable echo cancellers) ⏳ This tone is modem-specific and not specified in V.25 🤷♀️
- The called terminal plays out ANS for 2.6 to 4.0 seconds, or until it has detected calling station response for 100 ms 🎶 Then it waits 55-95 ms (nominal 75 ms) in silence 🤫 (Heads up: the upper limit of 95 ms is pretty close to when echo control might reestablish itself 😬) If ANS stopped because of a timeout instead of detecting the calling station response, the called terminal starts playing ANS again to keep echo control disabled until the calling station responds 🔁
The events defined for V.25 signalling are shown in Table 4 📋
+-------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+-------------------+----------------+------------+------+---------+
| Answer tone (ANS) | 2100 | 32 | tone | yes |
| | | | | |
| /ANS | 2100 ph. rev. | 33 | tone | yes |
| | | | | |
| CT | 1300 | 49 | tone | yes |
+-------------------+----------------+------------+------+---------+
Table 4: Events for V.25 SignalsANS: 🎈
The event begins at the start of the 2100-Hz tone 🎬 It ends at whichever comes first: the tone ending, or a phase reversal (which starts a /ANS event) ⏹️
An initial ANS event packet SHOULD NOT be sent until it's possible to tell an ANS event apart from an ANSam event (see V.8 events, above) 🕵️♀️
/ANS: 🦄
/ANS reports the same physical signal as ANS, but it's reported after the first phase reversal in that signal 🔄 It begins with the phase reversal and ends at the end of the tone 🌙 The receiver of /ANS MUST reverse the phase of the tone at the beginning of playout of /ANS and every 450 ms after that, until the end of the tone is reached 💖
CT: 🌷
A CT event begins at the start of an individual burst of the 1300-Hz tone, and ends at the end of that same tone burst 🎀 The gateway at the calling end SHOULD use a packetization interval smaller than the nominal duration of a CT burst, so CT playout at the called end happens before ANS gets sent from that end 🏃♀️💨
2.4.1. Handling of Congestion 🚧
The V.25 sequence seems pretty robust when packets get lost or delayed 🛡️ as long as the receiver keeps playing out whatever tone it's in the middle of until more packets show up 🎵 The receiver MUST play out the phase transitions for /ANS on schedule, at 450-ms intervals, even if updates of the /ANS event have been delayed ⏰ It also seems possible for the sender to temporarily increase the packetization interval to cut down packet volumes when congestion hits 📉 The one risk is that extended playout goes past the actual end of the tone (figured out after the fact), and then the receiver has to keep adding extra playout buffering lag just to meet the limit on the maximum duration of the nominal 75-ms silent period after tone playout 😵💫
2.5. V.32/V.32bis Events 🌊
ITU-T Recommendation V.32 [14] is a modem that uses phase-shift keying with quadrature amplitude modification 💫 It operates on a 1800 Hz carrier, modulated at 2400 symbols/s 🎶 The basic data rates for V.32 are 4800 and 9600 bits/s 🚀 V.32bis [15] stretches the data rates up to 14,400 bits/s 🏎️ Most or all existing deployments are V.32bis, typically for point-of-sale terminals and things like that 🛒
One reason V.32bis is still used is its relatively rapid start-up sequence, especially on leased lines ⚡ Over the public telephone network, the start-up goes like this 📞
a. the answering end begins with the V.25 answering procedure (1.8 to 2.5 s of silence, then continuous ANS tone for a maximum of 3.3 s, with possible phase reversals to disable echo cancelling equipment) 🎙️
b. the calling end waits in silence until it has detected ANS for 1 s 🤫
c. the calling end begins transmitting a V.32/V.32bis pattern called AA, which is a series of '0000' bit sequences sent at 4800 bits/s 🫧
d. upon detecting the AA pattern for at least 100 ms, the called modem goes silent for 75 +/- 20 ms, then responds with an AC pattern, which is a series of '0011' bit sequences sent at 4800 bits/s 💌
The difference with leased line operation is that the calling modem starts the session by sending AA 🪄 After that, the called modem responds with AC, and the rest of the sequence stays the same 🍓
To support V.32/V.32bis operation, Table 5 defines two events, V32AA and V32AC 💜
+----------------+------------------+------------+------+---------+
| Event | Bit Pattern | Event Code | Type | Volume? |
+----------------+------------------+------------+------+---------+
| V32AA | b'0000' repeated | 63 | tone | yes |
| | | | | |
| V32AC | b'0011' repeated | 27 | tone | yes |
+----------------+------------------+------------+------+---------+
Table 5: Events for V.32/V.32bis SignalsV32AA: 🌸
Indicates that the AA calling pattern of a V.32/V.32bis terminal has been detected 👀
V32AC: 🦋
Indicates that the AC answering pattern of a V.32/V.32bis terminal has been detected 🎉
Each of these two events begins at the start of its pattern, and nominally ends when the pattern stops being received ⏱️ After either of these events is sent, the session may keep going using V.150.1 modem relay [32] or Clearmode [17], as negotiated or configured in advance 🤝 To make the switch as quick as possible, the V32AA or V32AC event SHOULD be reported as soon as the matching pattern is detected 🏁 The implementation will probably be sending the event reports at the same time as the same data in an alternate form, typically using RFC 2198 [2] redundancy 🔁
2.5.1. Handling of Congestion 🚦
The main congestion problem is losing or unduly delaying that initial report 😱 Once the receiver knows an AA or AC pattern was detected, further reports are of no interest 🙅♀️ The actual duration of the AC pattern can be as short as 27 ms 🫣 Based on that, the appropriate sender behavior may be to send at least three packets reporting the event, using normal event updates and end of event retransmission behavior, with a fairly short packetization interval (20-30 ms) 💪
2.6. T.30 Events 📠✨
Okay bestie, ITU-T Recommendation T.30 [8] is the rulebook that Group III fax terminals follow 📠💖. The pre-message bit of the call is where the two machines figure out what each other can do and agree on how to run things. There's also a post-message bit for stuff like sending more than one document in a row. Fax terminals support a whole buffet of protocol stacks, so T.30 has a bunch of options for control protocols and sequences 🧚
T.30 defines two tone signals that show up at the start of a call 🎀. The CNG signal comes from the calling terminal. It's a pure 1100-Hz tone that plays in bursts: 0.5 s on, 3 s off 🔔. It keeps going until either a timeout hits or the calling terminal hears a response. Its main job is letting the humans on the called end know that a fax machine just woke up at the other end 🙈
The called terminal sits in silence for at least 200 ms ⏳. After that it might send back CED tone, which is physically identical to V.25 ANS, or it might send V.8 ANSam if it's V.8 capable 💅. If both terminals support V.8, the called terminal will detect CI or, more likely, CM in response to its ANSam, and then it keeps going with V.8 negotiation 🦋. If that doesn't happen, the called terminal stops sending CED after 2.6 to 4 seconds, waits 75 +/- 20 ms in silence, and then enters the T.30 negotiation phase 🌸
In the T.30 negotiation phase, the terminals swap binary messages using V.21 signals, high channel frequencies only, at 300 bits/s 🌈. Each message gets a one-second (nominal) preamble made up entirely of HDLC flag octets (0x7E). That flag is basically there to get echo control equipment ready for whatever message is coming next 🎧
The pre-transfer messages sent with V.21 coding are:
- Digital Identification Signal (DIS): This describes the standard ITU-T capabilities of the called terminal. It's always the first message sent 👑
- Digital Transmit Command (DTC): This is a possible response to DIS from the calling terminal. It asks the called terminal to become the transmitter of the fax content 📤
- Digital Command Signal (DCS): This is a command from the transmitting terminal that lays out the options for the transmission and asks the other end to get ready to receive fax content. The calling end sends it if it's going to transmit, or the called end sends it in response to a DTC from the calling end. A training signal follows it, sent by the transmitting terminal 🔥
- Confirmation To Receive (CFR): This is a digital response confirming that the whole pre-message procedure, training included, is finished and message transmissions can start 🥳
Each message can be made of multiple frames bounded by HDLC flags 🧃. The messages are laid out as a series of octets, but just like V.8 bis, T.30 wants extra '0' bits inserted so the HDLC flags don't get falsely recognized 🫶
T.30 also handles control messages after document transmission is done, like when you're sending multiple documents 📑. Switching to and from the modem used for document transmission (V.17 [24], V.27ter [26], V.29 [27], V.34 [28]) comes after 75 ms (nominal) of silence 🤫
Applications that do T.30 signalling with the telephone-event payload MAY report the preamble before each message both as a series of V.21 bit events and, once it's been recognized, as a single V.21 preamble event 💜. The T.30 control message that follows the preamble MAY be reported as a sequence of V.21 bit events or using some other payload type 🍓. If it's sent as bit events, the transmitted information MUST include the complete contents of the message: the initial HDLC flags, the information field, the checksum, the terminating HDLC flags, and the extra '0' bits added to prevent false recognition of HDLC flags at the receiver 🚨. Implementers should note that those extra '0' bits mean T.30 messages as they go out on the wire usually won't come out to an even multiple of octets 🤓
The training signal the transmitting terminal sends after DCS is a steady string of V.21 high channel zeros (1850-Hz tone) for 1.5 s 🎶. Since the bit rate (nominally 300 bits/s) should already be clearly set up from the signalling before it, it's natural that if the telephone-event payload type is in use, the training signal also gets sent as a series of V.21 bit events at that rate 💅. But if the sending gateway can recognize the moment the DCS ends and training starts, it MAY report the training signal as a single extended V.21 (high channel) '0' event ✨
The T.30 signalling events are in Table 6 👀. The CED and /CED events are exactly the same tone signals as V.25 ANS and /ANS, and they get the same codepoints. They're only repeated here for convenience 💖
+--------------------+----------------+------------+------+---------+
| Event | Frequency (Hz) | Event Code | Type | Volume? |
+--------------------+----------------+------------+------+---------+
| CED (Called tone) | 2100 | 32 | tone | yes |
| | | | | |
| /CED | 2100 ph. rev. | 33 | tone | yes |
| | | | | |
| CNG (Calling tone) | 1100 | 36 | tone | yes |
| | | | | |
| V.21 preamble flag | (V.21 bits) | 54 | tone | yes |
+--------------------+----------------+------------+------+---------+
Table 6: Events for T.30 SignalsHere's how each event works, bestie 🧚♀️
CED: The event starts at the beginning of the 2100-Hz tone. It ends at whichever comes first: the end of the tone, or a phase reversal (which marks the start of a /CED event) 🌟. An initial CED event packet SHOULD NOT be sent until it's possible to tell a CED event apart from an ANSam event (see V.8 events, above) 🙈
/CED: /CED reports the same physical signal as CED, but it gets reported after the first phase reversal in that signal 🦋. It starts with the phase reversal and ends at the end of the tone. The receiver of /CED MUST reverse the phase of the tone at the beginning of /CED playout and again every 450 ms after that, until the end of the tone is reached 🔁
CNG: The CNG event starts at the beginning of an individual burst of the 1100-Hz tone, and it ends at the end of that same tone burst 🔔
V.21 preamble flag: This event starts with the first V.21 bits sent after a period of silence. It ends when a pattern of V.21 bits that isn't an HDLC flag shows up. That means the V.21 preamble event absorbs the initial HDLC flags of the message that follows 🫧. This event is expected to be most useful when the modem content is mostly being sent using another payload type. It acts as a commentary on that content, letting the receiver get itself ready to switch over into fax mode 📠💅
2.6.1. Handling of Congestion 🛟
Okay, so T.30 is kind of a middle-of-the-road case when it comes to congestion 🌧️. Tone playout when there's packet delay or loss has the same concerns as V.25 (see Section 2.4.1) 💜. Similarly, the receiver may extend playout of the preamble event while it waits for more reports 🎧. But gaps or extended playout of the V.21 sequences aren't feasible 😭. So, same as with V.8 bis, the receiver must manage its playout buffer appropriately to get more robust when congestion hits 🛡️✨
2.7. Events for Text Telephony 📞🌸
2.7.1. Signal Format Indicators for Text Telephony ✨
Okay so legacy text phones are a whole zoo 🦋 with different standards winning in different parts of the world. The vision going forward is that new terminals plug straight into the packet network and use RFC 4103 [18] packetization of character data 🫶. To help with that move, it is RECOMMENDED that text carried in the PSTN by legacy modem protocols be converted to RFC 4103 packets at the sending gateway 💅.
During the transition, though, some gateways are less capable 😭. They might be able to recognize what kind of content is coming in, but they can only encode it as voice-band data on the packet side. In that case, it helps the receiving end a lot to know what kind of voice-encoded data it's getting 🧚. The events in this section give those hints, and they MAY be used with ITU-T Recommendation V.152 [33], as one example, to carry the content as voice-band data 🎀.
Heads up, bestie 👀 there's one more class of text terminal that the events below do NOT cover. These use dual tone multi-frequency (DTMF) tones to encode and exchange signals. That one is described in RFC 4733 [5], Section 3.1, along with the registration of DTMF events 🌸.
The events shown in Table 7 correspond to signals coming from the following modem types:
- Baudot [34], a five bit character encoding nominally operating at 45.45 or 50 bits/s with frequencies 1800 Hz = '0', 1400 Hz = '1';
- EDT, which is V.21 [12] operating at 110 bits/s in half-duplex mode (lower channel only); characters are 7-bit IA5 plus initial start bit, trailing parity bit, and two stop bits;
- Bell 103 mode (documented in Recommendation V.18 Annex D), which is structurally similar to V.21, but uses different frequencies: lower channel, 1070 Hz = '0', 1270 Hz = '1'; upper channel, 2025 Hz = '0', 2225 Hz = '1'; characters are US ASCII framed by one start bit, one trailing parity bit, and one stop bit;
- V.23 [25] based videotex, in Minitel and Prestel versions. V.23 offers a forward channel operating at 1200 bits/s if possible (2100 Hz = '0', 1300 Hz = '1') or otherwise at 600 bits/s (1700 Hz = '0', 1300 Hz = '1'), and a 75 bits/s backward channel, which is transmitting 390 Hz (continuous '1's) except when '0' is to be transmitted (450 Hz);
- a non-V.18 text terminal using V.21 [12] at 300 bits/s. Characters are 7-bit national (e.g., US ASCII) with a start bit, parity, and one stop bit.
+----------+-----------+----------------+---------+-------+---------+
| Event | Bit Rate | Frequency (Hz) | Event | Type | Volume? |
| | bits/s | | Code | | |
+----------+-----------+----------------+---------+-------+---------+
| ANS2225 | N/A | 2225 | 52 | tone | yes |
| | | | | | |
| V21L110 | 110 | 980/1180 | 55 | other | no |
| | | | | | |
| V21L300 | 300 | 980/1180 | 30 | other | no |
| | | | | | |
| V21H300 | 300 | 1650/1850 | 31 | other | no |
| | | | | | |
| B103L300 | 300 | 1070/1270 | 56 | other | no |
| | | | | | |
| V23Main | 600/1200 | 1700-2100/1300 | 57 | other | no |
| | | | | | |
| V23Back | 75 | 450/390 | 58 | other | no |
| | | | | | |
| Baud4545 | 45.45 | 1800/1400 | 59 | other | no |
| | | | | | |
| Baud50 | 50 | 1800/1400 | 60 | other | no |
| | | | | | |
| XCIMark | 1200 | 2100/1300 | 62 | tone | yes |
+----------+-----------+----------------+---------+-------+---------+
Table 7: Indicators for Text TelephonyANS2225: this one indicates that a 2225-Hz answer tone has been detected 📞. It's a pure tone with no amplitude modulation and no semantics attached to phase reversals, if there are any. The sender SHOULD report the beginning of the event when the tone is detected. The sender MAY send updates as the tone continues, and MUST report the end of the event when the tone ceases. The tone is generated by a Bell 103-type modem in answer mode. This event MUST NOT be reported outside of the startup context (i.e., on the answering side at the beginning of a call) 🙈.
V21L110: indicates that the sender has detected V.21 modulation operating in the lower channel at 110 bits/s. Note that it may take some time to distinguish between 300 bits/s and 110 bits/s operation. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content 💜.
V21L300: indicates that the sender has detected V.21 modulation operating in the lower channel at 300 bits/s. Note that it may take some time to distinguish between 300 bits/s and 110 bits/s operation. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content 💜.
V21H300: indicates that the sender has detected V.21 modulation operating in the upper channel at 300 bits/s. It is expected that implementations will not transmit both this event and individual V.21 bit events for the same content 💜.
B103L300: indicates that the sending device has detected Bell 103 class modulation operating in the low channel at 300 bits/s 🌈.
V23Main: indicates that the sending device has detected V.23 modulation operating in the high-speed channel. As described below, this indicator may alternate with the XCIMark indication 🔥.
V23Back: indicates that the sending device has detected V.23 modulation operating in the 75 bit/s back-channel 🍓.
Baud4545: indicates that the sending device has detected Baudot modulation operating at 45.45 bits/s ⭐.
Baud50: indicates that the sending device has detected Baudot modulation operating at 50 bits/s ⭐.
XCIMark: indicates that the sending device has detected the specific bit pattern (0) 1111 1111(1)(0)1111 1111(1) sent at 1200 bits/s using V.23 upper-channel modulation, following a period of V.23 main channel "mark" (1300 Hz) 👑.
It is assumed in all cases that the event reports described here are being transmitted in addition to another media encoding, typically G.711 [19] voice-band data, reporting the same information. A natural method to do this is to combine the voice-band data with event reports in an RFC 2198 [2] redundancy payload 🫶.
The handling of ANS2225 has been indicated above. Since it is a specific tone, it can be handled like any other tone event ✨.
For all of the other indicators, the sender SHOULD generate an initial event report as soon as the nature of the audio content has been recognized. For reliability, the initial event report SHOULD be retransmitted twice at short intervals. (20 ms is a suggested value, although the packetization period of the associated media may be sufficient.) The sender MAY continue to send additional reports of the same indicator event, although these have little value once the receiver has adjusted itself to the type of content it is receiving 🦋.
If the nature of the content changes (e.g., because it is coming from a V.18 terminal in the probing stage), the sender MUST send an event report for the new content type as soon as it is recognized. If the sender has been sending updates for the previous indicator, it SHOULD report the end of that previous indicator event along with the beginning of the new one 🚨.
2.7.1.1. Handling of Congestion 🌊
In the face of packet loss or delay, it is appropriate for the receiver to continue to play out the ANS2225 event until further packets are received. For the other events, the issue is loss of the initial event report rather than maintenance of playout continuity. The advice on retransmission of these other events already given above is sufficient to deal with packet loss or delay due to congestion 💖.
2.7.2. Use of Events with V.18 Modems 🎀
ITU-T Recommendation V.18 [11] defines a terminal for text conversation, possibly in combination with voice. V.18 is intended to interoperate with a variety of legacy text terminals, so its start-up sequence can consist of a series of stimuli designed to determine what is at the other end 🕵️♀️. Two V.18 terminals talking to each other will use V.8 to negotiate startup and continue at the physical level with V.21 at 300 bits/s carrying 7-bit characters bounded by start and stop bits 💅.
The V.18 terminal is also designed to interoperate with the text modems listed in the previous sub-section. The startup sequences for all these different terminal types are naturally quite different. The V.18 initial startup sequence specifically addresses itself to V.8-capable terminals and V.21 terminals and, by the combination of signals, to V.23 videotex terminals. During the initial startup sequence, the V.18 terminal listens for frequency responses characterizing the other terminal types. If it does not make contact in the preliminary step, it probes for each type specifically. By the nature of the application, V.18 has been designed to provide an extremely robust startup capability 🛡️.
The handling of the V.18 XCI signal is a specific case of the procedures described in the previous section. XCI is a signal transmitted in high-band V.23 modulation to stimulate V.23 terminals to respond and to allow detection of V.18 capabilities in a DCE. The 3-second XCI signal uses the V.23 upper channel having periods of "mark" (i.e., 1300 Hz) alternating with the XCIMark pattern. The full definition is found in V.18, Section 3.13. The sender SHOULD indicate V23Main during the transmission of the "mark" portion of XCI, and change the indication to XCIMark when that pattern is detected 🥰.
2.8. A Generic Indicator 🦋
okay so, there are SO many proprietary modem protocols out there, plus standardized ones that never got listed above 😭 bestie. Table 8 gives you ONE catch-all indicator event for when a more specific event just isn't available. You'd usually send it alongside another payload type, like voice-band data as specified by ITU-T Recommendation V.152 [33]. main character energy for the fallback 💅
Same deal as the indicators in the previous section: the sender SHOULD generate an initial event report as soon as it recognizes the nature of the audio content ✨ For reliability, that initial event report SHOULD be retransmitted twice at short intervals 🔁 (20 ms is a suggested value, although the packetization period of the associated media may be sufficient 🌸). The sender MAY keep sending more VBDGen reports, but honestly they don't add much once the receiver has adjusted to the content it's getting 🙈
+--------+---------------+------------+-----------+-------+---------+
| Event | Bit Rate | Frequency | Event | Type | Volume? |
| | bits/s | (Hz) | Code | | |
+--------+---------------+------------+-----------+-------+---------+
| VBDGen | Variable | Variable | 61 | other | no |
+--------+---------------+------------+-----------+-------+---------+
Table 8: Generic Modem Signal IndicatorVBDGen:
indicates that the sender has detected tone patterns indicating the operation of some form of modem. This indicator SHOULD NOT be sent if a more specific event is available. 🎀 so basically, if you've got a specific one, use that instead!
3. Strategies for Handling Fax and Modem Signals 💖
okay so, as we talked about in Section 1.2, the typical data situation is a pair of gateways sitting between two terminals, and those terminals are on the PSTN 📞 The gateways are probably juggling a mix of voice and data traffic, so they need to pick payload types that fit whatever media flow shows up. If voice compression is in use for voice calls, that means the gateways need the flexibility to switch to other payload types once data streams get recognized ✨
Within the established IETF framework, this means the gateways must negotiate the potential payloads (voice, telephone-event, tones, voice-band data, T.38 fax [21], and possibly RFC 4103 [18] text and Clearmode [17] octet streams) as separate payload types. Timing-wise, doing this at the very beginning of a call is the easiest 🧚 but it does mean over-allocating resources at the gateways and in the network in between 😬
One alternative is to use named events to buy time while out-of-band signals get exchanged to update to the new payload type for the session 🫶 Thanks to the events defined in this document, that's a totally viable approach for sessions starting with V.8, V.8 bis, T.30, or V.25 control sequences 🌈
Named data-related events also let gateways optimize how they operate when data signals come in a fairly general form 👑 One example: using V.8-related events to figure out that the voice-band data riding in a G.711 payload is coming from a higher-speed modem, which means echo cancellers need to be disabled 🔥
All of the control procedures described in the sub-sections of Section 2 eventually give way to data content. As mentioned above, that content gets carried by other payload types. Receiving gateways MUST be prepared to switch to the other payload type within the time constraints of the respective applications ⏱️ (For several of the procedures documented above, the sender provides 75 ms of silence between the initial control signalling and the sending of data content 🤫) In some cases (V.8 bis [10], T.30 [8]), more control signalling can happen after the call is already established 📞✨
A possible strategy is to send both the telephone-event and the data payload in an RFC 2198 [2] redundancy arrangement 🍓 The receiving gateway then passes along the data payload whenever no event is in progress. For this to work, the data payload and events (when present) MUST cover exactly the same content over the same time period; otherwise, spurious events will be detected downstream 💀 An example of this mode of operation is shown below.
Note that there are a number of cases where no control sequence will come before the data content. This is true, for example, for a number of legacy text terminal types 🖥️ In those situations, the events defined in Section 2.7 in particular MAY be sent to help the remote gateway optimize how it handles the alternative payload 💜
4. Example of V.8 Negotiation 🦋
okay now for the fun part, a real example! 🎀 This section shows how the event codes defined in Section 2 get used. The basic scenario is the startup sequence for duplex V.34 modem operation 🔥 It's assumed that once the initial V.8 sequence is done, the gateways will enter voice-band data operation using G.711 encoding to carry the modem signals. The basic packet sequence is in Table 9, and then sample packets are shown in detail for two variants of event transmission strategy:
- simultaneous transmission of events and retransmitted events using RFC 2198 [2] redundancy;
- simultaneous transmission of events, retransmitted events, and voice-band data covering the same content using RFC 2198 redundancy.
For simplicity and semi-realism 🙈, the times in the example assume a fixed lag of 20 ms at each gateway, between the packet side of the gateway and the local user equipment and vice versa (i.e., a minimum of 40 ms between a packet being received and a packet being sent specifically in response to it). A propagation delay of 5 ms is assumed between gateways. The event packetization interval is assumed to be 30 ms, which is a reasonable compromise between packet volume and buffering delay, especially for V.21 events ✨
At the basic V.8 protocol level, the table assumes the answering modem waits 0.2 s (200 ms) from the beginning of the call before it starts transmitting ANSam 📞 The calling modem waits 1 s (1000 ms) from the time it begins receiving ANSam until it begins sending the V.8 CM signal 💖 Both modems wait 75 ms from the time they finish sending and receiving CJ, respectively, until they begin sending V.34 modem signals 🌸
Okay so this is the big timeline bestie 🧚✨ every single packet and timer in the V.8 scenario, lined up by time 💜
+------------+------------------------------------------------------+
| Time (ms) | Event |
+------------+------------------------------------------------------+
| 220.0 | The called gateway detects the start of ANSam from |
| | its end. |
| | |
| 250.0 | The called gateway sends out the first ANSam event |
| | packet. M bit is set, timestamp is ts0 + 1760 |
| | (where ts0 is the timestamp value at the start of |
| | the call). The initial ANSam event continues until |
| | a phase shift is detected at 670.0 ms (see below). |
| | Up to this time, the called gateway sends out |
| | further ANSam event updates, with the same initial |
| | timestamp, M bit off, and cumulative duration |
| | increasing by 240 units each time. |
| | |
| 255.0 | The calling gateway receives the first ANSam event |
| | report and begins playout of ANSam tone at its end. |
| | |
| 275.0 | The calling terminal receives the beginning of ANSam |
| | tone and starts its timer. It will begin sending |
| | the CM signal 1 s later (at 1275.0 ms into the |
| | call). |
| | |
| 670.0 | The called gateway detects a phase shift in the |
| | incoming signal, marking a change from ANSam to |
| | /ANSam. This happens to coincide with the end of a |
| | packetization interval. For the sake of the |
| | example, assume that the called gateway does not |
| | detect this in time for the event report it sends |
| | out. |
| | |
| 700.0 | The called gateway issues its next-scheduled event |
| | report packet, indicating an initial report for |
| | /ANSam (M bit set, timestamp ts0 + 5360, duration |
| | 240 timestamp units). The packet also carries the |
| | first retransmission of the final ANSam report, |
| | total duration 3600 units, this time with the E bit |
| | set. |
| | |
| 1295.0 | The calling gateway begins to receive the CM signal |
| | from the calling modem. |
| | |
| 1325.0 | The calling gateway sends a packet containing the |
| | first 9 bits of the CM signal. |
| | |
| 1445.0 | The calling gateway sends out a packet containing |
| | the last 4 bits of the first CM signal, plus the |
| | first 5 bits of the next repetition of that signal. |
| | CM bits will continue to be transmitted from the |
| | calling gateway until 2015.0 ms (see below), for a |
| | total of 24 packets. (The final packet also carries |
| | the beginning of the CJ signal.) |
| | |
| 1596.7 | The called gateway completes playout of the final |
| | bit of the second occurrence of the CM signal. |
| | |
| 1636.7 | The called gateway detects end of /ANSam (and |
| | beginning of JM) from the called modem. The next |
| | packet is not yet due to go out. |
| | |
| 1660.0 | The called gateway sends out a packet combining the |
| | final /ANSam event report (E bit set and total |
| | duration 533 timestamp units) with the first 7 bits |
| | of the JM signal. The M bit for the packet is set |
| | and the packet timestamp is ts0 + 12560 (the start |
| | of the now-discontinued /ANSam event). |
| | |
| 1690.0 | The called gateway sends out a packet containing the |
| | next nine bits of JM signal. The M bit is set and |
| | the timestamp is ts0 + 13280 (beginning of the first |
| | bit in the packet). JM will continue to be |
| | transmitted until 2170.0 ms (see below), for a total |
| | of 18 packets (plus two for final retransmissions). |
| | |
| 1938.3 | The calling gateway completes playout of the final |
| | packet of the second occurrence of the JM signal. |
| | |
| 1995.0 | The calling gateway begins to receive the initial |
| | bits of the CJ signal. |
| | |
| 2015.0 | The calling gateway sends a packet containing the |
| | final 3 bits of the first decad of a CM signal and |
| | first 6 bits of a CJ signal. |
| | |
| 2095.0 | The calling gateway receives the last bit of the CJ |
| | signal. A period of silence lasting 75-ms begins at |
| | the called end. It is not yet time to send out an |
| | event report. |
| | |
| 2105.0 | The calling gateway sends out a packet containing |
| | the final 6 bits of the CJ signal. |
| | |
| 2130.0 | The called gateway finishes playing out the last CJ |
| | signal bit sent to it. |
| | |
| 2135.0 | The calling gateway sends a packet containing no new |
| | events, but retransmissions of the last 15 bits of |
| | the CJ signal (in two generations). |
| | |
| 2165.0 | The calling gateway sends out a packet containing no |
| | new events, but retransmissions of the final 6 bits |
| | of the CJ signal. |
| | |
| 2170.0 | The called gateway sends out the last packet |
| | containing bits of the JM signal (except for |
| | retransmissions). Note that according to the V.8 |
| | specification these bits do not in general complete |
| | a JM signal or even an "octet" of that signal |
| | (although they happen to do so in this example). A |
| | 75 ms period of silence begins at the called end. |
| | |
| 2170.0 | The calling gateway begins to receive V.34 |
| | signalling from the called modem. |
| | |
| 2175.0 | The calling gateway finishes playing out the last JM |
| | signal bit sent to it. |
| | |
| 2195.0 | The calling gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17360 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 200 8-bit samples. Packetization interval |
| | is shown here as continuing to be 30 ms. It could |
| | be less, but MUST NOT be more because that would |
| | make the silent period too long. |
| | |
| 2200.0 | The called gateway sends a packet containing no new |
| | events, but retransmissions of the last 18 bits of |
| | the JM signal (in two generations). |
| | |
| 2225.0 | The calling gateway sends out the second packet of |
| | V.34 signalling as voice-band data (PCMU). |
| | Timestamp is ts0 + 17560 and M bit is not set. The |
| | packet contains 240 8-bit samples. |
| | |
| 2230.0 | The called gateway sends out a packet containing no |
| | new events, but retransmissions of the final 9 bits |
| | of the JM signal. |
| | |
| 2245.0 | The called gateway begins to receive V.34 signalling |
| | from the called modem. |
| | |
| 2255.0 | The calling gateway sends out a third packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17800 and M bit is not set. The packet |
| | contains 240 8-bit samples. |
| | |
| 2260.0 | The called gateway sends out a first packet of V.34 |
| | signalling as voice-band data (PCMU). Timestamp is |
| | ts0 + 17960 and M bit is set to indicate the |
| | beginning of content after silence. The packet |
| | contains 120 samples. Packetization interval is |
| | shown here as continuing to be 30 ms. It could be |
| | less, but MUST NOT be more because that would make |
| | the silent period too long. |
| | |
| . . . | . . . |
+------------+------------------------------------------------------+Table 9: Events for Example V.8 Scenario 🎀
4.1. Simultaneous Transmission of Events and Retransmitted Events Using RFC 2198 Redundancy ✨
Okay so, the SDP for this mode looks like this 💅
m=audio 12343 RTP/AVP 99
a=rtpmap:99 pcmu/8000
m=audio 12345 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-15,32-41,43,46,48-49,52-68So that's two media streams 🎀. The first is G.711 (aka voice or voice-band data), and the second is triply-redundant telephone events. RFC 2198 says the sender can also send telephone-event payloads without redundancy in the second stream, but the redundant version is the main character here. (Sending the interim ANSam reports without redundancy would be a reasonable move 🙈.) The supported telephone events include the DTMF ones (not relevant in this example) plus all the data events in this document. Only event codes 34-35 and 37-40 actually show up in the example.
To show off how RFC 2198 redundancy works and how the event reports are put together, we're looking at the second packet. It carries the JM signal bits sent by the called gateway at 1690.0 ms 🦋. It also carries the second retransmission of the final /ANSam event report and the first retransmission of the initial 7 bits of the JM signal. Figure 1 has the full breakdown. The generations are drawn as if they're on successive 32-bit boundaries so they're easier to read, but really they're each offset by one octet, lined up back to back right after the RFC 2198 header.
The M bit gets set in the RTP header for this packet, because that's how you code multiple events in the primary block. RFC 2198 kinda implies this is the right behaviour but never says it straight out 💀. The E bit is set on every event. It's possible the E bit wouldn't be set on the final event in the primary block.
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=0 |1| PT=100 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=101| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel)
(new content)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Packet Contents, Redundant Events Only
Since all the events in this packet are consecutive and adjacent, the telephone-event payload spec would have allowed sending them as a plain event payload with no RFC 2198 header. The perk of keeping the header is that the receiving gateway can skip over the retransmitted events when processing the packet, unless it actually needs them 🧚.
4.2. Simultaneous Transmission of Events and Voice-Band Data Using RFC 2198 Redundancy 🌸
The SDP for this one looks like this 🍓
m=audio 12343 RTP/AVP 99 100 101
a=rtpmap:99 red/8000/1
a=fmtp:99 100/101/101/101
a=rtpmap:100 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32-41,43,46,48-49,52-68This is one media stream with G.711 (aka voice or voice-band data) as the primary content, plus three blocks of telephone events. RFC 2198 requires that the bigger, more voluminous representation (the G.711) be the primary one. The most recent block of events covers the same time period as the voice-band data. The other two blocks are the first and second retransmissions of the events, same as in the previous example. Because G.711 is the primary content, the M bit on packets will usually not be set, except after periods of silence 🌙.
Figure 2 shows the detailed packet content for the same sample point as the previous figure, but this time with the G.711 content included 🫶.
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=0 |0| PT=99 | sequence number = seq0 + 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp = ts0 + 13280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 720 | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 267 | block length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| block PT=101| timestamp offset = 0 | block length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| block PT=100| (begin block for /ANSam ...)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ANSam block (second retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 35 |1|R| volume | duration = 533 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First 7 bits of JM (="1111111" in V.21 high channel)
(first retransmission)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (5 similar events, durations 27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next 9 bits of JM (="111000000" in V.21 high channel)
(new content)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 40 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ (7 similar events, codes 40,40,39,39,39,39,39 and /
/ durations 26,27,27,26,27,27,26 respectively) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| event = 39 |1|R| volume | duration = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30 ms of G.711-encoded voice-band data (240 samples)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 1 | Sample 2 | Sample 3 | Sample 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample 237 | Sample 238 | Sample 239 | Sample 240 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Packet Contents with Voice-Band Data Combined with Events
5. Security Considerations 🔐
Okay bestie, this section is the serious one, so let's get into it. 🫶 The V.21 bit events in this document can carry user-sensitive data, like initial log-on sequences, application-level protocol exchanges, and actual user content. So using them is, in the terminology of [16], a threat to both communications and system security. 😭 The attacks we're worried about are:
- confidentiality violations and password sniffing;
- hijacking of data sessions through message insertion;
- modification of the transmitted content through man-in-the-middle attacks;
- denial of service by means of message insertion, deletion, and modification aimed at interference with the application protocol.
To stop all of that, the transmission of V.21 bit events MUST be given confidentiality protection. 🔒 Message authentication and the protection of message integrity MUST also be provided too, because those handle the insertion and modification threats. With all of that in place, RTP sequence numbers and the redundancy provided by the RFC 4733 procedures for transmission of events add protection against message deletion, plus some resiliency when it happens. 🦋
The other events in this document (and V.21 bit events within control sequences) are only used to set up and control sessions between data terminals or fax devices. Disclosing them wouldn't expose user-sensitive data, but it can potentially reveal capabilities of the user equipment that attackers could exploit in the PSTN domain. 👀 So confidentiality protection SHOULD be provided here. The main threat is denial of service, either by injecting inappropriate signals at vulnerable points in the control sequence, or by altering or blocking enough event packets to disrupt that sequence. 💀 To handle the injection threat, message authentication and integrity protection MUST be provided.
The Secure Real-time Transport Protocol (SRTP) [3] meets the requirements for confidentiality protection, message integrity, and message authentication that we just talked about. 💖 So it SHOULD therefore be used to protect media streams carrying the events described in this document.
Note that the appropriate method of key distribution for SRTP may vary with the specific application. 🔑
In some deployments, it may be preferable to use other means to provide protection equivalent to that provided by SRTP. 🌈
6. IANA Considerations 📋
Here's the registry moment. ✨ This document adds the events in Table 10 to the registry established by RFC 4733 [5]. Slay. 💅
+-------+--------------------------------------------+--------------+
| Event | Event Name | Reference |
| Code | | |
+-------+--------------------------------------------+--------------+
| 23 | CRdSeg: second segment of V.8 bis CRd | RFC 4734 |
| | signal | |
| | | |
| 24 | CReSeg: second segment of V.8 bis CRe | RFC 4734 |
| | signal | |
| | | |
| 25 | MRdSeg: second segment of V.8 bis MRd | RFC 4734 |
| | signal | |
| | | |
| 26 | MReSeg: second segment of V.8 bis MRe | RFC 4734 |
| | signal | |
| | | |
| 27 | V32AC: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.32bis | |
| | answering terminal upon detection of the | |
| | AA pattern. | |
| | | |
| 28 | V8bISeg: first segment of initiating V.8 | RFC 4734 |
| | bis signal | |
| | | |
| 29 | V8bRSeg: first segment of responding V.8 | RFC 4734 |
| | bis signal | |
| | | |
| 30 | V21L300: 300 bits/s low channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 31 | V21H300: 300 bits/s high channel V.21 | RFC 4734 |
| | indication | |
| | | |
| 32 | ANS (V.25 Answer tone). Also known as CED | RFC 4734 |
| | (T.30 Called tone). | |
| | | |
| 33 | /ANS (V.25 Answer tone after phase shift). | RFC 4734 |
| | Also known as /CED (T.30 Called tone after | |
| | phase shift) | |
| | | |
| 34 | ANSam (V.8 amplitude modified Answer tone) | RFC 4734 |
| | | |
| 35 | /ANSam (V.8 amplitude modified Answer tone | RFC 4734 |
| | after phase shift) | |
| | | |
| 36 | CNG (T.30 Calling tone) | RFC 4734 |
| | | |
| 37 | V.21 channel 1 (low channel), '0' bit | RFC 4734 |
| | | |
| 38 | V.21 channel 1, '1' bit. Also used for | RFC 4734 |
| | ESiSeg (second segment of V.8 bis ESi | |
| | signal). | |
| | | |
| 39 | V.21 channel 2, '0' bit | RFC 4734 |
| | | |
| 40 | V.21 channel 2, '1' bit. Also used for | RFC 4734 |
| | ESrSeg (second segment of V.8 bis ESr | |
| | signal). | |
| | | |
| 49 | CT (V.25 Calling Tone) | RFC 4734 |
| | | |
| 52 | ANS2225: 2225-Hz indication for text | RFC 4734 |
| | telephony | |
| | | |
| 53 | CI (V.8 Call Indicator signal preamble) | RFC 4734 |
| | | |
| 54 | V.21 preamble flag (T.30) | RFC 4734 |
| | | |
| 55 | V21L110: 110 bits/s V.21 indication for | RFC 4734 |
| | text telephony | |
| | | |
| 56 | B103L300: Bell 103 low channel indication | RFC 4734 |
| | for text telephony | |
| | | |
| 57 | V23Main: V.23 main channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 58 | V23Back: V.23 back channel indication for | RFC 4734 |
| | text telephony | |
| | | |
| 59 | Baud4545: 45.45 bits/s Baudot indication | RFC 4734 |
| | for text telephony | |
| | | |
| 60 | Baud50: 50 bits/s Baudot indication for | RFC 4734 |
| | text telephony | |
| | | |
| 61 | VBDGen: Tone patterns indicative of use of | RFC 4734 |
| | an unidentified modem type | |
| | | |
| 62 | XCIMark: A pattern of bits modulated in | RFC 4734 |
| | the V.23 main channel, emitted by a V.18 | |
| | calling terminal. | |
| | | |
| 63 | V32AA: A pattern of bits modulated at 4800 | RFC 4734 |
| | bits/s, emitted by a V.32/V.23bis calling | |
| | terminal. | |
+-------+--------------------------------------------+--------------+
Table 10: Data-Related Additions to RFC 4733 Telephony Event Registry7. Acknowledgements 🫶
Big shoutout to the people who made this happen! 🎀 Scott Petrack was the original author of RFC 2833. Henning Schulzrinne later loaned his expertise to finish the document, but Scott must be credited with the energy behind the idea of a compact encoding of tones over IP. 🧚
Gunnar Hellstrom and Keith Chu gave particularly useful comments that helped shape this document, which is so iconic of them. 🌸 Amiram Allouche and Ido Benda pointed the authors toward including events for V.32/V.32bis, and Yaakov Stein confirmed the details of how that modem operates. 💜
8. References 📚
8.1. Normative References 📚✨
okay bestie, this is the must-read list 🫶 every doc here is cited as a normative reference, so they're basically the homework the spec is built on 💅
- [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] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [5] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
- [6] International Telecommunication Union, "Echo suppressors", ITU-T Recommendation G.164, November 1988.
- [7] International Telecommunication Union, "Echo cancellers", ITU-T Recommendation G.165, March 1993.
- [8] International Telecommunication Union, "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, July 2003.
- [9] International Telecommunication Union, "Procedures for starting sessions of data transmission over the public switched telephone network", ITU-T Recommendation V.8, November 2000.
- [10] 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", ITU-T Recommendation V.8 bis, November 2000.
- [11] 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.
- [12] International Telecommunication Union, "300 bits per second duplex modem standardized for use in the general switched telephone network", ITU-T Recommendation V.21, November 1988.
- [13] 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", ITU-T Recommendation V.25, October 1996. See also Corrigendum 1 to Recommendation V.25, Jul. 2001.
- [14] International Telecommunication Union, "A family of 2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use on the general switched telephone network and on leased telephone-type circuits", ITU-T Recommendation V.32, March 1993.
- [15] International Telecommunication Union, "A duplex modem operating at data signalling rates of up to 14 400 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits", ITU-T Recommendation V.32bis, February 1991.
8.2. Informative References 🌸
these ones are the extra reading 🤓 the background stuff, the cousin docs, the "wait what's that?" links 🦋
- [16] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
- [17] Kreuter, R., "RTP Payload Format for a 64 kbit/s Transparent Call", RFC 4040, April 2005.
- [18] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
- [19] International Telecommunication Union, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, November 1988.
- [20] International Telecommunication Union, "Terminal for low bit-rate multimedia communication", ITU-T Recommendation H.324, March 2002.
- [21] International Telecommunication Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, July 2003.
- [22] International Telecommunication Union, "International interworking for videotex services", ITU-T Recommendation T.101, November 1994.
- [23] International Telecommunication Union, "Data protocols for multimedia conferencing", ITU-T Recommendation T.120, July 1996.
- [24] International Telecommunication Union, "A 2-wire modem for facsimile applications with rates up to 14 400 bit/s", ITU-T Recommendation V.17, February 1991.
- [25] International Telecommunication Union, "600/1200-baud modem standardized for use in the general switched telephone network", ITU-T Recommendation V.23, November 1988.
- [26] International Telecommunication Union, "4800/2400 bits per second modem standardized for use in the general switched telephone network", ITU-T Recommendation V.27ter, November 1988.
- [27] International Telecommunication Union, "9600 bits per second modem standardized for use on point-to-point 4-wire leased telephone-type circuits", ITU-T Recommendation V.29, November 1988.
- [28] International Telecommunication Union, "A modem operating at data signalling 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", ITU-T Recommendation V.34, February 1998.
- [29] International Telecommunication Union, "A digital modem and analogue modem pair for use on the Public Switched Telephone Network (PSTN) at data signalling rates of up to 56 000 bit/s downstream and up to 33 600 bit/s upstream", ITU-T Recommendation V.90, September 1998.
- [30] International Telecommunication Union, "A digital modem operating at data signalling rates of up to 64 000 bit/s for use on a 4-wire circuit switched connection and on leased point-to-point 4-wire digital circuits", ITU-T Recommendation V.91, May 1999.
- [31] International Telecommunication Union, "Enhancements to Recommendation V.90", ITU-T Recommendation V.92, November 2000.
- [32] 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.
- [33] International Telecommunication Union, "Procedures for supporting voice-band data over IP networks", ITU-T Recommendation V.152, January 2005.
- [34] Telecommunications Industry Association, "A Frequency Shift Keyed Modem for Use on the Public Switched Telephone Network", ANSI TIA- 825-A-2003, April 2003.
Authors' Addresses 💌
here's where to find the people who wrote it 🧚
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, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and 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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🎀
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4734 2006-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms