Audio/Video Transport M. Hatanaka
Internet-Draft J. Matsumoto
Expires: February 19, 2008
Sony Corporation
August 2007
RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family
draft-ietf-avt-rtp-atrac-family-10
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 Feb 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes an RTP payload format for efficient and
flexible transporting of audio data encoded with the Adaptive
TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements
to the ATRAC family of codecs support high quality audio coding with
multiple channels. The RTP payload format as presented in this
document also includes support for data fragmentation, elementary
redundancy measures, and a variation on scalable streaming.
Hatanaka, et al. [Page 1]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Codec Specific Details . . . . . . . . . . . . . . . . . . . . 3
4. RTP Packetization and Transport of ATRAC-Family Streams . . . 4
4.1 ATRAC Frames . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Concatenation of Frames . . . . . . . . . . . . . . . . . 4
4.3 Frame Fragmentation . . . . . . . . . . . . . . . . . . . 4
4.4 Transmission of Redundant Frames . . . . . . . . . . . . . 4
4.5 Scalable Lossless Streaming (High-Speed Transfer mode) . . 5
4.5.1 Scalable Multiplexed Streaming . . . . . . . . . . . . 5
4.5.2 Scalable Multi-Session Streaming . . . . . . . . . . . 5
5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Global Structure of Payload Format . . . . . . . . . . . . 6
5.2 Usage of RTP Header Fields . . . . . . . . . . . . . . . . 7
5.3 RTP Payload Structure . . . . . . . . . . . . . . . . . . 8
5.3.1 ATRAC Header Section . . . . . . . . . . . . . . . . . 8
5.3.2 ATRAC Frames Section . . . . . . . . . . . . . . . . . 8
5.3.2.1 Support of redundancy. . . . . . . . . . . . . . . . . 9
5.3.2.2 Frame Fragmentation . . . . . . . . . . . . . . . . . 10
6. Packetization Examples . . . . . . . . . . . . . . . . . . . . 11
6.1 Example Multi-frame Packet . . . . . . . . . . . . . . . . 11
6.2 Example Fragmented ATRAC Frame . . . . . . . . . . . . . . 12
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 13
7.1 ATRAC3 Media type Registration . . . . . . . . . . . . . . 13
7.2 ATRAC-X Media type Registraion . . . . . . . . . . . . . . 15
7.3 ATRAC Advanced Lossless Media type Registration . . . . . 17
7.4 Channel Mapping Configuration Table . . . . . . . . . . . 19
7.5 Mapping Media type Parameters into SDP . . . . . . . . . . 20
7.5.1 For Media subtype ATRAC3 . . . . . . . . . .. . . . . 20
7.5.2 For Media subtype ATRAC-X . . . . . . . . . .. . . . . 20
7.5.3 For Media subtype ATRAC Advanced Lossless . .. . . . . 21
7.6 Offer-Answer Model Considerations . . . . . . . . . . . . 21
7.6.1 For All Three Media Subtypes . . . . . . . .. . . . . 21
7.6.2 For Media subtype ATRAC3 . . . . . . . . . . . . . . 22
7.6.3 For Media subtype ATRAC-X . . . . . . . . . . . . . . 22
7.6.4 For Media subtype ATRAC Advanced Lossless . . . . . . 22
7.7 Usage of declarative SDP . . . . . . . . . . . . . . . . . 23
7.8 Example SDP Session Descriptions . . . . . . . . . . . . . 23
7.9 Example Offer-Answer Exchange . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 26
9.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 26
9.3 Decoding Validation . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1 Normative References . . . . . . . . . . . . . . . . . . . 27
10.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
Hatanaka, et al. [Page 2]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
1. Introduction
The ATRAC family of perceptual audio codecs are designed to address
numerous needs for high-quality, low bit-rate audio transfer. ATRAC
technology can be found in many consumer and professional products
and applications, including MD players, CD players, voice recorders,
and mobile phones. The need for real-time streaming of audio data
has grown, and this document details our efforts in increasing the
product and application space for the ATRAC family of codecs.
Recent advances in ATRAC technology allow for multiple channels of
audio to be encoded in customizable groupings. This should allow
for future expansions in scaled streaming. To provide the greatest
flexibility in streaming any one of the ATRAC family member codecs
however, this payload format does not distinguish between the codecs
on a packet level.
This simplified payload format contains only the basic information
needed to disassemble a packet of ATRAC audio in order to decode it.
There is also basic support for fragmentation and redundancy.
2. Conventions Used in This Document
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 [4].
3. Codec Specific Details
Early versions of the ATRAC codec handled only two channels of audio
at 44.1kHz sampling frequency, with typical bit-rates between 66kbps
and 132kbps. The latest version allows for a maximum 8 channels of
audio, up to 96kHz in sampling frequency, and a lossless encoding
option which can be transmitted in either a scalable (also known as
High-Speed Transfer mode) or standard (aka Standard mode) format.
The feasible bit-rate range has also expanded, allowing from a low of
8kbps up to 1400kbps in lossy encoding modes.
Depending on the version of ATRAC used, the sample-frame size is
either 512, 1024 or 2048 samples. While the lossy and Standard mode
lossless formats are encoded as sequential single audio frames,
High-Speed Transfer mode lossless data comprises two layers -- a
lossy base layer and an enhancement layer.
Although streaming of multi-channel audio is supported depending on
the ATRAC version used, all encoded audio for a given time period is
contained within a single frame. Therefore, there is no interleaving
nor splitting of audio data on a per-channel basis to be concerned
with.
Hatanaka, et al. [Page 3]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
4. RTP Packetization and Transport of ATRAC-Family Streams
4.1 ATRAC Frames
For transportation of compressed audio data, ATRAC uses the concept
of frames. ATRAC frames are the smallest data unit for which timing
information is attributed. Frames are octect-aligned by definition.
4.2 Concatenation of Frames
It is often possible to carry multiple frames in one RTP packet.
This can be useful in audio, where on a LAN with a 1500 byte MTU, an
average of 7 complete 64kbps ATRAC frames could be carried in a
single RTP packet, as each ATRAC frame would be approximately 200
bytes. ATRAC frames may be of fixed or variable length. To
facilitate parsing in the case of multiple frames in one RTP packet,
the size of each frame is made known to the receiver by carrying "in
band" the frame size for each contained frame in an RTP packet.
However, to simplify the implementation of RTP receivers, it is
required that when multiple frames are carried in an RTP packet, each
frame MUST be complete, i.e., the number of frames in an RTP packet
MUST be integral.
4.3 Frame Fragmentation
The ATRAC codec can handle very large frames. As most IP networks
have significantly smaller MTU sizes than the frame sizes ATRAC can
handle, this payload format allows for the fragmentation of an ATRAC
frame over multiple RTP packets. However, to simplify the
implementation of RTP receivers, an RTP packet SHALL either carry one
or more complete ATRAC frames or a single fragment of one ATRAC
frame. In other words, RTP packets MUST NOT contain fragments of
multiple ATRAC frames and MUST NOT contain a mix of complete and
fragmented frames.
4.4 Transmission of Redundant Frames
As RTP does not guarantee reliable transmission, receipt of data is
not assured. Loss of a packet can result in a "decoding gap" by the
receiver. One method to remedy this problem is to allow time-shifted
copies of ATRAC frames to be sent along with current data. For a
modest cost in latency and implementation complexity, error
resiliency to packet loss can be achieved.
Hatanaka, et al. [Page 4]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
4.5 Scalable Lossless Streaming (High-Speed Transfer mode)
As ATRAC supports a variation on scalable encoding, this payload
format provides a mechanism for transmitting essential data (also
referred to as the base layer) with its enhancement data in two ways
-- multiplexed through one session or separated over two sessions.
In either method, only the base layer is essential in producing audio
data. The enhancement layer carries the remaining audio data needed
to decode lossless audio data. So in situations of limited
bandwidth, the sender may choose not to transmit enhancement data yet
still provide a client with enough data to generate lossily-encoded
audio through the base layer.
4.5.1 Scalable Multiplexed Streaming
In multiplexed streaming, the base layer and enhancement layer are
coupled together in each packet, utilizing only one session as
illustrated in Figure 1.
While the packet may begin with either layer type, the two layer
types MUST interleave.
+----------------+ +----------------+ +----------------+
|Base|Enhancement|--|Base|Enhancement|--|Base|Enhancement| ...
+----------------+ +----------------+ +----------------+
N N+1 N+2 : Packet
Figure 1. Multiplexed strcture
4.5.2 Scalable Multi-Session Streaming
In multi-session streaming, the base layer and enhancement layer are
sent over two seperate sessions, allowing clients with certain
bandwidth limitations to receive just the base layer for decoding as
illustrated in Figure 2.
While there may be alternative methods for synchronization of the
layers, it is RECOMMENDED that the timestamp will be used for
synchronizing the base layer with its enhancement. Applications can
determine which sessions are paired together through use of the
Session Description Protocol (SDP) (RFC 4566) [2]. Further details
are discussed in the section titled "Usage of declarative SDP".
For decoding synchronization, the sequence number of RTP header
of both sessions shall be set the same value at the sender side.
If the enhancement layer's session data can not arrive until
the presentation time, the decoder SHALL decode the Base layer
session's data only with ignoring the enhancement layer's data.
Hatanaka, et al. [Page 5]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Session 1:
+------+ +------+ +------+ +------+
| Base |--| Base |--| Base |--| Base | ...
+------+ +------+ +------+ +------+
N N+1 N+2 N+3 : Packet
Session 2:
+-------------+ +-------------+ +-------------+
| Enhancement |--| Enhancement |--| Enhancement | ...
+-------------+ +-------------+ +-------------+
N N+1 N+2 : Packet
Figure 2. Multi-Session Streaming
5. Payload Format
5.1 Global Structure of Payload Format
The structure of ATRAC Payload is illustrated in Figure 3.
The RTP payload following the RTP header contains three
octet-aligned data sections, of which the second i.e ATRAC Header
Section MAY be empty:
+------+--------------+-----------------------------+
|RTP | ATRAC Header | ATRAC Frames Section |
|Header| Section | (including redundant data) |
+------+--------------+-----------------------------+
< ---------------- RTP Packet Payload ------------- >
Figure 3. Structure of RTP Payload of ATRAC family
The first data section is the ATRAC Header, containing just one
header with information for the whole packet. The second
section is where the encoded ATRAC frames are stored. This may
contain either a single fragment of one ATRAC frame, or one or more
complete ATRAC frames. The ATRAC Frames Section MUST NOT be empty.
In case of using redundant mechanism, the redundant frame data can
be included in this section and time stamp MUST be set to the oldest
redundant frame's time stamp.
To benefit from ATRAC's High-Speed Transfer mode lossless encoding
capability, the RTP payload can be split across two sessions, with
one transmitting an essential base layer and the other transmitting
enhancement data. However in either case, the above structure still
applies.
Hatanaka, et al. [Page 6]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
5.2 Usage of RTP Header Fields
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. RTP Standard Header Part
The structure of RTP Standard Header Part is illustrated in Figure 4.
Version(V): 2 bits
Set to 2.
Padding(P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding octets at the end which are not part of the
payload. The last octet of the padding contains a count of how
many padding octets should be ignored, including itself. Padding
may be needed by some encryption algorithms with fixed block sizes
or for carrying several RTP packets in a lower-layer protocol data
unit (see [1]).
Extention(X): 1 bit
Defined by the RTP profile used.
Marker (M): 1 bit
Set to 1 if the packet is the first packet after a silence period,
otherwise it MUST be set to 0.
The details of usage SHALL be defined by the RTP profile used.
Payload Type (PT): 7 bits
The assignment of an RTP payload type for this packet format is
outside the scope of this document; it is specified by the RTP
profile under which this payload format is used, or signaled
dynamically out-of-band (e.g., using SDP).
sequence number: 16bits
A sequential number for RTP packet. It ranges from 0 to 65535 and
repeats itself periodically.
Timestamp: 32 bits
A timestamp representing the sampling time of the first sample of
Hatanaka, et al. [Page 7]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
the first ATRAC frame in the current RTP packet.
When using SDP, the clock rate of the RTP timestamp MUST be
expressed using the "rtpmap" attribute.
For ATRAC3 and ATRAC Advanced Lossless, the RTP timestamp rate
MUST be 44100Hz. For ATRAC-X the RTP timestamp rate is 44100Hz or
48000Hz, and it will be selected by out-of-band sigalling.
5.3 RTP Payload Structure
5.3.1 Usage of ATRAC Header Section
The ATRAC header section has the fixed length of one byte as
illustrated in Figure 5.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|FrgNo|NFrames|
+-+-+-+-+-+-+-+-+
Figure 5. ATRAC RTP Header
Continuous flag (C): 1 bit
Set to 1 if this is part of a fragmented packet. The last packet in
a series would have this bit set to 0.
Fragment Number (FrgNo): 3 bits
In the event of data fragmentation, this value is 0 for the first
packet, and increases sequentially for the remaining fragmented data
packets.
Number of Frames (NFrames): 4 bits
The number of frames in this packet. This allows for a maximum of
16 ATRAC-encoded audio frames per packet, with 0 indicating one
frame. Each frame must be complete. Only the first frame is allowed
to be fragmented, in which case this MUST NOT be anything other than
0 for subsequent packets containing the fragmented frame.
5.3.2 Usage of ATRAC Frames Section
The ATRAC Frames Section contains an integer number of complete
ATRAC frames or a single fragment of one ATRAC frame as
illustrated in Figure 6. Each ATRAC frame is preceeded by a one-bit
flag indicating the layer type and a Block Length field indicating
the size in bytes of the ATRAC frame. If more than one ATRAC frame
is present, then the frames are concatenated into a contiguous
string of bit-flag, Block Length, and ATRAC frame. This section
MUST NOT be empty.
Hatanaka, et al. [Page 8]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Block Length | ATRAC frame |...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. ATRAC Frame Section Format
Layer Type Flag (E): 1 bit
Set to 1 if the corresponding ATRAC frame is from an enhancement
layer. 0 indicates a base layer encoded frame.
Block length: 15 bits
The byte length of encoded audio data for the following frame. This
is so that in the case of fragmentation, if only a subsequent packet
is received, decoding can still occur. 15 bits allows for a maximum
block length of 32,767 bytes. If there are multiple frames in a
packet, a block-length field exists before each frame data.
ATRAC frame: The encoded ATRAC audio data.
5.3.2.1 Support of redundancy
It provides a rudimentary scheme to compensate for occasional
packet loss. As every packet's timestamp corresponds to the first
audio frame regardless of whether it is redundant or not, and
because we know how many frames of audio each packet encapsulates,
if two successive packets are successfully transmitted, we can
calculate the number of redundant frames being sent. The result
gives the client a sense of how the server is responding to RTCP
reports and to expand its buffer size if necessary.
As an example of using the Redundant Data, refer to Figure 7 and 8.
In this example, the server has determined that for the next few
number of packets, it should send the last two frames from the
previous packet due to recent RTCP reports. Thus, between packets
N and N+1, there is a redundancy of two frames (which the client
may choose to dispose of). The benefit arises when packets N+2
and N+3 do not arrive at all, after which eventually packet N+4
arrives with successive necessary audio frame data.
[Sender]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr2-|-Fr3-|-Fr4-| Packet: N+2, TS=2048
|-Fr3-|-Fr4-|-Fr5-| Packet: N+3, TS=3072
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
-----------> Packet "N+2" and "N+3" not arrived ------------->
Hatanaka, et al. [Page 9]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
[Reciever]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
The reciever can decode from FR4 to Fr6 by using Packet "N+4" data
even if the packet loss of "N+2" and "N+3" is occured.
Figure 7. Redundant Exmaple
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (= start sample time of Fr1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 3 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) ATRAC frame (Fr1) data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) ATRAC frame (Fr2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | ATRAC frame (Fr3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Packet structure example with Redundant data
(case of Packet "N+1")
5.3.2.2 Frame Fragmentation
Each RTP packet SHALL contain either an integer number of ATRAC
encoded audio frames (with a maximum of 16), or one ATRAC frame
fragment. In the former case, as many complete ATRAC frames as can
fit in a single path-MTU SHOULD be placed in an RTP packet. However,
if even a single ATRAC frame will not fit into a complete RTP packet,
the ATRAC frame SHOULD be fragmented.
The start of a fragmented frame gets placed in its own RTP packet,
its Continuous bit (C) set to one, and its Fragment Number (FragNo)
set to one. As the frame must be the only one in the packet, the
Number of Frames field is zero. Subsequent packets are to contain
Hatanaka, et al. [Page 10]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
the remaining fragmented frame data, with the Fragment Number
increasing sequentially and the Continuous bit (C) consistently set
to one. As subsequent packets do not contain any new frames, the
Number of Frames field SHOULD be ignored. The last packet of
fragmented data MUST have the Continuous bit (C) set to zero.
In addition to the Continuous bit and Fragment Number fields
indicating fragmentation and a means to reorder the packets, the
timestamp can be used to determine which packets go together. Thus,
packets containing related fragmented frames MUST have identical
timestamps.
In the event of fragmentation, the basic redundancy measures MUST
NOT be used.
6. Packetization Examples
6.1 Example Multi-frame Packet
Multiple encoded audio frames are combined into one packet. Note
how for this example, only base layer frames are sent redundantly,
but are followed by interleaved base layer and enhancement layer
frames as illustrated in Figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 5 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) base layer frame 1 data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) base layer frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancment frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length | base layer frame 4... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Example Multi-frame Packet
Hatanaka, et al. [Page 11]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
6.2 Example Fragmented ATRAC Frame
The encoded audio data frame is split over three RTP packets as
illustrated in Figure 10. The following points are highlighted
in the example below:
o transition from one to zero of the Continuous bit (C)
o sequential increase in the Fragment Number
Packet 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 1 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 2 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...more enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hatanaka, et al. [Page 12]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 3 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...the last of the enhancement data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Example Fragmented ATRAC Frame
7. Payload Format Parameters
Certain parameters will need to be defined before ATRAC family
encoded content can be streamed. Other optional parameters may also
be defined to take advantage of specific features relevant to certain
ATRAC versions. Parameters for ATRAC3, ATRAC-X, and ATRAC Advanced
Lossless are defined here as part of the media subtype registration
process. A mapping of these parameters into the Session Description
Protocol (SDP) (RFC 4566) [2] is also provided for applications that
utilize SDP. These registrations use the template defined in RFC
4288 [5] and follow RFC 4855 [6].
The data format and parameters are specified for real-time transport
in RTP.
7.1 ATRAC3 Media type Registration
The media subtype for the Adaptive TRansform Codec version 3 (ATRAC3)
uses the template defined in RFC 4855 [6].
Note, any unknown parameter MUST be ignored by the receiver.
Type name: audio
Subtype name: atrac3
Hatanaka, et al. [Page 13]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Required parameters:
rate: Represents the sampling frequency in Hz of the original
audio data. Permissible value is 44100 only.
baseLayer: Indicates the encoded bit-rate in kbps for the audio
data to be streamed. Permissible values are 66, 105 and 132.
Optional parameters:
ptime: see RFC4566[2]
maxptime: see RFC4566[2]
The value of the parameter MUST be a multiple of 23.2(ms).
If this parameter is not present, the sender MAY encapsulate
a maximum of 6 encoded frames into one RTP packet, in streaming
of ATRAC3.
maxRedundantFrames: The maximum number of redundant frames that may
be sent during a session in any given packet under the redundant
framing mechanism detailed in the draft. Allowed values are integers
in the range of 0 to 15, inclusive. If this parameter is not used, a
default of 15 MUST be assumed.
Encoding considerations: This media type is framed and contains
binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: none
Published specification: none
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Magic number(s): none
File extension(s): 'at3', 'aa3', and 'omg'
Macintosh file type code(s): none
Person & email address to contact for further information:
Mitsuyuki Hatanaka
actech@jp.sony.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing,
and hence is only defined for transfer via RTP.
Hatanaka, et al. [Page 14]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Author/Change controller:
Mitsuyuki Hatanaka
actech@jp.sony.com
7.2 ATRAC-X Media type Registration
The media subtype for the Adaptive TRansform Codec version X
(ATRAC-X) uses the template defined in RFC 4855 [6].
Note, any unknown parameter MUST be ignored by the receiver.
Type name: audio
Subtype name: atrac-x
Required parameters:
rate: Represents the sampling frequency in Hz of the original
audio data. Permissible values are 44100 and 48000.
baseLayer: Indicates the encoded bit-rate in kbps for the audio
data to be streamed. Permissible values are 32, 48, 64, 96, 128,
160, 192, 256, 320 and 352.
channelID: Indicates the number of channels and channel layout
according to the table1 in Section 7.4. Note that this layout is
different from that proposed in RFC 3551 [3]. However, as
channelID = 0 defines an ambiguous channel layout, the channel
mapping defined in Section 4.1 of [3] could be used. Permissible
values are 0, 1, 2, 3, 4, 5, 6, 7.
Optional parameters:
ptime: see RFC4566[2]
maxptime: see RFC4566[2]
The value of the parameter MUST be a multiple of 46.4(ms) when rate
parameter is 44100, and 42.6(ms) when rate parameter is 48000.
If this parameter is not present, the sender MAY encapsulate a
maximum of 16 encoded frames into one RTP packet, in streaming
of ATRAC-X.
maxRedundantFrames: The maximum number of redundant frames that
may be sent during a session in any given packet under the redundant
framing mechanism detailed in the draft. Allowed values are integers
in the range 0 to 15, inclusive. If this parameter is not used, a
default of 15 MUST be assumed.
delayMode: Indicates a desire to use low-delay features, in which
case the decoder will process received data accordingly based on
Hatanaka, et al. [Page 15]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
this value. Permissible values are 2 and 4.
Encoding considerations: This media type is framed and contains
binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: none
Published specification: none
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Magic number(s): none
File extension(s): 'atx', 'aa3', and 'omg'
Macintosh file type code(s): none
Person & email address to contact for further information:
Mitsuyuki Hatanaka
actech@jp.sony.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing,
and hence is only defined for transfer via RTP.
Hatanaka, et al. [Page 16]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Author/Change controller:
Mitsuyuki Hatanaka
actech@jp.sony.com
7.3 ATRAC Advanced Lossless Media type Registration
The media subtype for the Adaptive TRansform Codec Lossless version
(ATRAC Advanced Lossless) uses the template defined in RFC 4855 [6].
Note, any unknown parameter MUST be ignored by the receiver.
Type name: audio
Subtype name: atrac-advanced-lossless
Required parameters:
rate: Represents the sampling frequency in Hz of the original
audio data. Permissible value is 44100 only.
baseLayer: Indicates the encoded bit-rate in kbps for the base
layer in High-Speed Transfer mode lossless encodings.
For Standard lossless mode this value MUST be 0.
The Permissible values for ATRAC3 baselayer are 66, 105 and 132.
For ATRAC-X baselayer, they are 32, 48, 64, 96, 128, 160, 192, 256,
320 and 352.
blockLength: Indicates the block length. In High-speed Transfer
mode, the value of 1024 and 2048 is used for ATRAC3 and ATRAC-X
based ATRAC Advanced Lossless streaming, respectively.
Any value of 512, 1024 and 2048 can be used for Standard mode.
channelID: Indicates the number of channels and channel layout
according to the table1 in Section 7.4. Note that this layout is
different from that proposed in RFC 3551 [3]. However, as channelID
= 0 defines an ambiguous channel layout, the channel mapping defined
in Section 4.1 of [3] could be used. Permissible values are 0, 1, 2,
3, 4, 5, 6, 7.
ptime: see RFC4566[2]
maxptime: see RFC4566[2]
In streaming of ATRAC Advanced Lossless, a multiple frames can
not be transmitted in a single RTP packet, as the frame size
is large. So it SHOULD be regarded as the time of one encoded
frame in both of the sender and the reciever side.
The value of the parameter MUST be 11.5, 23.2 or 46.4(ms).
Encoding considerations: This media type is framed and contains
Hatanaka, et al. [Page 17]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
binary data.
Security considerations: See Section 9 of this document.
Interoperability considerations: none
Published specification: none
Applications that use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Magic number(s): none
File extension(s): 'aal', 'aa3', and 'omg'
Macintosh file type code(s): none
Person & email address to contact for further information:
Mitsuyuki Hatanaka
actech@jp.sony.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing,
and hence is only defined for transfer via RTP.
Author/Change controller:
Mitsuyuki Hatanaka
actech@jp.sony.com
Hatanaka, et al. [Page 18]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
7.4 Channel Mapping Configuration Table
The Table 1. is explaining the mapping between the channelID
as passed during SDP negotiations, and the speaker mapping
the value represents.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channelID | Number of | Default Speaker |
| | Channels | Mapping |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | max 64 | undefined |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | front: left, right |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | front: left, right |
| | | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 | front: left, right |
| | | front: center |
| | | rear: surround |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 6+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | rear: center |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 7+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | side: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1. Channel Configuration
Hatanaka, et al. [Page 19]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
7.5 Mapping Media type Parameters into SDP
The information carried in the Media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[2], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the ATRAC family of codecs, the
following mapping rules according to the ATRAC codec apply:
7.5.1 For Media subtype ATRAC3
o The Media type ("audio") goes in SDP "m=" as the media name
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. ATRAC3 supports only mono or stereo signals,
so a corresponding number of channels SHALL also be included in
this attribute.
o The "baseLayer" parameter goes in SDP "a=fmtp". This parameter
MUST be present. "maxRedundantFrames" may follow, but if no value
is transmitted, the receiver SHOULD assume a default value of
"15".
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
7.5.2 For Media subtype ATRAC-X
o The Media type ("audio") goes in SDP "m=" as the media name
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. This should be followed by the "sampleRate"
(as the RTP clock rate), and then the actual number of channels
regardless of the channelID parameter.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the Media type string as a
semicolon separated list of parameter=value pairs. The
"baseLayer" parameter must be the first entry on this line. It is
recommened that the "channelID" parameter be the next entry. The
receiver MUST assume a default value of "15" for
"maxRedundantFrames".
Hatanaka, et al. [Page 20]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
7.5.3 For Media subtype ATRAC Advanced Lossless
o The Media type ("audio") goes in SDP "m=" as the media name
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. This should be followed by the "sampleRate"
(as the RTP clock rate), and then the actual number of channels
regardless of the channelID parameter.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
o Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the Media type string as a
semicolon separated list of parameter=value pairs.
On this line, the parameters "baseLayer" and "blockLength"
MUST be existing in this order.
The value of "blockLength" MUST be one of 1024 and 2048, for
using ATRAC3 and ATRAC-X as baselayer, respectively.
If "baseLayer=0" (means standard mode), "blockLength" MUST be one
of either 512, 1024, or 2048. It is recommended that the
"channelID" parameter be the next entry. The receiver MUST assume
a default value of "15" for "maxRedundantFrames".
7.6 Offer-Answer Model Considerations
Some options for encoding and decoding ATRAC audio data will require
either or both the sender and receiver to comply with certain
specifications. In order to establish an interoperable transmission
framework, an Offer-Answer negotiation in SDP should observe the
following considerations. (See reference [8].):
7.6.1 For All Three Media Subtypes
o Each combination of the RTP payload transport format configuration
parameters (baseLayer and blockLength, sampleRate, channelID) is
unique in its bit-pattern and not compatible with any other
combination. When creating an offer in an application desiring to
use the more advanced features (sample rates above 44100kHz, more
than two channels), the offerer is RECOMMENDED to also offer a
payload type containing only the lowest set of necessary
requirements. If multiple configurations are of interest to the
application they may all be offered, however care should be taken
not to offer too many payload types.
o The parameters "maxptime" and "ptime" will in most cases not
affect interoperability, however the setting of the parameters can
affect the performance of the application. The SDP offer-answer
handling of the "ptime" parameter is described in RFC3264. The
"maxptime" parameter MUST be handled in the same way.
Hatanaka, et al. [Page 21]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
7.6.2 For Media subtype ATRAC3
o In response to an offer, downgraded subsets of "baseLayer" are
possible. However for best performance, we suggest the answer
contain the highest possible values offered.
7.6.3 For Media subtype ATRAC-X
o When creating an offer with considerably high requirements (such
as 8 channels at 96kHz), it is RECOMMENDED that the offer also
contain a configuration with lower requirements (such as a stereo
only option). Although multiple alternative configurations may be
offered, care should be taken not to offer too many payload types.
o In response to an offer, downgraded subsets of "sampleRate",
"baseLayer", and "channelID" are possible. For best performance,
we suggest an answer SHALL NOT contain any values requiring
further capabilities than the offer contains, but is RECOMMENDED
to provide values as close as possible to those in the offer.
o The "maxRedundantFrames" is a suggested minimum. This value MAY
be increased in an answer (with a maximum of 15), but SHALL NOT be
reduced.
o The optional parameter "delayMode" is non-negotiable. If the
Answerer cannot comply with the offered value, the session must be
deemed inoperable.
7.6.4 For Media subtype ATRAC Advanced Lossless
o When creating an offer with considerably high requirements (such
as 8 channels at 96kHz), it is RECOMMENDED that the offer also
contain a configuration with lower requirements (such as a stereo
only option). Although multiple alternative configurations may be
offered, care should be taken not to offer too many payload types.
o In response to an offer, downgraded subsets of "sampleRate",
"baseLayer", and "channelID" are possible. For best performance,
we suggest an answer SHALL NOT contain any values requiring
further capabilities than the offer contains, but is RECOMMENDED
to provide values as close as possible to those in the offer.
o There are no requirements when negotiating "blockLength", other
than that both parties must be in agreement.
o The "maxRedundantFrames" is a suggested minimum. This value MAY
be increased in an answer (with a maximum of 15), but SHALL NOT be
reduced.
Hatanaka, et al. [Page 22]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
7.7 Usage of declarative SDP
In declarative usage, like SDP in RTSP [9] or SAP [10], the
parameters SHALL be interpreted as follows:
o The payload format configuration parameters (baseLayer,
sampleRate, channelID) are all declarative and a participant MUST
use the configuration(s) that is provided for the session. More
than one configuration may be provided if necessary by declaring
multiple RTP payload types, however the number of types should be
kept small.
o Any "maxptime" and "ptime" values should be selected with care to
ensure that the session's participants can achieve reasonable
performance.
For transmission of scalable multi-session streaming of ATRAC
Advanced Lossless content, section 6 of the Session Description
Protocol (RFC 4566) [2] defines attributes for notifying applications
of hierarchically encoded streams. For multicast sessions, the base
layer and enhancement layer are transmitted over seperate multicast
groups, thus requiring multiple multicast addresses. For this
scenario, SDP slash notation as defined in RFC 4566 [2] for the "c="
field should be followed. For IP unicast addresses, it will be
necessary to specify multiple transport ports. This is done with
slash notation in the "m=" field similarly defined in RFC 4566 [2].
7.8 Example SDP Session Descriptions
Example usage of ATRAC-X with stereo at 44100Hz:
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=128; channelID=2; delayMode=2
a=maxptime:20
Example usage of ATRAC-X with 5.1 setup at 48000Hz:
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
a=maxptime:42.6
Example usage of ATRAC-Advanced-Lossless in Standard mode:
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
a=maxptime:23.2
Hatanaka, et al. [Page 23]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Example usage of ATRAC-Advanced-Lossless in High-Speed Transfer
mode (note slash notation for multiple port-pairings):
m=audio 49200/2 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:30
7.9 Example Offer-Answer Exchange
The following Offer/Answer example shows how a desire to stream
multi-channel content is turned down by the receiver, who answers
with only the ability to receive stereo content:
Offer:
m=audio 49170 RTP/AVP 98 99
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=320; channelID=5
a=rtpmap:99 ATRAC-X/44100/6
a=fmtp:99 baseLayer=160; channelID=5
Answer:
m=audio 49170 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2
The following Offer/Answer example shows the receiver answering with
a selection of supported parameters:
Offer:
m=audio 49170 RTP/AVP 97 98 99
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
Answer:
m=audio 49170 RTP/AVP 97 98
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5
Hatanaka, et al. [Page 24]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
The following Offer/Answer example shows an exchange in trying to
resolve using ATRAC-Advanced-Lossless. The offer contains three
options: multi-session High-Speed Transfer mode, multiplexed High-
Speed Transfer mode, and Standard mode.
Offer:
m=audio 49170/2 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=64; blockLength=2048; channelID=2
m=audio 49170 RTP/AVP 98
a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2
m=audio 49170 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
Answer:
m=audio 49170/2 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=64; blockLength=2048; channelID=2
m=audio 49170 RTP/AVP 98
a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2
m=audio 0 RTP/AVP 99
Note that 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.
8. IANA Considerations
Three new Media subtypes, for ATRAC3, ATRAC-X,
ATRAC-ADVANCED-LOSSLESS are requested to be registered (see
Section 7).
9. Security Considerations
Certain security precautions may be desired to protect copyrighted
material. The payload format as described in this document is
subject to the security considerations defined in RFC3550 [1] and
any applicable profile, for example RFC 3551 [3]. Also the security
of media type registration MUST be taken into account as described
in section 5 of RFC 4855[6]. This payload format however does not
implement any security mechanisms of its own. External means,
such as SRTP [7], MAY be used since the audio compression scheme
Hatanaka, et al. [Page 25]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
follows an end-to-end model. Since the data transported is audio
that is already encoded, the main security issues are
confidentiality, integrity, and authentication of the actual audio.
9.1 Confidentiality
To ensure confidentiality of ATRAC encoded audio, the audio frames
will have to be encrypted. Encryption of the payload header,
however, is not as neccessary, and in fact may not be preferrable if
the information could be useful to some third party application.
Because the audio compression scheme follows an end-to-end model,
encryption may be performed after packet encapsulation. As multi-
channel transmissions are contained in single encoded audio frames,
there is no concern for encryption affecting interleaving data.
9.2 Authentication
Transmitted data may be tampered or altered due malicious attempts,
such as man-in-the-middle attacks. Such attacks may result in
depacketization and/or decoding errors that could decimate audio
quality.
As this payload format does not include its own means for sender
authentication and integrity protection, an external mechanism must
be used. It is RECOMMENDED, however, that the chosen mechanism
protect more than just the audio data bits. For example, to
protect against a man-in-the-middle attack, the payload header and
RTP header SHOULD be protected.
9.3 Decoding Validation
Verification of the received encoded audio packets should be
performed so as to ensure a minimal level of audio quality. As a
most primitive implementation, if the receiver calculates a packet
size differing from the payload length based on data in the payload
header fields, the receiver SHOULD discard the packet.
Hatanaka, et al. [Page 26]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
10. References
10.1 Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, STD 64, July 2003.
[2] Handley, M. , V. Jacobson and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 3551, STD 65, July 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, BCP 14", RFC 2119, March 1997.
[5] N. Freed, J. Klensin,
"Media Type Specifications and Registration Procedures",
RFC 4288, STD 64, December 2005.
[6] S. Casner,
"Media Type Registration of RTP Payload Formats",
RFC 4855, STD 64, July 2003.
10.2 Informative References
[7] Baugher, M., Carrara, E., McGrew, D., Naslund, M., and Norrman,
"The Secure Real Time Transport Protocol", July 2003.
[8] Rosenberg, J. and Schulzrinne, "An Offer/Answer Model with the
Session Description Protocl (SDP)", RFC 3264, June 2002.
[9] Schulzrinne, H., Rao, and Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[10] Handley, M., Perkins, C. and Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
Authors' Addresses
Mitsuyuki Hatanaka
Sony Corporation, Japan
1-7-1 Konan
Minato-ku
Tokyo 108-0075
Japan
Hatanaka, et al. [Page 27]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Jun Matsumoto
Sony Corporation, Japan
1-7-1 Konan
Minato-ku
Tokyo 108-0075
Japan
Email: actech@jp.sony.com
Hatanaka, et al. [Page 28]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2007). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hatanaka, et al. [Page 29]
INTERNET-DRAFT draft-ietf-avt-rtp-atrac-family-10.txt August, 2007