Audio/Video Transport M. Hatanaka Internet-Draft J. Matsumoto Expires: June 3, 2007 Sony Corporation December 2006 RTP Payload Format for ATRAC Family draft-ietf-avt-rtp-atrac-family-07 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 June 3, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. Hatanaka, et al. Expires June 3, 2007 [Page 1] Internet-Draft RTP Payload Format for ATRAC Family December 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 5 4.5 Global Structure of Payload Format . . . . . . . . . . . . 5 4.6 Scalable Lossless Streaming (High-Speed Transfer mode) . . 5 4.6.1 Scalable Multiplexed Streaming . . . . . . . . . . . . 6 4.6.2 Scalable Multi-Session Streaming . . . . . . . . . . . 6 5. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Usage of RTP Header Fields . . . . . . . . . . . . . . . . 6 5.2 RTP Payload Structure . . . . . . . . . . . . . . . . . . 7 5.2.1 ATRAC Header Section . . . . . . . . . . . . . . . . . 7 5.2.2 Redundant Data Section . . . . . . . . . . . . . . . . 8 5.2.3 ATRAC Frames Section . . . . . . . . . . . . . . . . . 8 5.2.3.1 Frame Fragmentation . . . . . . . . . . . . . . . . . 8 6. Packetization Examples . . . . . . . . . . . . . . . . . . . . 10 6.1 Example Multi-frame Packet . . . . . . . . . . . . . . . . 10 6.2 Example Fragmented ATRAC Frame . . . . . . . . . . . . . . 10 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 7.1 ATRAC3 Media type Registration . . . . . . . . . . . . . . 12 7.2 ATRAC-X Media type Registraion . . . . . . . . . . . . . . 13 7.3 ATRAC Advanced Lossless Media type Registration . . . . . 15 7.4 Channel Mapping Configuration Table . . . . . . . . . . . 17 7.5 Mapping Media type Parameters into SDP . . . . . . . . . . 18 7.5.1 For Media subtype ATRAC3 . . . . . . . . . .. . . . . 18 7.5.2 For Media subtype ATRAC-X . . . . . . . . . .. . . . . 18 7.5.3 For Media subtype ATRAC Advanced Lossless . .. . . . . 19 7.6 Offer-Answer Model Considerations . . . . . . . . . . . . 19 7.6.1 For All Three Media Subtypes . . . . . . . .. . . . . 19 7.6.2 For Media subtype ATRAC3 . . . . . . . . . . . . . . 20 7.6.3 For Media subtype ATRAC-X . . . . . . . . . . . . . . 20 7.6.4 For Media subtype ATRAC Advanced Lossless . . . . . . 20 7.7 Usage of declarative SDP . . . . . . . . . . . . . . . . . 21 7.8 Example SDP Session Descriptions . . . . . . . . . . . . . 21 7.9 Example Offer-Answer Exchange . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 24 9.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 24 9.3 Decoding Validation . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 Hatanaka, et al. Expires June 3, 2007 [Page 2] Internet-Draft RTP Payload Format for ATRAC Family December 2006 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 10.2 Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 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 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 Hatanaka, et al. Expires June 3, 2007 [Page 3] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 Hatanaka, et al. Expires June 3, 2007 [Page 4] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 --------- > Figure 1. 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 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 Hatanaka, et al. Expires June 3, 2007 [Page 5] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 Figure 2. Multiplexed strcture 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 Figure 3. Multi-Session Streaming 5. Payload Format 5.1 Usage of RTP Header Fields Hatanaka, et al. Expires June 3, 2007 [Page 6] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 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 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| +-+-+-+-+-+-+-+-+ 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 Hatanaka, et al. Expires June 3, 2007 [Page 7] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 Figure 6. Redundant Exmaple 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. Hatanaka, et al. Expires June 3, 2007 [Page 8] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 7. ATRAC Frame Section Format 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 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. Hatanaka, et al. Expires June 3, 2007 [Page 9] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 8. Example Multi-frame Packet 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hatanaka, et al. Expires June 3, 2007 [Page 10] Internet-Draft RTP Payload Format for ATRAC Family December 2006 | 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 9. Example Fragmented ATRAC Frame Hatanaka, et al. Expires June 3, 2007 [Page 11] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 2327) [2] is also provided for applications that utilize SDP. These registrations use the template defined in RFC 4288 and follow RFC 3555. 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) 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. Type name: audio 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 Encoding considerations: This media type is framed and contains binary data. Hatanaka, et al. Expires June 3, 2007 [Page 12] Internet-Draft RTP Payload Format for ATRAC Family December 2006 Security considerations: See Section 5 of RFC 3555. 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. Author/Change controller: Mitsuyuki Hatanaka actech@jp.sony.com 7.2 ATRAC-X Media type Registraion The media 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. Type name: audio Subtype name: vnd.sony.atrac-x Required parameters: rate: 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. Hatanaka, et al. Expires June 3, 2007 [Page 13] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 media type is framed and contains binary data. Security considerations: See Section 5 of RFC 3555. Interoperability considerations: none Published specification: none Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: none Hatanaka, et al. Expires June 3, 2007 [Page 14] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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) 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. Type name: audio Subtype name: vnd.sony.atrac-advanced-lossless Required parameters: rate: 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. Hatanaka, et al. Expires June 3, 2007 [Page 15] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. ptime: see RFC 2327 [2] Encoding considerations: This media type is framed and contains binary data. Security considerations: See Section 5 of RFC 3555. 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. Hatanaka, et al. Expires June 3, 2007 [Page 16] Internet-Draft RTP Payload Format for ATRAC Family December 2006 Author/Change controller: Mitsuyuki Hatanaka actech@jp.sony.com 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. Table 1. Channel Configuration +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hatanaka, et al. Expires June 3, 2007 [Page 17] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. Expires June 3, 2007 [Page 18] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. 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 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. Expires June 3, 2007 [Page 19] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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. Expires June 3, 2007 [Page 20] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 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 Hatanaka, et al. Expires June 3, 2007 [Page 21] Internet-Draft RTP Payload Format for ATRAC Family December 2006 Example usage of ATRAC-Advanced-Lossless in High-Speed mode (note slash notation for multiple port-pairings): 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 Hatanaka, et al. Expires June 3, 2007 [Page 22] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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=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. 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 Two new Media 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 the actual audio. Hatanaka, et al. Expires June 3, 2007 [Page 23] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 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. Hatanaka, et al. Expires June 3, 2007 [Page 24] Internet-Draft RTP Payload Format for ATRAC Family December 2006 [5] N. Freed, J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, STD 64, December 2005. [6] Casner, Hoschka , "MIME Type Registration of RTP Payload Formats", RFC 3555, STD 64, July 2003. 10.2 Informative References [7] Kerr, P., "RTP Payload Format for Vorbis Encoded Audio", October 2003. [8] 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. [9] Baugher, M., Carrara, E., McGrew, D., Naslund, M., and Norrman, "The Secure Real Time Transport Protocol", July 2003. [10] Rosenberg, J. and Schulzrinne, "An Offer/Answer Model with the Session Description Protocl (SDP)", RFC 3264, June 2002. [11] Schulzrinne, H., Rao, and Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [12] Handley, M., Perkins, and Whelan, "Session Announcement Protocol", RFC 2974, October 2000. Authors' Addresses Mitsuyuki Hatanaka Sony Corporation, Japan 6-7-35 Kitashinagawa Shinagawa-ku Tokyo 141-0001 Japan Jun Matsumoto Sony Corporation, Japan 6-7-35 Kitashinagawa Shinagawa-ku Tokyo 141-0001 Japan Email: actech@jp.sony.com Hatanaka, et al. Expires June 3, 2007 [Page 25] Internet-Draft RTP Payload Format for ATRAC Family December 2006 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 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. Hatanaka, et al. Expires June 3, 2007 [Page 26] Internet-Draft RTP Payload Format for ATRAC Family December 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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. Expires June 3, 2007 [Page 27]