rfc-3558

RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)

A. Li
date2003-07 streamIETF arearai wgavt statusPROPOSED STANDARD pages23 canonicalhttps://www.rfc-editor.org/rfc/rfc3558 doi10.17487/RFC3558
This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]

updated by

Extracted elements (27)

design-rationale §6

Bundling is a degenerate case of interleaving (LLL=0) that amortizes RTP header overhead across multiple frames. Interleaving with LLL>0 additionally spreads packet-loss effects across non-consecutive frames, since EVRC/SMV quality degrades exponentially with consecutive frame loss but can compensate for isolated losses.

rtp, realtime, voip

design-rationale §9.1

For interactive sessions, interleaving length LLL=0 (bundling) or Header-Free format is RECOMMENDED to minimize end-to-end delay. For non-interactive use, LLL of 4 or 5 is RECOMMENDED as a balance between packet-loss robustness and latency.

rtp, realtime, voip

design-rationale §4.2

The Header-Free format omits all payload headers and ToC entries, relying on packet length to determine codec rate. This is designed for maximum bandwidth efficiency and low latency in conversational applications where only one frame per packet is needed.

rtp, realtime, voip

interoperability-note §13

The maxptime and maxinterleave SDP parameters are exchanged at session setup. maxptime maps to SDP 'a=maxptime'; maxinterleave maps to SDP 'a=fmtp' as 'maxinterleave=value'. Payload format names are case-insensitive in both MIME types and SDP.

rtp, realtime, voip

normative-requirement §4.3 MUST

A receiver MUST have prior knowledge of the packet format to correctly decode RTP packets. When both formats are used in the same session, different RTP payload type values MUST be used for each format.

rtp, realtime

normative-requirement §4.3 SHOULD

All receivers SHOULD be able to process both the Interleaved/Bundled and Header-Free packet formats.

rtp, realtime

normative-requirement §8 MUST

Erasure frames MUST be used in storage format to record missing frames (frame type 5), maintaining synchronization with the original media.

rtp, realtime

normative-requirement §6 MUST

In one-to-one sessions, the sender MUST respect the receiver's maxptime and maxinterleave values and MUST NOT interleave/bundle beyond those limits. The sender MUST NOT increase LLL to exceed the signaled maxinterleave during a session.

rtp, realtime

normative-requirement §4.1 MUST

Reserved bits (RR) in the Interleave Octet MUST be set to zero by the sender and SHOULD be ignored by the receiver.

rtp, realtime

normative-requirement §6 MUST

Silence suppression MUST only be used between interleave groups. Within an interleave group, a ToC with Frame Type 0 (Blank) MUST be used if the codec outputs a blank frame; the M bit is not set for blank frames.

rtp, realtime

normative-requirement §4.1 MUST

The Interleave Index (NNN) MUST have a value less than or equal to LLL. Packets with NNN greater than LLL are invalid and SHOULD be ignored by the receiver.

rtp, realtime

normative-requirement §10 MUST

The Mode Request field MUST be interpreted per Tables 2.2.1.2-1 and 2.2.1.2-2 for EVRC, and per Table 2.2-2 for SMV. All implementations are RECOMMENDED to honor the Mode Request signal.

rtp, realtime, voip

normative-requirement §5.2 MUST

The remaining unused bits of the last octet of a codec data frame MUST be set to zero (applicable to Rate 1 frames with 171 bits padded to 22 octets).

rtp, realtime

normative-requirement §5.1 MUST

ToC entries with reserved frame type values SHOULD be considered invalid. Frame type 2 (Rate 1/4) MUST be considered reserved when the EVRC codec is in use, as EVRC has no 1/4 rate frames.

rtp, realtime

normative-requirement §9.2 SHOULD

When receiving a packet, the receiver SHOULD check validity of ToC fields and match packet length against ToC-indicated lengths; mismatches or invalidity SHOULD cause the packet to be discarded and treated as lost.

rtp, realtime

normative-requirement §4.1 MUST

When the frame count is odd, the sender MUST add 4 bits of zero padding after the last ToC. When the frame count is even, the sender MUST NOT add padding bits.

rtp, realtime

normative-requirement §6 MUST

Within an interleave group, RTP packets MUST be transmitted in value-increasing order of the NNN field. The bundling value for all RTP packets in an interleave group MUST be the same.

rtp, realtime

protocol-element §10

The Mode Request field (3 bits, MMM) in the packet header signals the receiver to set a particular encoding mode on its audio encoder, affecting the reverse-direction bit rate. The sender SHOULD continue sending the same value until the mode changes to handle packet loss.

rtp, realtime, voip

protocol-element §4

Two RTP payload sub-formats are defined: an Interleaved/Bundled format (supports multiple frames per packet with interleaving or bundling) and a Header-Free format (single frame per packet, no payload header, maximum bandwidth efficiency).

rtp, realtime, voip

registry §12

This document registers four MIME subtypes with IANA: audio/EVRC (Interleaved/Bundled format, optional maxptime default 200ms and maxinterleave default 5), audio/EVRC0 (Header-Free format), audio/SMV (Interleaved/Bundled format), and audio/SMV0 (Header-Free format).

rtp, realtime, voip, registry

security-consideration §14

A potential DoS threat exists from pathological datagrams with high decoder computational load; however, EVRC and SMV encodings do not exhibit significant non-uniformity in decoding cost. Receivers may also be overloaded by excessive packet volume from undesired sources.

security, rtp, realtime

security-consideration §14

Confidentiality is achieved by encryption applied after end-to-end compression with no conflict between the two. Interleaving may impose constraints on encryption key changes, which SHOULD occur at interleave group boundaries.

security, rtp, realtime

wire-format §5.2

Codec output bits are packed MSB-first into octets: bit 1 of the vocoder output goes to the most significant bit of octet 1. Rate 1 frames (171 bits) are 22 octets with 5 trailing zero-pad bits; other rates align on octet boundaries without padding.

rtp, realtime, voip

wire-format §5.1

Each ToC entry is 4 bits encoding a frame type: 0=Blank (0 octets), 1=Rate 1/8 (2 octets), 2=Rate 1/4 (5 octets, SMV only), 3=Rate 1/2 (10 octets), 4=Rate 1 (22 octets, 171 bits with 5 zero-padded bits), 5=Erasure (0 octets, SHOULD NOT be transmitted).

rtp, realtime, voip

wire-format §4.2

The Header-Free packet format contains only the standard RTP header followed by exactly one codec data frame; no payload header fields (LLL, NNN, MMM, Count) or ToC entries are present. The codec rate is inferred from the frame length.

rtp, realtime, voip

wire-format §4.1

The Interleaved/Bundled packet format begins with an Interleave Octet (2-bit reserved, 3-bit LLL interleave length, 3-bit NNN interleave index), followed by a second octet (3-bit MMM mode request, 5-bit frame count), then ToC entries (4 bits each), optional 4-bit padding, and codec data frames.

rtp, realtime, voip

wire-format §11

The storage format begins with an ASCII magic number ('#!EVRC\n' = 0x23 0x21 0x45 0x56 0x52 0x43 0x0A for EVRC, '#!SMV\n' = 0x23 0x21 0x53 0x4d 0x56 0x0a for SMV), followed by codec data frames each prefixed by a 1-octet ToC (upper 4 bits zeroed).

rtp, realtime, voip