Network Working Group Q. Xie Internet-Draft Motorola Expires: October 10, 2005 April 8, 2005 Compact Bundled RTP Format for EVRC Speech draft-xie-avt-compact-bundle-evrc-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 10, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a compact (header-free) bundled format for EVRC RTP payload format. This compact bundled format is an addition to the bundled format and header-free format as already defined in RFC 3558. It is expected that some VoIP applications, such as Push-to-Talk, may find this compact bundled format more advantageous to use. Xie Expires October 10, 2005 [Page 1] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Compact Bundled Format . . . . . . . . . . . . . . . . . . . . 4 4. Single Rate Operation . . . . . . . . . . . . . . . . . . . . 4 5. Discontinuous Transmission Considerations . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1 Mapping MIME Parameters into SDP . . . . . . . . . . . . . 6 6.2 Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Xie Expires October 10, 2005 [Page 2] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 1. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [2]. 2. Introduction This document defines a compact (header-free) bundled packet format for EVRC RTP payload. This compact bundled packet format is an addition to the interleaved/bundled packet format and header-free packet format as already defined in RFC 3558 [3]. It is expected that some VoIP applications, such as Push-to-Talk, may find this compact bundled packet format more advantageous to use. 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 rate change request, and interleaving. To support these functions, a Table of Content (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 [3]. 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 contains only one speech frame (of any allowable rate), i.e., bundling is not allowed. Moreover, interleaving and rate change request are not supported in the header-free format [3]. Since the biggest EVRC speech frame is 171 bits (full rate), it is therefore very inefficient in terms of bandwidth utilization to send EVRC speech frames one at a time over RTP/UDP/IP, as being required by the header-free format. It is hoped that this shortcoming of the header-free format will be eliminated or at least mostly alleviated in practice by the use of RTP/UDP/IP header compression or removal techniques such as LLA ROHC [7]. However, in many wireless systems such as 3GPP and 3GPP2, header compression/removal is only applied between the mobile station and the radio access network, not to the entire path from the EVRC sender to the EVRC receiver. This means that over the rest of the path between the EVRC sender and receiver, the speech will be carried one speech frame per RTP packet with full RTP/UDP/IP headers. This would result in very poor bandwidth utilization in that part of the network. Xie Expires October 10, 2005 [Page 3] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 The compact bundled format described in this document presents the user an alternative to the header-free format defined in RFC 3558. The compact bundled format is wireless-friendly since it does not use a ToC. It also allows bundling of multiple EVRC frames thus won't create bandwidth inefficiency problems in the network. However, to use this compact bundled format the compromise one has to make is that only one EVRC rate (full rate or 1/2 rate) can be used in the session. And similar to the header-free format defined in RFC 3558, interleaving and rate change request are not supported in the compact bundled format. 3. 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 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 codec data frames of same rate | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The EVRC codec date frames MUST be generated from the output of the vocoder following the procedure described in 5.2 in RFC 3558 [3] and they MUST be of the same rate and size. 4. Single Rate Operation As mentioned earlier, to use the compact bundled format, all the EVRC data frames in the session MUST be of the same rate (either 1 or 1/2 rate). To some VoIP applications, such as Push-to-Talk over cellular, this is not viewed as much of a limitation due to their unique communication style where rate changes in a session are often difficult and sometimes even undesirable. 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. Discontinuous Transmission Considerations In general, EVRC codec does not provide discontinuous transmission (DTX) support. Instead, the encoder sends 1/8 rate (or blank) frames Xie Expires October 10, 2005 [Page 4] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 during periods of silence. When compact bundled format is used, since blank or 1/8 rate frames can not be sent in the session, outside explicit DTX mechanisms can be considered. One example of such mechanism is the floor control signaling used in push-to-talk sessions, which provides the equivalent function of DTX. 6. IANA Considerations A new MIME subtype registration is required for the compact bundled format payload type, as described below. Media Type name: audio Media subtype names: EVRC1 Required parameters: none Optional parameters: ptime: see RFC 2327 [6]. 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. evrcrate: Indicates the EVRC rate of the session. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate EVRC while a value of 1 indicates the full rate EVRC. If this parameter is not present, 1/2 rate EVRC is assumed. Encoding considerations: These types are defined for transfer of EVRC encoded data via RTP using the compact bundled format as described in Section 3 of RFC XXXX. Security considerations: See Section 7 of RFC XXXX. Public specification: The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer method with compact bundled RTP format is specified in RFC XXXX. Person & email address to contact for further information: Qiaobing.Xie@motorola.com Xie Expires October 10, 2005 [Page 5] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type. Author/Change controller: * Qiaobing.Xie@motorola.com * IETF Audio/Video transport working group 6.1 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) [6], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the compact bundled format for EVRC encoded speech, the mapping is as follows: o The MIME type ("audio") goes in SDP "m=" as the media name. o The MIME subtype ("EVRC1") goes in SDP "a=rtpmap" as the encoding name. o The optional parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. o The optional parameter "evrcrate" goes in "a=fmtp" attribute by copying it directly from the MIME media type string as "evrcrate=value". Example of usage of EVRC1: m=audio 49120 RTP/AVP 97 a=rtpmap:97 EVRC1/8000 a=fmtp:97 evrcrate=0.5 a=maxptime:120 6.2 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 [5] should be followed. 7. Security Considerations Implementations using the payload defined in this specification are Xie Expires October 10, 2005 [Page 6] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 subject to the security considerations discussed in the RTP specification RFC 3550 [4] and any appropriate profile (for example RFC3551 [8]). This payload does not specify any different security services. 8. References 8.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. [3] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003. [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 8.2 Informative References [7] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002. [8] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. Author's Address Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US Phone: +1-847-632-3028 Email: qxie1@email.mot.com Xie Expires October 10, 2005 [Page 7] Internet-Draft Compact Bundled Format for EVRC Speech April 2005 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 (2005). 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 Expires October 10, 2005 [Page 8]