rfc-6884

RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)

Z. Fang
date2013-03 streamIETF areaart wgpayload statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc6884 doi10.17487/RFC6884
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.

Extracted elements (25)

design-rationale §5

A 16 kHz RTP clock rate is always mandated even when the encoder input or decoder output is configured at 8 kHz, because the EVRC-NW decoder does not require a priori knowledge of the encoder's sampling rate and can produce output at either rate. A single fixed clock rate simplifies RTP session negotiation.

rtp, realtime

design-rationale §10

'sendmode' is used as an SDP mode attribute in EVRC, EVRC-B, and EVRC-WB, but it is deprecated in EVRC-NW. The encoding capability C-bit in the RTP payload header and the 'mode-set-recv' parameter serve the equivalent dynamic and session-level signaling roles.

rtp, realtime, voip

design-rationale §11

The MMM mode request mechanism allows vocoders to operate at the highest possible average bit-rate when the network is lightly loaded, and at lower bit-rates under heavy load to avoid sharp declines in voice quality due to high frame-erasure rates. This is especially important for mobile-mobile calls where each wireless side has a potentially different network load.

realtime, voip, congestion, qos

interoperability-note §3

EVRC-NW modes 0, 1, and 7 are interoperable with EVRC-WB; modes 1 through 7 are interoperable with EVRC-B. By default, EVRC-NW supports narrowband modes 1–7; wideband mode 0 support is optional. Mode changes among supported modes cause bit-rate changes but do not cause decoding problems at the receiver.

realtime, voip

interoperability-note §13

When making an SDP offer, an EVRC-NW offerer SHOULD also announce EVRC-B and EVRC-WB support in its 'm=audio' lines with EVRC-NW as the preferred codec. This enables fallback interoperability with endpoints that support only EVRC-B and/or EVRC-WB.

realtime, voip, sip

normative-requirement §5 MUST

A 16 kHz RTP clock rate MUST always be used for EVRC-NW, regardless of whether the encoder input or decoder output is configured at 8 kHz. The RTP timestamp is increased by 320 for each 20 milliseconds.

rtp, realtime, voip

normative-requirement §13 MUST

Any unknown parameter in an SDP offer MUST be ignored by the receiver and MUST NOT be included in the SDP answer.

rtp, realtime

normative-requirement §9.1.2 REQUIRED

audio/EVRCNW0 and audio/EVRCNW1 SHALL NOT be used for storage or file transfer; audio/EVRCNW SHALL be used instead. These two subtypes depend on RTP framing and are only defined for transfer via RTP.

rtp, realtime

normative-requirement §4 SHOULD NOT

Erasure frames (frame type value 5) SHOULD NOT be transmitted by the sender over RTP. They are reserved for use in the storage format to maintain synchronization.

rtp, realtime

normative-requirement §9.1.1 MUST

If the maxinterleave parameter is not signaled in SDP, the maximum interleaving length MUST be 5. The interleaving lengths used in the entire session MUST NOT exceed the negotiated maxinterleave value.

rtp, realtime

normative-requirement §8 MUST

Speech frames lost in transmission and non-received frames MUST be stored as erasure frames (TOC value 5) in the storage format to maintain synchronization with the original media.

realtime, voip

normative-requirement §13 MUST

The 'maxptime' SDP parameter MUST be handled in the same way as 'ptime' as described in RFC 3264. For a sendonly stream, 'mode-set-recv' is not useful and SHOULD NOT be used.

rtp, realtime

normative-requirement §6 SHOULD

The mode change request field in the interleaved/bundled format SHOULD be honored by an EVRC-NW encoding endpoint in a one-to-one session (e.g., a two-party call or conference leg) with a dedicated EVRC-NW decoding endpoint.

rtp, realtime, voip

normative-requirement §6 MUST

The mode change request field (MMM) in the interleaved/bundled packet format MUST be interpreted according to the RATE_REDUC parameter definition for EVRC-NW in 3GPP2 C.S0014-D.

