rfc-2658

RTP Payload Format for PureVoice(tm) Audio

K. McKay
date1999-08 streamLegacy statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc2658 doi10.17487/RFC2658
This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

Extracted elements (19)

design-rationale §5

Interleaving is desirable because the Qcelp CODEC interpolates missing audio via erasure frames, but quality degrades when erasure frames are consecutive. Interleaving spreads the impact of dropped packets across non-consecutive frames, improving perceived audio quality at the cost of increased end-to-end delay.

rtp, realtime

design-rationale §5

The restriction that senders may never increase bundling or interleave values (only decrease them) guarantees that a receiver can allocate a fixed, sufficient buffer after the first packet, preventing situations where the receiver needs more buffer space mid-session (possibly unavailable) or must pause playback.

rtp, realtime

interoperability-note §5

For interactive sessions, an interleave (LLL) value of 0 or 1 and a bundling factor of 4 or less is recommended to minimize end-to-end delay. When delay is not a concern, a bundling value of at least 4 and LLL of 4 or 5 (subject to MTU limits) is recommended for better packet-loss resilience.

rtp, realtime

normative-requirement §4 MUST

Erasure frames MUST be fed to the Qcelp CODEC for all missing packets. Receivers MUST use the RTP timestamp clock (each CODEC data frame advances the clock exactly 160 counts) to determine how many frames are missing when a packet is dropped.

rtp, realtime

normative-requirement §3.4 MUST

Once transmission begins with a given SSRC and interleave value, senders MUST NOT increase the interleave value; a new SSRC MUST be used if an increase is needed. The interleave value MAY be decreased only between interleave groups and once decreased MUST NOT be increased.

rtp, realtime

normative-requirement §3.2 MUST

Receipt of a CODEC data frame with a reserved value in octet 0 MUST be considered invalid data. The erasure rate octet value (14) SHOULD NOT be transmitted by senders, and reserved rate value 5 SHOULD be treated as reserved by receivers.

rtp, realtime

normative-requirement §3.1 MUST

Receipt of an RTP packet with an invalid LLL or NNN field value MUST be treated as a lost packet by the receiver, triggering erasure frame generation as described in section 4.

rtp, realtime

normative-requirement §3.3 MUST

Receivers MUST handle bundles of up to 10 CODEC data frames in a single RTP packet. Senders MUST NOT bundle more frames than fit in the MTU (computed assuming Rate 1 size for all frames) and MUST NOT bundle more than 10 frames.

rtp, realtime

normative-requirement §3.4 MUST

Senders MUST transmit packets in timestamp-increasing order, and within each interleave group MUST transmit packets in value-increasing order of the NNN field to minimize end-to-end delay when the underlying transport delivers in order.

rtp, realtime

normative-requirement §3 MUST

The Interleave field (LLL) MUST have a value between 0 and 5 inclusive; values 6 and 7 MUST NOT be used by senders. All receivers MUST support interleaving; senders MAY support it, and senders that do not support interleaving MUST set LLL and NNN to zero.

rtp, realtime

normative-requirement §3 MUST

The Interleave Index (NNN) MUST have a value less than or equal to LLL. Values of NNN greater than LLL are invalid and the packet MUST be treated as lost, generating an erasure frame.

rtp, realtime

normative-requirement §3 MUST

The Reserved (RR) field MUST be set to zero by senders and SHOULD be ignored by receivers.

rtp, realtime

normative-requirement §3.6.1 SHOULD

When reconstructing interleaved audio, if a needed packet arrives before the next frame from it is required, receivers SHOULD use the newly arrived packet's frame rather than substituting an erasure — i.e., late arrivals within the interleave window SHOULD still be consumed.

rtp, realtime

protocol-element §3.3.1

The number of bundled CODEC data frames in an RTP packet is not explicitly transmitted; receivers must parse octet 0 of each successive CODEC data frame until the end of the RTP payload to determine the count, since frames have variable length.

rtp, realtime

security-consideration §6

A receiver may be overloaded by receipt of too many packets. Network-layer authentication can discard packets from unwanted sources, but authentication overhead itself may be prohibitive. In multicast environments, future IGMP and multicast routing protocol extensions may allow source pruning.

rtp, security, multicast, realtime

security-consideration §6

RTP packets using this format are subject to the security considerations of the RTP specification. Confidentiality is achieved via encryption, which may be applied after compression without conflict. A denial-of-service threat from pathological datagrams causing excessive decode load is noted, though Qcelp encoding does not exhibit significant non-uniform computational load.

rtp, security, realtime

state-machine §3.5

An interleave group consists of L+1 consecutive RTP packets (sequence numbers S-N through S-N+L) all sharing the same bundling value. The receiver determines the expected bundling value from the first received packet of the group; on mismatch, the receiver MAY trim/pad or discard the entire group and play silence.

rtp, realtime

wire-format §3.2

Each CODEC data frame begins with a 1-octet rate indicator (octet 0): value 0=Blank (1 octet total), 1=Rate 1/8 (4 octets), 2=Rate 1/4 (8 octets), 3=Rate 1/2 (17 octets), 4=Rate 1 (35 octets), 14=Erasure (1 octet, SHOULD NOT be sent). Bits from the IS-733 standard are packed MSB-first into subsequent octets, with unused trailing bits set to zero.

rtp, realtime

wire-format §3

The RTP payload for Qcelp begins with a 1-octet header containing three fields: Reserved (RR, 2 bits, must be zero), Interleave (LLL, 3 bits, values 0–5), and Interleave Index (NNN, 3 bits, must be ≤ LLL). These are followed by one or more codec data frames aligned on octet boundaries.

rtp, realtime