draft-ietf-avt-rtp-evrc-nw-09.txt   draft-ietf-avt-rtp-evrc-nw-10.txt 
Network Working Group Z. Fang Network Working Group Z. Fang
Internet-Draft Qualcomm Incorporated Internet-Draft Qualcomm Incorporated
Intended status: Standards Track December 13, 2012 Intended status: Standards Track January 20, 2013
Expires: June 16, 2013 Expires: July 24, 2013
RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec
(EVRC-NW) (EVRC-NW)
draft-ietf-avt-rtp-evrc-nw-09 draft-ietf-avt-rtp-evrc-nw-10
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 Enhanced Variable Rate Narrowband-Wideband formats to be used for the Enhanced Variable Rate Narrowband-Wideband
Codec (EVRC-NW). Three media type registrations are included for Codec (EVRC-NW). Three media type registrations are included for
EVRC-NW RTP payload formats. In addition, a file format is specified EVRC-NW RTP payload formats. In addition, a file format is specified
for transport of EVRC-NW speech data in storage mode applications for transport of EVRC-NW speech data in storage mode applications
such as e-mail. such as e-mail.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on June 16, 2013. This Internet-Draft will expire on July 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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-NW is an extension of both the EVRC-B [2] and EVRC-WB [3] speech EVRC-NW is an extension of both the EVRC-B [2] and EVRC-WB [3] speech
codecs developed in 3GPP2 with support for discontinuous transmission codecs developed in 3GPP2 with support for discontinuous transmission
(DTX). It provides enhanced voice quality and high spectral (DTX). It provides enhanced voice quality and high spectral
efficiency. efficiency.
The EVRC-NW codec operates on 20 ms frames, and the default sampling The EVRC-NW codec operates on 20 ms frames, and the default sampling
rate is 16 kHz. Input and output at 8 kHz sampling rate is also rate is 16 kHz (wideband). Input and output at 8 kHz sampling rate
supported. The EVRC-NW codec can operate in eight modes (0 to 7) (narrowband) is also supported. The EVRC-NW codec can operate in
defined in [4]. EVRC-NW modes 0, 1, and 7 are interoperable with eight modes (0 to 7) defined in [4]. EVRC-NW modes 0, 1, and 7 are
EVRC-WB. EVRC-NW modes 1 to 7 are interoperable with EVRC-B. interoperable with EVRC-WB. EVRC-NW modes 1 to 7 are interoperable
EVRC-NW modes 0 to 6 use the full set or a subset of full rate, 1/2 with EVRC-B. EVRC-NW modes 0 to 6 use the full set or a subset of
rate, 1/4 rate and 1/8 rate frames. EVRC-NW mode 7 uses only 1/2 full rate, 1/2 rate, 1/4 rate and 1/8 rate frames. EVRC-NW mode 7
rate and 1/8 rate frames. By default, EVRC-NW supports all uses only 1/2 rate and 1/8 rate frames. By default, EVRC-NW supports
narrowband modes (modes 1 to 7). The support of wideband mode (mode all narrowband modes (modes 1 to 7). The support of wideband mode
0) is optional. Mode change among modes 1 to 7 (or among modes 0 to (mode 0) is optional. Mode change among modes 1 to 7 (or among modes
7 if the receiver supports wideband mode) results in codec output 0 to 7 if the receiver supports wideband mode) results in codec
bit-rate change but does not cause any decoding problems at the output bit-rate change but does not cause any decoding problems at
receiver. EVRC-NW provides a standardized solution for packetized the receiver. EVRC-NW provides a standardized solution for
voice applications that allow transitions between enhanced quality packetized voice applications that allow transitions between enhanced
and increased capacity. The most important service addressed is IP quality and increased capacity. The most important service addressed
telephony. Target devices can be IP phones or VoIP handsets, media is IP telephony. Target devices can be IP phones or VoIP handsets,
gateways, voice messaging servers, etc. media gateways, voice messaging servers, etc.
4. EVRC-NW codec 4. EVRC-NW codec
The EVRC-NW codec operates on 20 ms frames. It produces output The EVRC-NW codec operates on 20 ms frames. It produces output
frames of one of the four different sizes: 171 bits (Rate 1), 80 bits frames of one of the four different sizes: 171 bits (Rate 1), 80 bits
(Rate 1/2), 40 bits (Rate 1/4), or 16 bits (Rate 1/8). In addition, (Rate 1/2), 40 bits (Rate 1/4), or 16 bits (Rate 1/8). In addition,
there are two zero-bit codec frame types: blank (null) frames and there are two zero-bit codec frame types: blank (null) frames and
erasure frames. The default sampling rate is 16 kHz. Input and erasure frames. The default sampling rate is 16 kHz. Input and
output at 8 kHz sampling rate is also supported. output at 8 kHz sampling rate is also supported.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
format format
The EVRC-NW interleaved/bundled format defines an encoding capability The EVRC-NW interleaved/bundled format defines an encoding capability
identification flag, which is used to signal the local EVRC-NW identification flag, which is used to signal the local EVRC-NW
wideband/narrowband encoding capability at the time of construction wideband/narrowband encoding capability at the time of construction
of an RTP packet to the far end of a communication session. This of an RTP packet to the far end of a communication session. This
capability identification flag allows the far end to use the MMM capability identification flag allows the far end to use the MMM
field in its out-going (returning) EVRC-NW interleaved/bundled format field in its out-going (returning) EVRC-NW interleaved/bundled format
packets to request the desired EVRC-NW wideband or narrowband packets to request the desired EVRC-NW wideband or narrowband
encoding mode in accordance with the dynamic/instantaneous encoding encoding mode in accordance with the dynamic/instantaneous encoding
capability information. The following examples illustrate a few capability information. See RFC 3558 [6] for the definition of MMM
scenarios where the encoding capability information is used: field. The following examples illustrate a few scenarios where the
encoding capability information is used:
o An end-to-end wideband communication is established first between o An end-to-end wideband communication is established first between
two communication end points using EVRC-NW interleaved/bundled two communication end points using EVRC-NW interleaved/bundled
format. The called end point becomes wideband encoding incapable format. The called end point becomes wideband encoding incapable
during the call and makes the other end aware of this change using during the call and makes the other end aware of this change using
the encoding capability identification flag. Based on the new the encoding capability identification flag. Based on the new
information the calling end point could change the MMM value in information the calling end point could change the MMM value in
its outgoing EVRC-NW packets from Mode-0 to Mode-4 to request its outgoing EVRC-NW packets from Mode-0 to Mode-4 to request
narrowband encoded traffic for bandwidth efficiency or from Mode-0 narrowband encoded traffic for bandwidth efficiency or from Mode-0
to Mode-1 for best perceptual quality. to Mode-1 for best perceptual quality.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
capable or set to one to indicate narrowband encoding capable capable or set to one to indicate narrowband encoding capable
only. only.
C = 0 : Mode-0 wideband encoding capable C = 0 : Mode-0 wideband encoding capable
= 1 : Mode-0 wideband encoding incapable, i.e. narrowband = 1 : Mode-0 wideband encoding incapable, i.e. narrowband
encoding only. encoding only.
7. Congestion Control Considerations 7. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP is discussed in RFC 3550 [5], and in
[5], and with any applicable RTP profile, e.g., RFC 3551 [7]. applicable RTP profiles, e.g., RFC3551 [7]. This document does not
change those considerations.
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 the EVRC-NW Codec 8. Storage format for the EVRC-NW Codec
The storage format is used for storing EVRC-NW encoded speech frames, The storage format is used for storing EVRC-NW encoded speech frames,
skipping to change at page 14, line 48 skipping to change at page 14, line 48
"audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11]. "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].
Person & email address to contact for further information: Person & email address to contact for further information:
Zheng Fang <zfang@qualcomm.com> Zheng Fang <zfang@qualcomm.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: Restrictions on usage:
When this media type is used in the context of transfer over RTP, the This media type can be used with the file format defined in Section 8
RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be of RFC XXXX in contexts other than RTP. In context of transfers over
used. In all other contexts, the file format defined in Section 8 of RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6]
RFC XXXX SHALL be used. See Section 6 of RFC XXXX for details for is used for this media type. [Note to the RFC editor: please replace
EVRC-NW. [Note to the RFC editor: please replace XXXX with the RFC XXXX with the RFC number of this document.]
number of this document.]
Author: Author:
Zheng Fang <zfang@qualcomm.com> Zheng Fang <zfang@qualcomm.com>
Change controller: Change controller:
IETF Payload working group delegated from the IESG. IETF Payload working group delegated from the IESG.
9.1.2. Registration of Media Type audio/EVRCNW0 9.1.2. Registration of Media Type audio/EVRCNW0
skipping to change at page 30, line 21 skipping to change at page 30, line 21
[2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for [2] Xie, Q. and R. Kapoor, "Enhancements to RTP Payload Formats for
EVRC Family Codecs", RFC 4788, January 2007. EVRC Family Codecs", RFC 4788, January 2007.
[3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced [3] Desineni, H. and Q. Xie, "RTP Payload Format for the Enhanced
Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype
Updates for EVRC-B Codec", RFC 5188, February 2008. Updates for EVRC-B Codec", RFC 5188, February 2008.
[4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68, [4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68,
70, and 73 for Wideband Spread Spectrum Digital Systems", 70, and 73 for Wideband Spread Spectrum Digital Systems",
3GPP2 C.S0014-D v1.0, May 2009. 3GPP2 C.S0014-D v3.0, October 2010.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[6] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs [6] 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.
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
 End of changes. 9 change blocks. 
32 lines changed or deleted 33 lines changed or added

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