draft-ietf-payload-rtp-aptx-00.txt   draft-ietf-payload-rtp-aptx-01.txt 
Internet-Draft J. Lindsay Internet-Draft J. Lindsay
A/V Transport Payloads Working Group H.Foerster A/V Transport Payloads Working Group H.Foerster
Intended status: Standards Track APT Ltd Intended status: Standards Track APT Ltd
Expires: September 12, 2013 March 12, 2013 Expires: March 5, 2014 September 5, 2013
RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs
draft-ietf-payload-rtp-aptx-00 draft-ietf-payload-rtp-aptx-01
Abstract Abstract
This document specifies a scheme for packetizing Standard apt-X, or This document specifies a scheme for packetizing Standard apt-X, or
Enhanced apt-X, encoded audio data into Real-time Transport Protocol Enhanced apt-X, encoded audio data into Real-time Transport Protocol
(RTP) packets. The document describes a payload format that permits (RTP) packets. The document describes a payload format that permits
transmission of multiple related audio channels in a single RTP transmission of multiple related audio channels in a single RTP
payload, and a means of establishing Standard apt-X and Enhanced payload, and a means of establishing Standard apt-X and Enhanced
apt-X connections through the Session Description Protocol (SDP). apt-X connections through the Session Description Protocol (SDP).
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Sept 12, 2013 . This Internet-Draft will expire on February 22, 2014.
Submission Compliance for Internet-Drafts. Submission Compliance for Internet-Drafts.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 10, line 37 skipping to change at page 10, line 37
then packed into the packet in time sequence beginning with the then packed into the packet in time sequence beginning with the
oldest coded sample block. oldest coded sample block.
l left l left
r right r right
c center c center
S surround S surround
F front F front
R rear R rear
channels description channel channels, description, channel
1 2 3 4 5 6 1 2 3 4 5 6
_________________________________________________ _________________________________________________
2 stereo l r 2 stereo l r
3 l r c 3 l r c
4 l c r S 4 l c r S
5 Fl Fr Fc Sl Sr 5 Fl Fr Fc Sl Sr
6 l lc c r rc S 6 l lc c r rc S
For the two-channel encoding example, the sample sequence is (left For the two-channel encoding example, the sample sequence is (left
channel, first sample), (right channel, first sample), (left channel, channel, first sample), (right channel, first sample), (left channel,
skipping to change at page 14, line 9 skipping to change at page 14, line 9
0 1 2 3 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 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 | | | MSB | MB | LSB | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Payload Format Parameters 6. Payload Format Parameters
This RTP payload format is identified using the media type audio/ This RTP payload format is identified using the media type audio/
aptx, which is registered in accordance with RFC 4855 [RFC4855] and aptx, which is registered in accordance with RFC 4855 [RFC4855] and
using the template of RFC 4288 [RFC4288] using the template of RFC 6838 [RFC6838]
6.1. Media Type Definition 6.1. Media Type Definition
Registration of media subtype audio/aptx. Registration of media subtype audio/aptx.
MIME media type name: audio MIME media type name: audio
MIME subtype name: aptx MIME subtype name: aptx
Required parameters: Required parameters:
skipping to change at page 16, line 41 skipping to change at page 16, line 41
attribute field and is signalled as "a=ptime:<value>", where attribute field and is signalled as "a=ptime:<value>", where
<value> is the number of millseconds of audio represented by one <value> is the number of millseconds of audio represented by one
RTP packet. See Section 6 of [RFC4566]. RTP packet. See Section 6 of [RFC4566].
6.2.1. SDP Usage Examples 6.2.1. SDP Usage Examples
Some example SDP session descriptions utilizing apt-X encodings Some example SDP session descriptions utilizing apt-X encodings
follow. In these examples, long a=fmtp lines are folded to meet the follow. In these examples, long a=fmtp lines are folded to meet the
column width constraints of this document. column width constraints of this document.
Example 1: An standard apt-X stream that encodes two independent Example 1: A standard apt-X stream that encodes two independent
44.1kHz 16-bit PCM channels into a 4ms RTP packet. 44.1kHz 16-bit PCM channels into a 4ms RTP packet.
. .
m=audio 5004 RTP/AVP 98 m=audio 5004 RTP/AVP 98
a=rtpmap:98 aptx/44100/2 a=rtpmap:98 aptx/44100/2
a=fmtp:98 variant=standard; bitresolution=16; a=fmtp:98 variant=standard; bitresolution=16;
a=ptime:4 a=ptime:4
Example 2: An enhanced apt-X stream that encodes two 48kHz 24-bit Example 2: An enhanced apt-X stream that encodes two 48kHz 24-bit
stereo channels into a 4ms RTP packet and that carries both an stereo channels into a 4ms RTP packet and that carries both an
embedded autosync and auxiliary data channel. embedded autosync and auxiliary data channel.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
The only negotiable parameter is the delivery method. All other The only negotiable parameter is the delivery method. All other
parameters are declarative. The offer, as described in [RFC3264], parameters are declarative. The offer, as described in [RFC3264],
may contain a large number of delivery methods per single fmtp may contain a large number of delivery methods per single fmtp
attribute, the answerer MUST remove every delivery method and attribute, the answerer MUST remove every delivery method and
configuration uri not supported. Apart from this exceptional case, configuration uri not supported. Apart from this exceptional case,
all parameters MUST NOT be altered on answer. all parameters MUST NOT be altered on answer.
7. IANA Considerations 7. IANA Considerations
One media type (audio/aptx) has been defined and needs registration One media type (audio/aptx) has been defined and needs registration
in the media types registry. See Section 7.1 in the media types registry. See Section 6.1
8. Security Considerations 8. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550], and any appropriate RTP profile (for example specification [RFC3550], and any appropriate RTP profile (for example
[RFC3551]). This implies that confidentiality of the media streams [RFC3551]). This implies that confidentiality of the media streams
is achieved by encryption. Because the audio coding used with this is achieved by encryption. Because the audio coding used with this
payload format is applied end-to-end, encryption may be performed payload format is applied end-to-end, encryption may be performed
after audio coding so there is no conflict between the two after audio coding so there is no conflict between the two
skipping to change at page 21, line 37 skipping to change at page 21, line 37
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC6838] Freed, N.,J. Klensin, and T. Hansen, "Media Type
Registration Procedures", BCP 13, RFC 4288, December 2005. Specifications andRegistration Procedures", BCP 13,
RFC 6838, January 2013.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in [RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", the RTP Profile for Audio and Video Conferences",
RFC 4856, February 2007. RFC 4856, February 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
 End of changes. 9 change blocks. 
10 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/