summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7310.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7310.txt')
-rw-r--r--doc/rfc/rfc7310.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7310.txt b/doc/rfc/rfc7310.txt
new file mode 100644
index 0000000..35d8306
--- /dev/null
+++ b/doc/rfc/rfc7310.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Lindsay
+Request for Comments: 7310 H. Foerster
+Category: Standards Track APT Ltd
+ISSN: 2070-1721 July 2014
+
+
+ RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs
+
+Abstract
+
+ This document specifies a scheme for packetizing Standard apt-X or
+ Enhanced apt-X encoded audio data into Real-time Transport Protocol
+ (RTP) packets. The document describes a payload format that permits
+ transmission of multiple related audio channels in a single RTP
+ payload and a means of establishing Standard apt-X and Enhanced apt-X
+ connections through the Session Description Protocol (SDP).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7310.
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+ 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 Simplified BSD License.
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 1]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions .....................................................3
+ 3. Standard apt-X and Enhanced apt-X Codecs ........................3
+ 4. Payload Format Capabilities .....................................5
+ 4.1. Use of Forward Error Correction (FEC) ......................5
+ 5. Payload Format ..................................................5
+ 5.1. RTP Header Usage ...........................................5
+ 5.2. Payload Structure ..........................................6
+ 5.3. Default Packetization Interval .............................7
+ 5.4. Implementation Considerations ..............................8
+ 5.5. Payload Example ............................................8
+ 6. Payload Format Parameters ......................................10
+ 6.1. Media Type Definition .....................................10
+ 6.2. Mapping to SDP ............................................12
+ 6.2.1. SDP Usage Examples .................................13
+ 6.2.2. Offer/Answer Considerations ........................14
+ 7. IANA Considerations ............................................14
+ 8. Security Considerations ........................................14
+ 9. Acknowledgements ...............................................14
+ 10. References ....................................................15
+ 10.1. Normative References .....................................15
+ 10.2. Informative References ...................................15
+
+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 RTP payload format is detailed, and a relevant
+ example of the format is provided. The media type, its mappings to
+ SDP [RFC4566], and its usage in the SDP offer/answer model are 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.
+
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 2]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+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].
+
+3. Standard apt-X and Enhanced apt-X Codecs
+
+ Standard apt-X and Enhanced apt-X are proprietary audio coding
+ algorithms, which can be licensed from CSR plc. and are widely
+ deployed in a variety of audio processing equipment. For commercial
+ reasons, the detailed internal operations of these algorithms are not
+ described in standards or reference documents. However, the data
+ interfaces to implementations of these algorithms are very simple and
+ allow easy RTP packetization of data coded with the algorithms
+ without detailed knowledge of the actual 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 produce a constant coded bit rate that is 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 two channels
+ of 16-bit Pulse Code Modulated (PCM) audio that is sampled at a
+ frequency of 48 kHz is encoded at 384 kbit/s.
+
+ Standard apt-X and Enhanced apt-X do not enforce a coded frame
+ structure, and the coded data forms a continuous coded sample stream
+ with each coded sample capable of regenerating four PCM samples when
+ decoded. The Standard apt-X algorithm encodes four 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 four
+ successive 16-bit or 24-bit PCM samples from each audio channel and
+ respectively produces a single 16-bit or 24-bit coded sample per
+ channel. The same RTP packetization rules apply for each of these
+ algorithmic variations.
+
+ Standard apt-X and Enhanced apt-X coded data streams can optionally
+ carry synchronization information and an auxiliary data channel
+ within the coded audio data without additional overhead. These
+ mechanisms can, for instance, be used when the IP system is cascaded
+ with another transportation system and the decoder is acting as a
+
+
+
+Lindsay & Foerster Standards Track [Page 3]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ simple bridge between the two systems. Since auxiliary data channel
+ and synchronization information are carried within the coded audio
+ data without additional overhead, RTP payload format rules do not
+ change if they are present. Out-of-band signaling is required,
+ however, to notify the receiver end when autosync and auxiliary data
+ have been embedded in the apt-X stream.
+
+ Embedded auxiliary data is typically used to transport non-audio data
+ and timecode information for synchronization with video. The bit
+ rate of the auxiliary data channel is 1/4 of the sample frequency.
+ For example, with a single audio channel encoded at Fs = 48 kHz, an
+ auxiliary data bit rate of 12 kbit/s can be embedded.
+
+ apt-X further provides a means of stereo-pairing apt-X channels so
+ that the embedded autosync and auxiliary data channel can be shared
+ across the channel pair. In the case of a 1.536-Mbit/s stereo audio
+ stream composed of two channels of 16-bit PCM audio that is sampled
+ at 48 kHz, a byte of auxiliary data would typically be fed into the
+ Standard apt-X or Enhanced apt-X encoder once every 32 uncoded left
+ channel samples. By default, apt-X channel-pairing is not enabled.
+ Out-of-band signaling is required to notify the receiver when the
+ option is being used.
+
+ Standard apt-X and Enhanced apt-X decoders that have not been set up
+ with the correct embedded autosync, auxiliary data, and
+ stereo-pairing information will play out uncoded PCM samples with a
+ loss of decoding quality. In the case of Standard apt-X, the loss of
+ quality can be significant.
+
+ Further details on the algorithm operation can be obtained from
+ CSR plc.
+
+ Corporate HQ
+ Churchill House
+ Cambridge Business Park
+ Cowley Road
+ Cambridge
+ CB4 0WZ
+ UK
+ Tel: +44 1223 692000
+ Fax: +44 1223 692001
+ <http://www.csr.com>
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 4]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+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 carried by the payload.
+
+4.1. Use of Forward Error Correction (FEC)
+
+ Standard apt-X and Enhanced apt-X do not inherently provide any
+ mechanism for adding redundancy or error-control coding into the
+ coded audio stream. Generic schemes for RTP, such as forward error
+ correction as described in RFC 5109 [RFC5109] and RFC 2733 [RFC2733],
+ can be used to add redundant information to Standard apt-X and
+ Enhanced apt-X RTP packet streams, making them more resilient to
+ packet losses at the expense of a higher bit rate.
+
+5. Payload Format
+
+ The Standard apt-X and Enhanced apt-X algorithms encode four
+ successive PCM samples from each audio channel and produce a single
+ compressed sample for each audio channel. The encoder MUST 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
+ packetization of the encoded data SHALL be on a byte-by-byte basis.
+
+5.1. RTP Header Usage
+
+ Utilization 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. 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] and [RFC3551] Section 4.1
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 5]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ o PT - A dynamic payload type; MUST be used [RFC3551]
+
+ o SN (sequence number) - As per [RFC3550]
+
+ o Timestamp - As per [RFC3550]. The RTP timestamp reflects the
+ instant at which the first audio sample in the packet was sampled,
+ that is, the oldest information in the packet.
+
+ Header field abbreviations are defined as follows.
+
+ o V - Version Number
+
+ o P - Padding
+
+ o X - Extensions
+
+ o CC - Count of contributing sources
+
+ o M - Marker
+
+ o PT - Payload Type
+
+ o PS - Payload Structure
+
+5.2. Payload Structure
+
+ The RTP payload data for Standard apt-X and Enhanced apt-X MUST be
+ structured as follows.
+
+ Standard apt-X and Enhanced apt-X coded samples are packed
+ contiguously into payload octets in "network byte order", also known
+ as big-endian order, and starting with the most significant bit.
+ Coded samples are packed into the packet in time sequence, beginning
+ with the oldest coded sample. An integer number of coded samples
+ MUST be within the same packet.
+
+ When multiple channels of Standard apt-X and Enhanced apt-X coded
+ audio, such as in a stereo program, are multiplexed into a single RTP
+ stream, the coded samples from each channel, at a single sampling
+ instant, are interleaved into a coded sample block according to the
+ following standard audio channel ordering [RFC3551]. Coded sample
+ blocks are then packed into the packet in time sequence beginning
+ with the oldest coded sample block.
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 6]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ l left
+ r right
+ c center
+ S surround
+ F front
+ R rear
+
+ channels description channel
+ 1 2 3 4 5 6
+ ___________________________________________________
+ 2 stereo l r
+ 3 l r c
+ 4 l c r S
+ 5 Fl Fr Fc Sl Sr
+ 6 l lc c r rc S
+
+ For the two-channel encoding example, the sample sequence is (left
+ channel, first sample), (right channel, first sample), (left channel,
+ second sample), (right channel, second sample). Coded samples for
+ all channels, belonging to a single coded sampling instant, MUST be
+ contained in the same packet. All channels in the same RTP stream
+ MUST be sampled at the same frequency.
+
+5.3. Default Packetization Interval
+
+ The default packetization interval MUST have a duration of
+ 4 milliseconds. When an integer number of coded samples per channel
+ cannot be contained within this 4-millisecond interval, the default
+ packet interval MUST be rounded down to the nearest packet interval
+ that can contain a complete integer set of coded samples. For
+ example, when encoding audio with either Standard apt-X or Enhanced
+ apt-X, sampled at 11025 Hz, 22050 Hz, or 44100 Hz, the packetization
+ interval MUST be rounded down to 3.99 milliseconds.
+
+ The packetization interval sets limits on the end-to-end delay;
+ shorter packets minimize the audio delay through a system at the
+ expense of increased bandwidth, while longer packets introduce less
+ header overhead but increase delay and make packet loss more
+ noticeable. A default packet interval of 4 milliseconds maintains an
+ acceptable ratio of payload to header bytes and minimizes the
+ end-to-end delay to allow viable interactive applications based on
+ apt-X. All implementations MUST support this default packetization
+ interval.
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 7]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+5.4. Implementation Considerations
+
+ An application implementing this payload format MUST understand all
+ the payload parameters that are defined in this specification. Any
+ mapping of these parameters to a signaling protocol MUST support all
+ parameters. Implementations can always decide whether they are
+ capable of communicating based on the entities defined in this
+ specification.
+
+5.5. Payload Example
+
+ As an example payload format, consider the transmission of an
+ arbitrary 5.1 audio signal consisting of six channels of 24-bit PCM
+ data, sampled at a rate of 48 kHz and packetized on an RTP packet
+ interval of 4 milliseconds. The total bit rate before audio coding
+ is 6 * 24 * 48000 = 6.912 Mbit/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. On
+ packet intervals of 4 milliseconds, packets contain 864 bytes of
+ encoded data that contain 48 Enhanced apt-X coded samples per
+ channel.
+
+ For the example format, the diagram below shows how coded samples
+ from each channel are packed into a sample block and how sample
+ blocks 1, 2, and 48 are subsequently packed into the RTP packet.
+
+ C:
+ Channel index: Left (l) = 1, left center (lc) = 2,
+ center (c) = 3, right (r) = 4, right center (rc) = 5,
+ and surround (S) = 6.
+
+ T:
+ Sample Block time index: The first sample block is 1; the final
+ sample is 48.
+
+ S(C)(T):
+ The Tth sample from channel C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 8]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ 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(1)(1) | S(2)(1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(2)(1) | S(3)(1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(3)(1) | S(4)(1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(5)(1) | S(6)(1) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(6)(1) | S(1)(2) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(2)(2) | S(3)(2) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(4)(2) | S(5)(2) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(5)(2) | S(6)(2) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(6)(2) | S(1)(3) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(6)(47) | S(1)(48) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(1)(48) | S(2)(48) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(3)(48) | S(4)(48) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(4)(48) | S(5)(48) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S(5)(48) | S(6)(48) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ For the example format, the diagram below indicates the order that
+ coded bytes are packed into the packet payload in terms of sample
+ byte significance. 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:
+ Least Significant Byte of a 24-bit coded sample
+
+
+
+
+Lindsay & Foerster Standards Track [Page 9]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ 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 | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+6. 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 6838 [RFC6838].
+
+6.1. Media Type Definition
+
+ Type name: audio
+
+ Subtype name: aptx
+
+ Required parameters:
+
+ rate:
+ RTP timestamp clock rate, which is equal to the sampling rate
+ in Hz. RECOMMENDED values for rate are 8000, 11025, 16000,
+ 22050, 24000, 32000, 44100, and 48000 samples per second. Other
+ values are permissible.
+
+ channels:
+ The number of logical audio channels that are present in the
+ audio stream.
+
+ variant:
+ The variant of apt-X (i.e., Standard or Enhanced) that is being
+ used. The following variants can be signaled:
+
+ variant=standard
+ variant=enhanced
+
+ bitresolution:
+ The number of bits used by the algorithm to encode four PCM
+ samples. This value MAY only be set to 16 for Standard apt-X
+ and 16 or 24 for Enhanced apt-X.
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 10]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ Optional parameters:
+
+ ptime:
+ The recommended length of time (in milliseconds) represented by
+ the media in a packet. Defaults to 4 milliseconds.
+ See Section 6 of [RFC4566].
+
+ maxptime:
+ The maximum amount of media that can be encapsulated in each
+ packet, expressed as time in milliseconds. See Section 6 of
+ [RFC4566].
+
+ stereo-channel-pairs:
+ Defines audio channels that are stereo paired in the stream.
+ See Section 3. Each pair of audio channels is defined as two
+ comma-separated values that correspond to channel numbers in
+ the range 1..channels. Each stereo channel pair is preceded
+ by a '{' and followed by a '}'. Pairs of audio channels are
+ separated by a comma. A channel MUST NOT be paired with more
+ than one other channel. The absence of this parameter signals
+ that each channel has been independently encoded.
+
+ embedded-autosync-channels:
+ Defines channels that carry embedded autosync.
+ Embedded-autosync-channels is defined as a list of
+ comma-separated values that correspond to channel numbers in
+ the range 1..channels. When a channel is stereo paired, embedded
+ autosync is shared across channels in the pair. The first channel
+ as defined in stereo-channel-pairs MUST be specified in the
+ embedded-autosync-channels list.
+
+ embedded-aux-channels:
+ Defines channels that carry embedded auxiliary data.
+ Embedded-aux-channels is defined as a list of comma-separated
+ values that correspond to channel numbers in the range
+ 1..channels. When a channel is stereo paired, embedded auxiliary
+ data is shared across channels in the pair. The second channel
+ as defined in stereo-channel-pairs MUST be specified in the
+ embedded-aux-channels list.
+
+ Encoding considerations: This media type is framed in RTP and
+ contains binary data; see Section 4.8 of [RFC6838].
+
+ Security considerations: See Section 5 of [RFC4855] and Section 4
+ of [RFC4856].
+
+ Interoperability considerations: none
+
+
+
+
+Lindsay & Foerster Standards Track [Page 11]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ Published specification: RFC 7310
+
+ Applications which use this media type: Audio streaming
+
+ Fragment identifier considerations: None
+
+ Additional information: none
+
+ Person & email address to contact for further information:
+ John Lindsay <Lindsay@worldcastsystems.com>
+
+ Intended usage: COMMON
+
+ Restrictions on usage: This media type depends on RTP framing,
+ and hence is only defined for transfer via RTP [RFC3550].
+
+ Author/Change controller: IETF Payload Working Group delegated
+ from the IESG.
+
+6.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
+ is used to describe sessions, the media type mappings 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 the clock rate.
+
+ o The parameter "channels" also goes in "a=rtpmap" as the channel
+ count.
+
+ o The parameter "maxptime", when present, MUST be included in the
+ SDP "a=maxptime" attribute.
+
+ o The required parameters "variant" and "bitresolution" MUST be
+ included in the SDP "a=fmtp" attribute.
+
+ o The optional parameters "stereo-channel-pairs",
+ "embedded-autosync-channels", and "embedded-aux-channels", when
+ present, MUST be included in the SDP "a=fmtp" attribute.
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 12]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ o The parameter "ptime", when present, goes in a separate SDP
+ attribute field and is signaled as "a=ptime:<value>", where
+ <value> is the number of milliseconds of audio represented by
+ one RTP packet. See Section 6 of [RFC4566].
+
+6.2.1. SDP Usage Examples
+
+ Some example SDP session descriptions utilizing apt-X encodings
+ follow. In these examples, long "a=fmtp" lines are folded to meet
+ the column width constraints of this document.
+
+ Example 1: A Standard apt-X stream that encodes two independent
+ 44.1-kHz 16-bit PCM channels into a 4-millisecond RTP packet.
+
+ m=audio 5004 RTP/AVP 98
+ a=rtpmap:98 aptx/44100/2
+ a=fmtp:98 variant=standard; bitresolution=16;
+ a=ptime:4
+
+ Example 2: An Enhanced apt-X stream that encodes two 48-kHz 24-bit
+ stereo channels into a 4-millisecond RTP packet and carries both an
+ embedded autosync and auxiliary data channel.
+
+ m=audio 5004 RTP/AVP 98
+ a=rtpmap:98 aptx/48000/2
+ a=fmtp:98 variant=enhanced; bitresolution=24;
+ stereo-channel-pairs={1,2}; embedded-autosync-channels=1;
+ embedded-aux-channels=2
+ a=ptime:4
+
+ Example 3: An Enhanced apt-X stream that encodes six 44.1-kHz 24-bit
+ channels into a 6-millisecond RTP packet. Channels 1,2 and 3,4 are
+ stereo pairs. Both stereo pairs carry both an embedded autosync and
+ auxiliary data channel.
+
+ m=audio 5004 RTP/AVP 98
+ a=rtpmap:98 aptx/44100/6
+ a=fmtp:98 variant=enhanced; bitresolution=24;
+ stereo-channel-pairs={1,2},{3,4}; embedded-autosync-channels=1,3;
+ embedded-aux-channels=2,4
+ a=ptime:6
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 13]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+6.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 that is not supported. Apart from this exceptional
+ case, all parameters MUST NOT be altered on answer.
+
+7. IANA Considerations
+
+ One media type (audio/aptx) has been registered in the "Media Types"
+ registry. See Section 6.1.
+
+8. 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
+ that 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. [RFC6562] has
+ highlighted potential security vulnerabilities of Variable Bit Rate
+ (VBR) codecs using Secure RTP transmission methods. As the Standard
+ apt-X and Enhanced apt-X codecs are Constant Bit Rate (CBR) codecs,
+ this security vulnerability is therefore not applicable.
+
+9. Acknowledgements
+
+ This specification was facilitated by earlier documents produced by
+ Greg Massey, David Trainer, James Hunter, and Derrick Rea, along with
+ practical tests carried out by Paul McCambridge of APT Ltd.
+
+
+
+
+Lindsay & Foerster Standards Track [Page 14]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+10. References
+
+10.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.
+
+ [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+ Video Conferences with Minimal Control", STD 65, RFC 3551,
+ July 2003.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+10.2. Informative References
+
+ [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
+ for Generic Forward Error Correction", RFC 2733,
+ December 1999.
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol,
+ Version 3", RFC 3376, October 2002.
+
+ [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., Ed., "RTP Payload Format for Generic Forward Error
+ Correction", RFC 5109, December 2007.
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 15]
+
+RFC 7310 apt-X RTP Format July 2014
+
+
+ [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
+ Variable Bit Rate Audio with Secure RTP", RFC 6562,
+ March 2012.
+
+ [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
+ Specifications and Registration Procedures", BCP 13,
+ RFC 6838, January 2013.
+
+Authors' Addresses
+
+ John Lindsay
+ APT Ltd
+ 729 Springfield Road
+ Belfast
+ Northern Ireland
+ BT12 7FP
+ UK
+
+ Phone: +44 2890 677200
+ EMail: Lindsay@worldcastsystems.com
+
+
+ Hartmut Foerster
+ APT Ltd
+ 729 Springfield Road
+ Belfast
+ Northern Ireland
+ BT12 7FP
+ UK
+
+ Phone: +44 2890 677200
+ EMail: Foerster@worldcastsystems.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lindsay & Foerster Standards Track [Page 16]
+