draft-ietf-avt-rtp-evrc-nw-04.txt   draft-ietf-avt-rtp-evrc-nw-05.txt 
Network Working Group Z. Fang Network Working Group Z. Fang
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Standards Track October 6, 2011 Intended status: Standards Track October 25, 2011
Expires: April 8, 2012 Expires: April 27, 2012
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-04 draft-ietf-avt-rtp-evrc-nw-05
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 April 8, 2012. This Internet-Draft will expire on April 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. EVRC-NW codec . . . . . . . . . . . . . . . . . . . . . . . . 6 4. EVRC-NW codec . . . . . . . . . . . . . . . . . . . . . . . . 6
5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7 5. RTP header usage . . . . . . . . . . . . . . . . . . . . . . . 7
6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Payload format . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Congestion Control Considerations . . . . . . . . . . . . . . 9 6.1. Encoding capability identification in EVRC-NW
8. Storage format for the EVRC-NW Codec . . . . . . . . . . . . . 10 interleaved/bundled format . . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Congestion Control Considerations . . . . . . . . . . . . . . 11
9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 11 8. Storage format for the EVRC-NW Codec . . . . . . . . . . . . . 12
9.1.1. Registration of Media Type audio/EVRCNW . . . . . . . 11 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1.2. Registration of Media Type audio/EVRCNW0 . . . . . . . 13 9.1. Media Type Registrations . . . . . . . . . . . . . . . . . 13
9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 14 9.1.1. Registration of Media Type audio/EVRCNW . . . . . . . 13
10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 17 9.1.2. Registration of Media Type audio/EVRCNW0 . . . . . . . 15
11. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 18 9.1.3. Registration of Media Type audio/EVRCNW1 . . . . . . . 16
12. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 19 10. SDP mode attributes for EVRC-NW . . . . . . . . . . . . . . . 19
13. Declarative SDP Considerations . . . . . . . . . . . . . . . . 21 11. Mapping EVRC-NW media type parameters into SDP . . . . . . . . 20
14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Offer-Answer Model Considerations for EVRC-NW . . . . . . . . 21
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. Declarative SDP Considerations . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27
16.2. Informative References . . . . . . . . . . . . . . . . . . 26 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . . 28
16.2. Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
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
than the EVRC and EVRC-B codecs and better capacity than EVRC-WB than the EVRC and EVRC-B codecs and better capacity than EVRC-WB
skipping to change at page 8, line 23 skipping to change at page 8, line 23
1. the mode change request field in the interleaved/bundled packet 1. the mode change request field in the interleaved/bundled packet
format MUST be interpreted according to the definition of the format MUST be interpreted according to the definition of the
RATE_REDUC parameter as defined in EVRC-NW [4]. RATE_REDUC parameter as defined in EVRC-NW [4].
2. the mode change request field in the interleaved/bundled packet 2. the mode change request field in the interleaved/bundled packet
format SHOULD be honored by an EVRCNW encoding end point in an format SHOULD be honored by an EVRCNW encoding end point in an
one-to-one session with a dedicated EVRCNW decoding end point one-to-one session with a dedicated EVRCNW decoding end point
such as in a two-party call or in a conference leg. such as in a two-party call or in a conference leg.
3. the reserved bit field in the first octet of the interleaved/
bundled format has only one bit. Bit 1 of the first octet is an
EVRC-NW wideband/narrowband encoding capability identfication
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
format
The EVRC-NW interleaved/bundled format defines an encoding capability
identification flag, which is used to signal the far end of a
communication session of the instantaneous local EVRC-NW wideband/
narrowband encoding capability. This capability identification flag
allows the far end to use the MMM field in its out-going (returning)
EVRC-NW interleaved/bundled format packets to request the desired
EVRC-NW wideband or narrowband encoding mode in accordance with the
dynamic/instantaneous encoding capability information. 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
two communication end points using EVRC-NW interleaved/bundled
format. The called end point becomes wideband encoding incapable
during the call and makes the other end aware of this change using
the encoding capability identification flag. Based on the new
information the calling end point could change the MMM value in
its outgoing EVRC-NW packets from Mode-0 to Mode-4 to request
narrowband encoded traffic for bandwidth efficiency or from Mode-0
to Mode-1 for best perceptual quality.
o An end-to-end narrowband communication is established between an
EVRC-NW wideband encoding capable calling end point and an EVRC-NW
wideband encoding incapable called end point. The called end
point becomes EVRC-NW wideband encoding capable during the call
and makes the other end aware of this change using the encoding
capability identification flag. Based on the new information the
calling end point could change the MMM value in its outgoing
EVRC-NW packets from non-Mode-0 to Mode-0 to request wideband
traffic.
EVRC-NW interleaved/bundled format defines the encoding capability
identification flag in bit 1 of the first octet, as illustrated in
the figure below. The flag shall be set to zero (C=0) when the local
EVRC-NW encoder is capable of Mode-0 wideband encoding. The flag
shall be set to one (C=1) when the local EVRC-NW encoder is capable
of non-Mode-0 narrowband encoding only. See RFC 3558 [6] for
original definitions of other fields in the interleaved/bundled
format.
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|R|C| LLL | NNN | MMM | Count | TOC | ... | TOC |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| one or more codec data frames, one per TOC entry |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (R): 1 bit
Reserved bit. MUST be set to zero by sender, SHOULD be ignored by
receiver.
Encoding capability identification (C): 1 bit
Must be set to zero by sender to indicate wideband encoding
capable or set to one to indicate narrowband encoding capable
only.
C = 0 : Mode-0 wideband encoding capable
= 1 : Mode-0 wideband encoding incapable, i.e. narrowband
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 SHALL be used in accordance with RFC 3550
[5], and with any applicable RTP profile; e.g., RFC 3551 [7]. [5], and with any applicable RTP profile; e.g., RFC 3551 [7].
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.
skipping to change at page 12, 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 15. Security considerations: See Section 15.
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]. specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW.
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 12, line 49 skipping to change at page 14, line 49
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
SHALL be used. SHALL be used. See Section 6 for details for EVRC-NW.
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 19, line 47 skipping to change at page 21, line 47
a=rtpmap:98 EVRCNW0/16000 a=rtpmap:98 EVRCNW0/16000
a=fmtp:98 mode-set-recv=4 a=fmtp:98 mode-set-recv=4
o 'mode-set-recv' is a uni-directional receive only parameter. o 'mode-set-recv' is a uni-directional receive only parameter.
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
'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv' 'mode-set-recv'. A remote sender MAY ignore 'mode-set-recv'
requests. However, a remote sender shall not assume the other requests. However, a remote sender shall not assume the other
side can support mode 0, unless the offer includes mode 0 side can support mode 0, unless the offer includes mode 0
explicitly in 'mode-set-recv'. explicitly in 'mode-set-recv' or the remote sender receives mode
requests with MMM = 0 from the communication partner during an
active call using EVRC-NW interleaved/bundled format.
o The parameters 'maxptime' and 'ptime' will in most cases not o The parameters 'maxptime' and 'ptime' will in most cases not
affect interoperability, however the setting of the parameters can affect interoperability, however the setting of the parameters can
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 RFC 3264 [12]. handling of the 'ptime' parameter is described in RFC 3264 [12].
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, the 'mode-set-recv' parameter is not useful o For a sendonly stream, the 'mode-set-recv' parameter is not useful
and SHOULD NOT be used. and SHOULD NOT be used.
 End of changes. 9 change blocks. 
24 lines changed or deleted 103 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/