draft-ietf-avt-rtp-evrc-wb-00.txt   draft-ietf-avt-rtp-evrc-wb-01.txt 
Network Working Group H. Desineni Network Working Group H. Desineni
Internet-Draft Qualcomm Internet-Draft Qualcomm
Updates: 4788 (if approved) Q. Xie Updates: 4788 (if approved) Q. Xie
Expires: July 15, 2007 Motorola Intended status: Standards Track Motorola
January 11, 2007 Expires: October 6, 2007 April 4, 2007
RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec
draft-ietf-avt-rtp-evrc-wb-00.txt draft-ietf-avt-rtp-evrc-wb-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 15, 2007. This Internet-Draft will expire on October 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies real-time transport protocol (RTP) payload This document specifies real-time transport protocol (RTP) payload
formats to be used for the EVRC wideband codec (EVRC-WB) and updates formats to be used for the EVRC wideband codec (EVRC-WB) and updates
the MIME registrations for EVRC-B codec. Several media type the MIME registrations for EVRC-B codec. Several media type
registrations are included for EVRC-WB RTP payload formats. In registrations are included for EVRC-WB RTP payload formats. In
addition, a file format is specified for transport of EVRC-WB speech addition, a file format is specified for transport of EVRC-WB speech
data in storage mode applications such as e-mail. data in storage mode applications such as e-mail.
skipping to change at page 2, line 21 skipping to change at page 2, line 30
5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7 5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7
6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Congestion Control Considerations . . . . . . . . . . . . . . 9 7. Congestion Control Considerations . . . . . . . . . . . . . . 9
8. Storage format for EVRC-WB Codec . . . . . . . . . . . . . . . 10 8. Storage format for EVRC-WB Codec . . . . . . . . . . . . . . . 10
9. Media type definitions . . . . . . . . . . . . . . . . . . . . 11 9. Media type definitions . . . . . . . . . . . . . . . . . . . . 11
9.1. Registration of Media Type EVRCWB . . . . . . . . . . . . 11 9.1. Registration of Media Type EVRCWB . . . . . . . . . . . . 11
9.2. Registration of Media Type EVRCWB0 . . . . . . . . . . . . 13 9.2. Registration of Media Type EVRCWB0 . . . . . . . . . . . . 13
9.3. Registration of Media Type EVRCWB1 . . . . . . . . . . . . 15 9.3. Registration of Media Type EVRCWB1 . . . . . . . . . . . . 15
9.4. Updated Registration of Media Type EVRCB . . . . . . . . . 17 9.4. Updated Registration of Media Type EVRCB . . . . . . . . . 17
9.5. Updated Registration of Media Type EVRCB0 . . . . . . . . 19 9.5. Updated Registration of Media Type EVRCB0 . . . . . . . . 19
9.6. Updated Registration of Media Type EVRCB1 . . . . . . . . 20
10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC
4788) implementations . . . . . . . . . . . . . . . . . . . . 23 4788) implementations . . . . . . . . . . . . . . . . . . . . 21
11. Mapping MIME Parameters into SDP . . . . . . . . . . . . . . . 24 11. Mapping EVRC-WB MIME Parameters into SDP . . . . . . . . . . . 22
12. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 25 12. Mapping EVRC-B MIME Parameters into SDP . . . . . . . . . . . 23
13. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 27 13. Offer-Answer Model Considerations for EVRC-WB . . . . . . . . 24
14. Declarative SDP Considerations . . . . . . . . . . . . . . . . 28 14. Offer-Answer Model Considerations for EVRC-B . . . . . . . . . 26
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. Declarative SDP Considerations . . . . . . . . . . . . . . . . 27
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17. Security Considerations . . . . . . . . . . . . . . . . . . . 34 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 18. Security Considerations . . . . . . . . . . . . . . . . . . . 33
18.1. Normative References . . . . . . . . . . . . . . . . . . . 35 19. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . . 35 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
20.1. Normative References . . . . . . . . . . . . . . . . . . . 35
20.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
This document specifies the payload formats for packetization of This document specifies the payload formats for packetization of
EVRC-WB encoded speech signals into the real-time transport protocol EVRC-WB encoded speech signals into the real-time transport protocol
(RTP).It defines support for the header-free, interleaved/bundled and (RTP).It defines support for the header-free, interleaved/bundled and
compact bundle packet formats for the EVRC-WB codec as well as compact bundle packet formats for the EVRC-WB codec as well as
discontinuous transmission (DTX) support for EVRC-WB encoded speech discontinuous transmission (DTX) support for EVRC-WB encoded speech
skipping to change at page 5, line 13 skipping to change at page 5, line 13
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Background 3. Background
EVRC-WB is a wideband extension of EVRC-B [4] speech codec developed EVRC-WB is a wideband extension of EVRC-B [4] speech codec developed
in 3GPP2 with support for discontinuous transmission (DTX). It in 3GPP2 with support for discontinuous transmission (DTX). It
provides enhanced (wideband) voice quality. provides enhanced (wideband) voice quality.
EVRC-WB codec operates on 20 ms frames, and the default sampling rate EVRC-WB codec operates on 20 ms frames, and the default sampling rate
is 16 kHz. Input and output at 8 kHz sampling rate is also is 16 kHz. Input and output at 8 kHz sampling rate is also
supported. EVRC-WB modes are defined in [5]. EVRC-WB mode 4 is supported. EVRC-WB modes are defined in [5]. EVRC-WB modes 4,7 are
interoperable with EVRC-B. EVRC-WB provides a standardized solution interoperable with EVRC-B. EVRC-WB provides a standardized solution
for packetized voice applications that allow transitions between for packetized voice applications that allow transitions between
narrowband and wideband telephony. The most important service narrowband and wideband telephony. The most important service
addressed is IP telephony. Target devices can be IP phones or VoIP addressed is IP telephony. Target devices can be IP phones or VoIP
handsets, media gateways, voice messaging servers, etc. handsets, media gateways, voice messaging servers, etc.
4. EVRC-WB codec 4. EVRC-WB codec
EVRC-WB codec operates on 20 ms frames. It produces output frames of 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 one of the three different sizes: 171 bits, 80 bits or 16 bits. In
skipping to change at page 9, line 8 skipping to change at page 9, line 8
the compact bundled packet format. For all these formats, the the compact bundled packet format. For all these formats, the
operational details and capabilities, such as ToC, interleaving, DTX, operational details and capabilities, such as ToC, interleaving, DTX,
and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as and bundling, of EVRC-WB are exactly the same as those of EVRC-B, as
defined in [4], except that the mode change request field in the ToC defined in [4], except that the mode change request field in the ToC
MUST be interpreted according to the definition of the RATE_REDUC MUST be interpreted according to the definition of the RATE_REDUC
parameter as defined in EVRC-WB [5]. parameter as defined in EVRC-WB [5].
7. Congestion Control Considerations 7. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[6], and with any applicable RTP profile; e.g., RFC 3551 [13]. [6], and with any applicable RTP profile; e.g., RFC 3551 [12].
Due to the header overhead, the number of frames encapsulated in each Due to the header overhead, the number of frames encapsulated in each
RTP packet influences the overall bandwidth of the RTP stream. RTP packet influences the overall bandwidth of the RTP stream.
Packing more frames in each RTP packet can reduce the number of Packing more frames in each RTP packet can reduce the number of
packets sent and hence the header overhead, at the expense of packets sent and hence the header overhead, at the expense of
increased delay and reduced error robustness. increased delay and reduced error robustness.
8. Storage format for EVRC-WB Codec 8. Storage format for EVRC-WB Codec
The storage format is used for storing EVRC-WB encoded speech frames, The storage format is used for storing EVRC-WB encoded speech frames,
skipping to change at page 10, line 23 skipping to change at page 10, line 23
0x42 0x0A". 0x42 0x0A".
The codec data frames are stored in consecutive order, with a single The codec data frames are stored in consecutive order, with a single
TOC entry field, extended to one octet, prefixing each codec data TOC entry field, extended to one octet, prefixing each codec data
frame. The ToC field is extended to one octet by setting the four 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 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 of 4 (a full-rate frame) is stored as 0x04. See Section 4 for the
mapping from frame type to ToC value. mapping from frame type to ToC value.
Speech frames lost in transmission and non-received frames MUST be Speech frames lost in transmission and non-received frames MUST be
stored as erasure frames to maintain synchronization with the stored as erasure frames (ToC value of 5) to maintain synchronization
original media. with the original media.
9. Media type definitions 9. Media type definitions
9.1. Registration of Media Type EVRCWB 9.1. Registration of Media Type EVRCWB
Type name: audio Type name: audio
Subtype names: EVRCWB Subtype names: EVRCWB
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
mode-set-recv: A subset of EVRC-WB modes. Possible values are a 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 XX [5]). comma separated list of modes from the set: 0,4,7 (see Table2.5.1.2-1
A decoder can use this to signal an encoder to limit its modes to the [5]). A decoder can use this to signal an encoder to limit its modes
specified subset. Absence of this parameter signals a set of all to the specified subset. Absence of this parameter signals a set of
EVRC-WB modes. all EVRC-WB modes. The default value of 'mode-set-recv' is 0,4,7.
sendmode: A mode of EVRC-WB codec. Encoder can use this to signal sendmode: A mode of EVRC-WB codec. Encoder can use this to signal
its current mode of operation. Possible values are a comma separated its current mode of operation. Possible values are a comma separated
list of modes from the set: 0,4,7 (see Table XX [5]). list of modes from the set: 0,4,7 (see Table2.5.1.2-1 [5]). The
default value of 'sendmode' is 0.
ptime: see RFC 4566 [10]. ptime: see RFC 4566 [9].
maxptime: The maximum amount of media which can be encapsulated in maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST be each packet, expressed as time in milliseconds. The time MUST be
calculated as the sum of the time the media present in the packet calculated as the sum of the time the media present in the packet
represents. The time SHOULD be a multiple of the duration of a represents. The time SHOULD be a multiple of the duration of a
single codec data frame (20 msec). If not signaled, the default single codec data frame (20 msec). If not signaled, the default
maxptime value MUST be 200 milliseconds. maxptime value MUST be 200 milliseconds.
maxinterleave: Maximum number for interleaving length (field LLL in maxinterleave: Maximum number for interleaving length (field LLL in
the Interleaving Octet). The interleaving lengths used in the entire the Interleaving Octet). The interleaving lengths used in the entire
skipping to change at page 12, line 6 skipping to change at page 12, line 7
dtxmin: see Section 6.1 in [2] dtxmin: see Section 6.1 in [2]
hangover: see Section 6.1 in [2] hangover: see Section 6.1 in [2]
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and 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 is defined for transfer of EVRC-WB encoded data via RTP using the
Interleaved/Bundled packet format specified in RFC 3558 [14]. Interleaved/Bundled packet format specified in RFC 3558 [14].
Security considerations: See Section 17 of RFC XXXX. Security considerations: See Section 18 of RFC XXXX.
Interoperability considerations: none Interoperability considerations: none
Published specification: Published specification:
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer
method with Interleaved/Bundled packet format via RTP is specified in method with Interleaved/Bundled packet format via RTP is specified in
RFC 3558 and RFC XXXX. RFC 3558 and RFC XXXX.
3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 specifications are publicly accessible at http://www.3gpp2.org 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
Applications that use this media type: Applications that use this media type:
It is expected that many VoIP applications (as well as mobile It is expected that many VoIP applications (as well as mobile
applications) will use this type. applications) will use this type.
Additional information: Additional information:
skipping to change at page 12, line 38 skipping to change at page 12, line 39
Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) Magic number: #!EVCWB\n (see Section 8 of RFC XXXX)
File extensions: evw, EVW File extensions: evw, EVW
Macintosh file type code: none Macintosh file type code: none
Object identifier or OID: none Object identifier or OID: none
EVRC-WB speech frames may also be stored in the file format "3g2" EVRC-WB speech frames may also be stored in the file format "3g2"
defined in 3GPP2 C.S0050-A, which is identified using the media types defined in 3GPP2 C.S0050-B, which is identified using the media types
"audio/3gpp2" or "video/3gpp2" registered by RFC4393. "audio/3gpp2" or "video/3gpp2" registered by RFC4393.
Person & email address to contact for further information: Person & email address to contact for further information:
Harikishan Desineni <hd@qualcomm.com> Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
skipping to change at page 13, line 25 skipping to change at page 13, line 26
Type name: audio Type name: audio
Subtype names: EVRCWB0 Subtype names: EVRCWB0
Required parameters: Required parameters:
Optional parameters: Optional parameters:
mode-set-recv: A subset of EVRC-WB modes. Possible values are a 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 XX [5]). comma separated list of modes from the set: 0,4,7 (see Table2.5.1.2-1
A decoder can use this to signal an encoder to limit its modes to the [5]). A decoder can use this to signal an encoder to limit its modes
specified subset. Absence of this parameter signals a set of all to the specified subset. Absence of this parameter signals a set of
EVRC-WB modes. all EVRC-WB modes. The default value of 'mode-set-recv' is 0,4,7.
sendmode: A mode of EVRC-WB codec. Encoder can use this to signal sendmode: A mode of EVRC-WB codec. Encoder can use this to signal
its current mode of operation. Possible values are a comma separated its current mode of operation. Possible values are a comma separated
list of modes from the set: 0,4,7 (see Table XX [5]). list of modes from the set: 0,4,7 (see Table2.5.1.2-1 [5]). The
default value of 'sendmode' is 0.
ptime: see RFC 4566 [10]. ptime: see RFC 4566 [9].
silencesupp: see Section 6.1 in [2] silencesupp: see Section 6.1 in [2]
dtxmax: see Section 6.1 in [2] dtxmax: see Section 6.1 in [2]
dtxmin: see Section 6.1 in [2] dtxmin: see Section 6.1 in [2]
hangover: see Section 6.1 in [2] hangover: see Section 6.1 in [2]
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and 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 is defined for transfer of EVRC-WB encoded data via RTP using the
Header-Free packet format specified in RFC 3558. Header-Free packet format specified in RFC 3558.
Security considerations: See Section 17 of RFC XXXX. Security considerations: See Section 18 of RFC XXXX.
Interoperability considerations: none Interoperability considerations: none
Published specification: Published specification:
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C [5]. Transfer
method with header free packet format via RTP is specified in RFC method with header free packet format via RTP is specified in RFC
3558 and RFC XXXX. 3558 and RFC XXXX.
3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 specifications are publicly accessible at http://www.3gpp2.org 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
Applications that use this media type: Applications that use this media type:
It is expected that many VoIP applications (as well as mobile It is expected that many VoIP applications (as well as mobile
applications) will use this type. applications) will use this type.
Additional information: Additional information:
skipping to change at page 14, line 35 skipping to change at page 14, line 37
Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) Magic number: #!EVCWB\n (see Section 8 of RFC XXXX)
File extensions: evw, EVW File extensions: evw, EVW
Macintosh file type code: none Macintosh file type code: none
Object identifier or OID: none Object identifier or OID: none
EVRC-WB speech frames may also be stored in the file format "3g2" EVRC-WB speech frames may also be stored in the file format "3g2"
defined in 3GPP2 C.S0050-A, which is identified using the media types defined in 3GPP2 C.S0050-B, which is identified using the media types
"audio/3gpp2" or "video/3gpp2" registered by RFC4393. "audio/3gpp2" or "video/3gpp2" registered by RFC4393.
Person & email address to contact for further information: Person & email address to contact for further information:
Harikishan Desineni <hd@qualcomm.com> Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
skipping to change at page 15, line 22 skipping to change at page 15, line 24
Type name: audio Type name: audio
Subtype names: EVRCWB1 Subtype names: EVRCWB1
Required parameters: Required parameters:
Optional parameters: Optional parameters:
mode-set-recv: A subset of EVRC-WB modes. Possible values are a 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 XX [5]). comma separated list of modes from the set: 0,4,7 (see Table2.5.1.2-1
A decoder can use this to signal an encoder to limit its modes to the [5]). A decoder can use this to signal an encoder to limit its modes
specified subset. Absence of this parameter signals a set of all to the specified subset. Absence of this parameter signals a set of
EVRC-WB modes. all EVRC-WB modes. Value of 0 signals the support for wideband fixed
rate (full or half rate, depending on the value of 'fixedrate'
parameter). Value of 4 signals narroband fixed full rate. Value of
7 signals narrowband fixed half rate. The default value of 'mode-
set-recv' is 0.
sendmode: A mode of EVRC-WB codec. Encoder can use this to signal sendmode: A mode of EVRC-WB codec. Encoder can use this to signal
its current mode of operation. Possible values are a comma separated its current mode of operation. Possible values are a comma separated
list of modes from the set: 0,4,7 (see Table XX [5]). list of modes from the set: 0,4,7 (see Table2.5.1.2-1 [5]).
'sendmode' with value 0 signals wideband fixed rate (full or half
rate, depending on the value of 'fixedrate' parameter) operation.
'sendmode' with value 4 signals narrowband fixed full rate operation.
'sendmode' with value 7 signals narrowband fixed half rate operation.
'fixedrate' parameter MUST not be present when 'sendmode' value is 4
or 7. The default value of 'sendmode' is 0.
ptime: see RFC 4566 [10]. ptime: see RFC 4566 [9].
maxptime: The maximum amount of media which can be encapsulated in maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST be each packet, expressed as time in milliseconds. The time MUST be
calculated as the sum of the time the media present in the packet calculated as the sum of the time the media present in the packet
represents. The time SHOULD be an integer multiple of the duration represents. The time SHOULD be an integer multiple of the duration
of a single codec data frame (20 msec). If not signaled, the default of a single codec data frame (20 msec). If not signaled, the default
maxptime value MUST be 200 milliseconds. maxptime value MUST be 200 milliseconds.
fixedrate: Indicates the EVRC-WB rate of the session while in single 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 rate operation. Valid values include: 0.5 and 1, where a value of
skipping to change at page 16, line 4 skipping to change at page 16, line 15
0.5 indicates the 1/2 rate while a value of 1 indicates the full 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. rate. If this parameter is not present, 1/2 rate is assumed.
silencesupp: see Section 6.1 in [2] silencesupp: see Section 6.1 in [2]
dtxmax: see Section 6.1 in [2] dtxmax: see Section 6.1 in [2]
dtxmin: see Section 6.1 in [2] dtxmin: see Section 6.1 in [2]
hangover: see Section 6.1 in [2] hangover: see Section 6.1 in [2]
Encoding considerations: Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8) and 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 is defined for transfer of EVRC-WB encoded data via RTP using the
compact bundle packet format specified in RFC 4788. compact bundle packet format specified in RFC 4788.
Security considerations: See Section 17 of RFC XXXX. Security considerations: See Section 18 of RFC XXXX.
Interoperability considerations: none Interoperability considerations: none
Published specification: Published specification:
The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. Transfer method The EVRC-WB vocoder is specified in 3GPP2 C.S0014-C. Transfer method
with compact bundled packet format via RTP is specified in RFC 4788 with compact bundled packet format via RTP is specified in RFC 4788
and RFC XXXX. and RFC XXXX.
3GPP2 C.S0050-A, 3GPP2 File Formats for Multimedia Services. 3GPP2 C.S0050-B, 3GPP2 File Formats for Multimedia Services.
3GPP2 specifications are publicly accessible at http://www.3gpp2.org 3GPP2 specifications are publicly accessible at http://www.3gpp2.org
Applications that use this media type: Applications that use this media type:
It is expected that many VoIP applications (as well as mobile It is expected that many VoIP applications (as well as mobile
applications) will use this type. applications) will use this type.
Additional information: Additional information:
skipping to change at page 16, line 40 skipping to change at page 17, line 4
The following information applies for storage format only. The following information applies for storage format only.
Magic number: #!EVCWB\n (see Section 8 of RFC XXXX) Magic number: #!EVCWB\n (see Section 8 of RFC XXXX)
File extensions: evw, EVW File extensions: evw, EVW
Macintosh file type code: none Macintosh file type code: none
Object identifier or OID: none Object identifier or OID: none
EVRC-WB speech frames may also be stored in the file format "3g2" EVRC-WB speech frames may also be stored in the file format "3g2"
defined in 3GPP2 C.S0050-A, which is identified using the media types defined in 3GPP2 C.S0050-B, which is identified using the media types
"audio/3gpp2" or "video/3gpp2" registered by RFC 4393. "audio/3gpp2" or "video/3gpp2" registered by RFC 4393.
Person & email address to contact for further information: Person & email address to contact for further information:
Harikishan Desineni <hd@qualcomm.com> Harikishan Desineni <hd@qualcomm.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
skipping to change at page 20, line 34 skipping to change at page 21, line 5
is not defined at this time. is not defined at this time.
Author: Author:
Qiaobing Xie / Harikishan Desineni Qiaobing Xie / Harikishan Desineni
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
9.6. Updated Registration of Media Type EVRCB1
Type name: audio
Subtype names: EVRCB1
Required parameters: none
Optional parameters:
recvmode: A mode of EVRC-B codec. A decoder can use this to signal
an encoder to operate in the specified mode. Possible values are a
comma separated list of modes from the set: 0..7 (see encoder
operating point column in Table 2-6 [4]).
sendmode: A mode of EVRC-B codec. An encoder can use this to signal
its current mode of operation. Possible values are a comma separated
list of modes from the set: 0..7 (see encoder operating point column
in Table 2-6 [4]).
silencesupp: see Section 6.1 for definition. If this parameter is
not present, the default value 1 MUST be assumed.
dtxmax: see Section 6.1 of [2]
dtxmin: see Section 6.1 of [2]
hangover: see Section 6.1 of [2]
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
compact bundle packet format specified in RFC 4788.
Security considerations: See Section 9 of RFC 4788.
Interoperability considerations: none
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B. Transfer method
with compact bundle packet format via RTP is specified in RFC 4788
and RFC XXXX.
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 (RFC 3550). Transfer within other framing protocols
is not defined at this time.
Author:
Qiaobing Xie / Harikishan Desineni
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 4788) 10. EVRC-B RFC XXXX Interoperability with legacy EVRC-B (RFC 4788)
implementations implementations
This document adds new optional parameters "recvmode" and "sendmode" This document adds new optional parameters "recvmode" and "sendmode"
to the original EVRC-B payload subtypes "EVRCB", "EVRCB0" and to the original EVRC-B payload subtypes "EVRCB" and "EVRCB0" defined
"EVRCB1" defined in RFC 4788. Since the new parameters are receiver in RFC 4788. Since the new parameters are receiver options, the
options, the existing RFC 4788 implementations will not send these existing RFC 4788 implementations will not send these parameters in
parameters in SDP and will ignore if they are received. This will SDP and will ignore if they are received. This will allow
allow interoperability between RFC 4788 and RFC XXXX implementations interoperability between RFC 4788 and RFC XXXX implementations of
of EVRC-B. For an example offer and answer exchange, see Section 15. EVRC-B. For an example offer and answer exchange, see Section 16.
11. Mapping MIME Parameters into SDP 11. Mapping EVRC-WB MIME Parameters into SDP
Information carried in the MIME media type specification has a Information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[10], which is commonly used to describe RTP sessions. When SDP is [9], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing EVRC-WB encoded speech, the used to specify sessions employing EVRC-WB encoded speech, the
mapping is as follows: mapping is as follows.
The MIME type ("audio") goes in SDP "m=" as the media name. The MIME type ("audio") goes in SDP "m=" as the media name.
o The MIME subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP o The MIME subtype ("EVRCWB", "EVRCWB0" or "EVRCWB1") goes in SDP
"a=rtpmap" as the encoding name. "a=rtpmap" as the encoding name.
o The optional parameters "mode-set-recv" and "sendmode" (for
subtypes EVRCWB, EVRCWB0 and EVRCWB1) go in the SDP "a=fmtp"
attribute by copying them directly from the MIME media type
string.
o The optional parameters "ptime" and "maxptime" (for subtypes o The optional parameters "ptime" and "maxptime" (for subtypes
EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime" EVRCWB, EVRCWB1) go in the SDP "a=ptime" and "a=maxptime"
attributes, respectively. attributes, respectively.
o The optional parameter "maxinterleave" for subtype EVRCWB goes in o Any remaining parameters (for subtypes EVRCWB, EVRCWB0 and
the SDP "a=fmtp" attribute by copying it directly from the MIME EVRCWB1) go in the SDP "a=fmtp" attribute by copying them from the
media type string as "maxinterleave=value". MIME media type string as a semicolon separated list of
parameter=value pairs.
o The optional parameter "fixedrate" for subtypes EVRCWB1 goes in
"a=fmtp" attribute by copying it directly from the MIME media type
string as "fixedrate=value".
o The optional parameters "silencesupp", "dtxmax", "dtxmin", and 12. Mapping EVRC-B MIME Parameters into SDP
"hangover" go in "a=fmtp" attribute by copying them directly from
the MIME media type string as "silencesupp=value", "dtxmax=value",
"dtxmin=value", and "hangover=value", respectively.
o The optional parameters "recvmode" and "sendmode" (for subtypes The optional parameters "recvmode" and "sendmode" (for subtypes EVRCB
EVRCB, EVRCB0 and EVRCB1) go in the SDP "a=fmtp" attribute by and EVRCB0) go in the SDP "a=fmtp" attribute by copying them directly
copying them directly from the MIME media type string. from the MIME media type string.
12. Offer-Answer Model Considerations for EVRC-WB 13. Offer-Answer Model Considerations for EVRC-WB
The following considerations apply when using SDP offer-answer The following considerations apply when using SDP offer-answer
procedures [7] to negotiate the use of EVRC-WB payload in RTP: procedures [7] to negotiate the use of EVRC-WB payload in RTP:
o Since EVRC-WB is an extension of EVRC-B, the offerer SHOULD 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 announce EVRC-B support in its "m=audio" line, with EVRC-WB as the
preferred codec. This will allow interoperability with an preferred codec. This will allow interoperability with an
answerer which supports only EVRC-B. answerer which supports only EVRC-B.
Below is an example of such an offer: Below is an example of such an offer:
m=audio 55954 RTP/AVP 98 99 m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4 sendmode=0 a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=4 a=fmtp:99 recvmode=0 sendmode=4
If the answerer supports EVRC-WB then the answerer can keep the If the answerer supports EVRC-WB then the answerer can keep the
payload type 98 in its answer and the conversation can be done payload type 98 in its answer and the conversation can be done
using EVRC-WB. Else, if the answerer supports only EVRC-B then 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 answerer will leave only the payload type 99 in its answer and
the conversation will be done using EVRC-B. the conversation will be done using EVRC-B.
An example answer for the above offer: An example answer for the above offer:
m=audio 55954 RTP/AVP 98 m=audio 55954 RTP/AVP 98
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=fmtp:98 mode-set-recv=4 sendmode=4 a=fmtp:98 mode-set-recv=4;sendmode=4
o "mode-set-recv" is a uni-directional receive only parameter. o "mode-set-recv" is a uni-directional receive only parameter.
o "sendmode" is a uni-directional send only parameter. o "sendmode" is a uni-directional send only parameter.
o Using "sendmode", a sender can signal its current mode of o Using "sendmode", a sender can signal its current mode of
operation. operation.
o An offerer can use "mode-set-recv" to request that the remote 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 sender's encoder be limited to the list of modes signaled in
skipping to change at page 26, line 11 skipping to change at page 25, line 11
affect the performance of the application. The SDP offer-answer affect the performance of the application. The SDP offer-answer
handling of the "ptime" parameter is described in RFC3264 [7]. handling of the "ptime" parameter is described in RFC3264 [7].
The "maxptime" parameter MUST be handled in the same way. The "maxptime" parameter MUST be handled in the same way.
o For a sendonly stream, "mode-set-recv" parameter is not useful and o For a sendonly stream, "mode-set-recv" parameter is not useful and
SHOULD NOT be used. SHOULD NOT be used.
o For a recvonly stream, "sendmode" parameter is not useful and o For a recvonly stream, "sendmode" parameter is not useful and
SHOULD NOT be used. 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).
o For additional rules which MUST be followed while negotiating DTX o For additional rules which MUST be followed while negotiating DTX
parameters, see Section 6.8 in [2]. parameters, see Section 6.8 in [2].
o Any unknown parameter in an SDP offer MUST be ignored by the o Any unknown parameter in an SDP offer MUST be ignored by the
receiver and MUST NOT be included in the SDP answer. receiver and MUST NOT be included in the SDP answer.
13. Offer-Answer Model Considerations for EVRC-B 14. Offer-Answer Model Considerations for EVRC-B
See Section 6.8 of [2] for offer-answer usage of EVRC-B. The See Section 6.8 of [2] for offer-answer usage of EVRC-B. The
following are several additional considerations for EVRC-B. following are several additional considerations for EVRC-B.
o "recvmode" is a uni-directional receive only parameter. o "recvmode" is a uni-directional receive only parameter.
o "sendmode" is a uni-directional send only parameter. o "sendmode" is a uni-directional send only parameter.
o Using "recvmode", a receiver can signal the remote sender to o Using "recvmode", a receiver can signal the remote sender to
operate its encoder in the specified mode. A remote sender MAY operate its encoder in the specified mode. A remote sender MAY
skipping to change at page 28, line 5 skipping to change at page 27, line 5
o Using "sendmode", a sender can signal its current mode of o Using "sendmode", a sender can signal its current mode of
operation. operation.
o For a sendonly stream, "recvmode" parameter is not useful and o For a sendonly stream, "recvmode" parameter is not useful and
SHOULD NOT be used. SHOULD NOT be used.
o For a recvonly stream, "sendmode" parameter is not useful and o For a recvonly stream, "sendmode" parameter is not useful and
SHOULD NOT be used. SHOULD NOT be used.
14. Declarative SDP Considerations 15. Declarative SDP Considerations
For declarative use of SDP in SAP [15] and RTSP [16] , the following For declarative use of SDP in SAP [15] and RTSP [16] , the following
considerations apply: considerations apply:
o Any "maxptime" and "ptime" values should be selected with care to o Any "maxptime" and "ptime" values should be selected with care to
ensure that the session's participants can achieve reasonable ensure that the session's participants can achieve reasonable
performance. performance.
o The payload format configuration parameters are all declarative o The payload format configuration parameters are all declarative
and a participant MUST use the configuration(s) that is provided and a participant MUST use the configuration(s) that is provided
for the session. More than one configuration may be provided if for the session. More than one configuration may be provided if
necessary by declaring multiple RTP payload types, however the necessary by declaring multiple RTP payload types, however the
number of types should be kept small. number of types should be kept small.
15. Examples 16. Examples
Some example SDP session descriptions utilizing EVRC-WB and EVRC-B Some example SDP session descriptions utilizing EVRC-WB and EVRC-B
encodings follow. In these examples, long a=fmtp lines are folded to encodings follow. In these examples, long a=fmtp lines are folded to
meet the column width constraints of this document. The backslash meet the column width constraints of this document. The backslash
("\") at the end of a line and the carriage return that follows it ("\") at the end of a line and the carriage return that follows it
should be ignored. Note that MIME subtype names are case- should be ignored. Note that MIME subtype names are case-
insensitive. Parameter names are case-insensitive both in MIME types insensitive. Parameter names are case-insensitive both in MIME types
and in the mapping to the SDP a=fmtp attribute. and in the mapping to the SDP a=fmtp attribute.
Example usage of EVRCWB: Example usage of EVRCWB:
m=audio 49120 RTP/AVP 97 98 m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000 a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4 sendmode=0 a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120 a=maxptime:120
Example usage of EVRCWB0: Example usage of EVRCWB0:
m=audio 49120 RTP/AVP 97 98 m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB0/16000 a=rtpmap:97 EVRCWB0/16000
a=rtpmap:98 EVRCB0/8000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 mode-set-recv=0,4 sendmode=0 a=fmtp:97 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
Example SDP answer from a media gateway requesting a terminal to Example SDP answer from a media gateway requesting a terminal to
limit its encoder operation to EVRC-WB mode 4. limit its encoder operation to EVRC-WB mode 4.
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCWB0/16000 a=rtpmap:97 EVRCWB0/16000
a=fmtp:97 mode-set-recv=4 sendmode=4 a=fmtp:97 mode-set-recv=4;sendmode=4
Example usage of EVRCWB1: Example usage of EVRCWB1:
m=audio 49120 RTP/AVP 97 98 m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB1/16000 a=rtpmap:97 EVRCWB1/16000
a=rtpmap:98 EVRCB0/8000 a=fmtp:97 mode-set-recv=4;sendmode=4
a=fmtp:97 fixedrate=0.5 mode-set-recv=4 sendmode=7
a=fmtp:98 recvmode=7 sendmode=7
a=maxptime:100 a=maxptime:100
Example usage of EVRCWB with DTX with silencesupp=1: Example usage of EVRCWB with DTX with silencesupp=1:
m=audio 49120 RTP/AVP 97 98 m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000 a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1 \ a=fmtp:97 silencesupp=1;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4 sendmode=0 mode-set-recv=0,4; sendmode=0
a=fmtp:98 recvmode=0 sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120 a=maxptime:120
Examples usage of EVRCWB with DTX with silencesupp=0: Examples usage of EVRCWB with DTX with silencesupp=0:
m=audio 49120 RTP/AVP 97 98 m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 EVRCWB/16000 a=rtpmap:97 EVRCWB/16000
a=rtpmap:98 EVRCB0/8000 a=rtpmap:98 EVRCB0/8000
a=fmtp:97 silencesupp=0 dtxmax=32 dtxmin=12 hangover=1 \ a=fmtp:97 silencesupp=0;dtxmax=32;dtxmin=12;hangover=1 \
mode-set-recv=0,4 sendmode=0 mode-set-recv=0,4;sendmode=0
a=fmtp:98 recvmode=0 sendmode=0 a=fmtp:98 recvmode=0 sendmode=0
a=maxptime:120 a=maxptime:120
Example usage of EVRCB: Example usage of EVRCB:
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000 a=rtpmap:97 EVRCB/8000
a=fmtp:97 recvmode=0 sendmode=4 a=fmtp:97 recvmode=0 sendmode=4
a=maxptime:120 a=maxptime:120
Example usage of EVRCB0: Example usage of EVRCB0:
m=audio 49120 RTP/AVP 97 m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000 a=rtpmap:97 EVRCB0/8000
a=fmtp:97 recvmode=0 sendmode=4 a=fmtp:97 recvmode=0 sendmode=4
Example usage of EVRCB1:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5 recvmode=7 sendmode=7
a=maxptime:100
Example offer answer exchange between EVRC-WB and Example offer answer exchange between EVRC-WB and
legacy EVRC-B (RFC 4788): legacy EVRC-B (RFC 4788):
Offer: Offer:
m=audio 55954 RTP/AVP 98 99 m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4 sendmode=0 a=fmtp:98 mode-set-recv=0,4;sendmode=0
a=fmtp:99 recvmode=0 sendmode=0 a=fmtp:99 recvmode=0 sendmode=0
Answer: Answer:
m=audio 55954 RTP/AVP 99 m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
Example offer answer exchange between EVRC-WB and Example offer answer exchange between EVRC-WB and
updated EVRC-B (RFC XXXX): updated EVRC-B (RFC XXXX):
Offer: Offer:
m=audio 55954 RTP/AVP 98 99 m=audio 55954 RTP/AVP 98 99
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:98 mode-set-recv=0,4 sendmode=0 a=fmtp:98 mode-set-recv=0,4; sendmode=0
a=fmtp:99 recvmode=0 sendmode=0 a=fmtp:99 recvmode=0 sendmode=0
Answer: Answer:
m=audio 55954 RTP/AVP 99 m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4 a=fmtp:99 recvmode=0 sendmode=4
Example offer answer exchanges for interoperability between Example offer answer exchanges for interoperability between
legacy (RFC XXXX) and updated EVRC-B(RFC 4788) implementations: legacy (RFC XXXX) and updated EVRC-B(RFC 4788) implementations:
skipping to change at page 33, line 5 skipping to change at page 32, line 5
m=audio 55954 RTP/AVP 99 m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
Answer from an answerer which supports updated Answer from an answerer which supports updated
EVRC-B (RFC XXXX) implementation: EVRC-B (RFC XXXX) implementation:
m=audio 55954 RTP/AVP 99 m=audio 55954 RTP/AVP 99
a=rtpmap:99 EVRCB0/8000 a=rtpmap:99 EVRCB0/8000
a=fmtp:99 recvmode=0 sendmode=4 a=fmtp:99 recvmode=0 sendmode=4
16. IANA Considerations 17. IANA Considerations
Three new MIME subtype registrations ("EVRCWB", "EVRCWB0" and Three new MIME subtype registrations ("EVRCWB", "EVRCWB0" and
"EVRCWB1") are defined in this document. "EVRCWB1") are defined in this document.
The MIME subtype registrations "EVRCB","EVRCB0" and "EVRCB1" The MIME subtype registrations "EVRCB" and "EVRCB0" originally
originally defined in [2] are updated with optional "recvmode" and defined in [2] are updated with optional "recvmode" and "sendmode"
"sendmode" parameters (See Section 9.4, Section 9.5 and Section 9.6). parameters (See Section 9.4 and Section 9.5).
[-- RFC Editor: Please replace all instances of "RFC XXXX" in this [-- RFC Editor: Please replace all instances of "RFC XXXX" in this
document with the RFC number of this document prior to IANA document with the RFC number of this document prior to IANA
registration and RFC publication, and remove this note.] registration and RFC publication, and remove this note.]
[-- RFC Editor:Please add MIME subtypes "EVRCWB","EVRCWB0", and [-- RFC Editor:Please add MIME subtypes "EVRCWB","EVRCWB0", and
"EVRCWB1" to the IANA registry for "RTP Payload Format MIME types" at "EVRCWB1" to the IANA registry for "RTP Payload Format MIME types" at
http://www.iana.org/assignments/rtp-parameters, and remove this http://www.iana.org/assignments/rtp-parameters, and remove this
note.] note.]
17. Security Considerations 18. Security Considerations
Implementations using the payload defined in this specification are Implementations using the payload defined in this specification are
subject to the security considerations discussed in RFC3558 [14], subject to the security considerations discussed in RFC3558 [14],
RFC3550 [6], and any appropriate profile (for example RFC3551 [13]). RFC3550 [6], and any appropriate profile (for example RFC3551 [12]).
This payload does not specify any different security services. This payload does not specify any different security services.
18. References 19. Changes
18.1. Normative References This document updates RFC 4788 and the updates are summarized below:
o Added new media type attribute "sendmode" to MIME sub-types EVRCB
and EVRCB0. This attribute can be used to signal EVRC-B encoder's
current mode of operation.
o Added new media type attribute "recvmode" to MIME sub-types EVRCB
and EVRCB0. This attribute can be used to signal 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family [2] Xie, Q., "Enhancements to RTP Payload Formats for EVRC Family
Codecs", RFC 4788, January 2007. Codecs", RFC 4788, January 2007.
[3] "Enhanced Variable Rate Codec, Speech Service Option 3 for [3] "Enhanced Variable Rate Codec, Speech Service Option 3 for
Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014 , Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014 ,
January 1997. January 1997.
[4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68 [4] "Enhanced Variable Rate Codec, Speech Service Option 3 and 68
for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B
v1.0 , May 2006. v1.0 , May 2006.
[5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and [5] "Enhanced Variable Rate Codec, Speech Service Option 3,68 and
70 for Wideband Spread Spectrum Digital Systems", 3GPP2 Work 70 for Wideband Spread Spectrum Digital Systems", 3GPP2
in Progress, October 2006. C.S0014-C v1.0 , October 2006.
[6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time [6] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, March 1997. Applications", STD 64, RFC 3550, March 1997.
[7] Rosenberg, J., "An Offer/Answer Model with Session Description [7] Rosenberg, J., "An Offer/Answer Model with Session Description
Protocol (SDP)", RFC 3264, June 2002. Protocol (SDP)", RFC 3264, June 2002.
[8] Narten, T., "Guidelines for Writing an IANA Considerations [8] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, October 1998. Section in RFCs", RFC 2434, October 1998.
[9] Johnston, A., "SDP Offer/Answer Examples", RFC 4317, [9] Handley, M., "SDP: Session Description Protocol", RFC 4566,
December 2005.
[10] Handley, M., "SDP: Session Description Protocol", RFC 4566,
July 2006. July 2006.
[11] Garudadri, H., "3GPP2 Multimedia Registrations", RFC 4393, [10] Garudadri, H., "3GPP2 Multimedia Registrations", RFC 4393,
March 2006. March 2006.
[12] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-A , [11] "3GPP2 File Formats for Multimedia Services", 3GPP2 C.S0050-B ,
March 2006. April 2007.
18.2. Informative References 20.2. Informative References
[13] Schulzrinne, H., "RTP Profile for Audio and Video Conferences [12] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", STD 65, RFC 3551, July 2003. with Minimal Control", STD 65, RFC 3551, July 2003.
[13] Johnston, A., "SDP Offer/Answer Examples", RFC 4317,
December 2005.
[14] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs [14] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558,
July 2003. July 2003.
[15] Handley, M., "Session Announcement Protocol", RFC 2974, [15] Handley, M., "Session Announcement Protocol", RFC 2974,
October 2000. October 2000.
[16] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", [16] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)",
RFC 2326, April 1998. RFC 2326, April 1998.
skipping to change at page 38, line 5 skipping to change at page 38, line 5
Qiaobing Xie Qiaobing Xie
Motorola Motorola
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
Email: Qiaobing.Xie@Motorola.com Email: Qiaobing.Xie@Motorola.com
URI: http://www.motorola.com URI: http://www.motorola.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 38, line 29 skipping to change at page 38, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2007). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 70 change blocks. 
210 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/