Network Working Group G S. Massey Internet-Draft APT Ltd Intended status: Standards Track June 24, 2008 Expires: December 26, 2008 "RTP Payload Format for apt-X" draft-gmassey-avt-rtp-aptx-02.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 December 26, 2008. Massey Expires December 26, 2008 [Page 1] Internet-Draft "RTP Payload Format for apt-X" June 2008 Abstract This document describes an RTP payload format for transporting apt-X encoded audio. It details the RTP encapsulation mechanism for standard, enhanced apt-X and apt-X Live data. Also included within this memo are media type registrations, and the details necessary for the use of apt-X, enhanced apt-X and apt-X Live with the Session Description Protocol. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Encapsulation of apt-X Live and Enhanced apt-X Streams . . . . 5 3.1. RTP header usage . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.1. Standard apt-X . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Enhanced apt-X 16 Bit . . . . . . . . . . . . . . . . . . 7 4.3. Enhanced apt-X 24 Bit . . . . . . . . . . . . . . . . . . 8 4.4. apt-X Live . . . . . . . . . . . . . . . . . . . . . . . . 9 5. SDP Related Considerations . . . . . . . . . . . . . . . . . . 11 5.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 11 5.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Usage with the SDP Offer/Answer Model . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Massey Expires December 26, 2008 [Page 2] Internet-Draft "RTP Payload Format for apt-X" June 2008 1. Requirements notation 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 [RFC2119]. Massey Expires December 26, 2008 [Page 3] Internet-Draft "RTP Payload Format for apt-X" June 2008 2. Introduction apt-X, enhanced apt-X16/enhanced apt-X24 and apt-X Live are proprietary audio compression algorithms. No prior RFC or standard has been used to describe how to packetise this audio data. The compression algorithm yields a fixed bit rate scaled according to the sample frequency of the input audio. The fixed rate is one quarter of the original bit rate. This rule also applies to the resolution of the audio. Example, a 1.536MB/s stereo audio stream using 16 bit PCM is reduced to 384 kb/s. The apt-X and enhanced apt-X algorithms can carry an ancillary data stream and synchronisation information within the compressed audio stream without additional overhead. The ancillary data stream can be used to transport data or timecode data for synchronisation with video. The bandwidth of the ancillary data channel is one quarter the sample frequency, example at Fs = 48kHz the ancillary data stream is 12 kb/s. The similarities between the packetisation is such that it does each variant does not warrant a separate RFC. Massey Expires December 26, 2008 [Page 4] Internet-Draft "RTP Payload Format for apt-X" June 2008 3. Encapsulation of apt-X Live and Enhanced apt-X Streams apt-X Live and Enhanced apt-X are non framed based algorithm and produces as its output a sixteen bit word representing four sixteen bit PCM samples. The packetisation of the data shall be on a byte by byte basis. Packet size must be a multiple of the number of n x 64kbps channels in the resultant bitrate. For example a 384kbps channel would result in a multiple of 6. Therefore the resultant payload size would be N x 6 bytes. Likewise a 576kbps channel would require a payload N * 9 bytes. 3.1. RTP header usage apt-X Live and Enhanced apt-X require no special considerations be placed in the RTP header. The timestamp used in the RTP header shall comply with the same timestamp specified in RFC3550. PT type shall be either specified as dynamic for use with SIP signalling but can also be used with static PT numbers for manual call establishment. Payload Header (payload format dependent) V - As per RFC3550 P - As per RFC3550 X - As per RFC3550 CC - As per RFC3550 M - As per RFC3550 PT - Payload Number to be defined according to MIME allocation: audio/aptX audio/EaptX audio/aptXLive SN - As per RFC3550 Payload See description below V - Version Number P - Padding X - Extensions CC - Count of contributing sources Massey Expires December 26, 2008 [Page 5] Internet-Draft "RTP Payload Format for apt-X" June 2008 M - Marker PT - Payload Type PS - Payload Structure The payload data for apt-X Live and Enhanced apt-X shall be delineated as Left channel data/ Right Channel data. Data is word aligned big endian format. For multi-channel packets the data is allocated as per the following rules. 1) N bytes interleaved (Left Channel /Right Channel) format per channel 2) N is defined by the number of N x 64kb/s channels present in the overall audio bit stream. Therefore a 128kbps stereo stream would have an N of 2 and the data would be formatted Left(Byte) / Right (Byte) Multiple channels are grouped together for transmission to preserve phase between channels. Thus a transmission of a 5.1 audio track would group together six audio channels in a single packet. The channels would be grouped in a sequential order from first to last and would remain in this order. Example 6.912 mb/s 5.1 Enhanced apt-X 24bit (3 * 576)/64 = N = 9 Channels 1/2 Bytes(0..17) Channels 3/4 Bytes(0..17) Channels 5/6 Bytes(0..17) Massey Expires December 26, 2008 [Page 6] Internet-Draft "RTP Payload Format for apt-X" June 2008 4. IANA Considerations 4.1. Standard apt-X MIME media type name: audio MIME subtype name: aptX Required parameters: rate/Channels: The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 48000, but other rates may be specified. Allowable rates are 48000,44100,32000,24000,22050,16000,12000,8000. Any number of channels may be used and specified as 1,2,3,4,5,6,7,8 etc Optional parameters: audio-mode: (stereo/mono/dualmono) Encoding considerations: This type is only defined for transfer via RTP [RFC3550]. Security considerations: See Section 5 of [RFC4855][RFC4856] Interoperability considerations: none Published specification: RFC XXXX [RFC Editor: please replace by the RFC number of this memo, when published] Applications which use this media type: Audio streaming. Additional information: none Person & email address to contact for further information: Gregory Massey Intended usage: COMMON Author/Change controller: Gregory Massey 4.2. Enhanced apt-X 16 Bit Massey Expires December 26, 2008 [Page 7] Internet-Draft "RTP Payload Format for apt-X" June 2008 MIME media type name: audio MIME subtype name: EaptX 16 Required parameters: rate, channels The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 48000, but other rates may be specified. Default for channels is 2 (Stereo) Optional parameters: audio-mode: (stereo/mono/dualmono) Encoding considerations: This type is only defined for transfer via RTP [RFC3550]. Security considerations: See Section 5 of [RFC4855][RFC4856] Interoperability considerations: none Published specification: RFC XXXX [RFC Editor: please replace by the RFC number of this memo, when published] Applications which use this media type: Audio streaming. Additional information: none Person & email address to contact for further information: Gregory Massey Intended usage: COMMON Author/Change controller: Gregory Massey 4.3. Enhanced apt-X 24 Bit MIME media type name: audio MIME subtype name: EaptX 24 Massey Expires December 26, 2008 [Page 8] Internet-Draft "RTP Payload Format for apt-X" June 2008 Required parameters: rate/Channels The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 48000, but other rates may be specified. Optional parameters: audio-mode: stereo/mono/dualmono Encoding considerations: This type is only defined for transfer via RTP [RFC3550]. Security considerations: See Section 5 of [RFC4855][RFC4856] Interoperability considerations: none Published specification: RFC XXXX [RFC Editor: please replace by the RFC number of this memo, when published] Applications which use this media type: Audio streaming. Additional information: none Person & email address to contact for further information: Gregory Massey Intended usage: COMMON Author/Change controller: Gregory Massey 4.4. apt-X Live MIME media type name: audio MIME subtype name: aptXLive Required parameters: rate/Channels The RTP timestamp clock rate, which is equal to the sampling rate. The typical rate is 48000, but other rates may be specified. Massey Expires December 26, 2008 [Page 9] Internet-Draft "RTP Payload Format for apt-X" June 2008 Optional parameters: audio-mode: stereo/mono scale: Scale factors for aptX-Live algorithm (S20/S25/S30) Encoding considerations: This type is only defined for transfer via RTP [RFC3550]. Security considerations: See Section 5 of [RFC4855][RFC4856] Interoperability considerations: none Published specification: RFC XXXX [RFC Editor: please replace by the RFC number of this memo, when published] Applications which use this media type: Audio streaming. Additional information: none Person & email address to contact for further information: Gregory Massey Intended usage: COMMON Author/Change controller: Gregory Massey Massey Expires December 26, 2008 [Page 10] Internet-Draft "RTP Payload Format for apt-X" June 2008 5. SDP Related Considerations The following paragraphs defines the mapping of the parameters described in the IANA considerations section and their usage in the Offer/Answer Model [RFC3264]. 5.1. Mapping Media Type Parameters into SDP The information carried in the Media Type media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], that is commonly used to describe RTP sessions. When SDP is used to specify sessions the mapping are as follows: o The type name ("audio") goes in SDP "m=" as the media name. o The subtype name ("aptX") goes in SDP "a=rtpmap" as the encoding name. o The parameter "rate" also goes in "a=rtpmap" as clock rate. o The parameter "channels" also goes in "a=rtpmap" as channel count. o The optional parameter "audio-mode", "aux", "scale", when present, MUST be included in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies. 5.2. SDP Example The following example shows a basic SDP single stream. The first configuration packet is inlined in the sdp. c=IN IP4 192.0.2.x m=audio RTP/AVP 98 a=rtpmap:98 aptX/44100/2 a=fmtp:98 audio-mode=stereo; 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. Massey Expires December 26, 2008 [Page 11] Internet-Draft "RTP Payload Format for apt-X" June 2008 5.3. Usage with the SDP Offer/Answer Model The only parameter negotiable is the delivery method. All the others are declarative: the offer, as described in An Offer/Answer Model Session Description Protocol offer answer model [RFC3264], may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery-method. All the parameters MUST not be altered on answer otherwise. Massey Expires December 26, 2008 [Page 12] Internet-Draft "RTP Payload Format for apt-X" June 2008 6. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [2], and any appropriate RTP profile (for example [RFC3550]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [RFC3376] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. Massey Expires December 26, 2008 [Page 13] Internet-Draft "RTP Payload Format for apt-X" June 2008 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007. Massey Expires December 26, 2008 [Page 14] Internet-Draft "RTP Payload Format for apt-X" June 2008 Author's Address Gregory S. Massey APT Ltd Edgewater Road Belfast, CA BT3 9JQ UK Phone: +44 2890 371110 Email: gmassey@aptx.com URI: http://www.aptx.com/ Massey Expires December 26, 2008 [Page 15] Internet-Draft "RTP Payload Format for apt-X" June 2008 Full 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. 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. Intellectual Property 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. Massey Expires December 26, 2008 [Page 16]