Network Working Group Q. Xie
Internet-Draft Motorola
Expires: October 26, 2006 R. Kapoor
Qualcomm
April 24, 2006
Enhancements to RTP Payload Formats for EVRC Family Codecs
draft-ietf-avt-compact-bundled-evrc-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines several enhancements and extensions to the EVRC
RTP payload formats defined in RFC 3558. In particular, it defines
support for the header-free and interleaved/bundled packet formats
for the EVRC-B codec, a new compact bundled format for the EVRC and
EVRC-B codecs, as well as discontinuous transmission (DTX) support
for EVRC and EVRC-B encoded speech transported via RTP. VoIP
applications operating over low bandwidth dial-up and wireless
Xie & Kapoor Expires October 26, 2006 [Page 1]
Internet-Draft EVRC RTP Format Enhancements April 2006
networks require such enhancements for efficient use of the
bandwidth.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Support of EVRC-B Codec . . . . . . . . . . . . . . . . . 3
1.2 Compact (Header-free) Bundled Format . . . . . . . . . . . 3
1.3 Discontinuous Transmission (DTX) . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EVRC-B Codec . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Other Frame-Based Vocoders . . . . . . . . . . . . . . . . 5
4. Compact Bundled Format . . . . . . . . . . . . . . . . . . . 5
4.1 Single Rate Operation . . . . . . . . . . . . . . . . . . 6
5. Storage Format For EVRC-B Codec . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
6.1 Registration of Media Type EVRC1 . . . . . . . . . . . . . 7
6.2 Registration of Media Type EVRCB . . . . . . . . . . . . . 9
6.3 Registration of Media Type EVRCB0 . . . . . . . . . . . . 11
6.4 Registration of Media Type EVRCB1 . . . . . . . . . . . . 12
6.5 Updated Registration of Media Type EVRC . . . . . . . . . 13
6.6 Updated Registration of Media Type EVRC0 . . . . . . . . . 15
6.7 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 17
6.8 Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 18
7. Backward Compatibility with RFC 3558 . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . 19
10.2 Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 22
Xie & Kapoor Expires October 26, 2006 [Page 2]
Internet-Draft EVRC RTP Format Enhancements April 2006
1. Introduction
This document defines support for the header-free and interleaved/
bundled packet formats for the EVRC-B codec, a new compact bundled
format for the EVRC and EVRC-B codecs, as well as discontinuous
transmission (DTX) support for EVRC and EVRC-B encoded speech
transported via RTP. VoIP applications operating over low bandwidth
dial-up and wireless networks require such EVRC RTP payload
capabilities for efficient use of the bandwidth.
1.1 Support of EVRC-B Codec
EVRC-B [4] is an extension to [3] developed in 3GPP2. EVRC-B [4]
compresses each 20 milliseconds of 8000Hz, 16-bit sampled speech
input into output frames of one of the four different sizes: Rate 1
(171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16
bits). In addition, there are two zero bit codec frame types: null
frames and erasure frames, similar to EVRC [3]. One significant
enhancement in EVRC-B is the use of 1/4 rate frames that were not
used in EVRC. This provides lower average data rates (ADRs) compared
to EVRC, for a given voice quality.
Since speech frames encoded by EVRC-B are different from those
encoded by EVRC, EVRC-B and EVRC codecs do not interoperate with each
other. At the initiation of a RTP session, the RTP sender and
receiver need to indicate (e.g., using MIME subtypes that are
separate from those of EVRC) that EVRC-B is to be used for the
ensuing session.
1.2 Compact (Header-free) Bundled Format
The current interleaved/bundled packet format defined in RFC 3558
allows bundling of multiple speech frames of different rate in a
single RTP packet, sending mode change requests, and interleaving.
To support these functions, a Table of Contents (ToC) is used in each
RTP packet in addition to the standard RTP header. The size of the
ToC is variable, depending on the number of EVRC frames carried in
the packet [5].
The current header-free packet format defined in RFC 3558 is more
compact and optimized for use over wireless links. It eliminates the
need for a ToC by requiring that each RTP packet contain only one
speech frame (of any allowable rate), i.e., bundling is not allowed.
Moreover, interleaving and mode change request are not supported in
the header-free format [5].
The compact bundled format described in this document presents the
user an alternative to the header-free format defined in RFC 3558.
Xie & Kapoor Expires October 26, 2006 [Page 3]
Internet-Draft EVRC RTP Format Enhancements April 2006
This format allows bundling of multiple EVRC or EVRC-B frames without
the addition of extra headers, as would be in case of the
interleaved/bundled format. However, in order to use this compact
bundled format, only one EVRC/EVRC-B rate (full rate or 1/2 rate) can
be used in the session. Similar to the header-free format defined in
RFC 3558, interleaving and mode change request are not supported in
the compact bundled format.
1.3 Discontinuous Transmission (DTX)
The EVRC and EVRC-B codecs do not use Silence Descriptor frames;
instead, in variable rate operation mode the encoder sends 1/8 rate
frames during periods of silence, while in single rate operation mode
(see Section 4), silence is encoded and sent in frames of the same
rate as that of speech frames. The DTX parameters defined in this
document apply to 1/8th rate frames in the variable rate mode and to
silence frames in the single rate operation mode.
For simplicity, in the rest of this document the term "silence frame"
refers either to an 1/8th rate frame in variable rate operation or a
frame that contains only silence in the signal rate operation.
Information carried in silence frames of EVRC and EVRC-B codecs
varies little during periods of silence. The transmission of these
silence frames across the radio interface in a wireless system is
expensive in terms of capacity, and therefore, suppression of these
frames is desirable.
Suppression of silence frames is accomplished by using DTX. When DTX
is applied, the first few silence frames may be transmitted to
establish background noise during the period of silence. Then a
portion of the stream of subsequent silence frames is not transmitted
and is discarded at the sender. At the receiver, background or
comfort noise may be generated by using the previously received
silence frames.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, MUST, MUST NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as described in [2].
3. EVRC-B Codec
Three RTP packet formats are supported for the EVRC-B codec - the
interleaved/bundled packet format, the header-free packet format and
the compact bundled packet format. For the interleaved/bundled and
header-free packet formats, the operational details and capabilities,
Xie & Kapoor Expires October 26, 2006 [Page 4]
Internet-Draft EVRC RTP Format Enhancements April 2006
such as ToC, interleaving, and bundling, of EVRC-B are exactly the
same as those of EVRC, as defined in RFC3558 [5], except that the
mode change request field in the ToC MUST be interpreted according to
the definition of the RATE_REDUC parameter in EVRC-B [4]. The
compact bundled packet format for EVRC-B is defined in Section 4 of
this document.
3.1 Other Frame-Based Vocoders
Other frame-based vocoders can be carried in the packet formats
defined in this document, as long as they possess the following
properties:
o the codec is frame-based;
o blank and erasure frames are supported;
o the total number of rates is less than 17;
o the maximum full rate frame can be transported in a single RTP
packet using this specific format.
Vocoders with the characteristics listed above can be transported
using the packet format specified in this document with some
additional specification work; the pieces that must be defined are
listed in Section 15 of RFC 3558.
4. Compact Bundled Format
A packet in the compact bundled format consists of an RTP header
followed by a sequence of one or more consecutive EVRC/EVRC-B codec
data frames of the same rate, as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| One or more EVRC/EVRC-B data frames of same rate |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The codec data frames MUST be generated from the output of the codec
following the procedure described in 5.2 in RFC 3558 [5] and all MUST
be of the same rate and size.
Xie & Kapoor Expires October 26, 2006 [Page 5]
Internet-Draft EVRC RTP Format Enhancements April 2006
4.1 Single Rate Operation
As mentioned earlier, in order to use the compact bundled format, all
the EVRC/EVRC-B data frames in the session MUST be of the same rate.
This packet format may carry only full or half-rate frames.
For a session that uses the compact bundled format, the rate for the
session can be determined during the session setup signaling, for
example, via SDP exchanges. See Section 6 below for more details.
5. Storage Format For EVRC-B Codec
The storage format is used for storing EVRC-B encoded speech frames,
e.g., as a file or e-mail attachment.
The file begins with a magic number to identify the vocoder that is
used. The magic number for EVRC-B corresponds to the ASCII character
string "#!EVRC-B\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 0x2D 0x42
0x0A".
Note, the "\n" is an important part of the magic number and MUST be
included in the comparison, since, otherwise, the EVRC-B magic number
will become indistinguishable from magic number used for EVRC.
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.
Speech frames lost in transmission and non-received frames MUST be
stored as erasure frames to maintain synchronization with the
original media.
6. IANA Considerations
Four (4) new MIME subtype registrations - "EVRC1", "EVRCB", "EVRCB0",
and "EVRCB1" - are defined in this document for EVRC-B and compact
bundled payload format support.
For all the EVRC and EVRC-B RTP payload formats defined in RFC 3558
[5] and RFC XXXX, four additional optional parameters -
"silencesupp", "dtxmax", "dtxmin", and "hangover" - are defined and
used in DTX.
The MIME subtype registrations, "EVRC" and "EVRC0" originally defined
in RFC 3558 [5], are updated with the optional DTX parameters.
Xie & Kapoor Expires October 26, 2006 [Page 6]
Internet-Draft EVRC RTP Format Enhancements April 2006
6.1 Registration of Media Type EVRC1
Type name: audio
Subtype names: EVRC1
Required parameters: none
Optional parameters:
ptime: see RFC 2327 [8].
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be 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 single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
fixedrate: Indicates the EVRC 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: Permissible values are 0 and 1. A value of 1
indicates that the sender of this parameter is capable of and
desires to support silence suppression using DTX. A value of 0
indicates that the sender of this parameter is either incapable
of or unwilling to use silence suppression using DTX. An RTP
endpoint may use this parameter to declare its ability and
desire to support silence suppression using DTX.
If this parameter is not present, the default value specified
in [9] MUST be assumed. If the RTP receiver indicates through
the use of SIP signaling or other means that it is incapable of
or unwilling to use silence suppression using DTX, silence
suppression using DTX as specified in this document MUST NOT be
used for the session.
dtxmax: indicates the maximum DTX update interval in number of
frames. During DTX, the RTP sender occasionally updates the
RTP receiver about the change in background noise
characteristics, etc., by sending a new silence frame to the
RTP receiver. The RTP receiver may use 'dtxmax' to indicate to
the RTP sender the maximum interval (in number of frames)
between any two DTX updates it expects to receive from the RTP
sender.
Xie & Kapoor Expires October 26, 2006 [Page 7]
Internet-Draft EVRC RTP Format Enhancements April 2006
If this parameter is not present in a session that uses DTX,
the default value specified in [9] MUST be assumed. This
parameter MUST be ignored if silence suppression using DTX is
not used for the session.
dtxmin: indicates the minimum DTX update interval in number of
frames. The RTP receiver may use 'dtxmin' to indicate to the
RTP sender the minimal interval (in number of frames) between
any two DTX updates it expects to receive from the RTP sender.
If this parameter is not present, the default value specified
in [9] MUST be assumed. This parameter MUST be ignored if
silence suppression using DTX is not used for the session.
hangover: indicates the number of consecutive silence frames
transmitted at the end of an active speech interval but before
the DTX interval begins. When setting up an RTP session that
uses DTX, an RTP receiver can use this parameter to signal the
number of silence frames it expects to receive before the
beginning of DTX. While hangover=0 is allowed, it is
RECOMMENDED that hangover be set to 1 or greater since the
presence of silence frames at the end of active speech can help
the RTP receiver to identify the beginning of the DTX period.
If this parameter is not present for a session that uses DTX,
the default value specified in [9] MUST be assumed. This
parameter MUST be ignored if silence suppression using DTX is
not used for the session.
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC encoded data via RTP using the
compact bundled format as described in RFC XXXX.
Security considerations: See Section 8 of RFC XXXX.
Interoperability considerations: none
Published specification:
The EVRC vocoder is specified in 3GPP2 C.S0014 [3]. Transfer
method with compact bundled RTP format is specified in RFC XXXX.
Applications that use this media type:
It is expected that many VoIP applications (as well as mobile
applications) will use this type.
Xie & Kapoor Expires October 26, 2006 [Page 8]
Internet-Draft EVRC RTP Format Enhancements April 2006
Additional information: none
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.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 [6]). Transfer within other
framing protocols is not defined at this time.
Author:
Qiaobing Xie
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.2 Registration of Media Type EVRCB
Type name: audio
Subtype names: EVRCB
Required parameters: none
Optional parameters:
ptime: see RFC 2327 [8].
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be 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 single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
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
Xie & Kapoor Expires October 26, 2006 [Page 9]
Internet-Draft EVRC RTP Format Enhancements April 2006
dtxmax: see Section 6.1
dtxmin: see Section 6.1
hangover: see Section 6.1
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 [5].
Security considerations: See Section 8 of RFC XXXX.
Interoperability considerations: none
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [4]. Transfer
method with Interleaved/Bundled packet format via RTP is specified
in RFC 3558.
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 storage format only.
Magic number: #!EVRC-B\n (see Section 5 of RFC XXXX)
File extensions: evb, EVB
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
Restrictions on usage:
This media type may be used with RTP framing (RFC 3550 [6]) and as
a storage format. When used with RTP, the procedures in Section 3
MUST be followed. In all other contexts, the storage format
defined in Section 5 MUST be used.
Author:
Qiaobing Xie
Xie & Kapoor Expires October 26, 2006 [Page 10]
Internet-Draft EVRC RTP Format Enhancements April 2006
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.3 Registration of Media Type EVRCB0
Type name: audio
Subtype names: EVRCB0
Required parameters: none
Optional parameters:
silencesupp: see Section 6.1
dtxmax: see Section 6.1
dtxmin: see Section 6.1
hangover: see Section 6.1
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 [5].
Security considerations: See Section 8 of RFC XXXX.
Interoperability considerations: none
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [4]. Transfer
method with Header-Free packet format via RTP is specified in RFC
3558 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:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Xie & Kapoor Expires October 26, 2006 [Page 11]
Internet-Draft EVRC RTP Format Enhancements April 2006
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only defined
for transfer via RTP (RFC 3550 [6]). Transfer within other
framing protocols is not defined at this time.
Author:
Qiaobing Xie
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.4 Registration of Media Type EVRCB1
Type name: audio
Subtype names: EVRCB1
Required parameters: none
Optional parameters:
ptime: see RFC 2327 [8].
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time MUST
be 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 single codec data frame (20 msec). If not
signaled, the default maxptime value MUST be 200 milliseconds.
fixedrate: Indicates the EVRC-B 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
dtxmax: see Section 6.1
dtxmin: see Section 6.1
Xie & Kapoor Expires October 26, 2006 [Page 12]
Internet-Draft EVRC RTP Format Enhancements April 2006
hangover: see Section 6.1
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 bundled format as described in RFC XXXX.
Security considerations: See Section 8 of RFC XXXX.
Interoperability considerations: none.
Published specification:
The EVRC-B vocoder is specified in 3GPP2 C.S0014-B [4]. Transfer
method with compact bundled RTP format is specified in 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:
Qiaobing Xie <Qiaobing.Xie@motorola.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 [6]). Transfer within other
framing protocols is not defined at this time.
Author:
Qiaobing Xie
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.5 Updated Registration of Media Type EVRC
(The definition is from RFC 3558, added with the optional DTX
parameters, and updated with the new template specified in [11].)
Type name: audio
Xie & Kapoor Expires October 26, 2006 [Page 13]
Internet-Draft EVRC RTP Format Enhancements April 2006
Subtype names: EVRC
Required parameters: none
Optional parameters:
ptime: Defined as usual for RTP audio (see RFC 2327).
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time SHALL
be 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 single codec data frame (20 msec). If not
signaled, the default maxptime value SHALL be 200 milliseconds.
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 SHALL be 5.
silencesupp: see Section 6.1
dtxmax: see Section 6.1
dtxmin: see Section 6.1
hangover: see Section 6.1
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is defined for transfer of EVRC-encoded data via RTP using the
Interleaved/Bundled packet format specified in Sections 4.1, 6,
and 7 of RFC 3558. It is also defined for other transfer methods
using the storage format specified in Section 11 of RFC 3558.
Security considerations: See Section 14 "Security Considerations" of
RFC 3558.
Interoperability considerations:
The DTX parameters are receiver options. Existing RFC 3558
implementations will not send any of the DTX parameters in their
SDP and will ignore any DTX parameters they receive. The adaptive
DTX behavior of DTX-capable EVRC codecs (as detailed in [9],
Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
Xie & Kapoor Expires October 26, 2006 [Page 14]
Internet-Draft EVRC RTP Format Enhancements April 2006
Published specification: The EVRC vocoder is specified in 3GPP2
C.S0014. Transfer methods are specified in RFC 3558.
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 storage format only.
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
Qiaobing Xie <Qiaobing.Xie@motorola.com>
Intended usage: COMMON
Restrictions on usage:
This media type may be used with RTP framing (RFC 3550 [6]) and as
a storage format. When used with RTP, the procedures in RFC 3558,
Section 4.1 MUST be followed. In all other contexts, the storage
format defined in RFC 3558, Section 11 MUST be used.
Author:
Adam Li/Qiaobing Xie
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.6 Updated Registration of Media Type EVRC0
(The definition is from RFC 3558, added with the optional DTX
parameters, and updated with the new template specified in [11].)
Type name: audio
Subtype names: EVRC0
Required parameters: none
Optional parameters:
Xie & Kapoor Expires October 26, 2006 [Page 15]
Internet-Draft EVRC RTP Format Enhancements April 2006
silencesupp: see Section 6.1
dtxmax: see Section 6.1
dtxmin: see Section 6.1
hangover: see Section 6.1
Encoding considerations:
This media type is framed binary data (see RFC 4288, Section 4.8)
and is only defined for transfer of EVRC-encoded data via RTP
using the Header-Free packet format specified in Section 4.2 of
RFC 3558.
Security considerations: See Section 14 "Security Considerations" of
RFC 3558.
Interoperability considerations:
The DTX parameters are receiver options. Existing RFC 3558
implementations will not send any of the DTX parameters in their
SDP and will ignore any DTX parameters they receive. The adaptive
DTX behavior of DTX-capable EVRC codecs (as detailed in [9],
Section 4.3.5) ensures interoperability with non-DTX EVRC codecs.
Published specification:
The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods
are specified in RFC 3558.
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:
Qiaobing Xie <Qiaobing.Xie@motorola.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 [6]). Transfer within other
framing protocols is not defined at this time.
Author:
Adam Li/Qiaobing Xie
Xie & Kapoor Expires October 26, 2006 [Page 16]
Internet-Draft EVRC RTP Format Enhancements April 2006
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
6.7 Mapping MIME Parameters into SDP
The information carried in the MIME 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 the compact bundled format for
EVRC/EVRC-B encoded speech, the mapping is as follows:
o The MIME type ("audio") goes in SDP "m=" as the media name.
o The MIME subtype ("EVRC", "EVRC0", "EVRC1", "EVRCB", EVRCB0", or
"EVRCB1") goes in SDP "a=rtpmap" as the encoding name.
o The optional parameters "ptime" and "maxptime" (for subtypes EVRC,
EVRC1, EVRCB, and EVRCB1) go in the SDP "a=ptime" and "a=maxptime"
attributes, respectively.
o The optional parameter "maxinterleave" (for subtypes EVRC and
EVRCB) goes in the SDP "a=fmtp" attribute by copying it directly
from the MIME media type string as "maxinterleave=value".
o The optional parameter "fixedrate" (for subtypes EVRC1 and EVRCB1)
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
"hangover" go in "a=fmtp" attribute by copying it directly from
the MIME media type string as "silencesupp=value", "dtxmax=value",
"dtxmin=value", and "hangover=value", respectively.
Example of usage of EVRC1:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:120
Example of usage of EVRCB:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB/8000
a=maxptime:120
Example of usage of EVRCB0:
Xie & Kapoor Expires October 26, 2006 [Page 17]
Internet-Draft EVRC RTP Format Enhancements April 2006
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB0/8000
Example of usage of EVRCB1:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRCB1/8000
a=fmtp:97 fixedrate=0.5
a=maxptime:100
Example of usage of EVRC with DTX with silencesupp=1:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1
Examples of usage of EVRC with DTX with silencesupp=0:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 silencesupp=0
6.8 Usage in Offer/Answer
All SDP parameters in this payload format are declarative, and all
reasonable values are expected to be supported. Thus, the standard
usage of Offer/Answer as described in RFC 3264 [7] SHOULD be
followed.
In addition, the following rules MUST be followed while negotiating
DTX parameters:
1. If either offer and/or answer does not contain DTX parameters,
the default values of the DTX parameters MUST be used.
2. If silencesupp is present and set to 1 in either offer or answer,
all four DTX parameters MUST be present. An example of this SDP
usage is shown in Section 6.7.
3. If silencesupp is present and set to 0 in either offer or answer,
the values of all received DTX parameters other than silencesupp
SHOULD be ignored.
4. The value of dtxmax MUST be larger than or equal to the value of
dtxmin. Furthermore, if both offer and answer contain the dtxmax
parameter, the value of dtxmax in the answer MUST be less than or
equal to the value of dtxmax in the offer.
Xie & Kapoor Expires October 26, 2006 [Page 18]
Internet-Draft EVRC RTP Format Enhancements April 2006
5. If both offer and answer contain the dtxmin parameter, the value
of dtxmin in the answer MUST be greater than or equal to the
value of dtxmin in the offer.
6. If both offer and answer contain the hangover parameter, the
value of hangover in the answer MUST be greater than or equal to
the value of hangover in the offer.
7. Backward Compatibility with RFC 3558
This document adds new optional DTX parameters to the original EVRC
payload subtypes "EVRC" and "EVRC0" defined in RFC 3558. Since the
new DTX parameters are receiver options, we expect the existing RFC
3558 implementations will not send any of the DTX parameters in their
SDP and will ignore any DTX parameters they receive. The adaptive
DTX behavior of DTX-capable EVRC codecs (as detailed in [9], Section
4.3.5) ensures the backward interoperability between the DTX-capable
EVRC codec and non-DTX EVRC codecs.
8. Security Considerations
Implementations using the payload defined in this specification are
subject to the security considerations discussed in RFC 3558 [5], RFC
3550 [6], and any appropriate profile (for example RFC3551 [10]).
This payload does not specify any different security services.
9. Acknowledgements
The following people have made significant contributions to this
document (in alphabetic order): Parag Agashe, Jim Ashley, Harikishan
Desineni, Serafin Diaz, Harinath Garudadri, Gouri Johanssen, Ananth
Kandhadai, Waqar Mohsin, Ashok Roy, Gino Scribano, and Gajinder Singh
Vij.
Special thanks to Colin Perkins for his careful review and comments
that significantly improved the quality of this document.
10. References
10.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Xie & Kapoor Expires October 26, 2006 [Page 19]
Internet-Draft EVRC RTP Format Enhancements April 2006
[3] "Enhanced Variable Rate Codec, Speech Service Option 3 for
Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014,
January 1997.
[4] "Enhanced Variable Rate Codec, Speech Service Option XX for
Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-B, in
progress.
[5] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] "Discontinuous Transmission (DTX) of Speech in cdma2000
Systems", 3GPP2 C.S0076-0, Version 1.0, December 2005.
10.2 Informative References
[10] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[11] Casner, S., "Media Type Registration of RTP Payload Formats",
draft-ietf-avt-rfc3555bis-03.txt (work in progress),
March 2006.
Authors' Addresses
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004
US
Phone: +1-847-632-3028
Email: Qiaobing.Xie@Motorola.com
Xie & Kapoor Expires October 26, 2006 [Page 20]
Internet-Draft EVRC RTP Format Enhancements April 2006
Rohit Kapoor
Qualcomm Inc.
US
Phone: +1-858-845-1161
Email: rkapoor@qualcomm.com
Xie & Kapoor Expires October 26, 2006 [Page 21]
Internet-Draft EVRC RTP Format Enhancements April 2006
Intellectual Property Statement
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.
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 (2006). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Xie & Kapoor Expires October 26, 2006 [Page 22]
