Subject: [AVT] draft-ietf-avt-rtp-atrac-family-04

From: Matthew Romaine <[email-masked]>
Date: Fri, 8 Jul 2005 19:51:35 +0900

fellow avt'ers,

I have submitted draft -04 of our ATRAC family payload for your  
consideration, and enclosed it below incase the editors don't get  
around to submitting the link before the weekend.

The main changes are:

- removal of any auxiliary data features
- additional support for a new ATRAC codec -- ATRAC Advanced Lossless  
-- which supports multiplexed and multi-session streaming
- updated SDP sections to reflect support for the above mentioned new  
codec.

Would greatly appreciate comments so that presentation time at IETF  
63 can be used most effectively.  Incidentally, if things go well,  
you all may get to walk home with a free SDK for this codec :)

Have a great weekend,
Matt

Audio/Video Transport                                         M. Romaine
Internet-Draft                                               M. Hatanaka
Expires: December 3, 2005                                   J. Matsumoto
                                                                      
SONY
                                                                June  
2005

                   RTP Payload Format for ATRAC Family
                    draft-ietf-avt-rtp-atrac-family-04

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 3, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2005).

Abstract

    This document describes an RTP payload format for efficient and
    flexible transporting of audio data encoded with the Adaptive
    TRansform Audio Codec (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.

Romaine, et al.         Expires December 3, 2005                [Page 1]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    2.   
Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Codec Specific  
Details . . . . . . . . . . . . . . . . . . . .  4
    4.  RTP Packetization and Transport of ATRAC-Family  
Streams  . . .  5
      4.1   ATRAC  
Frames . . . . . . . . . . . . . . . . . . . . . . .  5
      4.2   Concatenation of  
Frames  . . . . . . . . . . . . . . . . .  5
      4.3   Frame  
Fragmentation  . . . . . . . . . . . . . . . . . . .  5
      4.4   Transmission of Redundant  
Frames . . . . . . . . . . . . .  5
      4.5   Global Structure of Payload  
Format . . . . . . . . . . . .  6
      4.6   Scalable Lossless Streaming (High-Speed Transfer  
mode) . .  6
        4.6.1   Scalable Multiplexed  
Streaming . . . . . . . . . . . .  6
        4.6.2   Scalable Multi-Session  
Streaming . . . . . . . . . . .  7
    5.  Payload  
Format . . . . . . . . . . . . . . . . . . . . . . . .  7
      5.1   Usage of RTP Header  
Fields . . . . . . . . . . . . . . . .  7
      5.2   RTP Payload  
Structure  . . . . . . . . . . . . . . . . . .  8
        5.2.1   ATRAC Header  
Section . . . . . . . . . . . . . . . . .  8
        5.2.2   Redundant Data  
Section . . . . . . . . . . . . . . . .  8
        5.2.3   ATRAC Frames  
Section . . . . . . . . . . . . . . . . .  9
    6.  Packetization  
Examples . . . . . . . . . . . . . . . . . . . . 10
      6.1   Example Multi-frame  
Packet . . . . . . . . . . . . . . . . 10
      6.2   Example Fragmented ATRAC  
Frame . . . . . . . . . . . . . . 11
    7.  Payload Format  
Parameters  . . . . . . . . . . . . . . . . . . 12
      7.1   ATRAC3 MIME  
Registration . . . . . . . . . . . . . . . . . 13
      7.2   ATRAC-X MIME  
Registraion . . . . . . . . . . . . . . . . . 14
      7.3   ATRAC Advanced Lossless MIME  
Registration  . . . . . . . . 15
      7.4   Channel Mapping Configuration  
Table  . . . . . . . . . . . 17
      7.5   Mapping MIME Parameters into  
SDP . . . . . . . . . . . . . 18
        7.5.1   For MIME subtype  
ATRAC3  . . . . . . . . . . . . . . . 18
        7.5.2   For MIME subtype ATRAC- 
X . . . . . . . . . . . . . . . 19
        7.5.3   For MIME subtype ATRAC Advanced  
Lossless . . . . . . . 19
      7.6   Offer-Answer Model  
Considerations  . . . . . . . . . . . . 20
        7.6.1   For All Three MIME  
Subtypes  . . . . . . . . . . . . . 20
        7.6.2   For MIME subtype  
ATRAC3  . . . . . . . . . . . . . . . 20
        7.6.3   For MIME subtype ATRAC- 
X . . . . . . . . . . . . . . . 20
        7.6.4   For MIME subtype ATRAC Advanced  
Lossless . . . . . . . 21
      7.7   Usage of declarative  
SDP . . . . . . . . . . . . . . . . . 21
      7.8   Example SDP Session  
Descriptions . . . . . . . . . . . . . 22
      7.9   Example Offer-Answer  
Exchange  . . . . . . . . . . . . . . 23
    8.  IANA  
Considerations  . . . . . . . . . . . . . . . . . . . . . 24
    9.  Security  
Considerations  . . . . . . . . . . . . . . . . . . . 24
      9.1    
Confidentiality  . . . . . . . . . . . . . . . . . . . . . 25
      9.2    
Authentication . . . . . . . . . . . . . . . . . . . . . . 25
      9.3   Decoding  
Validation  . . . . . . . . . . . . . . . . . . . 25
    10.    
References . . . . . . . . . . . . . . . . . . . . . . . . . 25
      10.1  Normative  
References . . . . . . . . . . . . . . . . . . . 25
      10.2  Informative  
References . . . . . . . . . . . . . . . . . . 26

Romaine, et al.         Expires December 3, 2005                [Page 2]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

        Authors'  
Addresses . . . . . . . . . . . . . . . . . . . . . . 26
        Intellectual Property and Copyright  
Statements . . . . . . . . 28

Romaine, et al.         Expires December 3, 2005                [Page 3]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

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.
    Timestamps are in sample units, with audio data currently encoded
    into frames of 512, 1024 or 2048 samples depending on the ATRAC
    version.  There is also basic support for fragmentation and
    redundancy, as ATRAC frames MAY exceed an MTU size of 1500 octets.

    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.

2.  Conventions

    The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [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

Romaine, et al.         Expires December 3, 2005                [Page 4]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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.

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.

Romaine, et al.         Expires December 3, 2005                [Page 5]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

4.5  Global Structure of Payload Format

    The RTP payload following the RTP header contains three octet- 
aligned
    data sections, of which the second MAY be empty:

    +------+--------------+--------------+--------------+
    |RTP   | ATRAC Header | Redundant    | ATRAC Frames |
    |Header| Section      | Data Section | Section      |
    +------+--------------+--------------+--------------+
            < ----------- RTP Packet Payload --------- >

    The first data section is the ATRAC Header, containing just one
    header with information for the whole packet.  The second section is
    for redundant ATRAC frames; this section MAY be empty.  The third
    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.

    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.

4.6  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.6.1  Scalable Multiplexed Streaming

    In multiplexed streaming, the base layer and enhancement layer are
    coupled together in each packet, utilizing only one session.  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

Romaine, et al.         Expires December 3, 2005                [Page 6]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

4.6.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.
    While there may be alternative methods for synchronization of the
    layers, it is RECOMMENDED that the timestamp 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 2327) [2].  Further details
    are discussed in the section titled "Usage of declarative SDP".

    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

5.  Payload Format

5.1  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              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Marker (M): 1 bit
    Set to zero as silence suppression is currently not 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

Romaine, et al.         Expires December 3, 2005                [Page 7]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    profile under which this payload format is used, or signaled
    dynamically out-of-band (e.g., using SDP).

    Timestamp: 32 bits
    A timestamp representing the sampling time of the first sample of  
the
    first ATRAC frame in the RTP packet.  When using SDP, the clock rate
    of the RTP timestamp MUST be expressed using the "rtpmap" attribute.
    For ATRAC3 the RTP timestamp rate MUST be 44100Hz.  For ATRAC-X the
    RTP timestamp rate is defined out-of-band.

5.2  RTP Payload Structure

5.2.1  ATRAC Header Section

    The ATRAC family payload header is one byte.

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |C|FrgNo|NFrames|
    +-+-+-+-+-+-+-+-+

    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 1 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.2.2  Redundant Data Section

    The Redundant Data Section provides a rudimentary mechanism 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.

Romaine, et al.         Expires December 3, 2005                [Page 8]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    As an example of using the Redundant Data Section, refer to  
Figure 1.
    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.  This field SHOULD NOT be  
used
    in packets containing fragmented data.

     |-Fr1-|-Fr2-|-Fr3-|                             Packet N,   TS=1
           |-Fr2-|-Fr3-|-Fr4-|                       Packet N+1, TS=2
                             |-Fr5-|-Fr6-|-Fr7-|     Packet N+4, TS=5

5.2.3  ATRAC Frames Section

    The ATRAC Frames Section contains an integer number of complete  
ATRAC
    frames or a single fragment of one ATRAC frame.  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.

       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            
|...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Layer Type Flag: 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.2.3.1  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

Romaine, et al.         Expires December 3, 2005                [Page 9]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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
    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.  This means the Frame Offset field MUST be ignored.

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.

Romaine, et al.         Expires December 3, 2005               [Page 10]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

       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...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2  Example Fragmented ATRAC Frame

    The encoded audio data frame is split over three RTP packets.  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           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Romaine, et al.         Expires December 3, 2005               [Page 11]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

      |           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...                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.  Payload Format Parameters

    Certain parameters will need to be defined before ATRAC family

Romaine, et al.         Expires December 3, 2005               [Page 12]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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 MIME subtype registration
    process.  A mapping of these parameters into the Session Description
    Protocol (SDP) (RFC 2327) [2] is also provided for applications that
    utilize SDP.

    The data format and parameters are specified for real-time transport
    in RTP.

7.1  ATRAC3 MIME Registration

    The MIME subtype for the Adaptive TRansform Codec version 3 (ATRAC3)
    is allocated from the Vendor tree since this codec is intended to be
    used with commercial products, and use of any ATRAC family codec
    requires a license from Sony Corporation, the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac3

    Required parameters:

    baseLayer:  Indicates the encoded bit-rate for the audio data to be
    streamed.  Permissible values are 66, 105, and 132.

    Optional parameters:

    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.

    maxptime: The maximum amount of media which can be encapsulated in
    each packet, expressed as time in milliseconds.  The time SHALL be
    calculated as the sum of the time the media present in the packet
    represents.  For frame based codecs, the time MUST be an integer
    multiple of the frame size.  If this parameter is not present, the
    sender MAY encapsulate a maximum of 16 encoded frames into one RTP
    packet.

    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP

Romaine, et al.         Expires December 3, 2005               [Page 13]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    RFC 3550 [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    [email-masked]

    Intended usage: COMMON

    Author/Change controller:
    [email-masked]

7.2  ATRAC-X MIME Registraion

    The MIME subtype for the Adaptive TRansform Codec version X  
(ATRAC-X)
    is allocated from the Vendor tree since this codec is intended to be
    used with commercial products, and use of any ATRAC family codec
    requires a license from Sony Corporation, the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac-x

    Required parameters:

    sampleRate:  Represents the sampling frequency in Hz of the original
    audio data.  Permissible values are 32000, 44100, 48000, 88200,
    96000.

    baseLayer:  Indicates the encoded bit-rate for the audio data to be
    streamed.  Permissible values are 48, 64, 96, 128, 160, 192, 256,  
and
    320.

    channelID:  Indicates the number of channels and channel layout
    according to the table in Section 5.3.  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,

Romaine, et al.         Expires December 3, 2005               [Page 14]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    3, 4, 5, 6, 7.

    Optional parameters:

    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  
this
    value.  Permissible values are 2 and 4.

    maxptime: The maximum amount of media which can be encapsulated in a
    payload packet, expressed as time in milliseconds.  The time is
    calculated as the sum of the time the media present in the packet
    represents.  The time MUST be a multiple of the frame size.  If this
    parameter is not present, the sender MAY encapsulate a maximum of 16
    encoded frames into one RTP packet.

    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP
    (RFC 3550) [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    [email-masked]

    Intended usage: COMMON

    Author/Change controller:
    [email-masked]

7.3  ATRAC Advanced Lossless MIME Registration

    The MIME subtype for the Adaptive TRansform Codec Lossless version
    (ATRAC Advanced Lossless) is allocated from the Vendor tree since

Romaine, et al.         Expires December 3, 2005               [Page 15]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    this codec is intended to be used with commercial products, and use
    of any ATRAC family codec requires a license from Sony Corporation,
    the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac-advanced-lossless

    Required parameters:

    sampleRate:  Represents the sampling frequency in Hz of the original
    audio data.  Permissible values are 32000, 44100, 48000, 88200,
    96000.

    baseLayer:  Indicates the encoded bit-rate for the base layer in
    High-Speed Transfer mode lossless encodings.  For Standard lossless
    mode this value MUST be 0.  Permissible values are 0, 48, 64, 66,  
96,
    105, 128, 132, 160, 192, 256, and 320.

    blockLength: Indicates the block length being used for Standard
    lossless mode.  When "baseLayer=0", this value MUST be one of either
    512, 1024, or 2048.  If the "baseLayer" parameter is not "0", this
    parameter MUST be ignored.

    channelID:  Indicates the number of channels and channel layout
    according to the table in Section 5.3.  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:

    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.

    maxptime: The maximum amount of media which can be encapsulated in a
    payload packet, expressed as time in milliseconds.  The time is
    calculated as the sum of the time the media present in the packet
    represents.  The time MUST be a multiple of the frame size.  If this
    parameter is not present, the sender MAY encapsulate a maximum of 16
    encoded frames into one RTP packet.

Romaine, et al.         Expires December 3, 2005               [Page 16]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP
    (RFC 3550) [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    [email-masked]

    Intended usage: COMMON

    Author/Change controller:
    [email-masked]

7.4  Channel Mapping Configuration Table

    The following is a table explaining the mapping between the  
channelID
    as passed during SDP negotiations, and the speaker mapping the value
    represents.

Romaine, et al.         Expires December 3, 2005               [Page 17]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | 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                 |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.5  Mapping MIME Parameters into SDP

    The information carried in the MIME 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 MIME subtype ATRAC3

    o  The MIME type ("audio") goes in SDP "m=" as the media name

Romaine, et al.         Expires December 3, 2005               [Page 18]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    o  The MIME 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 MIME subtype ATRAC-X

    o  The MIME type ("audio") goes in SDP "m=" as the media name

    o  The MIME 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 MIME 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".

7.5.3  For MIME subtype ATRAC Advanced Lossless

    o  The MIME type ("audio") goes in SDP "m=" as the media name

    o  The MIME 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.

Romaine, et al.         Expires December 3, 2005               [Page 19]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    o  Any remaining parameters go in the SDP "a=fmtp" attribute by
       copying them directly from the MIME media type string as a
       semicolon separated list of parameter=value pairs.  The
       "baseLayer" parameter must be the first entry on this line.  If
       "baseLayer=0", the "blockLength" parameter MUST follow and 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:

7.6.1  For All Three MIME 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.

7.6.2  For MIME 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 MIME subtype ATRAC-X

Romaine, et al.         Expires December 3, 2005               [Page 20]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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 MIME 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.

7.7  Usage of declarative SDP

    In declarative usage, like SDP in RTSP [9] or SAP [10], the
    parameters SHALL be interpreted as follows:

Romaine, et al.         Expires December 3, 2005               [Page 21]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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 2327) [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 2327 [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 2327 [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:30

    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:30

    Example usage of ATRAC-Advanced-Lossless in High-Speed mode (note
    slash notation for multiple port-pairings):

Romaine, et al.         Expires December 3, 2005               [Page 22]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    m=audio 49200/2 RTP/AVP 99
    a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/48000/2
    a=fmtp:99 baseLayer=128; blockLength=0; 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

    The following Offer/Answer example shows an exchange in trying to
    resolve using ATRAC-Advanced-Lossless.  The offer contains three

Romaine, et al.         Expires December 3, 2005               [Page 23]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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=0; channelID=2
    m=audio 49170 RTP/AVP 98
    a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:98 baseLayer=256; blockLength=0; channelID=2
    m=audio 49170 RTP/AVP 99
    a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/48000/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=0; channelID=2
    m=audio 49170 RTP/AVP 98
    a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:98 baseLayer=256; blockLength=0; channelID=2
    m=audio 0 RTP/AVP 99

    Note that payload format (encoding) names are commonly shown in  
upper
    case.  MIME subtypes are commonly shown in lower case.  These names
    are case-insensitive in both places.  Similarly, parameter names are
    case-insensitive both in MIME types and in the default mapping to  
the
    SDP a=fmtp attribute.

8.  IANA Considerations

    Two new MIME subtypes, for ATRAC3 and ATRAC-X, are requested to be
    registered (see Section 5).

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].  This payload format
    however does not implement any security mechanisms of its own.
    External means, such as SRTP [5], MAY be used since the audio
    compression scheme 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

Romaine, et al.         Expires December 3, 2005               [Page 24]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    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.

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. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

    [3]  Schulzrinne, H., "RTP Profile for Audio and Video Conferences

Romaine, et al.         Expires December 3, 2005               [Page 25]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

         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.

10.2  Informative References

    [5]   Kerr, P., "RTP Payload Format for Vorbis Encoded Audio",
          October 2003.

    [6]   Sjoberg, J., "Real-Time Transport Protocol (RTP) Payload  
Format
          and File Storage Format for the Adaptive Multi-Rate (AMR) and
          Adpative Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267,
          June 2002.

    [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, and Whelan, "Session Announcement
          Protocol", RFC 2974, October 2000.

Authors' Addresses

    Matthew Romaine
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: [email-masked]

Romaine, et al.         Expires December 3, 2005               [Page 26]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

    Mitsuyuki Hatanaka
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: [email-masked]

    Jun Matsumoto
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: [email-masked]

Romaine, et al.         Expires December 3, 2005               [Page 27]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005

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
    [email-masked].

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 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 Internet Society (2005).  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.

Romaine, et al.         Expires December 3, 2005               [Page 28]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt