RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec
updates
- rfc-4788 — Enhancements to RTP Payload Formats for EVRC Family Codecs
Extracted elements (23)
A 16-kHz RTP clock is mandated even when devices operate at 8 kHz because the decoder output can be at either 8 or 16 kHz regardless of encoder sampling rate, so a fixed clock rate avoids ambiguity without requiring the decoder to know the encoder's configuration.
Since EVRC-WB is an extension of EVRC-B, offerers SHOULD announce EVRC-B support alongside EVRC-WB as the preferred codec. This allows interoperability with answerers that support only EVRC-B, providing graceful fallback in negotiation.
EVRC-WB modes 4 and 7 are interoperable with EVRC-B. The decoder does not require a priori knowledge of the encoder's mode, and mode changes do not cause decoding problems.
The new 'recvmode' and 'sendmode' parameters added to audio/EVRCB and audio/EVRCB0 are backward-compatible: legacy RFC 4788 implementations will not send them and will ignore them if received, enabling interoperability between RFC 4788 and RFC 5188 implementations.
A 16-kHz RTP clock rate MUST always be used for EVRC-WB, even when the encoder or decoder is configured at 8 kHz. The RTP timestamp is increased by 320 for each 20 milliseconds.
Any unknown parameter in an SDP offer MUST be ignored by the receiver and MUST NOT be included in the SDP answer.
audio/EVRCWB0 depends on RTP framing and is only defined for transfer via RTP; it SHALL NOT be used for storage or file transfer — audio/EVRCWB SHALL be used instead.
Congestion control for RTP SHALL be used in accordance with RFC 3550 and with any applicable RTP profile such as RFC 3551.
For audio/EVRCWB1, the 'fixedrate' parameter MUST NOT be present when the 'sendmode' value is 4 or 7.
Speech frames lost in transmission and non-received frames MUST be stored as erasure frames (ToC value of 5) in the storage format to maintain synchronization with the original media.
The erasure frame type (value 5) SHOULD NOT be transmitted by the sender over RTP.
The maxinterleave parameter's interleaving lengths used in the entire session MUST NOT exceed the signaled maximum value; if not signaled, the maxinterleave length MUST be 5.
The 'maxptime' parameter MUST be handled in the same way as 'ptime' per RFC 3264 offer-answer procedures.
The RTP header marker bit (M) SHALL be set to 1 if the first frame in the packet is the first speech frame in a talkspurt; for all other packets it SHALL be set to zero.
When using EVRCWB1, the entire session MUST use the same fixed rate and mode (0-Wideband or 4,7-Narrowband).
EVRC-WB operates on 20-ms frames producing output of three sizes: 171 bits (full rate), 80 bits (1/2 rate), or 16 bits (1/8 rate), plus zero-bit blank and erasure frame types. Frame type values 0-5 map to Blank, 1/8, 1/4, 1/2, 1 (full), and Erasure respectively.
The 'mode-set-recv' parameter for EVRC-WB allows a decoder to signal its preferred subset of encoder modes ({0,4,7}). Absence of this parameter signals the full mode set {0,4,7}; for EVRCWB1, absence signals mode 0.
The 'sendmode' parameter allows an encoder to signal its current mode of operation (values 0, 4, or 7 for EVRC-WB; 0-7 for EVRC-B). Mode change does not cause decoding problems at the receiver, and the decoder does not need to know the encoder's current mode.
Three RTP packet formats are supported for EVRC-WB: interleaved/bundled (audio/EVRCWB), header-free (audio/EVRCWB0), and compact bundled (audio/EVRCWB1). The ToC mode change request field MUST be interpreted according to the RATE_REDUC parameter as defined in EVRC-WB.
This document registers three new IANA media subtypes: audio/EVRCWB (interleaved/bundled format), audio/EVRCWB0 (header-free format), and audio/EVRCWB1 (compact bundled format) for the EVRC-WB codec.
This document updates the existing IANA media type registrations audio/EVRCB and audio/EVRCB0 from RFC 4788 by adding new optional parameters 'recvmode' and 'sendmode'.
Implementations of this specification are subject to all security considerations specified in RFC 3558, RFC 3550, and any appropriate RTP profile (e.g., RFC 3551). Since compression is applied end-to-end and encodings do not exhibit significant non-uniformity, the primary security concerns are those of the underlying RTP transport.
The EVRC-WB storage file begins with magic number '#!EVCWB\n' (0x23 0x21 0x45 0x56 0x43 0x57 0x42 0x0A). Each codec data frame is prefixed by a one-octet ToC field with the four most significant bits set to zero (e.g., full-rate frame stored as 0x04).