idnits 2.17.1 draft-rea-payload-rtp-aptx-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 283 has weird spacing: '...hannels desc...' == Line 290 has weird spacing: '... l lc c r...' -- The document date (March 7, 2012) is 4423 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft J. Lindsay 2 A/V Transport Payloads Working Group D. Rea 3 Intended status: Standards Track APT Ltd 4 Expires: September 7, 2012 March 7, 2012 6 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs 7 draft-rea-payload-rtp-aptx-02 9 Abstract 11 This document specifies a scheme for packetizing Standard apt-X, or 12 Enhanced apt-X, encoded audio data into Real-time Transport Protocol 13 (RTP) packets. The document describes a payload format that permits 14 transmission of multiple related audio channels in a single RTP 15 payload, and a means of establishing Standard apt-X and Enhanced 16 apt-X connections through the Session Description Protocol (SDP). 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Comments are solicited and should be addressed to the A/V Transport 24 Payloads working group's mailing list at payload@ietf.org and/or the 25 authors. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 7, 2012. 45 Submission Compliance for Internet-Drafts. 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Copyright and License Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Standard apt-X and Enhanced apt-X Codecs . . . . . . . . . . . 6 70 4. Payload Format Capabilities . . . . . . . . . . . . . . . . . 8 71 4.1. Use of Forward Error Correction (FEC) . . . . . . . . . . 8 72 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Payload Structure . . . . . . . . . . . . . . . . . . . . 10 75 5.3. Default Packetization Interval . . . . . . . . . . . . . . 11 76 5.4. Implementation Considerations . . . . . . . . . . . . . . 11 77 5.5. Payload Example . . . . . . . . . . . . . . . . . . . . . 11 78 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 79 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 14 80 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 16 81 6.2.1. SDP Usage Example . . . . . . . . . . . . . . . . . . 16 82 6.2.2. Offer/Answer Considerations . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 89 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 This document specifies the payload format for packetization of audio 94 data, encoded with the Standard apt-X or Enhanced apt-X audio coding 95 algorithms, into the Real-time Transport Protocol (RTP). [RFC3550]. 97 The document outlines some conventions, a brief description of the 98 operating principles of the audio codecs, and the payload format 99 capabilities. The RTP payload format is detailed and a relevant 100 example of the format is provided. The media type, its mappings to 101 SDP [RFC4566] and its usage in the SDP offer/answer model are also 102 specified. Finally, some security considerations are outlined. 104 This document registers a media type (audio/aptx) for the RTP payload 105 format for the Standard apt-X and Enhanced apt-X audio codecs. 107 2. Conventions 109 This document uses the normal IETF bit-order representation. Bit 110 fields in figures are read left to right and then down. The leftmost 111 bit in each field is the most significant. The numbering starts from 112 0 and ascends, where bit 0 will be the most significant. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Standard apt-X and Enhanced apt-X Codecs 120 Standard apt-X and Enhanced apt-X are proprietary audio coding 121 algorithms, licensed by CSR plc and widely deployed in a variety of 122 audio processing equipment. For commercial reasons, the detailed 123 internal operations of these algorithms are not described in 124 standards or reference documents. However, the data interfaces to 125 implementations of these algorithms are very simple, and allow easy 126 RTP packetization of data coded with the algorithms, without a 127 detailed knowledge of the actual coded audio stream syntax. 129 Both the Standard apt-X and Enhanced apt-X coding algorithms are 130 based on Adaptive Differential Pulse Code Modulation principles. 131 They produce a constant coded bit rate that is scaled according to 132 the sample frequency of the uncoded audio. This constant rate is 1/4 133 of the bit rate of the uncoded audio, irrespective of the resolution 134 (number of bits) used to represent an uncoded audio sample. For 135 example, a 1.536 Mbit/s stereo audio stream, composed of 2 channels 136 of 16-bit Pulse Code Modulated (PCM) audio that is sampled at a 137 frequency of 48 kHz, is encoded at 384 kbit/s. 139 Standard apt-X and Enhanced apt-X do not enforce a coded frame 140 structure, and the coded data forms a continuous coded sample stream 141 with each coded sample capable of regenerating 4 PCM samples when 142 decoded. The Standard apt-X algorithm encodes 4 successive 16-bit 143 PCM samples from each audio channel into a single 16-bit coded sample 144 per audio channel. The Enhanced apt-X algorithm encodes 4 successive 145 16-bit or 24-bit PCM samples from each audio channel and respectively 146 produces a single 16-bit or 24-bit coded sample per channel. The 147 same RTP packetisation rules apply for each of these algorithmic 148 variations. 150 . Standard apt-X and Enhanced apt-X coded data streams can optionally 151 carry synchronisation information and an auxiliary data channel 152 within the coded audio data without additional overhead. These 153 mechanisms can, for instance, be used when the IP system is cascaded 154 with another transportation system and the decoder is acting as a 155 simple bridge between the two systems. Since auxiliary data channel 156 and synchronisation information are carried within the coded audio 157 data without additional overhead, RTP payload format rules do not 158 change if they are present. Out-of-band signalling is required 159 however to notify the receiver end when autosync and auxiliary data 160 have been embedded in the apt-X stream. 162 Embedded auxiliary data is typically used to transport non-audio 163 data, and timecode information for synchronisation with video. The 164 bit rate of the auxiliary data channel is 1/4 of the sample 165 frequency. For example with a single audio channel encoded at Fs = 166 48kHz, an auxiliary data bit rate of 12 kbit/s can be embedded. 168 apt-X further provides a means of stereo pairing apt-X channels so 169 that the embedded autosync and auxiliary data channel can be shared 170 across the channel pair. In the case of a 1.536 Mbit/s stereo audio 171 stream, composed of 2 channels of 16-bit PCM audio that is sampled 172 at 48 kHz, a byte of auxiliary data would typically be fed into the 173 Standard or Enhanced apt-X encoder once every 32 uncoded left 174 channel samples. By default apt-X channels pairing is not enabled. 175 Out-of-band signalling is required to notify the receiver when the 176 option is being used. 178 Standard apt-X and Enhanced apt-X decoders that have not be set up 179 with the correct embedded autosync, auxiliary data and stereo pairing 180 information will playout uncoded PCM samples with a loss of decoding 181 quality. In the case of standard apt-X the loss of quality can be 182 significant. 184 4. Payload Format Capabilities 186 This RTP payload format carries an integer number of Standard apt-X 187 or Enhanced apt-X coded audio samples. When multiple related audio 188 channels are being conveyed within the payload, each channel 189 contributes the same integer number of apt-X coded audio samples to 190 the total carried by the payload. 192 4.1. Use of Forward Error Correction (FEC) 194 Standard apt-X and Enhanced apt-X do not inherently provide any 195 mechanism for adding redundancy or error-control coding into the 196 coded audio stream. Generic forward error correction schemes for RTP 197 such as RFC 2198 [RFC2198] and RFC 5109 [RFC5109] can be used to add 198 redundant information to Standard apt-X and Enhanced apt-X RTP packet 199 streams, making them more resilient to packet losses at the expense 200 of a higher bit rate. 202 5. Payload Format 204 The Standard apt-X and Enhanced apt-X algorithms encode 4 successive 205 PCM samples from each audio channel and produce a single compressed 206 sample for each audio channel. The encoder MUST be presented with 207 an integer number S of input audio samples, where S is an arbitrary 208 multiple of 4. The encoder will produce exactly S/4 coded audio 209 samples. Since each coded audio sample is either 16 or 24 bits, the 210 amount of coded audio data produced upon each invocation of the 211 encoding process will be an integer number of bytes. RTP 212 packetization of the encoded data SHALL be on a byte-by-byte basis. 214 5.1. RTP Header Usage 216 Utilisation of the Standard apt-X and Enhanced apt-X coding 217 algorithms does not create any special requirements with respect to 218 the contents of the RTP packet header. Other RTP packet header 219 fields are defined as follows. 221 o V - As per [RFC3550] 223 o P - As per [RFC3550] 225 o X - As per [RFC3550] 227 o CC - As per [RFC3550] 229 o M - This payload format defines no use for this bit. Senders 230 SHOULD set this bit to zero in each outgoing packet. 232 o PT - A dynamic payload type, i.e. one within the range [96..127], 233 MUST be used. [RFC3551] 235 o SN - As per [RFC3550] 237 o Timestamp - As per [RFC3550]. The RTP timestamp reflects the 238 instant at which the first audio sample in the packet was sampled, 239 that is, the oldest information in the packet. 241 Header field abbreviations are defined as follows. 243 V - Version Number 245 P - Padding 247 X - Extensions 249 CC - Count of contributing sources 250 M - Marker 252 PT - Payload Type 254 PS - Payload Structure 256 5.2. Payload Structure 258 The RTP payload data for Standard apt-X and Enhanced apt-X MUST be 259 structured as follows. 261 Standard and Enhanced apt-X coded samples are packed contiguously 262 into payload octets in "network byte order", also known as big-endian 263 order and starting with the most significant bit. Coded samples are 264 packed into the packet in time sequence beginning with the oldest 265 coded sample. An integer number of coded samples MUST be within the 266 same packet. 268 When multiple channels of Standard and E-APTX coded audio, such as 269 in a stereo program, are multiplexed into a single RTP stream, the 270 coded samples from each channel, at a single sampling instant, are 271 interleaved into a coded sample block according to the following 272 standard audio channel ordering, [RFC3551]. Coded sample blocks are 273 then packed into the packet in time sequence beginning with the 274 oldest coded sample block. 276 l left 277 r right 278 c center 279 S surround 280 F front 281 R rear 283 channels description channel 284 1 2 3 4 5 6 285 _________________________________________________ 286 2 stereo l r 287 3 l r c 288 4 l c r S 289 5 Fl Fr Fc Sl Sr 290 6 l lc c r rc S 292 For the two-channel encoding example, the sample sequence is (left 293 channel, first sample), (right channel, first sample), (left channel, 294 second sample), (right channel, second sample). Coded Samples for all 295 channels, belonging to a single coded sampling instant, MUST be 296 contained in the same packet. All channels in the same RTP stream 297 MUST be sampled at the same frequency. 299 5.3. Default Packetization Interval 301 The default packetization interval MUST have a duration of 4 ms. 302 When an integer number of coded samples per channel cannot be 303 contained within this 4ms interval, the default packet interval MUST 304 be rounded down to the nearest packet interval that can contain a 305 complete integer set of coded samples. For example when encoding 306 audio with either Standard or Enhanced apt-X, sampled at 11025 Hz, 307 22050 Hz, or 44100 Hz, the packetization interval MUST be rounded 308 down to 3.99 ms. 310 The packetization interval sets limits on the end-to-end delay; 311 shorter packets minimize the audio delay through a system at the 312 expense of increased bandwidth while longer packets introduce 313 less header overhead but increase delay and make packet loss 314 more noticeable. A default packet interval of 4 ms maintains an 315 acceptable ratio of payload to header bytes and minimizes 316 the end-to-end delay to allow viable interactive apt-X based 317 applications. All implementations MUST support this default 318 packetization interval. 320 5.4. Implementation Considerations 322 An application implementing this payload format MUST understand all 323 the payload parameters that are defined in this specification. Any 324 mapping of these parameters to a signaling protocol MUST support all 325 parameters. Implementation can always decide whether they are 326 capable of communicating based on the entities defined in this 327 specification. 329 5.5. Payload Example 331 As an example payload format, consider the transmission of an 332 arbitrary 5.1 audio signal consisting of 6 channels of 24-bit PCM 333 data, sampled at a rate of 48 kHz and packetized on a RTP packet 334 interval of 4ms. The total bit rate before audio coding is 335 6 * 24 * 48000 = 6.912 Mbits/s. Applying Enhanced apt-X coding, 336 with a coded sample size of 24 bits, results in a transmitted coded 337 bit rate of 1/4 of the uncoded bit rate, i.e. 1.728 Mbit/s. On packet 338 intervals of 4 ms, packets contain 864 bytes of encoded data that 339 contain 48 Enhanced apt-X coded samples per channel. 341 For the example format, the diagram below shows how coded samples 342 from each channel are packed into a sample block and how sample 343 blocks 1, 2, and 48 are subsequently packed into the RTP packet. 345 C: 346 Channel index: Left (l) = 1, left centre (lc) = 2, centre 347 (c) = 3, right (r) = 4, right centre (rc) = 5, surround (S) = 6. 349 T: 350 Sample Block time index: The first sample block is 1, the final 351 sample is 48. 353 S(C)(T): 354 The Tth sample from channel C 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | S(1)(1) | S(2)(1) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | S(2)(1) | S(3)(1) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | S(3)(1) | S(4)(1) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | S(5)(1) | S(6)(1) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | S(6)(1) | S(1)(2) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | S(2)(2) | S(3)(2) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | S(4)(2) | S(5)(2) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | S(5)(2) | S(6)(2) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | S(6)(2) | S(1)(3) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | S(6)(47) | S(1)(48) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | S(1)(48) | S(2)(48) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | S(3)(48) | S(4)(48) | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | S(4)(48) | S(5)(48) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | S(5)(48) | S(6)(48) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 For the example format, the diagram below indicates the order that 390 coded bytes are packed into the packet payload in terms of sample 391 byte significance. The following abbreviations are used. 393 MSB: 394 Most Significant Byte of a 24-bit coded sample 396 MB: 397 Middle Byte of a 24-bit coded sample 399 LSB: 400 Least Significant Byte of a 24-bit coded sample 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | MSB | MB | LSB | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 6. Payload Format Parameters 410 This RTP payload format is identified using the media type audio/ 411 aptx, which is registered in accordance with RFC 4855 [RFC4855] and 412 using the template of RFC 4288 [RFC4288] 414 6.1. Media Type Definition 416 Registration of media subtype audio/aptx. 418 MIME media type name: audio 420 MIME subtype name: aptx 422 Required parameters: 424 rate: 425 RTP timestamp clock rate, which is equal to the sampling rate 426 in Hz. -- RECOMMENDED values for rate are 8000, 11025, 16000, 427 22050, 24000, 32000, 44100 and 48000 samples per second. Other 428 values are permissible. 430 channels: 431 The number of logical audio channels that are present in the 432 audio stream. 434 variant: 435 The variant of apt-X (i.e. Standard or Enhanced) that is being 436 used. The following variants can be signalled: 438 variant=standard 439 variant=enhanced 441 bitresolution: 442 The number of bits used by the algorithm to encode 4 PCM 443 samples. This value MAY only be set to 16 for Standard apt-X 444 and 16 or 24 for Enhanced apt-X. 446 Optional parameters: 448 ptime: 449 The recommended length of time (in milliseconds) represented by 450 the media in a packet. Defaults to 4 ms. See Section 6 of 451 [RFC4566]. 453 maxptime: 454 The maximum length of time (in milliseconds) that can be 455 encapsulated in a packet. See Section 6 of [RFC4566]. 457 stereo-channel-pairs: 458 Defines audio channels that are stereo paired in the stream. 459 See Section 3. Each pair of audio channels is defined as two 460 comma-separated values that correspond to channel numbers in 461 the range 1..channels. Each stereo channel pair is preceded 462 by a '{', and followed by a '}'. Pairs of audio channels are 463 separated by a comma. A channel MUST NOT be paired with more 464 than one other channel. Absence of this parameter signals that 465 each channel has been independently encoded. 467 embedded-autosync-channels: 468 Defines channels that carry embedded autosync. embedded- 469 autosync-channels is defined as a list of comma-separated 470 values that correspond to channel numbers in the range 1.. 471 channels. When a channel is stereo paired, embedded autosync 472 is shared across channels in the pair. Only the first channel 473 as defined in stereo-channel-pairs MUST be specified in the 474 embedded-autosync-channels list. 476 embedded-aux-channels: 477 Defines channels that carry embedded auxiliary data. embedded- 478 aux-channel is defined as a list of comma-separated values 479 that correspond to channel numbers in the range 1..channels. 480 When a channel is stereo paired, embedded auxiliary data is 481 shared across channels in the pair. Only the second channel as 482 defined in stereo-channel-pairs MUST be specified in the 483 embedded-autosync-channels list. 485 Encoding considerations: This type is only defined for transfer 486 via RTP [RFC3550]. 488 Security considerations: See Section 5 of [RFC4855] and Section 4 489 of [RFC4856]. 491 Interoperability considerations: none 493 Published specification: RFC XXXX 495 Applications which use this media type: Audio streaming 497 Additional information: none 499 Person & email address to contact for further information: Derrick 500 Rea email:rea@worldcastsystems.com 502 Intended usage: COMMON 504 Author/Change controller: Derrick Rea 506 6.2. Mapping to SDP 508 The information carried in the media type specification has a 509 specific mapping to fields in the Session Description Protocol (SDP) 510 [RFC4566] that is commonly used to describe RTP sessions. When SDP 511 is used to describe sessions the media type mappings are as follows. 513 The type name ("audio") goes in SDP "m=" as the media name. 515 The subtype name ("aptx") goes in SDP "a=rtpmap" as the encoding 516 name. 518 The parameter "rate" also goes in "a=rtpmap" as clock rate. 520 The parameter "channels" also goes in "a=rtpmap" as channel count. 522 The required parameters "variant" and "bitresolution" MUST be 523 included in the SDP "a=fmtp" attribute and MUST follow the 524 delivery-method that applies. 526 The optional parameters "stereo-channel-pairs", "embedded- 527 autosync-channels", "embedded-aux-channels", and "maxptime" when 528 present, MUST be included in the SDP "a=fmtp" attribute and MUST 529 follow the delivery-method that applies. 531 The parameter "ptime", when present, goes in a separate SDP 532 attribute field and is signalled as "a=ptime:", where 533 is the number of millseconds of audio represented by one 534 RTP packet. See Section 6 of [RFC4566]. 536 6.2.1. SDP Usage Examples 538 Some example SDP session descriptions utilizing apt-X encodings 539 follow. In these examples, long a=fmtp lines are folded to meet the 540 column width constraints of this document. 542 Example 1: An standard apt-X stream that encodes two independent 543 44.1kHz 16-bit PCM channels into a 4ms RTP packet. 544 . 545 m=audio 5004 RTP/AVP 98 546 a=rtpmap:98 aptx/44100/2 547 a=fmtp:98 variant=standard; bitresolution=16; 548 a=ptime:4 550 Example 2: An enhanced apt-X stream that encodes two 48kHz 24-bit 551 stereo channels into a 4ms RTP packet and that carries both an 552 embedded autosync and auxiliary data channel. 554 m=audio 5004 RTP/AVP 98 555 a=rtpmap:98 aptx/48000/2 556 a=fmtp:98 variant=enhanced; bitresolution=24; 557 stereo-channel-pairs={1,2}; embedded-autosync-channels=1; 558 embedded-aux-channels=2 560 a=ptime:4 562 Example 3: An enhanced apt-X stream that encodes six 44.1kHz 24-bit 563 channels into a 6ms RTP packet. Channels 1,2 and 3,4 are stereo 564 pairs. Both stereo pairs carry both an embedded autosync and 565 auxiliary data channel. 567 m=audio 5004 RTP/AVP 98 568 a=rtpmap:98 aptx/44100/6 569 a=fmtp:98 variant=enhanced; bitresolution=24; 570 stereo-channel-pairs={1,2},{3,4}; embedded-autosync-channels=1,3; 571 embedded-aux-channels=2,4 572 a=ptime:6 574 6.2.2. Offer/Answer Considerations 576 The only negotiable parameter is the delivery method. All other 577 parameters are declarative. The offer, as described in [RFC3264], 578 may contain a large number of delivery methods per single fmtp 579 attribute, the answerer MUST remove every delivery method and 580 configuration uri not supported. Apart from this exceptional case, 581 all parameters MUST NOT be altered on answer. 583 7. IANA Considerations 585 One media type (audio/aptx) has been defined and needs registration 586 in the media types registry. See Section 7.1 588 8. Security Considerations 590 RTP packets using the payload format defined in this specification 591 are subject to the security considerations discussed in the RTP 592 specification [RFC3550], and any appropriate RTP profile (for example 593 [RFC3551]). This implies that confidentiality of the media streams 594 is achieved by encryption. Because the audio coding used with this 595 payload format is applied end-to-end, encryption may be performed 596 after audio coding so there is no conflict between the two 597 operations. A potential denial-of-service threat exists for audio 598 coding techniques that have non-uniform receiver-end computational 599 load. The attacker can inject pathological datagrams into the stream 600 which are complex to decode and cause the receiver to be overloaded. 601 However, the Standard apt-X and Enhanced apt-X audio coding 602 algorithms do not exhibit any significant non-uniformity. As with 603 any IP-based protocol, in some circumstances a receiver may be 604 overloaded simply by the receipt of too many packets, either desired 605 or undesired. Network-layer authentication may be used to discard 606 packets from undesired sources, but the processing cost of the 607 authentication itself may be too high. In a multicast environment, 608 pruning of specific sources may be implemented in future versions of 609 IGMP [RFC3376] and in multicast routing protocols to allow a receiver 610 to select which sources are allowed to reach it. 612 9. Acknowledgements 614 This specification was facilitated by earlier documents produced by 615 Greg Massey, David Trainer and James Hunter, and practical tests 616 carried out by Paul McCambridge of APT Ltd. 618 10. References 620 10.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 626 with Session Description Protocol (SDP)", RFC 3264, 627 June 2002. 629 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 630 Jacobson, "RTP: A Transport Protocol for Real-Time 631 Applications", STD 64, RFC 3550, July 2003. 633 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 634 Description Protocol", RFC 4566, July 2006. 636 [RFC3551] H. Schulzrinne, "RTP profile for audio and video 637 conferences with minimal control", RFC 3551, July 2003. 639 10.2. Informative References 641 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 642 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 643 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 644 September 1997. 646 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 647 Thyagarajan, "Internet Group Management Protocol, Version 648 3", RFC 3376, October 2002. 650 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 651 Registration Procedures", BCP 13, RFC 4288, December 2005. 653 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 654 Formats", RFC 4855, February 2007. 656 [RFC4856] Casner, S., "Media Type Registration of Payload Formats in 657 the RTP Profile for Audio and Video Conferences", 658 RFC 4856, February 2007. 660 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 661 Correction", RFC 5109, December 2007. 663 11. Authors' Addresses 665 John Lindsay 666 APT Ltd 667 729 Springfield Road 668 Belfast 669 Northern Ireland 670 BT12 7FP 671 UK 673 Phone: +44 2890 677200 674 Email: Lindsay@worldcastsystems.com 676 Derrick Rea 677 APT Ltd 678 729 Springfield Road 679 Belfast 680 Northern Ireland 681 BT12 7FP 682 UK 684 Phone: +44 2890 677200 685 Email: Rea@worldcastsystems.com