draft-ietf-avt-rtp-evrc-nw-07.txt   draft-ietf-avt-rtp-evrc-nw-08.txt 
Network Working Group Z. Fang Network Working Group Z. Fang
Internet-Draft Qualcomm Internet-Draft Qualcomm Incorporated
Intended status: Standards Track August 22, 2012 Intended status: Standards Track November 15, 2012
Expires: February 23, 2013 Expires: May 19, 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-07 draft-ietf-avt-rtp-evrc-nw-08
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 February 23, 2013. This Internet-Draft will expire on May 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 16 9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 16
10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 19 10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 19
11. Mode Change Request/Response Considerations . . . . . . . . . 20 11. Mode Change Request/Response Considerations . . . . . . . . . 20
12. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 22 12. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 22
13. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 23 13. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 23
14. Declarative SDP Considerations . . . . . . . . . . . . . . . . 25 14. Declarative SDP Considerations . . . . . . . . . . . . . . . . 25
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29 16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Normative References . . . . . . . . . . . . . . . . . . . 30 17.1. Normative References . . . . . . . . . . . . . . . . . . . 30
17.2. Informative References . . . . . . . . . . . . . . . . . . 30 17.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document specifies the payload formats for packetization of This document specifies the payload formats for packetization of
EVRC-NW encoded speech signals into the real-time transport protocol EVRC-NW encoded speech signals into the real-time transport protocol
(RTP). It defines support for the header-free, interleaved/bundled (RTP). It defines support for the header-free, interleaved/bundled
and compact bundle packet formats for the EVRC-NW codec as well as and compact bundle packet formats for the EVRC-NW codec as well as
discontinuous transmission (DTX) support for EVRC-NW encoded speech discontinuous transmission (DTX) support for EVRC-NW encoded speech
transported via RTP. The EVRC-NW codec offers better speech quality transported via RTP. The EVRC-NW codec offers better speech quality
skipping to change at page 7, line 9 skipping to change at page 7, line 9
1 1/8 2 (16 bits) 1 1/8 2 (16 bits)
2 1/4 5 (40 bits) 2 1/4 5 (40 bits)
3 1/2 10 (80 bits) 3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 bits padded at the end) 4 1 22 (171 bits; 5 bits padded at the end)
5 Erasure 0 (SHOULD NOT be transmitted by sender) 5 Erasure 0 (SHOULD NOT be transmitted by sender)
5. RTP header usage 5. RTP header usage
The format of the RTP header is specified in RFC 3550 [5]. The The format of the RTP header is specified in RFC 3550 [5]. The
EVRC-NW payload formats (Section 6) use the fields of the RTP header EVRC-NW payload formats (Section 6) use the fields of the RTP header
in a manner consistent with RFC 3550 [5]. as specified in RFC 3550 [5].
EVRC-NW has also the capability to operate with 8 kHz sampled input/ EVRC-NW has also the capability to operate with 8 kHz sampled input/
output signals. The decoder does not require a priori knowledge output signals. The decoder does not require a priori knowledge
about the sampling rate of the original signal at the input of the about the sampling rate of the original signal at the input of the
encoder. The decoder output can be at 8kHz or 16kHz regardless of encoder. The decoder output can be at 8kHz or 16kHz regardless of
the sampling rate used at the encoder. Therefore, depending on the the sampling rate used at the encoder. Therefore, depending on the
implementation and the electroacoustic audio capabilities of the implementation and the electroacoustic audio capabilities of the
devices, the input of the encoder and/or the output of the decoder devices, the input of the encoder and/or the output of the decoder
can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST
always be used. The RTP timestamp is increased by 320 for each 20 always be used. The RTP timestamp is increased by 320 for each 20
skipping to change at page 8, line 36 skipping to change at page 8, line 36
flag. flag.
The media type audio/EVRCNW maps to the interleaved/bundled packet The media type audio/EVRCNW maps to the interleaved/bundled packet
format, audio/EVRCNW0 maps to the header-free packet format and format, audio/EVRCNW0 maps to the header-free packet format and
audio/EVRCNW1 maps to the compact bundled packet format. audio/EVRCNW1 maps to the compact bundled packet format.
6.1. Encoding capability identification in EVRC-NW interleaved/bundled 6.1. Encoding capability identification in EVRC-NW interleaved/bundled
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 far end of a identification flag, which is used to signal the local EVRC-NW
communication session of the instantaneous local EVRC-NW wideband/ wideband/narrowband encoding capability at the time of construction
narrowband encoding capability. This capability identification flag of an RTP packet to the far end of a communication session. This
allows the far end to use the MMM field in its out-going (returning) capability identification flag allows the far end to use the MMM
EVRC-NW interleaved/bundled format packets to request the desired field in its out-going (returning) EVRC-NW interleaved/bundled format
EVRC-NW wideband or narrowband encoding mode in accordance with the packets to request the desired EVRC-NW wideband or narrowband
dynamic/instantaneous encoding capability information. The following encoding mode in accordance with the dynamic/instantaneous encoding
examples illustrate a few scenarios where the encoding capability capability information. The following examples illustrate a few
information is used: 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 12, line 19 skipping to change at page 12, line 19
The file begins with a magic number to identify the vocoder that is The file begins with a magic number to identify the vocoder that is
used. The magic number for EVRC-NW corresponds to the ASCII used. The magic number for EVRC-NW corresponds to the ASCII
character string "#!EVRCNW\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43 character string "#!EVRCNW\n", i.e., "0x23 0x21 0x45 0x56 0x52 0x43
0x4E 0x57 0x0A". 0x4E 0x57 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. The Value column in the
mapping from frame type to ToC value. table in Section 4 provides the TOC values for corresponding frame
types.
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 (ToC value of 5) to maintain synchronization stored as erasure frames (ToC value of 5) to maintain synchronization
with the original media. with the original media.
9. IANA considerations 9. IANA considerations
This document introduces a new EVRC-NW 'audio' media subtype. This document introduces a new EVRC-NW 'audio' media subtype.
9.1. Media Type Registrations 9.1. Media Type Registrations
skipping to change at page 14, line 15 skipping to change at page 14, line 15
Interleaved/Bundled packet format specified in RFC 3558 [6]. Interleaved/Bundled packet format specified in RFC 3558 [6].
Security considerations: See Section 16. Security considerations: See Section 16.
Interoperability considerations: None Interoperability considerations: None
Published specification: Published specification:
The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer
method with the Interleaved/Bundled packet format via RTP is method with the Interleaved/Bundled packet format via RTP is
specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW. specified in RFC 3558 [6]. See Section 6 of RFC XXXX for details for
EVRC-NW. [Note to the RFC editor: please replace XXXX with the RFC
number of this document.]
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:
The following applies to stored-file transfer methods: The following applies to stored-file transfer methods:
skipping to change at page 14, line 48 skipping to change at page 14, line 50
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 When this media type is used in the context of transfer over RTP, the
RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
used. In all other contexts, the file format defined in Section 8 used. In all other contexts, the file format defined in Section 8 of
SHALL be used. See Section 6 for details for EVRC-NW. RFC XXXX SHALL be used. See Section 6 of RFC XXXX for details for
EVRC-NW. [Note to the RFC editor: please replace XXXX with the RFC
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 25, line 7 skipping to change at page 25, line 7
rate and mode (0-Wideband or 1-Narrowband). rate and mode (0-Wideband or 1-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 RFC 4788 [2]. parameters, see Section 6.8 in RFC 4788 [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.
14. Declarative SDP Considerations 14. Declarative SDP Considerations
For declarative use of SDP in SAP [13] and RTSP [14], the following For declarative use of SDP in SAP [14] and RTSP [15], 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
skipping to change at page 29, line 13 skipping to change at page 29, line 13
a=rtpmap:98 EVRCWB0/16000 a=rtpmap:98 EVRCWB0/16000
16. Security Considerations 16. Security Considerations
Since compression is applied to the payload formats end-to-end, and Since compression is applied to the payload formats end-to-end, and
the encodings do not exhibit significant non-uniformity, the encodings do not exhibit significant non-uniformity,
implementations of this specification are subject to all the security implementations of this specification are subject to all the security
considerations specified in RFC 3558 [6]. Implementations using the considerations specified in RFC 3558 [6]. Implementations using the
payload defined in this specification are subject to the security payload defined in this specification are subject to the security
considerations discussed in RFC 3558 [6], RFC 3550 [5] and any considerations discussed in RFC 3558 [6], RFC 3550 [5] and any
appropriate profile (for example RFC 3551 [7]). appropriate profile (for example RFC 3551 [7]). Additional security
considerations are described in RFC 6562 [13].
17. References 17. References
17.1. Normative References 17.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. 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.
skipping to change at page 30, line 49 skipping to change at page 30, line 49
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia [11] Garudadri, H., "MIME Type Registrations for 3GPP2 Multimedia
Files", RFC 4393, March 2006. Files", RFC 4393, March 2006.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable
Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
17.2. Informative References 17.2. Informative References
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[14] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
Author's Address Author's Address
Zheng Fang Zheng Fang
Qualcomm Qualcomm Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92126 San Diego, CA 92126
USA USA
Phone: +1 858 651 9484 Phone: +1 858 651 9484
Email: zfang@qualcomm.com Email: zfang@qualcomm.com
URI: http://www.qualcomm.com URI: http://www.qualcomm.com
 End of changes. 15 change blocks. 
26 lines changed or deleted 35 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/