Definition of Events for Modem, Fax, and Text Telephony Signals
obsoletes
- rfc-2833 — RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
updates
- rfc-4733 — RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
Extracted elements (31)
Named modem/fax events allow gateways to avoid pre-negotiating all potential payload types at call setup (which over-allocates resources) by using event reports to buy time while out-of-band signalling updates the active payload type when a data stream is recognized.
Text telephony content is RECOMMENDED to be converted to RFC 4103 character-mode packets at the sending gateway in anticipation of migration away from legacy PSTN modem protocols; signal format indicator events support a transitional period for lesser-capability gateways that can only encode the content as voice-band data.
V.21 event starting times SHOULD be rounded to the nearest whole timestamp unit because at 300 bits/s each bit occupies 3.33 ms = 26.67 timestamp units at 8000 Hz—a non-integer—making exact representation impossible; rounding every third event to 26 units and the rest to 27 maintains monotonicity.
V.21 events are defined per transmitted bit rather than per transition because per-bit reporting increases redundancy—each event completion is retransmitted three times, reducing risk of data corruption in unreliable networks without requiring separate reliability mechanisms.
An initial ANS (V.25) or CED (T.30) event packet SHOULD NOT be sent until it is possible to discriminate it from ANSam (V.8): both use 2100 Hz, but ANSam is amplitude-modulated at 15 Hz whereas ANS/CED has constant amplitude.
CED (T.30) uses event code 32 and /CED uses code 33, identical to V.25 ANS and /ANS, because the underlying 2100-Hz tone signals are physically identical; Table 6 reproduces them solely for convenience.
ESiSeg (code 38) and ESrSeg (code 40) share event codes with V.21 channel-1 '1' bit and channel-2 '1' bit respectively; implementations must use context (whether a V.8 bis signal is expected) to determine the correct interpretation of these shared codepoints.
ANS2225 MUST NOT be reported outside of the startup context (i.e., on the answering side at the beginning of a call), as the 2225-Hz tone is specific to Bell 103-type modems in answer mode.
Implementations MUST be prepared to send and receive data signals using payload types other than telephone-event simultaneously with the use of telephone-event, regardless of which events they support.
Receiving gateways MUST be prepared to switch to the appropriate data payload type within the time constraints of the respective application; for several procedures the sender provides only 75 ms of silence between control signalling and data content.
The CI event MUST NOT be reported except in a context where a V.8 CI signal might be expected, specifically at the calling end during call setup.
The receiver of /ANS MUST reverse the phase of the 2100-Hz tone at the beginning of /ANS playout and every 450 ms thereafter until the end of the tone; the same requirement applies to /CED in T.30 signalling.
The receiver of /ANSam MUST reverse the phase of the tone at the beginning of playout of /ANSam and every 450 ms thereafter until the end of the tone is reached.
The sender SHALL NOT report the V.8 bis 100-ms V.21 marking preamble tone using ESiSeg or ESrSeg events; those events are reserved solely for the second segment of the specific V.8 bis signals to which they pertain.
The VBDGen generic modem content indicator SHOULD NOT be sent if a more specific event (from Tables 2–7) is available to characterize the detected modem signal.
V.21 sending implementations SHOULD report a completed event for every bit transmitted rather than only at transitions, to increase reporting redundancy so each event completion is transmitted three times per RFC 4733 Section 2.5.1.4.
When sending consecutive V.21 bit events across packets, the sending gateway MUST ensure individual event durations do not cause the last event of one packet to overlap with the first event of the next, and MUST derive event durations as successive differences between event starting times.
When T.30 control messages are reported as V.21 bit events, the transmitted information MUST include the complete message: initial HDLC flags, information field, checksum, terminating HDLC flags, and extra '0' bits that prevent false HDLC flag recognition.
When the nature of text telephony content changes (e.g., during V.18 probing), the sender MUST send an event report for the new content type as soon as it is recognized and SHOULD report the end of the previous indicator event.
When transmitting V.8 bis messages as V.21 bit events, the transmitted information MUST include the complete contents: initial HDLC flags, information field, checksum, terminating HDLC flags, and extra '0' bits inserted per V.8 bis clause 7.2.8 to prevent false HDLC flag recognition.
When using RFC 2198 redundancy to carry both telephone-event and data payload simultaneously, the data payload and events MUST cover exactly the same content over the same time period; otherwise spurious events will be detected downstream.
T.30 fax events (Table 6): CED (code 32, 2100 Hz, identical to V.25 ANS), /CED (code 33, identical to V.25 /ANS), CNG calling tone (code 36, 1100 Hz, 0.5 s on / 3 s off bursts), V.21 preamble flag (code 54, begins at first V.21 bits after silence and ends when non-HDLC-flag bits are observed).
Text telephony signal format indicators (Table 7): ANS2225 (code 52, tone), V21L110 (code 55), V21L300 (code 30), V21H300 (code 31), B103L300 (code 56), V23Main (code 57), V23Back (code 58), Baud4545 (code 59), Baud50 (code 60), XCIMark (code 62). These 'other'-type events indicate detected modem encoding; most carry no volume.
The VBDGen generic voice-band data indicator (event code 61, Table 8) is an 'other'-type event with no volume, for use when modem content is detected but no more specific event from Tables 2–7 applies; typically combined with a V.152 voice-band data payload.
V.21 bit events (Table 2): channel 1 '0' bit (code 37, 1180 Hz), channel 1 '1' bit (code 38, 980 Hz), channel 2 '0' bit (code 39, 1850 Hz), channel 2 '1' bit (code 40, 1650 Hz). All tone-type with volume; used to carry V.8, V.8 bis, and T.30 control messages bit-by-bit.
V.25 events (Table 4): ANS answer tone (code 32, 2100 Hz constant amplitude), /ANS (code 33, ANS after first phase reversal), CT calling tone (code 49, 1300 Hz bursts 0.5–0.7 s on and 1.5–2.0 s off). All tone-type with volume.
V.32/V.32bis events (Table 5): V32AA (code 63, repeating '0000' bit pattern at 4800 bits/s) and V32AC (code 27, repeating '0011' bit pattern at 4800 bits/s). Both SHOULD be reported as soon as the pattern is detected to minimize transition time to V.150.1 modem relay.
V.8 bis signal events (Table 1): ESiSeg (code 38, 980 Hz, 100 ms), ESrSeg (code 40, 1650 Hz, 100 ms), CRdSeg (code 23, 1900 Hz), CReSeg (code 24, 400 Hz), MRdSeg (code 25, 1150 Hz), MReSeg (code 26, 650 Hz), V8bISeg (code 28, 1375+2002 Hz, 400 ms dual tone), V8bRSeg (code 29, 1529+2225 Hz, 400 ms dual tone). All tone-type with volume.
V.8 events (Table 3): ANSam (code 34, 2100 Hz AM-modulated at 15 Hz), /ANSam (code 35, same signal reported after first phase reversal), CI (code 53, V.21 bit pattern '11111 11111 00000 00001' marking start of V.8 call indicator). All tone-type with volume.
Section 6 (IANA Considerations) assigns event codes 23–68 for modem, fax, and text telephony signals in the Telephone Event and Separator registry, superseding RFC 2833's assignments for this purpose and updating the registry to reference RFC 4734.
Section 5 addresses security considerations for modem, fax, and text telephony events in the telephone-event RTP payload. The general security framework from RFC 4733 applies; implementations should be aware that unauthorized injection of modem/fax events could disrupt ongoing data sessions or trigger unintended mode transitions.