draft-ietf-avt-rtp-evrc-wb-06.txt   draft-ietf-avt-rtp-evrc-wb-07.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
Intended status: Standards Track Motorola Intended status: Standards Track Motorola
Expires: May 7, 2008 November 4, 2007 Expires: May 15, 2008 November 12, 2007
RTP payload format for EVRC-WB codec and media subtype updates for RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB)
EVRC-B codec and media subtype updates for EVRC-B codec
draft-ietf-avt-rtp-evrc-wb-06.txt draft-ietf-avt-rtp-evrc-wb-07.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 36 skipping to change at page 1, line 36
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 May 7, 2008. This Internet-Draft will expire on May 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (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 Enhanced Variable Rate Wideband Codec
the media type registrations for EVRC-B codec. Several media type (EVRC-WB) and updates the media type registrations for EVRC-B codec.
registrations are included for EVRC-WB RTP payload formats. In Several media type registrations are included for EVRC-WB RTP payload
addition, a file format is specified for transport of EVRC-WB speech formats. In addition, a file format is specified for transport of
data in storage mode applications such as e-mail. EVRC-WB speech data in storage mode applications such as e-mail.
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-WB codec . . . . . . . . . . . . . . . . . . . . . . . . 6 4. EVRC-WB 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 7. Congestion Control Considerations . . . . . . . . . . . . . . 9
skipping to change at page 8, line 14 skipping to change at page 8, line 14
6. Payload format 6. Payload format
Three RTP packet formats are supported for the EVRC-WB codec - the Three RTP packet formats are supported for the EVRC-WB codec - the
interleaved/bundled packet format, the header-free packet format and interleaved/bundled packet format, the header-free packet format and
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 [3], except that the mode change request field in the ToC defined in [3], 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]. The media type audio/EVRCWB
maps to the interleaved/bundled packet format, audio/EVWB0 maps to
the header-free packet format and audio/EVRCWB1 maps to the compact
bundled packet format.
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 [10]. [6], and with any applicable RTP profile; e.g., RFC 3551 [11].
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-WB Codec 8. Storage format for the 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,
e.g., as a file or e-mail attachment. e.g., as a file or e-mail attachment.
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-WB corresponds to the ASCII used. The magic number for EVRC-WB corresponds to the ASCII
character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57 character string "#!EVCWB\n", i.e., "0x23 0x21 0x45 0x56 0x43 0x57
0x42 0x0A". 0x42 0x0A". Magic number has no relationship with media type and
packet format. The same magic number can be used irrespective of the
media type and packet format used. The storage format defined in
this section can be used by all EVRCWB media types (audio/EVRCWB,
audio/EVRCWB0 and audio/EVRCWB1) registered by this document.
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 (ToC value of 5) to maintain synchronization stored as erasure frames (ToC value of 5) to maintain synchronization
skipping to change at page 11, line 16 skipping to change at page 11, line 16
This document updates the audio/EVRCB and audio/EVRCB0 media types This document updates the audio/EVRCB and audio/EVRCB0 media types
defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes. defined in RFC 4788 [3] and adds new EVRC-WB 'audio' media subtypes.
[-- 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.]
9.1. Media Type Registrations 9.1. Media Type Registrations
Following the guidelines in RFC 4288 [9], this section registers new Following the guidelines in RFC 4855 [9] and RFC 4288 [10], this
'audio' media subtypes for EVRC-WB and updates the audio/EVRCB and section registers new 'audio' media subtypes for EVRC-WB and updates
audio/EVRCB0 media type registrations contained in RFC 4788 [3]. the audio/EVRCB and audio/EVRCB0 media type registrations contained
in RFC 4788 [3].
9.1.1. Registration of Media Type audio/EVRCWB 9.1.1. Registration of Media Type audio/EVRCWB
Type name: audio Type name: audio
Subtype names: EVRCWB Subtype names: EVRCWB
Required parameters: none Required parameters: none
Optional parameters: Optional parameters:
skipping to change at page 28, line 7 skipping to change at page 28, line 7
parameter. parameter.
o For a sendonly stream, the 'recvmode' parameter is not useful and o For a sendonly stream, the 'recvmode' parameter is not useful and
SHOULD NOT be used. SHOULD NOT be used.
o For a recvonly stream, the 'sendmode' parameter is not useful and o For a recvonly stream, the 'sendmode' parameter is not useful and
SHOULD NOT be used. SHOULD NOT be used.
16. Declarative SDP Considerations 16. Declarative SDP Considerations
For declarative use of SDP in SAP [11] and RTSP [12] , the following For declarative use of SDP in SAP [12] and RTSP [13] , 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 33, line 13 skipping to change at page 33, line 13
a=fmtp:99 recvmode=0 sendmode=4 a=fmtp:99 recvmode=0 sendmode=4
18. Security Considerations 18. 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 [2]. Implementations using the considerations specified in RFC 3558 [2]. 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 [2], RFC 3550 [6] and any considerations discussed in RFC 3558 [2], RFC 3550 [6] and any
appropriate profile (for example RFC 3551 [10]). appropriate profile (for example RFC 3551 [11]).
19. Changes to RFC 4788 19. Changes to RFC 4788
This document updates RFC 4788 [3] and the updates are summarized This document updates RFC 4788 [3] and the updates are summarized
below: below:
o Added new media type attribute "sendmode" to media sub-types EVRCB o Added new media type attribute "sendmode" to media sub-types EVRCB
and EVRCB0. This attribute can be used to signal the EVRC-B and EVRCB0. This attribute can be used to signal the EVRC-B
encoder's current mode of operation. encoder's current mode of operation.
skipping to change at page 35, line 36 skipping to change at page 35, line 36
[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] Handley, M., "SDP: Session Description Protocol", RFC 4566, [8] Handley, M., "SDP: Session Description Protocol", RFC 4566,
July 2006. July 2006.
[9] Freed, N., "Media Type Specifications and Registration [9] Casner, S., "Media Type Specifications and Registration
Procedures", RFC 4855, February 2007.
[10] Freed, N., "Media Type Specifications and Registration
Procedures", BCP 13, RFC 4288, December 2005. Procedures", BCP 13, RFC 4288, December 2005.
20.2. Informative References 20.2. Informative References
[10] Schulzrinne, H., "RTP Profile for Audio and Video Conferences [11] 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.
[11] Handley, M., "Session Announcement Protocol", RFC 2974, [12] Handley, M., "Session Announcement Protocol", RFC 2974,
October 2000. October 2000.
[12] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)", [13] Schulzrinne, H., "Real Time Streaming Protocol (RTSP)",
RFC 2326, April 1998. RFC 2326, April 1998.
Authors' Addresses Authors' Addresses
Harikishan Desineni Harikishan Desineni
Qualcomm Qualcomm
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92126 San Diego, CA 92126
USA USA
 End of changes. 14 change blocks. 
22 lines changed or deleted 33 lines changed or added

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