Internet DRAFT - draft-gmassey-avt-rtp-aptx
draft-gmassey-avt-rtp-aptx
Network Working Group G S. Massey
Internet-Draft APT Ltd
Intended status: Standards Track June 24, 2008
Expires: December 26, 2008
"RTP Payload Format for apt-X"
draft-gmassey-avt-rtp-aptx-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2008.
Massey Expires December 26, 2008 [Page 1]
Internet-Draft "RTP Payload Format for apt-X" June 2008
Abstract
This document describes an RTP payload format for transporting apt-X
encoded audio. It details the RTP encapsulation mechanism for
standard, enhanced apt-X and apt-X Live data. Also included within
this memo are media type registrations, and the details necessary for
the use of apt-X, enhanced apt-X and apt-X Live with the Session
Description Protocol.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation of apt-X Live and Enhanced apt-X Streams . . . . 5
3.1. RTP header usage . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. Standard apt-X . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Enhanced apt-X 16 Bit . . . . . . . . . . . . . . . . . . 7
4.3. Enhanced apt-X 24 Bit . . . . . . . . . . . . . . . . . . 8
4.4. apt-X Live . . . . . . . . . . . . . . . . . . . . . . . . 9
5. SDP Related Considerations . . . . . . . . . . . . . . . . . . 11
5.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 11
5.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Usage with the SDP Offer/Answer Model . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Massey Expires December 26, 2008 [Page 2]
Internet-Draft "RTP Payload Format for apt-X" June 2008
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Massey Expires December 26, 2008 [Page 3]
Internet-Draft "RTP Payload Format for apt-X" June 2008
2. Introduction
apt-X, enhanced apt-X16/enhanced apt-X24 and apt-X Live are
proprietary audio compression algorithms. No prior RFC or standard
has been used to describe how to packetise this audio data. The
compression algorithm yields a fixed bit rate scaled according to the
sample frequency of the input audio. The fixed rate is one quarter
of the original bit rate. This rule also applies to the resolution
of the audio. Example, a 1.536MB/s stereo audio stream using 16 bit
PCM is reduced to 384 kb/s. The apt-X and enhanced apt-X algorithms
can carry an ancillary data stream and synchronisation information
within the compressed audio stream without additional overhead. The
ancillary data stream can be used to transport data or timecode data
for synchronisation with video. The bandwidth of the ancillary data
channel is one quarter the sample frequency, example at Fs = 48kHz
the ancillary data stream is 12 kb/s. The similarities between the
packetisation is such that it does each variant does not warrant a
separate RFC.
Massey Expires December 26, 2008 [Page 4]
Internet-Draft "RTP Payload Format for apt-X" June 2008
3. Encapsulation of apt-X Live and Enhanced apt-X Streams
apt-X Live and Enhanced apt-X are non framed based algorithm and
produces as its output a sixteen bit word representing four sixteen
bit PCM samples. The packetisation of the data shall be on a byte by
byte basis. Packet size must be a multiple of the number of n x
64kbps channels in the resultant bitrate. For example a 384kbps
channel would result in a multiple of 6. Therefore the resultant
payload size would be N x 6 bytes. Likewise a 576kbps channel would
require a payload N * 9 bytes.
3.1. RTP header usage
apt-X Live and Enhanced apt-X require no special considerations be
placed in the RTP header. The timestamp used in the RTP header shall
comply with the same timestamp specified in RFC3550. PT type shall
be either specified as dynamic for use with SIP signalling but can
also be used with static PT numbers for manual call establishment.
Payload Header (payload format dependent)
V - As per RFC3550
P - As per RFC3550
X - As per RFC3550
CC - As per RFC3550
M - As per RFC3550
PT - Payload Number to be defined according to MIME allocation:
audio/aptX audio/EaptX audio/aptXLive
SN - As per RFC3550
Payload See description below
V - Version Number
P - Padding
X - Extensions
CC - Count of contributing sources
Massey Expires December 26, 2008 [Page 5]
Internet-Draft "RTP Payload Format for apt-X" June 2008
M - Marker
PT - Payload Type
PS - Payload Structure
The payload data for apt-X Live and Enhanced apt-X shall be
delineated as Left channel data/ Right Channel data. Data is word
aligned big endian format. For multi-channel packets the data is
allocated as per the following rules.
1) N bytes interleaved (Left Channel /Right Channel) format per
channel
2) N is defined by the number of N x 64kb/s channels present in
the overall audio bit stream. Therefore a 128kbps stereo stream
would have an N of 2 and the data would be formatted Left(Byte)
/ Right (Byte)
Multiple channels are grouped together for transmission to preserve
phase between channels. Thus a transmission of a 5.1 audio track
would group together six audio channels in a single packet. The
channels would be grouped in a sequential order from first to last
and would remain in this order.
Example 6.912 mb/s 5.1 Enhanced apt-X 24bit (3 * 576)/64 = N = 9
Channels 1/2 Bytes(0..17) Channels 3/4 Bytes(0..17) Channels 5/6
Bytes(0..17)
Massey Expires December 26, 2008 [Page 6]
Internet-Draft "RTP Payload Format for apt-X" June 2008
4. IANA Considerations
4.1. Standard apt-X
MIME media type name: audio
MIME subtype name: aptX
Required parameters:
rate/Channels: The RTP timestamp clock rate, which is equal to
the sampling rate. The typical rate is 48000, but other rates
may be specified. Allowable rates are
48000,44100,32000,24000,22050,16000,12000,8000. Any number of
channels may be used and specified as 1,2,3,4,5,6,7,8 etc
Optional parameters:
audio-mode: (stereo/mono/dualmono)
Encoding considerations:
This type is only defined for transfer via RTP [RFC3550].
Security considerations: See Section 5 of [RFC4855][RFC4856]
Interoperability considerations: none
Published specification: RFC XXXX [RFC Editor: please replace by
the RFC number of this memo, when published]
Applications which use this media type: Audio streaming.
Additional information: none
Person & email address to contact for further information:
Gregory Massey
Intended usage: COMMON
Author/Change controller: Gregory Massey
4.2. Enhanced apt-X 16 Bit
Massey Expires December 26, 2008 [Page 7]
Internet-Draft "RTP Payload Format for apt-X" June 2008
MIME media type name: audio
MIME subtype name: EaptX 16
Required parameters:
rate, channels The RTP timestamp clock rate, which is equal to
the sampling rate. The typical rate is 48000, but other rates
may be specified.
Default for channels is 2 (Stereo)
Optional parameters:
audio-mode: (stereo/mono/dualmono)
Encoding considerations:
This type is only defined for transfer via RTP [RFC3550].
Security considerations:
See Section 5 of [RFC4855][RFC4856]
Interoperability considerations: none
Published specification: RFC XXXX [RFC Editor: please replace by
the RFC number of this memo, when published]
Applications which use this media type: Audio streaming.
Additional information: none
Person & email address to contact for further information:
Gregory Massey
Intended usage: COMMON
Author/Change controller: Gregory Massey
4.3. Enhanced apt-X 24 Bit
MIME media type name: audio
MIME subtype name: EaptX 24
Massey Expires December 26, 2008 [Page 8]
Internet-Draft "RTP Payload Format for apt-X" June 2008
Required parameters:
rate/Channels The RTP timestamp clock rate, which is equal to
the sampling rate. The typical rate is 48000, but other rates
may be specified.
Optional parameters:
audio-mode: stereo/mono/dualmono
Encoding considerations:
This type is only defined for transfer via RTP [RFC3550].
Security considerations:
See Section 5 of [RFC4855][RFC4856]
Interoperability considerations: none
Published specification: RFC XXXX [RFC Editor: please replace by
the RFC number of this memo, when published]
Applications which use this media type: Audio streaming.
Additional information: none
Person & email address to contact for further information:
Gregory Massey
Intended usage: COMMON
Author/Change controller: Gregory Massey
4.4. apt-X Live
MIME media type name: audio
MIME subtype name: aptXLive
Required parameters:
rate/Channels The RTP timestamp clock rate, which is equal to
the sampling rate. The typical rate is 48000, but other rates
may be specified.
Massey Expires December 26, 2008 [Page 9]
Internet-Draft "RTP Payload Format for apt-X" June 2008
Optional parameters:
audio-mode: stereo/mono
scale: Scale factors for aptX-Live algorithm (S20/S25/S30)
Encoding considerations:
This type is only defined for transfer via RTP [RFC3550].
Security considerations:
See Section 5 of [RFC4855][RFC4856]
Interoperability considerations: none
Published specification: RFC XXXX [RFC Editor: please replace by
the RFC number of this memo, when published]
Applications which use this media type: Audio streaming.
Additional information: none
Person & email address to contact for further information:
Gregory Massey
Intended usage: COMMON
Author/Change controller: Gregory Massey
Massey Expires December 26, 2008 [Page 10]
Internet-Draft "RTP Payload Format for apt-X" June 2008
5. SDP Related Considerations
The following paragraphs defines the mapping of the parameters
described in the IANA considerations section and their usage in the
Offer/Answer Model [RFC3264].
5.1. Mapping Media Type Parameters into SDP
The information carried in the Media Type media type specification
has a specific mapping to fields in the Session Description Protocol
(SDP) [RFC4566], that is commonly used to describe RTP sessions.
When SDP is used to specify sessions the mapping are as follows:
o The type name ("audio") goes in SDP "m=" as the media name.
o The subtype name ("aptX") goes in SDP "a=rtpmap" as the encoding
name.
o The parameter "rate" also goes in "a=rtpmap" as clock rate.
o The parameter "channels" also goes in "a=rtpmap" as channel
count.
o The optional parameter "audio-mode", "aux", "scale", when
present, MUST be included in the SDP "a=fmtp" attribute and MUST
follow the delivery-method that applies.
5.2. SDP Example
The following example shows a basic SDP single stream. The first
configuration packet is inlined in the sdp.
c=IN IP4 192.0.2.x
m=audio RTP/AVP 98
a=rtpmap:98 aptX/44100/2
a=fmtp:98 audio-mode=stereo;
Note that the payload format (encoding) names are commonly shown in
upper case. Media subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in media types and in the default
mapping to the SDP a=fmtp attribute.
Massey Expires December 26, 2008 [Page 11]
Internet-Draft "RTP Payload Format for apt-X" June 2008
5.3. Usage with the SDP Offer/Answer Model
The only parameter negotiable is the delivery method. All the others
are declarative: the offer, as described in An Offer/Answer Model
Session Description Protocol offer answer model [RFC3264], may
contain a large number of delivery methods per single fmtp attribute,
the answerer MUST remove every delivery-method. All the parameters
MUST not be altered on answer otherwise.
Massey Expires December 26, 2008 [Page 12]
Internet-Draft "RTP Payload Format for apt-X" June 2008
6. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [2], and any appropriate RTP profile (for example
[RFC3550]). This implies that confidentiality of the media streams
is achieved by encryption. Because the data compression used with
this payload format is applied end-to-end, encryption may be
performed after compression so there is no conflict between the two
operations. A potential denial-of-service threat exists for data
encodings using compression techniques that have non-uniform
receiver-end computational load. The attacker can inject
pathological datagrams into the stream which are complex to decode
and cause the receiver to be overloaded. However, this encoding does
not exhibit any significant non-uniformity. As with any IP-based
protocol, in some circumstances a receiver may be overloaded simply
by the receipt of too many packets, either desired or undesired.
Network-layer authentication may be used to discard packets from
undesired sources, but the processing cost of the authentication
itself may be too high. In a multicast environment, pruning of
specific sources may be implemented in future versions of IGMP
[RFC3376] and in multicast routing protocols to allow a receiver to
select which sources are allowed to reach it.
Massey Expires December 26, 2008 [Page 13]
Internet-Draft "RTP Payload Format for apt-X" June 2008
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences",
RFC 4856, February 2007.
Massey Expires December 26, 2008 [Page 14]
Internet-Draft "RTP Payload Format for apt-X" June 2008
Author's Address
Gregory S. Massey
APT Ltd
Edgewater Road
Belfast, CA BT3 9JQ
UK
Phone: +44 2890 371110
Email: gmassey@aptx.com
URI: http://www.aptx.com/
Massey Expires December 26, 2008 [Page 15]
Internet-Draft "RTP Payload Format for apt-X" June 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Massey Expires December 26, 2008 [Page 16]
