RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
Extracted elements (31)
DTMF events use the second playout algorithm (play until E bit, new event, or timeout) rather than the first (buffer exact duration), because unintended breaks in DTMF playout can cause receiving equipment to interpret a single digit as two, while slight extensions in duration are harmless for all DTMF applications.
Named events (the telephone-event payload) are the only feasible method for transmitting out-of-band PSTN signals such as 'on-hook' as content within RTP sessions, since these signals cannot be represented as audio tones at all.
Separate RTP payload formats for telephony tones are defined because low-rate voice codecs cannot reproduce tone signals accurately enough for automatic recognition, and properties such as phase reversals in the ANSam tone do not survive speech coding. Separate formats also permit higher redundancy at a low bit rate.
The named telephone-event payload type uses no static RTP payload type number and instead relies on dynamic assignment to allow the clock rate to be redefined (default 8000 Hz) and to follow current practice for dynamic media types.
The T bit in the tone payload allows the modulation frequency field to represent non-integer values such as 16 2/3 Hz and 33 1/3 Hz (by dividing the 9-bit modulation field by three), which are in practical use in telephony systems.
For backward compatibility with RFC 2833, if a sender receives no 'events' parameter from the remote end, it SHOULD assume support for DTMF events 0–15 but for no other events. This document removes the RFC 2833 requirement that all compliant implementations support DTMF events.
If a zero volume is indicated for an event for which the volume field is defined, the receiver MAY reconstruct volume from non-event audio or use the nominal ITU value, ensuring backward compatibility with RFC 2833 where volume was defined only for DTMF events.
A duration value of zero is reserved to indicate a 'state' event that lasts indefinitely until updated. A sender MUST NOT transmit a zero duration for events not defined as states, and the receiver SHOULD ignore a zero-duration report for a non-state event.
A receiver SHOULD NOT extend a tone by more than three packet interarrival times when using the 'play until E bit or timeout' playout algorithm, to prevent a tone from getting stuck due to loss of all retransmissions of the final packet.
For the tone payload, the sender SHOULD combine new and old tone reports in the same RTP packet using RFC 2198 audio redundancy to increase reliability, since each tone packet is independent and a lost packet represents a gap in information at the receiver.
For the tone payload type, the RTP timestamp MUST be updated for each successive packet (unlike named events, where the timestamp stays fixed for the event duration). The timestamp in each subsequent tone packet MUST equal the sum of the previous packet's timestamp and duration.
If the sender receives an 'events' parameter from the receiver (via SDP fmtp), it MUST restrict the set of events it sends to those listed. For backward compatibility, if no 'events' parameter is received, the sender SHOULD assume support for DTMF events 0–15 but for no other events.
It is RECOMMENDED that gateways render only the telephone-event payload once it is received rather than the simultaneous audio stream, since the audio may contain spurious tones introduced by compression algorithms.
Multiple named events MAY be packed into a single RTP packet only if they are consecutive and contiguous (no overlap, no pause between them). The RTP timestamp MUST identify the beginning of the first event or segment in the packet, and the M bit MUST be set if any new event begins in the packet.
Named telephone events MUST use the same RTP sequence number and timestamp base as the regular audio channel. For a multi-packet event, all update packets carry the same RTP timestamp (the time the event began); only the duration field increases.
SDP descriptions using the telephone-event payload MUST contain an fmtp format attribute listing the event values the receiver can process. The receiver MUST calculate jitter for RTCP receiver reports based on all packets sharing a given timestamp.
The final packet for each event or segment SHOULD be sent a total of three times at the source's update interval to protect against packet loss. The RTP sequence number MUST be incremented for each retransmission.
The first packet for an event MUST have the RTP marker (M) bit set. The final packet MUST have the E bit set (though setting of the E bit MAY be deferred to the retransmission). Intermediate packets MUST NOT have either the M bit or the E bit set.
The R (reserved) bit in the named-event payload MUST be set to zero by the sender and MUST be ignored by the receiver.
The RTP sequence number MUST be incremented by one for each successive RTP packet sent, including retransmissions of final event reports, so that the receiver can detect lost packets for RTCP receiver reports.
When an event duration exceeds the maximum representable value (0xFFFF timestamp units), the sender MUST send a packet with duration 0xFFFF and E bit clear, then begin a new segment with the RTP timestamp set to the end time of the previous segment. This MUST be repeated until the event ends, and the final packet MUST have the E bit set.
When events are combined with another payload type using RFC 2198 redundancy, the maximum segment duration MUST be constrained so that the RFC 2198 timestamp offset (14-bit field, max 0x3FFF) is never exceeded. The formula is: max duration = 0x3FFF − (R−1) × (packetization period in timestamp units).
DTMF event codes 0–9 represent digits 0–9, code 10 represents '*', code 11 represents '#', and codes 12–15 represent DTMF tones A–D. All are of type 'tone' and all support the volume field.
The named telephone-event payload type is designated media type 'audio/telephone-event'. It uses a dynamically assigned RTP payload type number (no static PT), with a default clock rate of 8000 Hz that may be redefined at payload type assignment time.
The tone payload type is designated media type 'audio/tone' and represents tones by frequency and cadence rather than by name. It uses a dynamically assigned RTP payload type and a default timestamp rate of 8000 Hz.
This document establishes an IANA registry for named telephone event codes (0–255) associated with the 'audio/telephone-event' payload type. Initial entries are DTMF events 0–15 defined in Section 3.2; remaining codes from RFC 2833 are conditionally reserved pending revival by other documents.
This document registers the media type 'audio/telephone-event' with IANA. The type supports optional parameters 'events' (comma-separated list or ranges of supported event codes) and 'rate' (sampling rate in Hz, default 8000).
This document registers the media type 'audio/tone' with IANA for the tone payload format. The type supports an optional 'rate' parameter (sampling rate in Hz, default 8000).
DTMF events frequently carry sensitive information such as PINs and passwords, and the telephone-event payload transmits these in cleartext within RTP. Implementations should consider using SRTP or other RTP-level security mechanisms to protect confidentiality of event streams. Additionally, unauthorized injection of fabricated event packets could disrupt or manipulate telephony sessions.
The named telephone-event payload is a 32-bit fixed-length structure containing: event (8-bit unsigned integer, 0–255), E (end) bit, R (reserved) bit, volume (6-bit unsigned, power in dBm0 magnitude), and duration (16-bit unsigned, in timestamp units, network byte order).
The tone payload begins with a 32-bit header: modulation (9-bit unsigned, Hz), T bit (divide modulation by 3), volume (6-bit dBm0 magnitude), and duration (16-bit, timestamp units). This is followed by pairs of 4-bit reserved fields and 12-bit frequency values (Hz), one pair per frequency component.