RFC 6884
RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
RFC 6884: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) 🎀
Title block tea 🫶
- Who wrote it: Z. Fang at Qualcomm Incorporated
- Stream: Internet Engineering Task Force (IETF)
- Request for Comments: 6884
- Category: Standards Track (it's an official Internet Standard, bestie 👑)
- Date: March 2013
- ISSN: 2070-1721
- Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates 🦋
Abstract ✨
Okay so this doc spells out the RTP payload formats for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) 🎧. There are three media type registrations for EVRC-NW RTP payload formats, and it also specifies a file format for EVRC-NW speech data in storage mode apps, like email 📧. Iconic range honestly 💅.
Status of This Memo 📋
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6884 🔎.
Copyright Notice ©️
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🌈.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Conventions .....................................................2
3. Background ......................................................3
4. EVRC-NW Codec ...................................................3
5. RTP Header Usage ................................................4
6. Payload Format ..................................................4
6.1. Encoding Capability Identification in EVRC-NW
Interleaved/Bundled Format .................................5
7. Congestion Control Considerations ...............................6
8. Storage Format for the EVRC-NW Codec ............................6
9. IANA Considerations .............................................7
9.1. Media Type Registrations ...................................7
9.1.1. Registration of Media Type audio/EVRCNW .............7
9.1.2. Registration of Media Type audio/EVRCNW0 ............9
9.1.3. Registration of Media Type audio/EVRCNW1 ...........10
10. SDP Mode Attributes for EVRC-NW ...............................12
11. Mode Change Request/Response Considerations ...................13
12. Mapping EVRC-NW Media Type Parameters into SDP ................14
13. Offer-Answer Model Considerations for EVRC-NW .................14
14. Declarative SDP Considerations ................................16
15. Examples ......................................................16
16. Security Considerations .......................................19
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................201. Introduction 🌸
This doc is all about how you pack EVRC-NW encoded speech into the Real-time Transport Protocol (RTP) 🎤. It supports the header-free, interleaved/bundled, and compact bundle packet formats for the EVRC-NW codec, plus discontinuous transmission (DTX) support for EVRC-NW speech sent over RTP 🫧.
EVRC-NW has better speech quality than EVRC and EVRC-B, and better capacity than the Enhanced Variable Rate Wideband Codec (EVRC-WB) 📈. It's part of the EVRC family, so it's giving family resemblance 🥹.
2. Conventions 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 💜.
3. Background 🧚
EVRC-NW is an extension of both the EVRC-B [2] and EVRC-WB [3] speech codecs, which were developed in the Third Generation Partnership Project 2 (3GPP2), and it adds DTX support 🎙️. It gives you enhanced voice quality and high spectral efficiency, so it's lowkey a whole vibe ✨.
The codec works on 20 ms frames, and the default sampling rate is 16 kHz (wideband). Input and output at 8 kHz (narrowband) is supported too 🍓. EVRC-NW can operate in eight modes (0 to 7) as defined in 3GPP2 C.S0014-D [4]. Modes 0, 1, and 7 are interoperable with EVRC-WB, and modes 1 to 7 are interoperable with EVRC-B 🔁.
Modes 0 to 6 use the full set or a subset of full rate, 1/2 rate, 1/4 rate, and 1/8 rate frames. Mode 7 uses only 1/2 rate and 1/8 rate frames 🧩. By default, EVRC-NW supports all narrowband modes (modes 1 to 7). Support for wideband mode (mode 0) is optional 🙈.
Switching modes among modes 1 to 7 (or among modes 0 to 7 if the receiver supports wideband mode) changes the codec output bit-rate, but it doesn't cause any decoding problems at the receiver 💅. So EVRC-NW gives you a standardized way to move between enhanced quality and increased capacity for packetized voice apps 🔥.
The big use case is IP telephony 📞. Target devices include IP phones or VoIP handsets, media gateways, voice messaging servers, and more 💖.
4. EVRC-NW Codec 🎶
The codec works on 20 ms frames. It outputs frames in one of four sizes: 171 bits (Rate 1), 80 bits (Rate 1/2), 40 bits (Rate 1/4), or 16 bits (Rate 1/8) 🌈. There are also two zero-bit codec frame types, blank (null) frames and erasure frames 🫥. The default sampling rate is 16 kHz, and input and output at 8 kHz are supported as well 🎧.
Here's the table of frame type values and the sizes of the matching codec data frames 📊:
Value Rate Total codec data frame size in bytes (and in bits)
--------------------------------------------------------------------
0 Blank (Null) 0 (0 bits)
1 1/8 2 (16 bits)
2 1/4 5 (40 bits)
3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 bits padded at the end)
5 Erasure 0 (SHOULD NOT be transmitted by sender)5. RTP Header Usage 📦
The RTP header format is specified in RFC 3550 [5]. The EVRC-NW payload formats (Section 6) use the RTP header fields exactly as RFC 3550 [5] specifies 🧾.
EVRC-NW can also work with 8 kHz sampled input and output signals 🎚️. The decoder doesn't need to know ahead of time what sampling rate the original signal had at the encoder's input. The decoder output can be 8 kHz or 16 kHz, no matter what rate the encoder used. Depending on the implementation and the electroacoustic audio capabilities of the devices, the encoder input and/or decoder output can be set to 8 kHz, but a 16 kHz RTP clock rate MUST always be used ⏰. The RTP timestamp goes up by 320 every 20 milliseconds ⏱️.
The RTP header marker bit (M) SHALL be set to 1 if the first frame in the packet is a speech frame that starts a talkspurt. For all other packets, the marker bit SHALL be set to zero (M=0) 🚩.
6. Payload Format 💎
Three RTP packet formats are supported for EVRC-NW: the interleaved/bundled packet format, the header-free packet format, and the compact bundled packet format 🎁. For all of these, the operational details and capabilities of EVRC-NW (like TOC, interleaving, DTX, and bundling) are exactly the same as in EVRC [6], EVRC-B [2], and EVRC-WB [3], with these exceptions 👀:
- The mode change request field in the interleaved/bundled packet format MUST be interpreted according to the definition of the RATE_REDUC parameter, as described for EVRC-NW in 3GPP2 C.S0014-D [4].
- The mode change request field in the interleaved/bundled packet format SHOULD be honored by an EVRC-NW encoding endpoint in a one-to-one session with a dedicated EVRC-NW decoding endpoint, such as in a two-party call or in a conference leg 🤝.
- The reserved bit field in the first octet of the interleaved/bundled format has only one bit. Bit 1 of the first octet is an EVRC-NW wideband/narrowband encoding capability identification flag 🩷.
Lastly, the media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format, and audio/EVRCNW1 maps to the compact bundled packet format 🦋.
6.1. Encoding Capability Identification in EVRC-NW Interleaved/Bundled Format 💖
okay so the EVRC-NW interleaved/bundled format has this encoding capability identification flag 🦋. It tells the far end what your local EVRC-NW wideband/narrowband encoding capability is at the moment you build an RTP packet 🎀. Then the other side can use the MMM field in its returning packets to ask for the wideband or narrowband mode that fits the current, dynamic/instantaneous capability info ✨. (See RFC 3558 [6] for the definition of the MMM field.) Here are a couple of scenarios where this shows up, bestie 💅:
- Wideband first, then things change 👑: an end-to-end wideband call starts on the interleaved/bundled format. Then the called endpoint becomes wideband encoding incapable mid-call and lets the other end know with the flag. So the calling endpoint could switch the MMM value in its outgoing EVRC-NW packets from mode 0 to mode 4 to ask for narrowband traffic to save bandwidth 🍓, or from mode 0 to mode 1 for the best perceptual quality 🌸.
- Narrowband first, then an upgrade 🔥: an end-to-end narrowband call goes between a calling endpoint that can do wideband and a called endpoint that can't. Then the called endpoint becomes wideband capable during the call and signals it with the flag. Now the calling endpoint can change the MMM value in its outgoing EVRC-NW packets from non-mode-0 to mode 0 to request wideband traffic 🦋✨.
The flag lives in bit 1 of the first octet, as shown in the diagram below 💜. The flag is set to zero (C=0) when the local EVRC-NW encoder is capable of mode 0 wideband encoding. It's set to one (C=1) when the local EVRC-NW encoder is capable of non-mode-0 narrowband encoding only. (For the original definitions of the other fields in the interleaved/bundled format, see RFC 3558 [6].)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|R|C| LLL | NNN | MMM | Count | TOC | ... | TOC |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| one or more codec data frames, one per TOC entry |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved (R): 1 bit 🙈
This is the reserved bit. It MUST be set to zero by the sender, and it SHOULD be ignored by the receiver.
Encoding capability identification (C): 1 bit 🌈
This one must be set to zero by the sender to indicate wideband encoding capable, or set to one to indicate narrowband encoding capable only:
C = 0 : mode 0 wideband encoding capable
= 1 : mode 0 wideband encoding incapable, i.e., narrowband
encoding only.7. Congestion Control Considerations 🚦
Congestion control for RTP is covered in RFC 3550 [5] and in the applicable RTP profiles, e.g., RFC3551 [7]. This document doesn't change any of that 🫶.
Here's the tea ☕: the header overhead means the number of frames you cram into each RTP packet affects the overall bandwidth of the RTP stream. Packing more frames into each packet cuts down how many packets get sent and therefore the header overhead 💖. The catch is that you pay for it with more delay and less error robustness 😭.
8. Storage Format for the EVRC-NW Codec 📁
The storage format is for saving EVRC-NW encoded speech frames, like as a file or an email attachment 💌.
The file starts with a magic number that identifies the vocoder being used 🧚. For EVRC-NW, the magic number is the ASCII character string #!EVRCNW\n, which is 0x23 0x21 0x45 0x56 0x52 0x43 0x4E 0x57 0x0A in hex 🔥.
The codec data frames are stored back to back, and each one gets a single TOC entry field in front of it. That TOC field is extended to one octet by setting the four most significant bits of the octet to zero 🌸. For example, a TOC value of 4 (a full-rate frame) gets stored as 0x04 ✨. The Value column in the table in Section 4 has the TOC values for each frame type.
Speech frames that get lost in transmission, along with non-received frames, MUST be stored as erasure frames (TOC value of 5) so they stay in sync with the original media 🫶.
9. IANA Considerations 🌷
This document introduces a new EVRC-NW audio media subtype 💜.
9.1. Media Type Registrations 🎀
Following the guidelines in RFC 4855 [8] and RFC 6838 [9], this section registers new audio media subtypes for EVRC-NW 💅.
9.1.1. Registration of Media Type audio/EVRCNW 🦋
The registration template is below, copied exactly so nothing gets lost in translation 🙈:
Type name: audio
Subtype name: EVRCNW
Required parameters: None
Optional parameters: These parameters apply to RTP transfer only.
mode-set-recv: A subset of EVRC-NW modes. Possible values are a
comma-separated list of modes from the set {0,1,2,3,4,5,6,7}
(see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can
use this attribute to inform an encoder of its preference to
operate in a specified subset of modes. Absence of this
parameter signals the mode set {1,2,3,4,5,6,7}.
ptime: See RFC 4566 [10].
maxptime: See RFC 4566.
maxinterleave: Maximum number for interleaving length (field LLL
in the Interleaving Octet) [0..7]. The interleaving lengths
used in the entire session MUST NOT exceed this maximum value.
If not signaled, the maxinterleave length MUST be 5.
silencesupp: See Section 6.1 in RFC 4788.
dtxmax: See Section 6.1 in RFC 4788.
dtxmin: See Section 6.1 in RFC 4788.
hangover: See Section 6.1 in RFC 4788.
Encoding considerations:
This media type is framed binary data (see RFC 6838, Section 4.8)
and is defined for transfer of EVRC-NW encoded data via RTP using
the interleaved/bundled packet format specified in RFC 3558 [6].
Security considerations: See Section 16.
Interoperability considerations: None
Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The
transfer method with the interleaved/bundled packet format via RTP
is specified in RFC 3558 [6]. See Section 6 of RFC 6884 for
details for EVRC-NW.
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
Additional information:
The following applies to stored-file transfer methods:
Magic number: #!EVRCNW\n (see Section 8)
File extensions: enw, ENW
Macintosh file type code: None
Object identifier or OID: None
EVRC-NW speech frames may also be stored in the file format "3g2" as
defined in 3GPP2 C.S0050-B [14], which is identified using the media
types "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON
Restrictions on usage:
This media type can be used with the file format defined in
Section 8 of RFC 6884 in contexts other than RTP. In the context
of transfers over RTP, the RTP payload format specified in
Section 4.1 of RFC 3558 [6] is used for this media type.
Author: Zheng Fang <zfang@qualcomm.com>
Change controller:
IETF Payload working group delegated from the IESG.9.1.2. Registration of Media Type audio/EVRCNW0 ✨
Here's the second registration, the header-free one 🌸:
Type name: audio
Subtype name: EVRCNW0
Required parameters: None
Optional parameters: These parameters apply to RTP transfer only.
mode-set-recv: A subset of EVRC-NW modes. Possible values are a
comma-separated list of modes from the set {0,1,2,3,4,5,6,7}
(see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can
use this attribute to inform an encoder of its preference to
operate in a specified subset of modes. Absence of this
parameter signals the mode set {1,2,3,4,5,6,7}.
ptime: See RFC 4566.
silencesupp: See Section 6.1 in RFC 4788.
dtxmax: See Section 6.1 in RFC 4788.
dtxmin: See Section 6.1 in RFC 4788.
hangover: See Section 6.1 in RFC 4788.
Encoding considerations:
This media type is framed binary data (see RFC 6838, Section 4.8)
and is defined for transfer of EVRC-NW encoded data via RTP using
the header-free packet format specified in RFC 3558 [6].
Security considerations: See Section 16.
Interoperability considerations: None
Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The
transfer method with the header-free packet format via RTP is
specified in RFC 3558 [6].
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
Additional information: None
Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing and hence is only defined
for transfer via RTP [5]. The RTP payload format specified in
Section 4.2 of RFC 3558 [6] SHALL be used. This media type SHALL
NOT be used for storage or file transfer; instead, audio/EVRCNW
SHALL be used.
Author: Zheng Fang <zfang@qualcomm.com>
Change controller:
IETF Payload working group delegated from the IESG.9.1.3. Registration of Media Type audio/EVRCNW1 🎀
Type name: audio 🫶 Subtype name: EVRCNW1 💖 Required parameters: None ✨ Optional parameters: These only apply to RTP transfer, so don't try them anywhere else 🦋
mode-set-recv: A subset of EVRC-NW modes. The possible values are a comma-separated list of modes from the set{0,1}(see Table 2.6.1.2-1 in 3GPP2 C.S0014-D [4]). A decoder can use this attribute to tell an encoder which subset of modes it'd prefer to operate in, which is so iconic 💅. A value of0signals support for wideband fixed rate (full or half rate, depending on the value of thefixedrateparameter). A value of1signals narrowband fixed rate (full or half rate, depending on the value of thefixedrateparameter). If this parameter is absent, that signals mode 1 🌸.ptime: See RFC 4566.maxptime: See RFC 4566.fixedrate: Shows the EVRC-NW rate of the session while it's in single rate operation 🍓. Valid values include0.5and1. A value of0.5means the 1/2 rate, and a value of1means the full rate. If this parameter isn't there at all, 1/2 rate is assumed.silencesupp: See Section 6.1 in RFC 4788.dtxmax: See Section 6.1 in RFC 4788.dtxmin: See Section 6.1 in RFC 4788.hangover: See Section 6.1 in RFC 4788.
Encoding considerations: This media type is framed binary data (see RFC 6838, Section 4.8). It's defined for transferring EVRC-NW encoded data over RTP using the compact bundled packet format specified in RFC 4788 🧚
Security considerations: See Section 16. 🔐
Interoperability considerations: None 🌈
Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D [4]. The transfer method using the compact bundled packet format over RTP is specified in RFC 4788 📜
Applications that use this media type: It's expected that lots of VoIP apps (plus mobile apps) will use this one, main character energy 👑
Additional information: None
Person & email address to contact for further information: Zheng Fang <zfang@qualcomm.com> 💌
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, so it's only defined for transfer via RTP [5]. The RTP payload format specified in Section 4 of RFC 4788 SHALL be used. This media type SHALL NOT be used for storage or file transfer. Instead, audio/EVRCNW SHALL be used. Not me reading "SHALL" three times in one bullet 💀
Author: Zheng Fang <zfang@qualcomm.com> ✍️
Change controller: IETF Payload working group delegated from the IESG.
10. SDP Mode Attributes for EVRC-NW 🎶
mode-set-recv can be used by a decoder to tell an encoder which subset of modes it prefers 💜. Saying you prefer something implicitly means you support it, so that's the vibe. If mode 0 isn't preferred for media type EVRCNW0 or EVRCNW1, there's no indication that mode 0 is supported. However, the absence of this parameter, or the absence of mode 0 in this parameter for media type EVRCNW, shall not preclude mode 0 support during a call where mode 0 may be requested via the MMM field. Lowkey a plot twist 🙈
- To let other nodes know it's capable of wideband mode: a decoder can always decode all the narrowband modes (modes 1 to 7). Unless the decoder indicates support for mode 0 (that is, a preference) in this parameter, or in the MMM mode request field in the interleaved/bundled payload format, an encoder at the other side shall not operate in mode 0 🔥.
- To indicate a preference for a subset of modes: a set has been defined so several modes can be expressed as a preference in one go. For instance, the set
{4,5,6,7}signals that the receiver prefers the sender to operate in the bandwidth-efficient narrowband modes of EVRC-NW 🦋.
Note that during an active call session using the interleaved/bundled packet format, the MMM mode request from a communication partner can contain a mode request that's different from the values in the last mode-set-recv attribute. The partner's EVRC-NW wideband decoding capability is determined by the latest mode-set-recv attribute or MMM mode request field. For example, a mode request with MMM=0 from a communication partner is an implicit indication of the partner's EVRC-NW wideband decoding capability and preference. An EVRC-NW wideband-capable node that receives the request can operate in wideband mode ✨. A mode request with MMM=1, 2, ..., or 7 from a communication partner is an implicit indication of the partner's EVRC-NW narrowband decoding preference. The encoder of an EVRC-NW node that receives the request shall honor it and operate in narrowband mode 🌸.
sendmode is used as an SDP mode attribute in EVRC [6], EVRC-B [2], and EVRC-WB [3]. However, it's deprecated in EVRC-NW. Bye bye, sendmode 👋
11. Mode Change Request/Response Considerations 🎀
The interleaved/bundled packet format for the EVRC family of vocoders supports a 3-bit field (MMM) that a communication node can use to indicate its preferred compression mode to the opposite node 💅. The compression mode (also known as Capacity Operating Point) was introduced to allow a controlled trade-off between voice quality and channel capacity. It makes it possible to run vocoders at the highest possible (average) bit rate, which means the highest voice quality, when the network is lightly loaded 🌈. Once the network load goes up, the vocoders can be asked to run at lower average bit rates so they can soak up the extra load without causing an undue increase in the frame-erasure rates. The underlying premise is that a higher bit rate improves vocoder performance, but it also increases network load, which risks a sharp drop in voice quality if the frame-erasure rate gets too high 😭. A lower bit-rate mode can absorb the extra load without causing unduly high frame-erasure rates, so overall quality ends up better even though the lower bit-rate mode sounds inherently less rich 🧁.
So the MMM field should be used to ask the far end to transmit compressed speech using a mode that gives the best balance between voice quality and capacity 💖. But in mobile-to-mobile calls, for example, there are two wireless sides involved, each with a potentially different network load level and therefore a different preferred mode. In those cases, getting optimal end-to-end performance depends on both sides coherently managing the operative mode. This means that even if the local node prefers a higher bit-rate vocoder mode, it should adjust to a lower bit-rate mode if the far end requests it, to avoid potentially high frame-erasure rates from heavy load on the far-end network 🫶. For similar reasons, when a mode requested by the far end shouldn't be supported, it might still be beneficial to switch to a supported vocoder mode with a lower average bit rate than the one requested. It is recommended that the next lower average bit-rate supported vocoder mode be used for encoding when a mode requested by the far end is not supported 🙌.
A wideband-capable endpoint can use the information in the C-bit of the RTP payload header to figure out the optimal mode to request from the far end. If the far end cannot provide mode 0 packets (C-bit=1), then the choice of MMM can be based strictly on the local network load. If the C-bit indicates the remote end's mode 0 encoding capability (C-bit=0), then even if the local network load isn't light, mode 0 can be requested, knowing definitively that it will be supported. This lets operators treat wideband-capable mobiles preferentially, if they want to adopt that policy 👑.
12. Mapping EVRC-NW Media Type Parameters into SDP 🧚
Information carried in the media type specification maps to specific fields in the Session Description Protocol (SDP) [10], which is commonly used to describe RTP sessions 🌸. When SDP is used to specify sessions that use EVRC-NW encoded speech, the mapping works like this:
- The media type (
audio) goes in the SDPm=line as the media name 🎀. - The media subtype (
EVRCNW,EVRCNW0, orEVRCNW1) goes in the SDPa=rtpmapas the encoding name 🦋. - The optional parameters 'ptime and 'maxptime' (for subtypes EVRCNW and EVRCNW1) go in the SDP
a=ptimeanda=maxptimeattributes, respectively ⭐. - Any remaining parameters (for subtypes EVRCNW, EVRCNW0, and EVRCNW1) go in the SDP
a=fmtpattribute. You copy them from the media type string as a semicolon-separated list of parameter=value pairs 🍓.
13. Offer-Answer Model Considerations for EVRC-NW 🤝
The following considerations apply when you use the SDP offer-answer procedures of RFC 3264 [12] to negotiate the use of an EVRC-NW payload in RTP 💜:
- Since EVRC-NW is an extension of both EVRC-B and EVRC-WB, the offerer SHOULD also announce EVRC-B and EVRC-WB support in its
m=audiolines, with EVRC-NW as the preferred codec. This lets it interoperate with an answerer that only supports EVRC-B and/or EVRC-WB 🫶.
Here's an example of that kind of offer 👀:
m=audio 55954 RTP/AVP 98 99 100
a=rtpmap:98 EVRCNW0/16000
a=rtpmap:99 EVRCWB0/16000
a=rtpmap:100 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:99 mode-set-recv=0,4
a=fmtp:100 recvmode=0If the answerer supports EVRC-NW, it can keep payload type 98 in its answer, and the conversation can happen using EVRC-NW ✨. Otherwise, if the answerer only supports EVRC-WB and/or EVRC-B, it will leave only payload type 99 and/or 100 in its answer, and the conversation will happen using EVRC-WB and/or EVRC-B, respectively.
An example answer for the above offer looks like this 🌈:
m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCNW0/16000
a=fmtp:98 mode-set-recv=4mode-set-recvis a unidirectional, receive-only parameter 🦋.- An offerer can use
mode-set-recvto ask that the remote sender's encoder be limited to the list of modes signaled inmode-set-recv. A remote sender MAY ignoremode-set-recvrequests. However, a remote sender shall not assume the other side can support mode 0, unless the offer explicitly includes mode 0 inmode-set-recv, or the remote sender receives mode requests with MMM=0 from the communication partner during an active call using the EVRC-NW interleaved/bundled format 🙈. - The parameters
maxptimeandptimewill in most cases not affect interoperability. However, setting them can affect the performance of the application ⭐. The SDP offer-answer handling of theptimeparameter is described in RFC 3264 [12]. Themaxptimeparameter MUST be handled in the same way 💅. - For a sendonly stream, the
mode-set-recvparameter isn't useful, so it SHOULD NOT be used 🍓. - When using EVRCNW1, the entire session MUST use the same fixed rate and mode (0-Wideband or 1-Narrowband) 🔥.
- For additional rules that MUST be followed while negotiating DTX parameters, see Section 6.8 in RFC 4788 [2] 🎀.
- Any unknown parameter in an SDP offer MUST be ignored by the receiver and MUST NOT be included in the SDP answer 🧁.
14. Declarative SDP Considerations ✨
Okay so, for declarative use of SDP in the Session Announcement Protocol (SAP) [15] and the Real Time Streaming Protocol (RTSP) [16], these considerations apply 🎀
- Any
maxptimeandptimevalues should be selected with care, so the session's participants can actually get reasonable performance 💅 - The payload format configuration parameters are all declarative, and a participant MUST use the configuration(s) that is provided for the session 🫶 More than one configuration MAY be provided if necessary, by declaring multiple RTP payload types. However, the number of types SHOULD be kept small 🧚 For declarative examples, see Section 15.
- Receive-only, unidirectional stuff like
mode-set-recvshould be excluded from any declarations, because those parameters are meaningless in one-way streaming applications 💀
15. Examples 🌈
Okay, here are some example SDP session descriptions using EVRC-NW encodings 🦋 In these examples, long a=fmtp lines are folded to fit the column width of this document. The backslash ("") at the end of a line, plus the carriage return that follows it, should be ignored. Also, media subtype names are case-insensitive, and parameter names are case-insensitive both in media types and in the mapping to the SDP a=fmtp attribute 💖
Example usage of EVRCNW if wideband mode is supported:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120Example usage of EVRCNW if wideband mode is not supported:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 mode-set-recv=1,2,3,4,5,6
a=fmtp:98 mode-set-recv=4
a=fmtp:99 recvmode=0
a=maxptime:120Example usage of EVRCNW0:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0Here's an example SDP answer from a media gateway, asking a terminal to limit its encoder operation to EVRC-NW mode 4 🍓
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCNW0/16000
a=fmtp:97 mode-set-recv=4Example usage of EVRCNW1:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW1/16000
a=rtpmap:98 EVRCWB1/16000
a=rtpmap:99 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=fmtp:98 fixedrate=0.5
a=fmtp:99 fixedrate=0.5
a=maxptime:100Example usage of EVRCNW with DTX with silencesupp=1:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120Example usage of EVRCNW with DTX with silencesupp=0:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW/16000
a=rtpmap:98 EVRCWB/16000
a=rtpmap:99 EVRCB/8000
a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1; \
mode-set-recv=0,4
a=fmtp:99 recvmode=0
a=maxptime:120Example offer-answer exchange between EVRC-NW and legacy EVRC-B (RFC 4788):
Offer:
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
Answer:
m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000Example offer-answer exchange between EVRC-NW and legacy EVRC-WB (RFC 5188):
Offer:
m=audio 55954 RTP/AVP 97 98 99
a=rtpmap:97 EVRCNW0/16000
a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000
a=rtpmap:97 mode-set-recv=0,1,2,3,4,5,6
a=fmtp:98 mode-set-recv=0,4
a=fmtp:99 recvmode=0
Answer:
m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/1600016. Security Considerations 🔥
Okay, this part is seriously important, so pay attention 👑 Compression is applied to the payload formats end-to-end, and the encodings do not show significant non-uniformity. Because of that, implementations of this specification are subject to all the security considerations specified in RFC 3558 [6]. Implementations using the payload defined in this specification are subject to the security considerations discussed in RFC 3558 [6], RFC 3550 [5], and any appropriate profile (for example, RFC 3551 [7]). Additional security considerations are described in RFC 6562 [13]. Read all of them, no skipping 😭🙈
17. References 📚
17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for
EVRC Family Codecs", RFC 4788, January 2007.
[3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced
Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype
Updates for EVRC-B Codec", RFC 5188, February 2008.
[4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68,
70, and 73 for Wideband Spread Spectrum Digital Systems",
3GPP2 C.S0014-D v3.0, October 2010, <http://www.3gpp2.org/
public_html/specs/C.S0014-D_v3.0_EVRC.pdf>.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[6] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
July 2003.
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[8] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[9] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia
Files", RFC 4393, March 2006.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable
Bit Rate Audio with Secure RTP", RFC 6562, March 2012.17.2. Informative References
[14] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-B
v1.0, May 2007, <http://www.3gpp2.org/public_html/specs/
C.S0050-B_v1.0_070521.pdf>.
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.Author's Address 💌
Zheng Fang
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA 92126
USA
Phone: +1 858 651 9484
EMail: zfang@qualcomm.com
URI: http://www.qualcomm.comThat's the whole spec, bestie! 🦋💖
📦 where this page comes from
- ietf: rfc6884 2013-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms