AVT T. le Grand Internet Draft Global IP Solutions Intended status: Standards Track P. Jones Expires: January 12, 2009 Cisco July 12, 2008 RTP Payload Format for the iSAC Codec draft-legrand-rtp-isac-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 12, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). le Grand Expires January 12, 2009 [Page 1] Internet-Draft iSAC July 2008 Abstract iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within an RTP packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). le Grand Expires January 12, 2009 [Page 2] Internet-Draft iSAC July 2008 Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. le Grand Expires January 12, 2009 [Page 3] Internet-Draft iSAC July 2008 Table of Contents 1. Introduction...................................................5 2. RTP Payload Format.............................................6 2.1. iSAC Payload..............................................6 2.2. Multiple iSAC frames in an RTP packet.....................6 3. IANA Considerations............................................7 3.1. Media Type registration of iSAC...........................7 4. Mapping to SDP Parameters......................................9 5. Offer/Answer Considerations...................................10 6. Security Considerations.......................................11 7. Acknowledgments...............................................12 8. References....................................................13 8.1. Normative References.....................................13 8.2. Informative References...................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................15 le Grand Expires January 12, 2009 [Page 4] Internet-Draft iSAC July 2008 1. Introduction The iSAC codec is an adaptive wideband speech and audio codec that operates with very short delay, making it suitable for high quality real time communication. It is specially designed to deliver wideband speech quality in both low and medium bit rate applications. It also handles non-speech audio, such as music and background noise, exceptionally well [5]. The iSAC codec compresses speech frames of 16 kHz, 16-bit sampled input speech, each frame containing 30 or 60 ms of speech. The iSAC codec operates at transmission rates from about 10 kbps to about 32 kbps. Even at dial-up modem data rates (including IP, UDP, and RTP overhead) iSAC delivers better than PSTN sound quality by automatically adjusting transmission rates to give the best possible listening experience over the available bandwidth. The main characteristics can be summarized as follows: o Wideband, 16 kHz, speech and audio codec o Variable bit rate, which depends on the input signal o Adaptive rate with two modes: channel-adaptive or channel- independent mode o Bit rate range from around 10 kbps to 32 kbps o Operates on 30 or 60 msec of speech frames le Grand Expires January 12, 2009 [Page 5] Internet-Draft iSAC July 2008 2. RTP Payload Format The iSAC codec uses 30 or 60 ms frames and a sampling rate clock of 16 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. The RTP payload for iSAC has the format shown in Figure 1. No additional header fields specific to this payload format are required. For RTP based transportation of iSAC encoded audio, the standard RTP header [2] is followed by one payload data block. 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 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + one iSAC frame + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTP packet format for iSAC 2.1. iSAC Payload The iSAC payload is padded to whole octets, and has a variable length depending on the input source signal, frame length, and target bit rate. The number of octets used to describe one frame of 30 ms speech typically varies from around 50 to around 120 octets. For the case of 60 ms frames, the number of octets varies from around 100 to around 240 octets. The absolute maximum allowed payload length is 600 octets. In channel-adaptive mode, the frame length can change at any time during a session. The frame length is signaled in band. The sensitivity to bit errors is equal for all bits in the payload. 2.2. Multiple iSAC frames in an RTP packet More than one iSAC frame MUST NOT be included in an RTP packet by a sender. Further, frames MUST NOT be split between RTP packets. le Grand Expires January 12, 2009 [Page 6] Internet-Draft iSAC July 2008 3. IANA Considerations This document defines the iSAC media type. 3.1. Media Type registration of iSAC Media type name: audio Media subtype: iSAC Required parameters: None Optional parameters: None Encoding considerations: This media format is framed and binary. Security considerations: See section 6. Interoperability considerations: None Published specification: Applications which use this media type: This media type is suitable for use in numerous applications needing to transport encoded voice or other audio. Some examples include Voice over IP, Streaming Media, Voice Messaging, and Conferencing. Additional information: None Intended usage: COMMON Other Information/General Comment: iSAC is a proprietary speech and audio codec owned by Global IP Solutions. The codec operates on 30 or 60 ms speech frames at a sampling rate clock of 16 kHz. Person to contact for further information: tina.legrand@gipscorp.com le Grand Expires January 12, 2009 [Page 7] Internet-Draft iSAC July 2008 Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [2]. Transport within other framing protocols is not defined at this time. Change controller: IETF Audio/Video Transport working group delegated from the IESG. le Grand Expires January 12, 2009 [Page 8] Internet-Draft iSAC July 2008 4. Mapping to SDP Parameters The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [4], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the iSAC codec, the mapping is as follows: o The media type ("audio") goes in SDP "m=" as the media name. o The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. When conveying information by SDP, the encoding name SHALL be "iSAC" (the same as the media subtype). An example of the media representation in SDP for describing iSAC might be: m=audio 49120 RTP/AVP 104 a=rtpmap: 104 iSAC/16000 Note that the payload format (encoding) names are commonly shown in upper case. Media subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in media types and in the default mapping to the SDP a=fmtp attribute. le Grand Expires January 12, 2009 [Page 9] Internet-Draft iSAC July 2008 5. Offer/Answer Considerations No special considerations must be given for the use of iSAC within the offer/answer model. le Grand Expires January 12, 2009 [Page 10] Internet-Draft iSAC July 2008 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RFC 3550 [2]. As this format transports encoded speech, the main security issues include confidentiality and authentication of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [3], MAY be used. le Grand Expires January 12, 2009 [Page 11] Internet-Draft iSAC July 2008 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. le Grand Expires January 12, 2009 [Page 12] Internet-Draft iSAC July 2008 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and Norrman, K., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [4] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session Description Protocol", RFC 4566, July 2006. 8.2. Informative References [5] iSAC datasheet at Global IP Solutions website, http://www.gipscorp.com/files/english/datasheets/iSAC.pdf le Grand Expires January 12, 2009 [Page 13] Internet-Draft iSAC July 2008 Author's Addresses Tina le Grand Global IP Solutions Magnus Ladulasgatan 63B SE-118 27 Stockholm Sweden Email: tina.legrand@gipscorp.com Paul E. Jones Cisco Systems, Inc, 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Tel: +1 919 476 2048 Email: paulej@packetizer.com le Grand Expires January 12, 2009 [Page 14] Internet-Draft iSAC July 2008 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, THE IETF TRUST 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 IETF Trust (2008). 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. le Grand Expires January 12, 2009 [Page 15]