rtp, realtime, voip

normative-requirement §5 REQUIRED

The RTP header marker bit (M) SHALL be set to 1 if the first frame in the packet is the first speech frame of a talkspurt. For all other packets, M SHALL be set to zero.

rtp, realtime

normative-requirement §13 MUST

When using audio/EVRCNW1 (compact bundled format), the entire session MUST use the same fixed rate and mode (0-Wideband or 1-Narrowband).

rtp, realtime, voip

protocol-element §4

EVRC-NW operates on 20 ms frames and produces output at one of four sizes: 171 bits (Rate 1), 80 bits (Rate 1/2), 40 bits (Rate 1/4), or 16 bits (Rate 1/8). Two zero-bit frame types also exist: blank (null, value 0) and erasure (value 5). The default sampling rate is 16 kHz, with optional 8 kHz input/output.

realtime, rtp, voip

protocol-element §6.1

The encoding capability identification flag C (bit 1 of the first octet) signals the local EVRC-NW wideband/narrowband encoding capability. C=0 indicates mode 0 wideband encoding capability; C=1 indicates narrowband-only encoding (mode 0 incapable). This allows the far end to make informed mode requests via the MMM field.

rtp, realtime, voip

protocol-element §11

The MMM 3-bit field in the interleaved/bundled format allows a communication node to indicate its preferred compression mode (Capacity Operating Point) to the opposite node, enabling a controlled trade-off between voice quality and channel capacity. A remote sender MAY ignore mode-set-recv requests but must not assume mode 0 support unless explicitly signaled.

rtp, realtime, voip, congestion

protocol-element §10

The 'mode-set-recv' SDP parameter is a unidirectional receive-only attribute that allows a decoder to express a preference for a subset of EVRC-NW modes (0–7). Absence of this parameter for audio/EVRCNW and audio/EVRCNW0 signals mode set {1,2,3,4,5,6,7}; absence for audio/EVRCNW1 signals mode 1.

rtp, realtime, voip

protocol-element §6

Three RTP packet formats are defined for EVRC-NW: interleaved/bundled (audio/EVRCNW), header-free (audio/EVRCNW0), and compact bundled (audio/EVRCNW1). All operational details such as TOC, interleaving, DTX, and bundling follow existing EVRC/EVRC-B/EVRC-WB definitions except for EVRC-NW-specific modifications to the mode change request field and the C-bit.

rtp, realtime, voip

registry §9.1

This document registers three new IANA 'audio' media subtypes: audio/EVRCNW (interleaved/bundled format, also usable for file storage), audio/EVRCNW0 (header-free format, RTP-only), and audio/EVRCNW1 (compact bundled format, RTP-only). All three support mode-set-recv, DTX, and silence suppression parameters.

registry, rtp, voip

security-consideration §16

Since compression is applied end-to-end and the encodings do not exhibit significant non-uniformity, implementations are subject to all security considerations in RFC 3558, RFC 3550, and applicable RTP profiles (e.g., RFC 3551). Variable bit-rate audio security considerations from RFC 6562 also apply.

security, rtp, realtime

wire-format §6.1

The EVRC-NW interleaved/bundled payload header is a 32-bit structure containing: Reserved (R, 1 bit, MUST be zero), Encoding capability flag (C, 1 bit), Interleave length (LLL, 3 bits), Interleave index (NNN, 3 bits), Mode request (MMM, 3 bits), Count (5 bits), followed by TOC entries and codec data frames.

rtp, realtime

wire-format §8

The EVRC-NW storage format begins with the magic number "#!EVRCNW\n" (hex: 0x23 0x21 0x45 0x56 0x52 0x43 0x4E 0x57 0x0A). Each codec data frame is prefixed with a one-octet TOC field (4 most-significant bits set to zero, lower 4 bits carry the frame type value from Section 4).

realtime, voip