A/V Transport Working Group D. Trainor, Ed. Internet-Draft APT Licensing Ltd Intended status: Standards Track December 22, 2009 Expires: June 25, 2010 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs draft-trainor-avt-rtp-aptx-00 Abstract This document specifies the payload format for packetization of audio data encoded with the Standard apt-X or Enhanced apt-X audio coding algorithms into the Real-time Transport Protocol (RTP).The payload format supports transmission of multiple related audio channels per payload. This document also describes the use of the Standard apt-X and Enhanced apt-X coding algorithms in conjunction with the Session Description Protocol (SDP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 June 25, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Trainor Expires June 25, 2010 [Page 1] Internet-Draft apt-X RTP Format December 2009 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Standard apt-X and Enhanced apt-X Codecs . . . . . . . . . . . 5 4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 6 4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 6 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 7 5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 8 5.3. Implementation Considerations . . . . . . . . . . . . . . 8 6. Payload Example . . . . . . . . . . . . . . . . . . . . . . . 9 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 13 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 13 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 14 7.2.1. SDP Usage Example . . . . . . . . . . . . . . . . . . 15 7.2.2. Offer/Answer Considerations . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Trainor Expires June 25, 2010 [Page 2] Internet-Draft apt-X RTP Format December 2009 1. Introduction This document specifies the payload format for packetization of audio data encoded with the Standard apt-X or Enhanced apt-X audio coding algorithms into the Real-time Transport Protocol (RTP). [RFC3550]. The document outlines some conventions, a brief description of the operating principles of the audio codecs, and the payload format capabilities. The detailed RTP payload format is specified and a relevant example of the format is provided. The media type, its mappings to the SDP [RFC4566] and its usage in the SDP offer/answer model is also specified. Finally, some security considerations are outlined. This document registers a media type (audio/aptx) for the RTP payload format for the Standard apt-X and Enhanced apt-X audio codecs. Trainor Expires June 25, 2010 [Page 3] Internet-Draft apt-X RTP Format December 2009 2. Conventions This document uses the normal IETF bit-order representation. Bit fields in figures are read left to right and then down. The leftmost bit in each field is the most significant. The numbering starts from 0 and ascends, where bit 0 will be the most significant. 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 [RFC2119]. Trainor Expires June 25, 2010 [Page 4] Internet-Draft apt-X RTP Format December 2009 3. Standard apt-X and Enhanced apt-X Codecs Standard apt-X and Enhanced apt-X are proprietary audio coding algorithms licensed by APT Licensing Ltd and widely deployed in a variety of audio processing equipment. For commercial reasons, the detailed internal operation of these algorithms is not described in standards or reference documents. However, the data interface of an implementation of either codec algorithm is very simple and allows easy RTP packetization without a particularly detailed knowledge of the coded audio stream syntax. Both the Standard apt-X and Enhanced apt-X coding algorithms are based on Adaptive Differential Pulse Code Modulation principles. They both produce a constant coded bit rate scaled according to the sample frequency of the uncoded audio. This constant rate is 1/4 of the bit rate of the uncoded audio, irrespective of the resolution (number of bits) used to represent an uncoded audio sample. For example, a 1.536 Mbit/s stereo audio stream composed of 2 channels of 16-bit Pulse Code Modulation (PCM) samples at a sample rate of 48 kHz is encoded at 384 kbit/s. The Standard apt-X and Enhanced apt-X algorithms can carry an auxiliary data channel and synchronisation information within the coded audio data without additional overhead. Hence the RTP payload format is unaffected by the presence or absence of the optional auxiliary data channel, which can be used to transport non-audio data or timecode information for synchronisation with video. The bit rate of the auxiliary data channel is 1/4 of the sample frequency, for example at Fs = 48 kHz bit rate of the auxiliary data stream is 12 kbit/s. The auxiliary data stream is fed into the Standard apt-X or Enhanced apt-X encoder implementation as separately from the uncoded audio data. Similarly the decoded audio data and recovered auxiliary data appear on separate outputs of a Standard apt-X or Enhanced apt-X decoder implementation. The Standard apt-X algorithm encodes 4 successive 16-bit PCM samples from each audio channel into a single 16-bit coded sample per audio channel. The Enhanced apt-X algorithm encodes 4 successive 16-bit or 24-bit PCM samples from each audio channel and produces a single 16- bit or 24-bit coded sample per channel. A similar RTP packetisation mechanism is applied for each of these algorithmic variations. Note that both Standard apt-X and Enhanced apt-X do not enforce a coded frame structure and the coded data syntax is a continuous coded sample stream, with each sample capable of regenerating 4 PCM samples upon decoding. Trainor Expires June 25, 2010 [Page 5] Internet-Draft apt-X RTP Format December 2009 4. Payload Format Capabilities This RTP payload format carries an integer number of Standard apt-X or Enhanced apt-X coded audio samples. When multiple related audio channels are being conveyed within the payload, each channel contributes the same integer number of apt-X coded audio samples to the total number of samples carried by the payload. 4.1. Use of Forward Error Correction (FEC) Generic forward error correction schemes for RTP such as RFC 2198 [RFC2198] and RFC 5109 [RFC5109] have been defined. Such generic and media-unaware schemes can be used to add redundant information to the RTP packet stream and make it more resilient to packet losses, at the expense of a higher bit rate. Neither Standard apt-X nor Enhanced apt-X provides any specific form of redundancy or error-control coding. Trainor Expires June 25, 2010 [Page 6] Internet-Draft apt-X RTP Format December 2009 5. Payload Format The Standard apt-X and Enhanced apt-X algorithms encode 4 successive PCM samples from each audio channel and produce a single compressed sample for each audio channel. The encoder SHALL be presented with an integer number S of input audio samples, where S is an arbitrary multiple of 4. The encoder will produce exactly S/4 coded audio samples. Since each coded audio sample is either 16 or 24 bits, the amount of coded audio data produced upon each invocation of the encoding process will be an integer number of bytes. RTP packetisation of the encoded data SHALL be on a byte-by-byte basis. 5.1. RTP Header Usage Utilisation of the Standard apt-X and Enhanced apt-X coding algorithms does not create any special requirements with respect to the contents of the RTP packet header. The timestamp used in the RTP header shall comply with the timestamp specified in RFC 3550 [RFC3550]. Other RTP packet header fields are defined as follows. o V - As per [RFC3550] o P - As per [RFC3550] o X - As per [RFC3550] o CC - As per [RFC3550] o M - As per [RFC3550] o PT - Payload Type to be defined according to MIME allocation: audio/aptx o SN - As per [RFC3550] Header field abbreviations are defined as follows. V - Version Number P - Padding X - Extensions CC - Count of contributing sources M - Marker Trainor Expires June 25, 2010 [Page 7] Internet-Draft apt-X RTP Format December 2009 PT - Payload Type PS - Payload Structure 5.2. Payload Structure The RTP payload data for Standard apt-X and Enhanced apt-X SHALL be structured as follows. The number of audio channels associated with an individual audio stream MUST be either 1 or an integer multiple of 2 and is hereafter referred to as a channel group. Within a channel group consisting of more than 1 channel, successive pairs of channels are considered together and hereafter referred to as channel pairs. When considering the formation of channel pairs, standard audio channel ordering within a channel group MUST be used, for example the left channel precedes the right for stereo and 5.1 audio uses the channel ordering Front Left, Front Right, Front Centre, Low Frequency, Back Left and Back Right. The packet payload MUST consist of an integer number of a basic data unit hereafter referred to as a sample block. Sample blocks are successively packed into the packet payload. Each sample block consists of a fixed number of coded bytes and each channel in a channel group contributes an identical number of coded bytes N to each sample block. N is calculated as the number of conceptual 64 kbit/s streams represented by the total coded bit rate of the audio signal. For example, N=6 when transmitting a 384 kbit/s coded audio stream and N=9 when transmitting a 576 kbit/s coded audio stream. Hence the total number of bytes in each sample block is the product N x C, where C is the number of channels in a channel group. Data ordering within a sample block SHALL be as follows. The sample block contribution from each channel pair SHALL be packed into the sample block in channel pair order. The sample block contribution from each channel pair SHALL be formed by interleaving corresponding coded samples from the 2 channels in the channel pair, beginning with the first sample in time from the first channel. Individual coded samples SHALL be packed into the payload in a byte-by-byte fashion, with most significant sample byte first. Individual bytes SHALL be packed most significant bit first. 5.3. Implementation Considerations An application implementing this payload format MUST understand all the payload parameters that is defined in this specification. Any mapping of the parameters to a signaling protocol MUST support all parameters. Hence, an implementation always can decide whether it is capable of communicating under the assumption that the communicating entities support this specification. Trainor Expires June 25, 2010 [Page 8] Internet-Draft apt-X RTP Format December 2009 6. Payload Example As an example payload format, consider the transmission of an arbitrary 5.1 audio signal consisting of 6 channels of 24-bit PCM data sampled at a rate of 48 kHz. The total bit rate before audio coding is 6 * 24 * 48000 = 6.912 Mbits/s. Applying Enhanced apt-X coding, with a coded sample size of 24 bits, results in a transmitted coded bit rate of 1/4 of the uncoded bit rate, i.e. 1.728 Mbit/s. Hence, the value of N defined in the previous section is N = 1728 / 64 = 27 bytes, thereby specifying that 27 coded bytes, or equivalently 9 coded samples are placed into each sample block from each audio channel. Channel ordering within a sample block is taken to be the standard 5.1 ordering of Front Left (FL), Front Right (FR), Front Centre (FC), Low Frequency (LF), Back Left (BL) and Back Right (BR). This results in 3 channel pairs. The first pair consists of FL and FR, in that channel order. The second pair consists of FC and LF, in that channel order. The third pair consists of BL and BR, in that channel order. For the example format, the diagram below indicates the order that coded bytes are placed into the packet payload in terms of sample byte significance. Note that the following abbreviations are used. MSB: Most Significant Byte of a 24-bit coded sample MB: Middle Byte of a 24-bit coded sample LSB: Most Significant Byte of a 24-bit coded sample 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSB | MB | LSB | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the example format, the diagram below indicates how the contribution that a channel pair makes to each sample block of coded data is placed into the packet payload. The coded samples, with byte ordering outlined in the previous diagram, are packed in terms of the channel ordering within the channel pair and the sample time index. Note that each channel contributes 9 coded samples to the sample block and that the following abbreviations are used. Trainor Expires June 25, 2010 [Page 9] Internet-Draft apt-X RTP Format December 2009 C: Channel index within the channel pair. The first channel is 0, second is 1 T: Sample time index within a sample block. The first sample is 0, the final sample is 8 S(C)(T): The Tth sample from channel C 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(0) | S(1)(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(1)(0) | S(0)(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(1) | S(1)(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(2) | S(1)(2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(1)(2) | S(0)(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(3) | S(1)(3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(4) | S(1)(4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(1)(4) | S(0)(5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(5) | S(1)(5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(6) | S(1)(6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(1)(6) | S(0)(7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(7) | S(1)(7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(0)(8) | S(1)(8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S(1)(8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the example format, the diagram below indicates how the contributions from each of the the 3 channel pairs, as specified in the previous diagram, are placed into the packet payload to form a sample block. The coded contributions are packed in channel pair Trainor Expires June 25, 2010 [Page 10] Internet-Draft apt-X RTP Format December 2009 ordering. Note that the following abbreviations are used. FLFR: The contribution from the channel pair consisting of the FL and FR channels FCLF: The contribution from the channel pair consisting of the FC and LF channels BLBR: The contribution from the channel pair consisting of the BL and BR channels 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b0 FLFR b31| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b32 FLFR b63| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b416 FLFR b431|b0 FCLF b15| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b16 FCLF b47| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b400 FCLF b431| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b0 BLBR b31| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |b416 BLBR b431| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An integer number B of sample blocks, as specified in the previous diagram, can be concatenated in sample time order into the RTP packet payload. The only restriction on the range of the integer B is that Trainor Expires June 25, 2010 [Page 11] Internet-Draft apt-X RTP Format December 2009 the corresponding amount of payload data must be within the range of payload lengths permitted by RTP. Trainor Expires June 25, 2010 [Page 12] Internet-Draft apt-X RTP Format December 2009 7. Payload Format Parameters This RTP payload format is identified using the media type audio/ aptx, which is registered in accordance with RFC 4855 [RFC4855] and using the template of RFC 4288 [RFC4288] 7.1. Media Type Definition Registration of media subtype audio/aptx. MIME media type name: audio MIME subtype name: aptx Required parameters: rate: RTP timestamp clock rate, which is equal to the sampling rate in Hz. The typical rate is 48000, but other rates may be specified. channels: How many logical audio channels are present in an audio stream. Defaults to 2 (stereo). variant: The variant of apt-X (i.e. Standard or Enhanced) that shall be used. The following variants can be signalled: variant=standard variant=enhanced bitresolution: The number of bits used by the algorithm to encode 4 PCM samples. This value may only be set to 16 for Standard apt-X and 16 or 24 for Enhanced apt-X. Optional parameters: ptime: The recommended length of time (in milliseconds) represented by the media in a packet. See Section 6 of [RFC4566]. maxptime: The maximum length of time (in milliseconds) that can be encapsulated in a packet. See Section 6 of [RFC4566]. Trainor Expires June 25, 2010 [Page 13] Internet-Draft apt-X RTP Format December 2009 aux: Indicates the transportation method of the auxiliary data discussed in Section 3. Allowed values are: aux=off No aux data present. aux=embedded Aux data embedded within the primary audio stream. aux=ip-aux Aux data transmitted on a separate ip stream. If this value is set then aux-port parameter MUST also be present. If the aux parameter is omitted then it is assumed that no auxiliary data is available. aux-port: Indicates the port on which aux data can be received. This parameter MUST be present when aux value is set to "ip-aux", in all other cases this value MUST NOT be used. Encoding considerations: This type is only defined for transfer via RTP [RFC3550]. Security considerations: See Section 5 of [RFC4855] and Section 4 of [RFC4856]. Interoperability considerations: none Published specification: RFC XXXX Applications which use this media type: Audio streaming Additional information: none Person & email address to contact for further information: David Trainor email:dtrainor@aptx.com Intended usage: COMMON Author/Change controller: David Trainor 7.2. Mapping to SDP The information carried in the 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 Trainor Expires June 25, 2010 [Page 14] Internet-Draft apt-X RTP Format December 2009 is used to describe sessions the media type mappings are as follows. The type name ("audio") goes in SDP "m=" as the media name. The subtype name ("aptx") goes in SDP "a=rtpmap" as the encoding name. The parameter "rate" also goes in "a=rtpmap" as clock rate. The parameter "channels" also goes in "a=rtpmap" as channel count. The required parameters "variant" and "bitresolution" MUST be included in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies. The optional parameters "aux", "aux-port", and "maxptime" when present, MUST be included in the SDP "a=fmtp" attribute and MUST follow the delivery-method that applies. The parameter "ptime", when present, goes in a separate SDP attribute field and is signalled as "a=ptime:", where is the number of millseconds of audio represented by one RTP packet. See Section 6 of [RFC4566]. 7.2.1. SDP Usage Example The following example shows a basic SDP description of a single audio stream. The first configuration packet is inlined in the SDP, other configurations could be fetched at any time from the first provided uri, or all the known configuration could be downloaded using the second uri. c=IN IP4 192.0.2.24 m=audio 5004 RTP/AVP 98 a=rtpmap:98 aptx/44100/2 a=fmtp:98 variant=enhanced; bitresolution=24; aux=ip-aux; aux- port=4000; a=ptime:4 Note that parameter names are case-insensitive both in media types and in the mapping to the SDP a=fmtp attribute. Trainor Expires June 25, 2010 [Page 15] Internet-Draft apt-X RTP Format December 2009 7.2.2. Offer/Answer Considerations The only negotiable parameter is the delivery method. All other parameters are declarative. The offer, as described in [RFC3264], may contain a large number of delivery methods per single fmtp attribute, the answerer MUST remove every delivery method and configuration uri not supported. Apart from this exceptional case, all parameters MUST NOT be altered on answer. Trainor Expires June 25, 2010 [Page 16] Internet-Draft apt-X RTP Format December 2009 8. IANA Considerations One media type (audio/aptx) has been defined and needs registration in the media types registry. See Section 7.1 Trainor Expires June 25, 2010 [Page 17] Internet-Draft apt-X RTP Format December 2009 9. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and any appropriate RTP profile (for example [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. Because the audio coding used with this payload format is applied end-to-end, encryption may be performed after audio coding so there is no conflict between the two operations. A potential denial-of-service threat exists for audio coding 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, the Standard apt-X and Enhanced apt-X audio coding algorithms do 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. Trainor Expires June 25, 2010 [Page 18] Internet-Draft apt-X RTP Format December 2009 10. Acknowledgements This specification was facilitated by earlier documents and practical results produced by Greg Massey, Paul McCambridge and James Hunter of APT Ltd. Trainor Expires June 25, 2010 [Page 19] Internet-Draft apt-X RTP Format December 2009 11. References 11.1. 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. [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. 11.2. Informative References [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [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. [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007. Trainor Expires June 25, 2010 [Page 20] Internet-Draft apt-X RTP Format December 2009 Author's Address David Trainor (editor) APT Licensing Ltd 729 Springfield Road Belfast, Northern Ireland BT12 7FP UK Phone: +44 2890 677250 Email: dtrainor@aptx.com Trainor Expires June 25, 2010 [Page 21]