RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
obsoleted by
Extracted elements (29)
A sender MAY delay setting the E (end) bit until retransmitting the final packet rather than on first transmission, to avoid prematurely signaling end-of-tone before confirming the tone has actually ceased.
Events are transmitted incrementally (before the end is known) rather than waiting for completion because some tones last two seconds; the transmitter does not know whether event length matters to the receiver, so immediate incremental transmission avoids unnecessary delay for both gateway and end-system use cases.
Separate RTP payload formats for DTMF and tones are necessary because low-rate voice codecs (e.g., G.723.1) cannot reliably reproduce tone signals accurately enough for automatic recognition; out-of-band event encoding also permits higher redundancy at lower bit rates.
The T bit in the tone payload allows the modulation frequency to be divided by three, enabling non-integer frequencies such as 16 2/3 Hz and 33 1/3 Hz that derive from older AC power grid frequencies and are in practical use in some telephone networks.
It is RECOMMENDED that gateways render only the encoded tone and discard concurrent audio, because compression artifacts may introduce spurious tones. However, overlap between encoded tone and audio periods must be tolerated at onset.
The named-event and tone payload formats can be combined in a single RTP packet using RFC 2198 redundancy, allowing simultaneous transmission of both representations so receivers can choose the appropriate rendering.
The RFC 2198 redundancy timestamp offset field is 14 bits, covering at most 2.048 seconds of telephone events at 8000 Hz. Redundancy with r=5 copies is suggested; effective overhead is r×1280 bits/second.
A compliant implementation MUST support all events listed in Table 1 (DTMF digits 0–9, *, #, A–D, encodings 0–15) with the exception of the Flash event if an out-of-band signaling mechanism is used instead.
Additional events beyond those defined in this document MUST be registered with IANA and their meaning MUST be documented as an RFC or equivalent standards document from another standardization body such as ITU-T.
An audio source SHOULD start transmitting event packets as soon as an event is recognized and every 50 ms thereafter (or per the codec packet interval). If no new event occurs, the event SHOULD be retransmitted three times to ensure correct duration recognition even if the last packet is lost.
DTMF digits and named telephone events MUST use the same RTP sequence number and timestamp base as the regular audio channel to enable precise audio waveform alignment at gateways.
For ABCD trunk signaling state transitions, implementations SHOULD use a triple-redundancy mechanism: the same ABCD bits are sent 3 times at 5 ms intervals on each transition; after a period of no change, ABCD is sent every 5 seconds.
If a gateway cannot present a tone representation (audio/tone), it SHOULD send the audio tones as regular RTP audio packets (e.g., PCMU) in addition to the named signals.
Regardless of the playout algorithm used, a tone SHOULD NOT be extended by more than three packet interarrival times to prevent a tone from getting stuck when retransmissions of the end packet are all lost.
The reserved R bit in the named event payload MUST be set to zero by the sender and MUST be ignored by the receiver. The same requirement applies to the 4-bit reserved fields flanking each frequency entry in the tone payload.
The RTP marker bit MUST indicate the beginning of a new named telephone event. The timestamp reflects the measurement point for the current packet, with event duration extending forwards.
Country-specific extended line events occupy encodings 96–112 (Table 5), and trunk events occupy 128–173 including MF digits (128–143), ABCD 4-bit signaling states (144–159), Wink (160), seizure/continuity signals (162–173).
Data modem and fax named events occupy encodings 32–49, covering ANS (32), /ANS (33), ANSam (34), /ANSam (35), CNG (36), V.21 channel bits (37–40), and V.8bis signaling tones CRdi/CRdr/CRe/ESi/ESr/MRdi/MRdr/MRe/CT (41–49).
DTMF named events are encoded as decimal integers 0–9 for digits 0–9, 10 for *, 11 for #, 12–15 for A–D, and 16 for Flash. These are carried in the 8-bit event field of the telephone-event payload.
Line events per ITU E.182 occupy encodings 64–89, including Off Hook (64), On Hook (65), dial tones (66–69), ringing and special ringing (70–71), busy/congestion/special information tones (72–74), hold/record/waiting tones (76–79), and Ring (89).
Receiver capabilities for named events are advertised via the SDP 'fmtp' attribute as a comma-separated list of event values or hyphen-delimited ranges (e.g., 'a=fmtp:100 0-15,66,70'). The MIME parameter equivalent is 'events'. Events 0–15 need not be listed as all implementations must support them.
The duration field in both payload formats is a 16-bit unsigned integer measured in RTP timestamp units. At 8000 Hz this allows durations up to approximately 8 seconds. The event begins at the RTP timestamp instant and has lasted for the stated duration.
The payload type for telephone-event and tone has no static RTP payload type number; it MUST be assigned dynamically and out-of-band. The default clock frequency is 8000 Hz but may be redefined when assigning the dynamic payload type.
The volume field in the named event payload encodes the tone power level in dBm0 magnitude (sign dropped), ranging 0 to 63. Valid DTMF range is 0–36 dBm0 (must accept); below -55 dBm0 must be rejected. For non-tone events the field is set to zero and ignored.
This document registers the MIME media type audio/tone. The only optional parameter is 'rate' (sampling rate in Hz, default 8000). Both types are defined only for transfer via RTP.
Confidentiality of RTP streams using these payload formats is achieved through encryption as defined in RFC 1889; because compression is applied end-to-end, encryption may be performed after compression with no conflict between the two operations.
In older telephone networks employing in-band signaling without appropriate tone filters, the trunk signaling events defined in Section 3.14 may be exploited to commit toll fraud by injecting synthetic tone signals.
Named telephone event payload is a 32-bit structure: event (8 bits), E (end, 1 bit), R (reserved, 1 bit), volume (6 bits, dBm0 magnitude), and duration (16 bits, in timestamp units). The event field encodes DTMF digits, line signals, and trunk events per Tables 1–6.
Telephony tone payload begins with a 32-bit header: modulation frequency (9 bits), T bit (divide modulation by 3), volume (6 bits), and duration (16 bits). This is followed by pairs of 16-bit frequency entries each consisting of 4 reserved bits and a 12-bit frequency value in Hz; any number of frequencies may be included.