summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5188.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5188.txt')
-rw-r--r--doc/rfc/rfc5188.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc5188.txt b/doc/rfc/rfc5188.txt
new file mode 100644
index 0000000..aa87f4a
--- /dev/null
+++ b/doc/rfc/rfc5188.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group H. Desineni
+Request for Comments: 5188 Qualcomm
+Updates: 4788 Q. Xie
+Category: Standards Track Motorola
+ February 2008
+
+
+ RTP Payload Format for
+ the Enhanced Variable Rate Wideband Codec (EVRC-WB)
+ and the Media Subtype Updates for EVRC-B Codec
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document specifies Real-time Transport Protocol (RTP) payload
+ formats to be used for the Enhanced Variable Rate Wideband Codec
+ (EVRC-WB) and updates the media type registrations for EVRC-B codec.
+ Several media type registrations are included for EVRC-WB RTP payload
+ formats. In addition, a file format is specified for transport of
+ EVRC-WB speech data in storage mode applications such as email.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 1]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. EVRC-WB Codec . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 5. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 7. Congestion Control Considerations . . . . . . . . . . . . . . 5
+ 8. Storage Format for the EVRC-WB Codec . . . . . . . . . . . . . 5
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 5
+ 9.1.1. Registration of Media Type audio/EVRCWB . . . . . . . 6
+ 9.1.2. Registration of Media Type audio/EVRCWB0 . . . . . . . 8
+ 9.1.3. Registration of Media Type audio/EVRCWB1 . . . . . . . 9
+ 9.1.4. Updated Registration of Media Type audio/EVRCB . . . . 11
+ 9.1.5. Updated Registration of Media Type audio/EVRCB0 . . . 13
+ 10. SDP Mode Attributes for EVRC-WB and EVRC-B . . . . . . . . . . 15
+ 11. EVRC-B Interoperability with Legacy Implementations (RFC 4788) 15
+ 12. Mapping EVRC-WB Media Type Parameters into SDP . . . . . . . . 16
+ 13. Mapping EVRC-B Media Type Parameters into SDP . . . . . . . . 16
+ 14. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 16
+ 15. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 18
+ 16. Declarative SDP Considerations . . . . . . . . . . . . . . . . 18
+ 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 18. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 19. Changes to RFC 4788 . . . . . . . . . . . . . . . . . . . . . 22
+ 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 20.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 20.2. Informative References . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 2]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+1. Introduction
+
+ This document specifies the payload formats for packetization of
+ EVRC-WB encoded speech signals into the Real-time Transport Protocol
+ (RTP). It defines support for the header-free, interleaved/bundled,
+ and compact bundle packet formats for the EVRC-WB codec as well as
+ discontinuous transmission (DTX) support for EVRC-WB encoded speech
+ transported via RTP. The EVRC-WB codec offers better speech quality
+ than the EVRC and EVRC-B codecs. EVRC-WB belongs to the EVRC family
+ of codecs. This document also updates the media type registrations
+ for the EVRC-B codec.
+
+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-WB is a wideband extension of the EVRC-B [4] speech codec
+ developed in the Third Generation Partnership Project 2 (3GPP2) with
+ support for discontinuous transmission (DTX). It provides enhanced
+ (wideband) voice quality.
+
+ The EVRC-WB codec operates on 20-ms frames, and the default sampling
+ rate is 16 kHz. Input and output at an 8-kHz sampling rate are also
+ supported. The EVRC-WB codec can operate in three modes (0, 4, and
+ 7) defined in [5]. EVRC-WB modes 4 and 7 are interoperable with
+ EVRC-B. EVRC-WB mode 4 uses full-rate, 1/2-rate, and 1/8-rate
+ frames. EVRC-WB mode 7 uses only 1/2 rate and 1/8 rate frames. Mode
+ change results in codec output bit-rate change but do not cause any
+ decoding problems at the receiver. For successful decoding, the
+ decoder does not need to know the encoder's current mode of
+ operation. EVRC-WB provides a standardized solution for packetized
+ voice applications that allow transitions between narrowband and
+ wideband telephony. The most important service addressed is IP
+ telephony. Target devices can be IP phones or Voice over IP (VoIP)
+ handsets, media gateways, voice messaging servers, etc.
+
+4. EVRC-WB Codec
+
+ The EVRC-WB codec operates on 20-ms frames. It produces output
+ frames of one of the three different sizes: 171 bits, 80 bits, or 16
+ bits. In addition, there are two zero-bit codec frame types: blank
+ (null) frames and erasure frames. The default sampling rate is 16
+ kHz. Input and output at an 8-kHz sampling rate are also supported.
+
+
+
+
+Desineni & Xie Standards Track [Page 3]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ The frame type values and sizes of the associated codec data frames
+ are listed in the table below:
+
+ Value Rate Total codec data frame size in bytes (and in bits)
+ --------------------------------------------------------------------
+ 0 Blank 0 (0 bit)
+ 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 format of the RTP header is specified in RFC 3550 [6]. The
+ EVRC-WB payload formats (Section 6) use the fields of the RTP header
+ in a manner consistent with RFC 3550 [6].
+
+ EVRC-WB also has the capability to operate with 8-kHz sampled input/
+ output signals. The decoder does not require a priori knowledge
+ about the sampling rate of the original signal at the input of the
+ encoder. The decoder output can be at 8 kHz or 16 kHz regardless of
+ the sampling rate used at the encoder. Therefore, depending on the
+ implementation and the electro acoustic audio capabilities of the
+ devices, the input of the encoder and/or the output of the decoder
+ can be configured at 8 kHz; however, a 16-kHz RTP clock rate MUST
+ always be used. The RTP timestamp is increased by 320 for each 20
+ milliseconds.
+
+ The RTP header marker bit (M) SHALL be set to 1 if the first frame
+ carried in the packet contains a speech frame that is the first in 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 the EVRC-WB codec -- the
+ interleaved/bundled packet format, the header-free packet format, and
+ the compact bundled packet format. For all these formats, the
+ operational details and capabilities, such as Table of Contents
+ (ToC), interleaving, DTX, and bundling, of EVRC-WB are exactly the
+ same as those of EVRC-B, as defined in [3], except that the mode
+ change request field in the ToC MUST be interpreted according to the
+ definition of the RATE_REDUC parameter as defined in EVRC-WB [5].
+ The media type audio/EVRCWB maps to the interleaved/bundled packet
+ format, audio/EVRCWB0 maps to the header-free packet format, and
+ audio/EVRCWB1 maps to the compact bundled packet format.
+
+
+
+
+Desineni & Xie Standards Track [Page 4]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+7. Congestion Control Considerations
+
+ Congestion control for RTP SHALL be used in accordance with RFC 3550
+ [6], and with any applicable RTP profile, e.g., RFC 3551 [11].
+
+ Due to the header overhead, the number of frames encapsulated in each
+ RTP packet influences the overall bandwidth of the RTP stream.
+ Packing more frames in each RTP packet can reduce the number of
+ packets sent and hence the header overhead, at the expense of
+ increased delay and reduced error robustness.
+
+8. Storage Format for the EVRC-WB Codec
+
+ The storage format is used for storing EVRC-WB encoded speech frames,
+ e.g., as a file or email attachment.
+
+ The file begins with a magic number to identify the vocoder that is
+ used. The magic number for EVRC-WB corresponds to the ASCII
+ character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57
+ 0x42 0x0A".
+
+ The codec data frames are stored in consecutive order, with a single
+ ToC entry field, extended to one octet, prefixing each codec data
+ frame. The 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) is stored as 0x04. See Section 4 for the
+ mapping from frame type to ToC value.
+
+ Speech frames lost in transmission and non-received frames MUST be
+ stored as erasure frames (ToC value of 5) to maintain synchronization
+ with the original media.
+
+9. IANA Considerations
+
+ This document updates the audio/EVRCB and audio/EVRCB0 media types
+ defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes.
+
+9.1. Media Type Registrations
+
+ Following the guidelines in RFC 4855 [9] and RFC 4288 [10], this
+ section registers new 'audio' media subtypes for EVRC-WB and updates
+ the audio/EVRCB and audio/EVRCB0 media type registrations contained
+ in RFC 4788 [3].
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 5]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+9.1.1. Registration of Media Type audio/EVRCWB
+
+ Type name: audio
+
+ Subtype name: EVRCWB
+
+ Required parameters: None
+
+ Optional parameters:
+
+ These parameters apply to RTP transfer only.
+
+ mode-set-recv: A subset of EVRC-WB modes. Possible values are a
+ comma-separated list of modes from the set {0,4,7} (see Table
+ 2.5.1.2-1 in 3GPP2 C.S0014-C). 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 {0,4,7}.
+
+ sendmode: A mode of the EVRC-WB codec. An encoder can use this to
+ signal its current mode of operation. Possible values are 0,4,7 (see
+ Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter
+ signals mode 0.
+
+ ptime: See RFC 4566.
+
+ 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 4288, Section 4.8) and
+ is defined for transfer of EVRC-WB encoded data via RTP using the
+ interleaved/bundled packet format specified in RFC 3558.
+
+ Security considerations: See Section 18 of RFC 5188.
+
+
+
+
+Desineni & Xie Standards Track [Page 6]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Interoperability considerations: None
+
+ Published specification:
+
+ The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer
+ method with the interleaved/bundled packet format via RTP is
+ specified in RFC 3558 and RFC 5188.
+
+ 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
+
+ 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
+
+ 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: #!EVCWB\n (see Section 8 of RFC 5188)
+
+ File extensions: evw, EVW
+
+ Macintosh file type code: None
+
+ Object identifier or OID: None
+
+ EVRC-WB speech frames may also be stored in the file format "3g2"
+ defined in 3GPP2 C.S0050-B, which is identified using the media types
+ "audio/3gpp2" or "video/3gpp2" registered by RFC 4393.
+
+ Person & email address to contact for further information:
+
+ Harikishan Desineni <hd@qualcomm.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage:
+
+ When this media type is used in the context of transfer over RTP, the
+ RTP payload format specified in Section 4.1 of RFC 3558 SHALL be
+ used. In all other contexts, the file format defined in Section 8 of
+ RFC 5188 SHALL be used.
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 7]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Author:
+
+ Harikishan Desineni
+
+ Change controller:
+
+ IETF Audio/Video Transport working group delegated from the IESG.
+
+9.1.2. Registration of Media Type audio/EVRCWB0
+
+ Type name: audio
+
+ Subtype name: EVRCWB0
+
+ Required parameters: None
+
+ Optional parameters:
+
+ These parameters apply to RTP transfer only.
+
+ mode-set-recv: A subset of EVRC-WB modes. Possible values are a
+ comma-separated list of modes from the set {0,4,7} (see Table
+ 2.5.1.2-1 in 3GPP2 C.S0014-C). 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 {0,4,7}.
+
+ sendmode: A mode of the EVRC-WB codec. An encoder can use this to
+ signal its current mode of operation. Possible values are 0,4,7 (see
+ Table 2.5.1.2-1 in 3GPP2 C.S0014-C). Absence of this parameter
+ signals mode 0.
+
+ 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 4288, Section 4.8) and
+ is defined for transfer of EVRC-WB encoded data via RTP using the
+ header-free packet format specified in RFC 3558.
+
+ Security considerations: See Section 18 of RFC 5188.
+
+
+
+Desineni & Xie Standards Track [Page 8]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Interoperability considerations: None
+
+ Published specification:
+
+ The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer
+ method with the header-free packet format via RTP is specified in RFC
+ 3558 and RFC 5188.
+
+ 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
+
+ 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
+
+ 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:
+
+ Harikishan Desineni <hd@qualcomm.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage:
+
+ This media type depends on RTP framing and hence is only defined for
+ transfer via RTP [6]; the RTP payload format specified in Section 4.2
+ of RFC 3558 SHALL be used. This media type SHALL NOT be used for
+ storage or file transfer using the file format defined in Section 8
+ of RFC 5188; instead, audio/EVRCWB SHALL be used.
+
+ Author:
+
+ Harikishan Desineni
+
+ Change controller:
+
+ IETF Audio/Video Transport working group delegated from the IESG.
+
+9.1.3. Registration of Media Type audio/EVRCWB1
+
+ Type name: audio
+
+ Subtype name: EVRCWB1
+
+ Required parameters: None
+
+
+
+Desineni & Xie Standards Track [Page 9]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Optional parameters:
+
+ These parameters apply to RTP transfer only.
+
+ mode-set-recv: A subset of EVRC-WB modes. Possible values are a
+ comma-separated list of modes from the set {0,4,7} (see Table
+ 2.5.1.2-1 in 3GPP2 C.S0014-C). A decoder can use this attribute to
+ inform an encoder of its preference to operate in a specified subset
+ of modes. A value of 0 signals the support for wideband fixed rate
+ (full or half rate, depending on the value of the 'fixedrate'
+ parameter). A value of 4 signals narrowband fixed full rate. A
+ value of 7 signals narrowband fixed half rate. Absence of this
+ parameter signals mode 0.
+
+ sendmode: A mode of the EVRC-WB codec. An encoder can use this to
+ signal its current mode of operation. Possible values are 0,4,7 (see
+ Table 2.5.1.2-1 in 3GPP2 C.S0014-C). 'sendmode' with value 0 signals
+ wideband fixed-rate operation (full or half rate, depending on the
+ value of the 'fixedrate' parameter). 'sendmode' with value 4 signals
+ narrowband fixed full-rate operation. 'sendmode' with value 7 signals
+ narrowband fixed half-rate operation. The 'fixedrate' parameter MUST
+ NOT be present when the 'sendmode' value is 4 or 7. Absence of this
+ parameter signals mode 0.
+
+ ptime: See RFC 4566.
+
+ maxptime: See RFC 4566.
+
+ fixedrate: Indicates the EVRC-WB rate of the session while in single-
+ rate operation. Valid values include 0.5 and 1, where a value of 0.5
+ indicates the 1/2 rate while a value of 1 indicates the full rate.
+ If this parameter is not present, 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 4288, Section 4.8) and
+ is defined for transfer of EVRC-WB encoded data via RTP using the
+ compact bundle packet format specified in RFC 4788.
+
+ Security considerations: See Section 18 of RFC 5188.
+
+
+
+Desineni & Xie Standards Track [Page 10]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Interoperability considerations: None
+
+ Published specification:
+
+ The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. The transfer
+ method with the compact bundled packet format via RTP is specified in
+ RFC 4788 and RFC 5188.
+
+ 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
+
+ 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
+
+ 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:
+
+ Harikishan Desineni <hd@qualcomm.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage:
+
+ This media type depends on RTP framing and hence is only defined for
+ transfer via RTP [6]; 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 using the file format defined in Section 8
+ of RFC 5188; instead, audio/EVRCWB SHALL be used.
+
+ Author:
+
+ Harikishan Desineni
+
+ Change controller:
+
+ IETF Audio/Video Transport working group delegated from the IESG.
+
+9.1.4. Updated Registration of Media Type audio/EVRCB
+
+ Type name: audio
+
+ Subtype name: EVRCB
+
+ Required parameters: None
+
+
+
+Desineni & Xie Standards Track [Page 11]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Optional parameters:
+
+ These parameters apply to RTP transfer only.
+
+ recvmode: A mode of the EVRC-B codec. A decoder can use this
+ attribute to inform an encoder of its preference to operate in a
+ specified mode. Possible values are 0..7 (see the encoder operating
+ point column in Table 2-6 of 3GPP2 C.S0014-B).
+
+ sendmode: A mode of the EVRC-B codec. An encoder can use this to
+ signal its current mode of operation. Possible values are 0..7 (see
+ encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
+
+ ptime: See RFC 4566.
+
+ maxptime: See RFC 4566.
+
+ maxinterleave: Maximum number for interleaving length (field LLL in
+ the Interleaving Octet). 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 of RFC 4788 for a definition. If this
+ parameter is not present, the default value 1 MUST be assumed.
+
+ dtxmax: See Section 6.1 of RFC 4788.
+
+ dtxmin: See Section 6.1 of RFC 4788.
+
+ hangover: See Section 6.1 of RFC 4788.
+
+ Encoding considerations:
+
+ This media type is framed binary data (see RFC 4288, Section 4.8) and
+ is defined for transfer of EVRC-B encoded data via RTP using the
+ interleaved/bundled packet format specified in RFC 3558.
+
+ Security considerations: See Section 9 of RFC 4788.
+
+ Interoperability considerations: None
+
+ Published specification:
+
+ The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer
+ method with the interleaved/bundled packet format via RTP is
+ specified in RFC 3558, RFC 4788, and RFC 5188.
+
+
+
+
+
+Desineni & Xie Standards Track [Page 12]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ 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 information applies for the
+ storage format only.
+
+ Magic number: #!EVRC-B\n (see Section 5 of RFC 4788)
+
+ File extensions: evb, EVB
+
+ Macintosh file type code: None
+
+ Object identifier or OID: None
+
+ Person & email address to contact for further information:
+
+ Harikishan Desineni <hd@qualcomm.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage:
+
+ When this media type is used in the context of transfer over RTP, the
+ RTP payload format specified in Section 4.1 of RFC 3558 SHALL be
+ used. In all other contexts, the file format defined in Section 5 of
+ RFC 4788 SHALL be used.
+
+ Author:
+
+ Qiaobing Xie / Harikishan Desineni
+
+ Change controller:
+
+ IETF Audio/Video Transport working group delegated from the IESG.
+
+9.1.5. Updated Registration of Media Type audio/EVRCB0
+
+ Type name: audio
+
+ Subtype name: EVRCB0
+
+ Required parameters: None
+
+ Optional parameters:
+
+ These parameters apply to RTP transfer only.
+
+
+
+Desineni & Xie Standards Track [Page 13]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ recvmode: A mode of the EVRC-B codec. A decoder can use this
+ attribute to inform an encoder of its preference to operate in a
+ specified mode. Possible values are 0..7 (see the encoder operating
+ point column in Table 2-6 of 3GPP2 C.S0014-B).
+
+ sendmode: A mode of the EVRC-B codec. An encoder can use this to
+ signal its current mode of operation. Possible values are 0..7 (see
+ the encoder operating point column in Table 2-6 of 3GPP2 C.S0014-B).
+
+ silencesupp: See Section 6.1 of RFC 4788 for a definition. If this
+ parameter is not present, the default value 1 MUST be assumed.
+
+ dtxmax: see Section 6.1 of RFC 4788.
+
+ dtxmin: see Section 6.1 of RFC 4788.
+
+ hangover: see Section 6.1 of RFC 4788.
+
+ Encoding considerations:
+
+ This media type is framed binary data (see RFC 4288, Section 4.8) and
+ is defined for transfer of EVRC-B encoded data via RTP using the
+ header-free packet format specified in RFC 3558.
+
+ Security considerations: See Section 9 of RFC 4788.
+
+ Interoperability considerations: None
+
+ Published specification:
+
+ The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. The transfer
+ method with the header-free packet format via RTP is specified in RFC
+ 3558, RFC 4788, and RFC 5188.
+
+ 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:
+
+ Harikishan Desineni <hd@qualcomm.com>
+
+ Intended usage: COMMON
+
+
+
+
+
+Desineni & Xie Standards Track [Page 14]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Restrictions on usage:
+
+ When this media type is used in the context of transfer over RTP, the
+ RTP payload format specified in Section 4.2 of RFC 3558 SHALL be
+ used.
+
+ This media type depends on RTP framing and hence is only defined for
+ transfer via RTP [6]; the RTP payload format specified in Section 4.2
+ of RFC 3558 SHALL be used. This media type SHALL NOT be used for
+ storage or file transfer using the file format defined in Section 5
+ of RFC 4788; instead, audio/EVRCB SHALL be used.
+
+ Author:
+
+ Qiaobing Xie / Harikishan Desineni
+
+ Change controller:
+
+ IETF Audio/Video Transport working group delegated from the IESG.
+
+10. SDP Mode Attributes for EVRC-WB and EVRC-B
+
+ 'sendmode' can be used by a sender (EVRC-WB or EVRC-B) to announce
+ its encoder's current mode of operation. A sender can change its
+ mode anytime, and this does not cause any decoding problems at the
+ receiver.
+
+ 'recvmode' is defined for use with EVRC-B. A decoder can use this
+ attribute to inform an encoder of its preference to operate in a
+ specified mode. The receiver will continue to decode properly even
+ if the sender does not operate in the preferred mode.
+
+ 'mode-set-recv' is defined for use with EVRC-WB. A decoder can use
+ this attribute to inform an encoder of its preference to operate in a
+ specified subset of modes. The receiver will continue to decode
+ properly even if the sender does not operate in one of the preferred
+ modes. A set has been defined so that several modes can be expressed
+ as a preference in one attempt. For instance, the set {4,7} signals
+ that the receiver prefers the sender to operate in narrowband modes
+ of EVRC-WB.
+
+11. EVRC-B Interoperability with Legacy Implementations (RFC 4788)
+
+ This document adds new optional parameters "recvmode" and "sendmode"
+ to the original EVRC-B media types "audio/EVRCB" and "audio/EVRCB0"
+ defined in RFC 4788 [3]. Existing RFC 4788 [3] implementations will
+ not send these parameters in the Session Description Protocol (SDP)
+ and will ignore them if they are received. This will allow
+
+
+
+Desineni & Xie Standards Track [Page 15]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ interoperability between RFC 4788 [3] and RFC 5188 implementations of
+ EVRC-B. For an example offer-and-answer exchange, see Section 17.
+
+12. Mapping EVRC-WB Media Type Parameters into SDP
+
+ Information carried in the media type specification has a specific
+ mapping to fields in the Session Description Protocol (SDP) [8],
+ which is commonly used to describe RTP sessions. When SDP is used to
+ specify sessions employing EVRC-WB encoded speech, the mapping is as
+ follows.
+
+ o The media type ("audio") goes in SDP "m=" as the media name.
+
+ o The media subtype ("EVRCWB", "EVRCWB0", or "EVRCWB1") goes in SDP
+ "a=rtpmap" as the encoding name.
+
+ o The optional parameters 'ptime' and 'maxptime' (for subtypes
+ EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime"
+ attributes, respectively.
+
+ o Any remaining parameters (for subtypes EVRCWB, EVRCWB0, and
+ EVRCWB1) go in the SDP "a=fmtp" attribute by copying them from the
+ media type string as a semicolon-separated list of parameter=value
+ pairs.
+
+13. Mapping EVRC-B Media Type Parameters into SDP
+
+ The new optional parameters 'recvmode' and 'sendmode' (for 'audio'
+ subtypes EVRCB and EVRCB0) go in the SDP "a=fmtp" attribute by
+ copying them directly from the media type string.
+
+ For all other media type parameters, the specification in Section 6.7
+ of RFC 4788 [3] still applies.
+
+14. Offer-Answer Model Considerations for EVRC-WB
+
+ The following considerations apply when using the SDP offer-answer
+ procedures of RFC 3264 [7] to negotiate the use of EVRC-WB payload in
+ RTP:
+
+ o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD
+ announce EVRC-B support in its "m=audio" line, with EVRC-WB as the
+ preferred codec. This will allow interoperability with an
+ answerer that supports only EVRC-B.
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 16]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Below is an example of such an offer:
+
+ m=audio 55954 RTP/AVP 98 99
+ a=rtpmap:98 EVRCWB0/16000
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:98 mode-set-recv=0,4;sendmode=0
+ a=fmtp:99 recvmode=0 sendmode=4
+
+ If the answerer supports EVRC-WB, then the answerer can keep the
+ payload type 98 in its answer and the conversation can be done using
+ EVRC-WB. Else, if the answerer supports only EVRC-B, then the
+ answerer will leave only the payload type 99 in its answer and the
+ conversation will be done using EVRC-B.
+
+ An example answer for the above offer is the following:
+
+ m=audio 55954 RTP/AVP 98
+ a=rtpmap:98 EVRCWB0/16000
+ a=fmtp:98 mode-set-recv=4;sendmode=4
+
+ o 'mode-set-recv' is a unidirectional receive-only parameter.
+
+ o 'sendmode' is a unidirectional send-only parameter.
+
+ o Using 'sendmode', a sender can signal its current mode of
+ operation. Note that a receiver may receive RTP media well before
+ the arrival of SDP with a (first-time, or updated) 'sendmode'
+ parameter.
+
+ o An offerer can use 'mode-set-recv' to request that the remote
+ sender's encoder be limited to the list of modes signaled in
+ 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv'
+ requests.
+
+ o The parameters 'maxptime' and 'ptime' will in most cases not
+ affect interoperability; however, the setting of the parameters
+ can affect the performance of the application. The SDP offer-
+ answer handling of the 'ptime' parameter is described in RFC 3264
+ [7]. The 'maxptime' parameter MUST be handled in the same way.
+
+ o For a sendonly stream, the 'mode-set-recv' parameter is not useful
+ and SHOULD NOT be used.
+
+ o For a recvonly stream, the 'sendmode' parameter is not useful and
+ SHOULD NOT be used.
+
+ o When using EVRCWB1, the entire session MUST use the same fixed
+ rate and mode (0-Wideband or 4,7-Narrowband).
+
+
+
+Desineni & Xie Standards Track [Page 17]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ o For additional rules that MUST be followed while negotiating DTX
+ parameters, see Section 6.8 in [3].
+
+ o Any unknown parameter in an SDP offer MUST be ignored by the
+ receiver and MUST NOT be included in the SDP answer.
+
+15. Offer-Answer Model Considerations for EVRC-B
+
+ See Section 6.8 of [3] for offer-answer usage of EVRC-B. The
+ following are several additional considerations for EVRC-B.
+
+ o 'recvmode' is a unidirectional receive-only parameter.
+
+ o 'sendmode' is a unidirectional send-only parameter.
+
+ o Using 'recvmode', a receiver can signal the remote sender to
+ operate its encoder in the specified mode. A remote sender MAY
+ ignore 'recvmode' requests.
+
+ o Using 'sendmode', a sender can signal its current mode of
+ operation. Note that a receiver may receive RTP media well before
+ the arrival of SDP with a (first-time, or updated) 'sendmode'
+ parameter.
+
+ o For a sendonly stream, the 'recvmode' parameter is not useful and
+ SHOULD NOT be used.
+
+ o For a recvonly stream, the 'sendmode' parameter is not useful and
+ SHOULD NOT be used.
+
+16. Declarative SDP Considerations
+
+ For declarative use of SDP in the Session Announcement Protocol (SAP)
+ [12] and the Real Time Streaming Protocol (RTSP) [13], the following
+ considerations apply:
+
+ o Any 'maxptime' and 'ptime' values should be selected with care to
+ ensure that the session's participants can achieve reasonable
+ performance.
+
+ o 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 17.
+
+
+
+
+
+Desineni & Xie Standards Track [Page 18]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+17. Examples
+
+ Some example SDP session descriptions utilizing EVRC-WB and EVRC-B
+ encodings follow. In these examples, long a=fmtp lines are folded to
+ meet the column width constraints of this document. The backslash
+ ("\") at the end of a line and the carriage return that follows it
+ should be ignored. Note that media subtype names are case-
+ insensitive. Parameter names are case-insensitive both in media
+ types and in the mapping to the SDP a=fmtp attribute.
+
+ Example usage of EVRCWB:
+
+ m=audio 49120 RTP/AVP 97 98
+ a=rtpmap:97 EVRCWB/16000
+ a=rtpmap:98 EVRCB0/8000
+ a=fmtp:97 mode-set-recv=0,4;sendmode=0
+ a=fmtp:98 recvmode=0 sendmode=0
+ a=maxptime:120
+
+ Example usage of EVRCWB0:
+
+ m=audio 49120 RTP/AVP 97 98
+ a=rtpmap:97 EVRCWB0/16000
+ a=rtpmap:98 EVRCB0/8000
+ a=fmtp:97 mode-set-recv=0,4;sendmode=0
+ a=fmtp:98 recvmode=0 sendmode=0
+
+ Example SDP answer from a media gateway requesting a terminal to
+ limit its encoder operation to EVRC-WB mode 4:
+
+ m=audio 49120 RTP/AVP 97
+ a=rtpmap:97 EVRCWB0/16000
+ a=fmtp:97 mode-set-recv=4;sendmode=4
+
+ Example usage of EVRCWB1:
+
+ m=audio 49120 RTP/AVP 97 98
+ a=rtpmap:97 EVRCWB1/16000
+ a=fmtp:97 mode-set-recv=4;sendmode=4
+ a=maxptime:100
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 19]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Example usage of EVRCWB with DTX with silencesupp=1:
+
+ m=audio 49120 RTP/AVP 97 98
+ a=rtpmap:97 EVRCWB/16000
+ a=rtpmap:98 EVRCB0/8000
+ a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \
+ mode-set-recv=0,4; sendmode=0
+ a=fmtp:98 recvmode=0 sendmode=0
+ a=maxptime:120
+
+ Example usage of EVRCWB with DTX with silencesupp=0:
+
+ m=audio 49120 RTP/AVP 97 98
+ a=rtpmap:97 EVRCWB/16000
+ a=rtpmap:98 EVRCB0/8000
+ a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \
+ mode-set-recv=0,4;sendmode=0
+ a=fmtp:98 recvmode=0 sendmode=0
+ a=maxptime:120
+
+ Example usage of EVRCB:
+
+ m=audio 49120 RTP/AVP 97
+ a=rtpmap:97 EVRCB/8000
+ a=fmtp:97 recvmode=0 sendmode=4
+ a=maxptime:120
+
+ Example usage of EVRCB0:
+
+ m=audio 49120 RTP/AVP 97
+ a=rtpmap:97 EVRCB0/8000
+ a=fmtp:97 recvmode=0 sendmode=4
+
+ Example offer-answer exchange between EVRC-WB and
+ legacy EVRC-B (RFC 4788):
+
+ Offer:
+
+ m=audio 55954 RTP/AVP 98 99
+ a=rtpmap:98 EVRCWB0/16000
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:98 mode-set-recv=0,4;sendmode=0
+ a=fmtp:99 recvmode=0 sendmode=0
+
+ Answer:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+
+
+
+Desineni & Xie Standards Track [Page 20]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Example offer-answer exchange between EVRC-WB and
+ updated EVRC-B (RFC 5188):
+
+ Offer:
+
+ m=audio 55954 RTP/AVP 98 99
+ a=rtpmap:98 EVRCWB0/16000
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:98 mode-set-recv=0,4; sendmode=0
+ a=fmtp:99 recvmode=0 sendmode=0
+
+ Answer:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:99 recvmode=0 sendmode=4
+
+ In the above example, note that the answerer has chosen
+ to send in mode 4 even though the offerer was willing to
+ receive in mode 0. 'recvmode' is a receiver's preference,
+ but the sender can send in a different mode.
+
+ Example offer-answer exchanges for interoperability between
+ legacy (RFC 4788) and updated EVRC-B (RFC 5188) implementations:
+
+ Offer from an offerer that supports updated EVRC-B (RFC 5188)
+ implementation:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:99 recvmode=0 sendmode=4
+
+ Answer from an answerer that supports only
+ legacy EVRC-B (RFC 4788) implementation:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+
+ Offer from an offerer that supports only
+ legacy EVRC-B (RFC 4788) implementation:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 21]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ Answer from an answerer that supports updated
+ EVRC-B (RFC 5188) implementation:
+
+ m=audio 55954 RTP/AVP 99
+ a=rtpmap:99 EVRCB0/8000
+ a=fmtp:99 recvmode=0 sendmode=4
+
+18. Security Considerations
+
+ Since compression is applied to the payload formats end-to-end, and
+ the encodings do not exhibit significant non-uniformity,
+ implementations of this specification are subject to all the security
+ considerations specified in RFC 3558 [2]. Implementations using the
+ payload defined in this specification are subject to the security
+ considerations discussed in RFC 3558 [2], RFC 3550 [6], and any
+ appropriate profile (for example, RFC 3551 [11]).
+
+19. Changes to RFC 4788
+
+ This document updates RFC 4788 [3], and the updates are summarized
+ below:
+
+ o Added new media type attribute "sendmode" to media subtypes EVRCB
+ and EVRCB0. This attribute can be used to signal the EVRC-B
+ encoder's current mode of operation.
+
+ o Added new media type attribute "recvmode" to media subtypes EVRCB
+ and EVRCB0. This attribute can be used to signal the EVRC-B
+ decoder's preferred operating mode to a remote sender.
+
+20. References
+
+20.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
+ (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
+ July 2003.
+
+ [3] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for
+ EVRC Family Codecs", RFC 4788, January 2007.
+
+ [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68
+ for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B
+ v1.0 , May 2006.
+
+
+
+
+Desineni & Xie Standards Track [Page 22]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+ [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and
+ 70 for Wideband Spread Spectrum Digital Systems", 3GPP2
+ C.S0014-C v1.0 , October 2006.
+
+ [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, March 1997.
+
+ [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [9] Casner, S., "Media Type Specifications and Registration
+ Procedures", RFC 4855, February 2007.
+
+ [10] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+20.2. Informative References
+
+ [11] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
+
+ [12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
+ Protocol", RFC 2974, October 2000.
+
+ [13] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
+ Protocol (RTSP)", RFC 2326, April 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 23]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+Authors' Addresses
+
+ Harikishan Desineni
+ Qualcomm
+ 5775 Morehouse Drive
+ San Diego, CA 92126
+ USA
+
+ Phone: +1 858 845 8996
+ EMail: hd@qualcomm.com
+ URI: http://www.qualcomm.com
+
+
+ Qiaobing Xie
+ Motorola
+ 1501 W. Shure Drive, 2-F9
+ Arlington Heights, IL 60004
+ USA
+
+ Phone: +1-847-372-8481
+ EMail: Qiaobing.Xie@Gmail.com
+ URI: http://www.motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 24]
+
+RFC 5188 EVRC-WB RTP Payload Format February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Desineni & Xie Standards Track [Page 25]
+