Network Working Group M. Hatanaka
Request for Comments: 5584 J. Matsumoto
Category: Standards Track Sony Corporation
July 2009
RTP Payload Format for
the Adaptive TRansform Acoustic Coding (ATRAC) Family
Abstract
抽象
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming.
この文書では、オーディオコーディング（ATRAC）コーデックの家族を変換適応でエンコードされたオーディオデータの効率的かつ柔軟な輸送のためのRTPペイロード形式について説明します。コーデックのATRACファミリーに最新の拡張機能は、複数のチャネルを有する高品質のオーディオコーディングをサポートしています。この文書で提示されるRTPペイロード形式は、データの断片化、基本冗長化対策、およびスケーラブルなストリーミングのバリエーションをサポートしています。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Codec-Specific Details ..........................................3
4. RTP Packetization and Transport of ATRAC-Family Streams .........4
4.1. ATRAC Frames ...............................................4
4.2. Concatenation of Frames ....................................4
4.3. Frame Fragmentation ........................................4
4.4. Transmission of Redundant Frames ...........................4
4.5. Scalable Lossless Streaming (High-Speed Transfer Mode) .....5
4.5.1. Scalable Multiplexed Streaming ......................5
4.5.2. Scalable Multi-Session Streaming ....................5
5. Payload Format ..................................................6
5.1. Global Structure of Payload Format .........................6
5.2. Usage of RTP Header Fields .................................7
5.3. RTP Payload Structure ......................................8
5.3.1. Usage of ATRAC Header Section .......................8
5.3.2. Usage of ATRAC Frames Section .......................9
6. Packetization Examples .........................................12
6.1. Example Multi-Frame Packet ................................12
6.2. Example Fragmented ATRAC Frame ............................13
7. Payload Format Parameters ......................................14
7.1. ATRAC3 Media Type Registration ............................14
7.2. ATRAC-X Media Type Registration ...........................16
7.3. ATRAC Advanced Lossless Media Type Registration ...........18
7.4. Channel Mapping Configuration Table .......................20
7.5. Mapping Media Type Parameters into SDP ....................21
7.5.1. For Media Subtype ATRAC3 ...........................21
7.5.2. For Media Subtype ATRAC-X ..........................21
7.5.3. For Media Subtype ATRAC Advanced Lossless ..........22
7.6. Offer/Answer Model Considerations .........................22
7.6.1. For All Three Media Subtypes .......................22
7.6.2. For Media Subtype ATRAC3 ...........................23
7.6.3. For Media Subtype ATRAC-X ..........................23
7.6.4. For Media Subtype ATRAC Advanced Lossless ..........23
7.7. Usage of Declarative SDP ..................................24
7.8. Example SDP Session Descriptions ..........................24
7.9. Example Offer/Answer Exchange .............................26
8. IANA Considerations ............................................28
9. Security Considerations ........................................28
10. Considerations on Correct Decoding ............................28
10.1. Verification of the Packets ..............................28
10.2. Validity Checking of the Packets .........................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................30
The ATRAC family of perceptual audio codecs is 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.
知覚オーディオコーデックのATRACファミリーは、高品質、低ビットレートのオーディオ転送のための多数のニーズに対応するように設計されています。 ATRAC技術は、MDプレーヤー、CDプレーヤー、ボイスレコーダ、携帯電話など、多くの消費者および専門家の製品やアプリケーション、で見つけることができます。
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.
ATRAC技術における最近の進歩は、カスタマイズ可能なグループでエンコードされたオーディオの複数のチャネルを可能にします。これは、ATRACファミリーメンバーコーデックのいずれかをストリーミングで最大の柔軟性を提供するためにスケーリングされたストリーミングで将来の拡張を可能にすべきです。しかし、このペイロード形式は、パケットレベルでのコーデックを区別しません。
This simplified payload format contains only the basic information needed to disassemble a packet of ATRAC audio in order to decode it. There is also basic support for fragmentation and redundancy.
この簡略化されたペイロードフォーマットは、それを復号化するために、ATRACオーディオのパケットを分解するのに必要な基本的な情報のみが含まれています。断片化と冗長性のための基本的なサポートもあります。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[4]。
Early versions of the ATRAC codec handled only two channels of audio at 44.1 kHz sampling frequency, with typical bit-rates between 66 kbps and 132 kbps. The latest version allows for a maximum of 8 channels of audio, up to 96 kHz in sampling frequency, and a lossless encoding option that 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 8 kbps up to 1400 kbps in lossy encoding modes.
ATRACコーデックの初期バージョンは、66 kbpsのと132 kbpsの間の典型的なビットレートで、44.1 kHzのサンプリング周波数でオーディオのみの2つのチャネルを扱います。最新バージョンは、サンプリング周波数が96kHzまで、オーディオの8つのチャンネルの最大を可能にし、いずれかのスケーラブルな（また、高速転送モードとも呼ばれる）または標準（別名標準モードで送信することができる可逆符号化オプション） フォーマット。実現可能なビットレートの範囲はまた、8 kbps単位のローからの非可逆符号化モードで1400 kbpsの最大可能、拡大しています。
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.
ATRACのバージョンに応じて、サンプルのフレームサイズが512、1024又は2048個のサンプルのいずれかである、使用。損失のあるベースレイヤ及びエンハンスメントレイヤ - ロッシーと標準モードのロスレスフォーマットが順次単一オーディオフレームとして符号化されているが、高速転送モードのロスレスデータは、2つの層を含みます。
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 with which to be concerned.
マルチチャネルオーディオのストリーミングを使用ATRACのバージョンによってサポートされていますが、一定期間のためのすべての符号化されたオーディオは、単一のフレーム内に含まれます。このため、気にすると、チャネルごとに何のインターリーブやオーディオデータの分割はありません。
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 octet-aligned by definition.
圧縮されたオーディオデータの輸送のために、ATRACは、フレームの概念を使用します。 ATRACフレームは、タイミング情報を帰属された最小データ単位です。フレームは、オクテット整列定義です。
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 64 kbps 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.
1つのRTPパケットに複数のフレームを伝送することが可能であることが多いです。各ATRACフレームは約200バイトになり、これは、1500バイトのMTU、単一のRTPパケットに実施することができ7つの完全な64 KbpsのATRACフレームの平均とLAN上のオーディオ、に有用であり得ます。 ATRACフレームは、固定長または可変長のものであってもよいです。 1つのRTPパケットに複数フレームの場合には解析を容易にするために、各フレームのサイズは、RTPパケットの各含まれるフレームは、「インバンド」フレームサイズを実施することによって受信機に知らされます。しかし、RTP受信機の実装を簡単にするために、それは複数のフレームは、RTPパケットで運ばれる場合、各フレームが完了していなければならないことが要求され、即ち、RTPパケット内のフレーム数は、一体でなければなりません。
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 MUST carry either 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.
ATRACコーデックは、非常に大きなフレームを処理することができます。フレームは、ATRACが処理できるサイズより最もIPネットワークはかなり小さいMTUサイズを有するように、このペイロードフォーマットは、複数のRTPパケット上ATRACフレームの断片化を可能にします。しかし、RTP受信機の実装を簡素化するために、RTPパケットは、1つ以上の完全なATRACフレームまたは1つのATRACフレームの単一フラグメントのいずれかを実行する必要があります。言い換えれば、RTPパケットは、複数のATRACフレームの断片を含んではならないと完全な断片化されたフレームの組み合わせを含めることはできません。
As RTP does not guarantee reliable transmission, receipt of data is not assured. Loss of a packet can result in a "decoding gap" at 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. For further details, see Section 5.3.2.1 and [12].
RTPは、信頼性の高い伝送を保証するものではありませんので、データの受信は保証されません。パケットのロスは、受信機における「復号ギャップ」をもたらすことができます。この問題を解決する一つの方法は、ATRACのタイムシフトコピーは、現在のデータと一緒に送信されるフレームをできるようにすることです。レイテンシと実装の複雑さの適度なコストのために、パケット損失にエラー耐性を実現することができます。詳細については、セクション5.3.2.1および[12]を参照してください。
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.
一つのセッションを介して多重化又は二つのセッションにわたって分離 - ATRACは、スケーラブル符号化の変形をサポートするように、このペイロード形式は2つの方法でそのエンハンスメントデータと（また、下地層と称する）を必須データを送信するためのメカニズムを提供します。
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.
いずれの方法においても、唯一のベース層は、音声データの生成に必須です。エンハンスメントレイヤは、ロスレスオーディオデータをデコードするために必要な残りのオーディオデータを搬送します。だから、限られた帯域幅の状況では、送信者は、エンハンスメントデータを送信しながらも、ベース層を介して非可逆符号化された音声を生成するための十分なデータをクライアントに提供しないことを選択することができます。
In multiplexed streaming, the base layer and enhancement layer are coupled together in each packet, utilizing only one session as illustrated in Figure 1.
多重化されたストリーミングでは、ベース層とエンハンスメント層は、図1に示すように、一つだけのセッションを利用し、各パケットに一緒に結合されています。
The packet MUST begin with the base layer, and the two layer types MUST interleave if both of the layers exist in a packet (only base or enhancement is included in a packet at the beginning of a streaming, or during the fragmentation).
パケットは、ベース層で始まる必要があり、層の両方が（、又は断片中のストリーミングの開始時にパケットにのみ塩基または増強が含まれる）パケット内に存在する場合、2層タイプがインターリーブしなければなりません。
+----------------+ +----------------+ +----------------+
|Base|Enhancement|--|Base|Enhancement|--|Base|Enhancement| ...
+----------------+ +----------------+ +----------------+
N N+1 N+2 : Packet
Figure 1. Multiplexed Structure
図1.多重構造
In multi-session streaming, the base layer and enhancement layer are sent over two separate sessions, allowing clients with certain bandwidth limitations to receive just the base layer for decoding as illustrated in Figure 2.
マルチセッションストリーミングでは、ベース層とエンハンスメント層は、図2に示すように、特定の帯域幅制限のあるクライアントは、復号化のためだけのベース層を受信することができ、二つの別個のセッションを介して送信されます。
In this case, it is REQUIRED to determine which sessions are paired together in receiver side. For paired base and enhancement layer sessions, the CNAME bindings in the RTP Control Protocol (RTCP) session MUST be applied using the same CNAME to ensure correct mapping to the RTP source.
この場合、受信機側で一緒にペアリングされているセッションを決定する必要があります。一対のベース及びエンハンスメントレイヤセッションのために、RTP制御プロトコル（RTCP）セッションにおけるCNAMEバインディングは、RTPソースへの正しいマッピングを保証するために、同じCNAMEを使用して適用されなければなりません。
While there may be alternative methods for synchronization of the layers, the timestamp SHOULD be used for synchronizing the base layer with its enhancement. The two sessions MUST be synchronized using the information in RTCP SR packets to align the RTP timestamps.
層の同期のための別の方法があるかもしれないが、タイムスタンプは、その拡張を有するベースレイヤを同期させるために使用されるべきです。二つのセッションは、RTPタイムスタンプを整列させるためにRTCP SRパケットの情報を使用して同期されなければなりません。
If the enhancement layer's session data cannot arrive until the presentation time, the decoder MUST decode the base layer session's data only, ignoring the enhancement layer's data.
エンハンスメントレイヤのセッション・データは、プレゼンテーション時まで到着できない場合、デコーダは、エンハンスメントレイヤのデータを無視して、唯一のベースレイヤセッションのデータを復号しなければなりません。
Session 1:
+------+ +------+ +------+ +------+
| Base |--| Base |--| Base |--| Base | ...
+------+ +------+ +------+ +------+
N N+1 N+2 N+3 : Packet
Session 2:
+-------------+ +-------------+ +-------------+
| Enhancement |--| Enhancement |--| Enhancement | ...
+-------------+ +-------------+ +-------------+
N N+1 N+2 : Packet
Figure 2. Multi-Session Streaming
図2.マルチセッションストリーミング
The structure of ATRAC Payload is illustrated in Figure 3. The RTP payload following the RTP header contains two octet-aligned data sections.
ATRACペイロードの構造は、図3にRTPヘッダに続くRTPペイロードを示した2つのオクテット整列データセクションを含んでいます。
+------+--------------+-----------------------------+
|RTP | ATRAC Header | ATRAC Frames Section |
|Header| Section | (including redundant data) |
+------+--------------+-----------------------------+
< ---------------- RTP Packet Payload ------------- >
Figure 3. Structure of RTP Payload of ATRAC Family
ATRACファミリーのRTPペイロードの図3の構造
The first data section is the ATRAC Header, containing just one header with information for the whole packet. The second section is where the encoded ATRAC frames are stored. This may contain either a single fragment of one ATRAC frame or one or more complete ATRAC frames. The ATRAC Frames Section MUST NOT be empty. When using the redundancy mechanism described in Section 5.3.2.1, the redundant frame data can be included in this section and timestamp MUST be set to the oldest redundant frame's timestamp.
最初のデータ・セクションは、パケット全体の情報が一つだけのヘッダーを含む、ATRACヘッダです。第2のセクションは、符号化されたATRACフレームが格納される場所です。これは、1つのATRACフレームまたは1つ以上の完全なATRACフレームの単一フラグメントのいずれかを含んでいてもよいです。 ATRACフレームセクションは空にすることはできません。セクション5.3.2.1に記載の冗長メカニズムを使用する場合、冗長フレームのデータは、このセクションに含めることができ、タイムスタンプが最も古い冗長フレームのタイムスタンプに設定しなければなりません。
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.
ATRACの高速転送モードの可逆符号化能力の恩恵を受けるために、RTPペイロードは、1つの必須のベース層と他の送信拡張データを送信すると、二つのセッションに分割することができます。しかし、いずれの場合も、上記の構造が適用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. RTP Standard Header Part
図4. RTP標準ヘッダパート
The structure of the RTP Standard Header Part is illustrated in Figure 4.
RTP標準ヘッダ部の構成は、図4に示されています。
Version(V): 2 bits Set to 2.
バージョン（V）：2に設定して2ビット。
Padding(P): 1 bit If the padding bit is set, the packet contains one or more additional padding octets at the end, which are not part of the payload. The last octet of the padding contains a count of how many padding octets should be ignored, including itself. Padding may be needed by some encryption algorithms with fixed block sizes or for carrying several RTP packets in a lower-layer protocol data unit (see [1]).
パディング（P）：パディングビットがセットされる1ビットの場合、パケットは、ペイロードに含まれていない端部に1つの以上の追加のパディングオクテットを含んでいます。パディングの最後のオクテットは、オクテットは自身を含め、無視されるべきであるどのように多くのパディングの数が含まれています。パディングは、（[1]参照）が固定されたブロックサイズの、または下位層プロトコル・データ・ユニットにいくつかのRTPパケットを運ぶための、いくつかの暗号化アルゴリズムによって必要とされるかもしれません。
Extension(X): 1 bit Defined by the RTP profile used.
拡張（X）：使用されるRTPプロファイルで定義され、1ビット。
CSRC count(CC): 4 bits See RFC 3550 [1].
CSRCカウント（CC）：4ビットは、RFC 3550 [1]を参照してください。
Marker (M): 1 bit Set to 1 if the packet is the first packet after a silence period; otherwise, it MUST be set to 0.
マーカー（M）：パケットが無音期間の後の最初のパケットである場合、1ビットを1に設定します。それ以外の場合は、0に設定しなければなりません。
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 the Session Description Protocol (SDP)).
ペイロードタイプ（PT）：このパケットフォーマットのためのRTPペイロードタイプの7ビット割り当ては、この文書の範囲外です。なお、このペイロードフォーマットが使用される、または動的にシグナリングされる下RTPプロファイルで指定されたアウトオブバンド（例えば、セッション記述プロトコル（SDP）を使用して）。
sequence number: 16 bits A sequential number for the RTP packet. It ranges from 0 to 65535 and repeats itself periodically.
配列番号：16ビットRTPパケットのシーケンス番号。これは、0から65535の範囲であり、定期的に繰り返されます。
Timestamp: 32 bits A timestamp representing the sampling time of the first sample of the first ATRAC frame in the current RTP packet. When using SDP, the clock rate of the RTP timestamp MUST be expressed using the "rtpmap" attribute. For ATRAC3 and ATRAC Advanced Lossless, the RTP timestamp rate MUST be 44100 Hz. For ATRAC-X, the RTP timestamp rate is 44100 Hz or 48000 Hz, and it will be selected by out-of-band signaling.
タイムスタンプ：32ビットの現在のRTPパケット内の最初のATRACフレームの最初のサンプルのサンプリング時間を表すタイムスタンプ。 SDPを使用する場合、RTPタイムスタンプのクロック速度は、「rtpmap」属性を使用して表現されなければなりません。 ATRAC3とATRAC高度なロスレスの場合、RTPタイムスタンプレートは44100 Hzでなければなりません。 ATRAC-Xのために、RTPタイムスタンプレートは44100ヘルツ又は48000ヘルツであり、そしてそれは、帯域外シグナリングによって選択されるであろう。
SSRC: 32 bits See RFC 3550 [1].
SSRC：32ビットRFC 3550 [1]を参照してください。
CSRC list: 0 to 15 items, 32 bits each See RFC 3550 [1].
CSRCリスト：0〜15項目、32ビット各参照RFC 3550 [1]。
The ATRAC header section has the fixed length of one byte as illustrated in Figure 5.
図5に示すように、ATRACヘッダ部は、1バイトの固定長を有します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|FrgNo|NFrames|
+-+-+-+-+-+-+-+-+
Figure 5. ATRAC RTP Header
図5. ATRAC RTPヘッダー
Continuation Flag (C) : 1 bit The packet that corresponds to the last part of the audio frame data in a fragmentation MUST have this bit set to 0; otherwise, it's set to 1.
継続フラグ（C）：1ビット断片のオーディオフレームデータの最後の部分に対応するパケットはこのビットを0に設定しなければなりません。それ以外の場合は1に設定されています。
Fragment Number (FrgNo): 3 bits In the event of data fragmentation, this value is one for the first packet, and increases sequentially for the remaining fragmented data packets. This value MUST be zero for an unfragmented frame. (Note: 3 bits is sufficient to avoid Fragment Number rollover given the current maximum supported bit-rate in the ATRAC specification. If that changes, the choice of 3 bits for the Fragment Number should be revisited.)
フラグメント番号（FrgNo）：データ断片化の場合には3ビットが、この値は、最初のパケットのための1つであり、残りの断片化されたデータパケットの順番を増加させます。この値は、断片化されていないフレームについてゼロでなければなりません。 （注：3ビットはATRAC仕様で現在サポートされる最大ビットレート所定のフラグメント番号のロールオーバを回避するのに十分であるが、変更された場合、フラグメント番号の3ビットの選択を再検討すべきです。）。
Number of Frames (NFrames): 4 bits The number of audio frames in this packet are field value + 1. This allows for a maximum of 16 ATRAC-encoded audio frames per packet, with 0 indicating one audio frame. Each audio frame MUST be complete in the packet if fragmentation is not applied. In the case of fragmentation, the data for only one audio frame is allowed to be fragmented, and this value MUST be 0.
フレーム数（NFRAMES）：このパケット内の4ビットの音声フレームの数は、これは、1つのオーディオフレームを示す0のパケット当たり16 ATRAC符号化音声フレームの最大を可能にするフィールド値+ 1です。断片化が適用されない場合は、各オーディオフレームは、パケット内に完了していなければなりません。断片化の場合には、唯一のオーディオフレームのデータが断片化することが許可され、この値は0でなければなりません。
The ATRAC Frames Section contains an integer number of complete ATRAC frames or a single fragment of one ATRAC frame, as illustrated in Figure 6. Each ATRAC frame is preceded 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 in order of their frame number. This section MUST NOT be empty.
各ATRACフレームはサイズを示す層種類及びブロック長のフィールドを示す1ビットのフラグによって先行され、図6に示すように、ATRACフレームセクションは、完全ATRACフレームまたは1つのATRACフレームの単一断片の整数を含んでいますATRACフレームのバイトインチ複数のATRACフレームが存在する場合、フレームは、そのフレーム番号の順にビットフラグ、ブロック長、及びATRACフレームの連続した文字列に連結されています。このセクションでは、空にすることはできません。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Block Length | ATRAC frame |...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. ATRAC Frame Section Format
図6. ATRAC枠部のフォーマット
Layer Type Flag (E): 1 bit Set to 1 if the corresponding ATRAC frame is from an enhancement layer. 0 indicates a base layer encoded frame.
層種別フラグ（E）：対応するATRACフレームがエンハンスメントレイヤからのものである場合、1ビットを1に設定します。 0は、ベース層符号化されたフレームを示しています。
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.
ブロック長：15ビットの次のフレームのための符号化オーディオデータのバイト長。唯一の後続パケットを受信した場合、断片化の場合には、復号が依然として発生することができるようです。 15ビットは32,767バイトの最大ブロック長を可能にします。
ATRAC frame: The encoded ATRAC audio data.
ATRACフレーム：エンコードされたATRACオーディオデータ。
This payload format provides a rudimentary scheme to compensate for occasional packet loss. As every packet's timestamp corresponds to the first audio frame regardless of whether or not it is redundant, 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 warns it to expand its buffer size if necessary. As an example of using the Redundant Data, refer to Figures 7 and 8.
このペイロード形式は時折パケットの損失を補償するための基本的な仕組みを提供します。すべてのパケットのタイムスタンプにかかわらず、それは冗長である、と私たちは各パケットがカプセル化するどのように多くのフレームオーディオの知っているので、二つの連続するパケットが正常に送信されている場合は、私たちが送信される冗長フレームの数を計算することができるかどうかの最初のオーディオフレームに対応したよう。その結果はクライアントにサーバがレポートをRTCPに応答しているかの感覚を与え、必要に応じてそのバッファサイズを拡大することを警告しています。冗長データを使用する例として、図7及び図8を参照します。
In this example, the server has determined that for the next few 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 (of which the client may choose to dispose). 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.
この例では、サーバーは、次のいくつかのパケットのために、それは近年のRTCPレポートに以前のパケットから最後の2つのフレームを送る必要があると判断しました。このように、パケットNおよびN + 1の間に、（クライアントが配置することを選択することができるの）二つのフレームの冗長性があります。パケットN + 2及びN + 3は、最終的にパケットN + 4は、連続する必要オーディオフレームデータと到着した後、全く到着しない場合。利益が生じます
[Sender]
[送信者]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0 |-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024 |-Fr2-|-Fr3-|-Fr4-| Packet: N+2, TS=2048 |-Fr3-|-Fr4-|-Fr5-| Packet: N+3, TS=3072 |-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
| -Fr0- | -Fr1- | -Fr2- |パケット：N、TS = 0 | -Fr1- | -Fr2- | -Fr3- |パケット：N + 1、TS = 1024 | -Fr2- | -Fr3- | -Fr4- |パケット：N + 2、TS = 2048 | -Fr3- | -Fr4- | -Fr5- |パケット：N + 3、TS = 3072 | -Fr4- | -Fr5- | -Fr6- |パケット：N + 4、TS = 4096
-----------> Packet "N+2" and "N+3" not arrived ------------->
[Receiver]
[受信機]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0 |-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024 |-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
| -Fr0- | -Fr1- | -Fr2- |パケット：N、TS = 0 | -Fr1- | -Fr2- | -Fr3- |パケット：N + 1、TS = 1024 | -Fr4- | -Fr5- | -Fr6- |パケット：N + 4、TS = 4096
The receiver can decode from FR4 to Fr6 by using Packet "N+4" data even if the packet loss of "N+2" and "N+3" has occurred.
受信機は、「N + 2」、「N + 3」のパケットロスが発生した場合でも、パケット「N + 4」のデータを用いて、FR4からFR6に復号することができます。
Figure 7. Redundant Example
図7.冗長例
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (= start sample time of Fr1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 3 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) ATRAC frame (Fr1) data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) ATRAC frame (Fr2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | ATRAC frame (Fr3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Packet Structure Example with Redundant Data
(Case of Packet "N+1")
Each RTP packet MUST 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 MUST be fragmented.
各RTPパケットは、または1つのATRACフレーム断片（16の最大値を有する）ATRAC符号化音声フレームの整数のいずれかを含まなければなりません。前者の場合には、できるだけ多くの完全なATRACフレームはRTPパケットに配置する必要が単一パスMTUに収まります。 1つでもATRACフレームは、完全なRTPパケットに収まらない場合は、ATRACフレームが断片化されなければなりません。
The start of a fragmented frame gets placed in its own RTP packet with its Continuation 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 Continuation bit (C) consistently set to one. As subsequent packets do not contain any new frames, the Number of Frames field MUST be ignored. The last packet of fragmented data MUST have the Continuation bit (C) set to zero.
断片化されたフレームの開始が1に設定された連続ビット（C）を用いて、自身のRTPパケットに配置されます、そしてそのフラグメント番号（FragNo）が1に設定されます。フレームは、パケット内の唯一でなければならないように、フレームのフィールドの数はゼロです。後続のパケットは、常にいずれかに設定フラグメント数増加順次連続ビット（C）と、残りの断片化されたフレームデータを含むことがあります。後続のパケットは、任意の新しいフレームが含まれていないとして、フレームのフィールドの数を無視しなければなりません。断片化されたデータの最後のパケットは連続ビット（C）がゼロに設定されなければなりません。
Packets containing related fragmented frames MUST have identical timestamps. Thus, while the Continuous bit and Fragment Number fields indicate fragmentation and a means to reorder the packets, the timestamp can be used to determine which packets go together.
関連断片化フレームを含むパケットは、同一のタイムスタンプを持たなければなりません。連続したビット及びフラグメント番号フィールドはフラグメンテーションとパケットの順序を変更する手段を示しつつ、タイムスタンプは、パケットが一緒に行くかを決定するために使用することができます。
Multiple encoded audio frames are combined into one packet. Note how, for this example, only base layer frames are sent redundantly, but are followed by interleaved base layer and enhancement layer frames as illustrated in Figure 9.
複数の符号化オーディオフレームは1つのパケットに結合されます。この例では、唯一の基本レイヤフレームが冗長送信されるが、図9に示すようにインターリーブベースレイヤとエンハンスメントレイヤフレームが続く方法を、注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 5 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) base layer frame 1 data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) base layer frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Example Multi-Frame Packet
図9の例のマルチフレームパケット
The encoded audio data frame is split over three RTP packets as illustrated in Figure 10. The following points are highlighted in the example below:
以下の点は、以下の例で強調表示され、図10に示すように符号化オーディオデータフレームは、三個のRTPパケットに分割されます。
o transition from one to zero of the Continuation bit (C)
継続ビットの1から0への遷移O（C）
o sequential increase in the Fragment Number
フラグメント数のOシーケンシャル増加
Packet 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 1 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 2 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...more enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 3 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...the last of the enhancement data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Example Fragmented ATRAC Frame
図10の例断片ATRACフレーム
Certain parameters will need to be defined before ATRAC-family-encoded content can be streamed. Other optional parameters may also be defined to take advantage of specific features relevant to certain ATRAC versions. Parameters for ATRAC3, ATRAC-X, and ATRAC Advanced Lossless are defined here as part of the media subtype registration process. A mapping of these parameters into the Session Description Protocol (SDP) (RFC 4566) [2] is also provided for applications that utilize SDP. These registrations use the template defined in RFC 4288 [5] and follow RFC 4855 [6].
ATRAC-家族でエンコードされたコンテンツをストリーミングすることができる前に、特定のパラメータを定義する必要があります。他のオプションのパラメータは、特定のATRACのバージョンに関連する特定の機能を活用するために定義されてもよいです。 ATRAC3、ATRAC-X、およびATRAC高度なロスレスのパラメータは、メディアサブタイプの登録プロセスの一部としてここで定義されています。セッション記述プロトコル（SDP）（RFC 4566）にこれらのパラメータのマッピングは、[2]また、SDPを利用するアプリケーションのために設けられています。これらの登録は、RFC 4288 [5]で定義されたテンプレートを使用して、RFC 4855に従う[6]。
The data format and parameters are specified for real-time transport in RTP.
データ形式とパラメータは、RTPにおけるリアルタイムの輸送用に指定されています。
The media subtype for the Adaptive TRansform Codec version 3 (ATRAC3) uses the template defined in RFC 4855 [6].
適応のためのメディアサブタイプは、コーデックバージョン3（ATRAC3）を形質転換RFC 4855で定義されたテンプレートを使用する[6]。
Note, any unknown parameter MUST be ignored by the receiver.
注、任意の未知パラメータは、受信機で無視しなければなりません。
Type name: audio
型名：オーディオ
Subtype name: ATRAC3
サブタイプ名：ATRAC3
Required parameters:
必須パラメータ：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only.
速度：元のオーディオデータのHzでのサンプリング周波数を示します。許容値は44100です。
baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 66, 105, and 132.
ベースレイヤー：ストリーミングされる音声データのkbps単位で符号化されたビットレートを示します。許容値は66、105、および132です。
Optional parameters:
オプションのパラメータ：
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. The frame length of ATRAC3 is 1024/44100 = 23.22...(ms), and fractional value may not be applicable for the SDP definition.
maxptime：RFC 4566 [2]を参照してください。 ATRAC3のフレーム長が44100分の1024 = 23.22 ...（MS）であり、端数値は、SDPの定義に適用可能でないかもしれません。
So the value of the parameter MUST be a multiple of 24 (ms) considering safe transmission.
そうパラメータの値は、安全な伝送を考慮24（ミリ秒）の倍数でなければなりません。
If this parameter is not present, the sender MAY encapsulate a maximum of 6 encoded frames into one RTP packet, in streaming of ATRAC3.
このパラメータが存在しない場合、送信者は、ATRAC3のストリーミングでは、1つのRTPパケットに6つの符号化フレームの最大値をカプセル化することができます。
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 document. 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.
maxRedundantFrames：文書に詳述冗長フレーミング機構の下で任意のパケットのセッション中に送信することができる冗長フレームの最大数。使用できる値は0以上15以下の範囲の整数です。このパラメータが使用されていない場合は、15のデフォルトが想定されなければなりません。
Encoding considerations: This media type is framed and contains binary data.
エンコードの考慮事項：このメディアタイプは、フレームとバイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティの考慮事項：このメディアタイプは、アクティブコンテンツを実行しません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: ATRAC3 Standard Specification [9]
公開された仕様：ATRAC3標準仕様[9]
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
追加情報：なしマジックナンバー（S）：なしファイルの拡張子（S）： 'AT3'、 'AA3'、および 'OMG' Macintoshファイルタイプコード（S）：なし
Person and email address to contact for further information: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
Personと詳細のために連絡する電子メールアドレス：光行畑中松本潤actech@jp.sony.com
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用上の制限：このメディアタイプは、RTPを介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
あうてょｒ： みつゆき はたなか じゅん まつもと あｃてｃｈ＠ｊｐ。そｎｙ。こｍ
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
The media subtype for the Adaptive TRansform Codec version X (ATRAC-X) uses the template defined in RFC 4855 [6].
適応のためのメディアサブタイプは、コーデックバージョンX（ATRAC-X）を形質転換RFC 4855で定義されたテンプレートを使用する[6]。
Note, any unknown parameter MUST be ignored by the receiver.
注、任意の未知パラメータは、受信機で無視しなければなりません。
Type name: audio
型名：オーディオ
Subtype name: ATRAC-X
サブタイプ名：ATRAC-X
Required parameters:
必須パラメータ：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible values are 44100 and 48000.
速度：元のオーディオデータのHzでのサンプリング周波数を示します。許容値は44100と48000です。
baseLayer: Indicates the encoded bit-rate in kbps for the audio data to be streamed. Permissible values are 32, 48, 64, 96, 128, 160, 192, 256, 320, and 352.
ベースレイヤー：ストリーミングされる音声データのkbps単位で符号化されたビットレートを示します。許容値は32、48、64、96、128、160、192、256、320、および352です。
channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7.
channelID：セクション7.4でTABLE1に係るチャネルの数およびチャネルのレイアウトを示します。このレイアウトは、RFC 3551で提案されたものとは異なることに注意してください[3]。しかし、channelIDよう= 0は、曖昧チャネルレイアウト、[3]に使用することができるのセクション4.1で定義されたチャネルマッピングを定義します。許容値は、0、1、2、3、4、5、6、7です。
Optional parameters:
オプションのパラメータ：
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. The frame length of ATRAC-X is 2048/44100 = 46.44...(ms) or 2048/48000 = 42.67...(ms), but fractional value may not be applicable for the SDP definition. So the value of the parameter MUST be a multiple of 47 (ms) or 43 (ms) considering safe transmission.
maxptime：RFC 4566 [2]を参照してください。 ATRAC-Xのフレーム長が44100分の2048 = 46.44 ...（MS）又は48000分の2048 = 42.67 ...（MS）であるが、端数値は、SDPの定義に適用可能でないかもしれません。そうパラメータの値は、安全な伝送を考慮47（MS）または43（ミリ秒）の倍数でなければなりません。
If this parameter is not present, the sender MAY encapsulate a maximum of 16 encoded frames into one RTP packet, in streaming of ATRAC-X.
このパラメータが存在しない場合、送信者は、ATRAC-Xのストリーミングでは、1つのRTPパケットに16の符号化フレームの最大値をカプセル化することができます。
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 document. Allowed values are integers in the range 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed.
maxRedundantFrames：文書に詳述冗長フレーミング機構の下で任意のパケットのセッション中に送信することができる冗長フレームの最大数。可能な値は、包括範囲0から15、の整数です。このパラメータが使用されていない場合は、15のデフォルトが想定されなければなりません。
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.
delayModeは：デコーダはそれに応じて、この値に基づいて、受信したデータを処理するその場合に低遅延機能を使用したい旨を示します。許容値は、2及び4です。
Encoding considerations: This media type is framed and contains binary data.
エンコードの考慮事項：このメディアタイプは、フレームとバイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティの考慮事項：このメディアタイプは、アクティブコンテンツを実行しません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: ATRAC-X Standard Specification [10]
公開された仕様：ATRAC-Xの標準仕様[10]
Applications that use this media type: Audio and video streaming and conferencing tools.
オーディオとビデオストリーミングと会議ツール：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Magic number(s): none File extension(s): 'atx', 'aa3', and 'omg' Macintosh file type code(s): none
マジックナンバー（S）：なしファイルの拡張子（S）： 'ATX'、 'AA3'、および 'OMG' Macintoshファイルタイプコード（S）：なし
Person and email address to contact for further information: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
Personと詳細のために連絡する電子メールアドレス：光行畑中松本潤actech@jp.sony.com
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用上の制限：このメディアタイプは、RTPを介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
あうてょｒ： みつゆき はたなか じゅん まつもと あｃてｃｈ＠ｊｐ。そｎｙ。こｍ
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
The media subtype for the Adaptive TRansform Codec Lossless version (ATRAC Advanced Lossless) uses the template defined in RFC 4855 [6].
適応変換コーデック可逆バージョン（ATRAC高度ロスレス）のメディアサブタイプは、RFC 4855で定義されたテンプレート[6]を使用します。
Note, any unknown parameter MUST be ignored by the receiver.
注、任意の未知パラメータは、受信機で無視しなければなりません。
Type name: audio
型名：オーディオ
Subtype name: ATRAC-ADVANCED-LOSSLESS
サブタイプ名：ATRAC-ADVANCEDロスレス
Required parameters:
必須パラメータ：
rate: Represents the sampling frequency in Hz of the original audio data. Permissible value is 44100 only for High-Speed Transfer mode. Any value of 24000, 32000, 44100, 48000, 64000, 88200, 96000, 176400, and 192000 can be used for Standard mode.
速度：元のオーディオデータのHzでのサンプリング周波数を示します。許容値は、唯一の高速転送モードの44100です。 24000、32000、44100、48000、64000、88200、96000、176400、および192000の任意の値は、標準モードのために使用することができます。
baseLayer: Indicates the encoded bit-rate in kbps for the base layer in High-Speed Transfer mode lossless encodings.
ベースレイヤー：高速転送モードのロスレス符号化におけるベース層のためのkbps単位で符号化されたビットレートを示します。
For Standard lossless mode, this value MUST be 0.
標準可逆モードの場合、この値は0でなければなりません。
The Permissible values for ATRAC3 baselayer are 66, 105, and 132. For ATRAC-X baselayer, they are 32, 48, 64, 96, 128, 160, 192, 256, 320, and 352.
ATRAC3のベースレイヤーの許容値は、ATRAC-Xのベースレイヤー66、105、および132であり、それらは32、48、64、96、128、160、192、256、320、および352です。
blockLength: Indicates the block length. In High-Speed Transfer mode, the value of 1024 and 2048 is used for ATRAC3 based and ATRAC-X based ATRAC Advanced Lossless streaming, respectively.
ブロック長：ブロック長を示します。高速転送モードでは、1024年と2048年の値は、それぞれ、ATRAC3に基づくとATRAC-XベースのATRAC高度なロスレス・ストリーミングのために使用されています。
Any value of 512, 1024, and 2048 can be used for Standard mode.
512、1024、2048の任意の値は、標準モードのために使用することができます。
channelID: Indicates the number of channels and channel layout according to the table1 in Section 7.4. Note that this layout is different from that proposed in RFC 3551 [3]. However, as channelID = 0 defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used in this case. Permissible values are 0, 1, 2, 3, 4, 5, 6, 7.
channelID：セクション7.4でTABLE1に係るチャネルの数およびチャネルのレイアウトを示します。このレイアウトは、RFC 3551で提案されたものとは異なることに注意してください[3]。しかし、channelIDよう= 0は、曖昧チャネルレイアウトのセクション4.1で定義されたチャネルマッピング[3]この場合に使用することができる定義します。許容値は、0、1、2、3、4、5、6、7です。
ptime: See RFC 4566 [2].
PTIME：RFC 4566 [2]を参照してください。
maxptime: See RFC 4566 [2]. In streaming of ATRAC Advanced Lossless, multiple frames cannot be transmitted in a single RTP packet, as the frame size is large. So it SHOULD be regarded as the time of one encoded frame in both of the sender and the receiver side. The frame length of ATRAC Advanced Lossless is 512/44100 = 11.6...(ms), 1024/44100 = 23.22...(ms), or 2048/44100 = 46.44...(ms), but fractional value may not be applicable for the SDP definition. So the value of the parameter MUST be 12(ms), 24(ms), or 47(ms) considering safe transmission.
maxptime：RFC 4566 [2]を参照してください。 ATRAC高度ロスレスのストリーミングでは、複数のフレームは、フレームサイズが大きくなるように、単一のRTPパケットで送信することができません。それは、送信側と受信側の両方で1つの符号化フレームの時間とみなされるべきです。 ATRAC高度ロスレスのフレーム長が44100分の512 = 11.6 ...（MS）、44100分の1024 = 23.22 ...（MS）、又は= 46.44 44100分の2048 ...（MS）であるが、分数値ではないかもしれませんSDPの定義に適用できます。そうパラメータの値は、安全な伝送を考慮12（MS）、24（MS）、または47（MS）でなければなりません。
Encoding considerations: This media type is framed and contains binary data.
エンコードの考慮事項：このメディアタイプは、フレームとバイナリデータが含まれています。
Security considerations: This media type does not carry active content. See Section 9 of this document.
セキュリティの考慮事項：このメディアタイプは、アクティブコンテンツを実行しません。このドキュメントのセクション9を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: ATRAC Advanced Lossless Standard Specification [11]
公開された仕様：ATRAC高度なロスレス標準仕様[11]
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
マジックナンバー（S）：なしファイルの拡張子（S）： 'AAL'、 'AA3'、および 'OMG' Macintoshファイルタイプコード（S）：なし
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
みつゆき はたなか じゅん まつもと あｃてｃｈ＠ｊｐ。そｎｙ。こｍ
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP.
使用上の制限：このメディアタイプは、RTPを介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。
Author: Mitsuyuki Hatanaka Jun Matsumoto actech@jp.sony.com
あうてょｒ： みつゆき はたなか じゅん まつもと あｃてｃｈ＠ｊｐ。そｎｙ。こｍ
Change controller: IETF AVT WG delegated from the IESG
変更コントローラ：IETF AVT WG IESGから委任
Table 1 explains the mapping between the channelID as passed during SDP negotiations, and the speaker mapping the value represents.
SDP交渉中に渡される表1は、channelIDとの間のマッピングを説明し、その値をマッピングスピーカを表します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channelID | Number of | Default Speaker |
| | Channels | Mapping |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | max 64 | undefined |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | front: left, right |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | front: left, right |
| | | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 | front: left, right |
| | | front: center |
| | | rear: surround |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 6+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | rear: center |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 7+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | side: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1. Channel Configuration
表1.チャネル構成
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.
メディアタイプの仕様で搬送される情報は、[2]、一般にRTPセッションを記述するために使用されるセッション記述プロトコル（SDP）内のフィールドに特定のマッピングを有します。 SDPは、次のマッピング規則は、コーデックが適用ATRACによれば、コーデックのATRACファミリーを用いたセッションを指定するために使用されます。
o The Media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
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 (0 or 1) MUST also be specified in this attribute.
O（ペイロードフォーマット名）メディアサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。 ATRAC3ので、対応するチャネルの数（0または1）は、この属性で指定する必要があり、唯一のモノまたはステレオ信号をサポートします。
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 "基層" パラメータは、SDPの "a =のfmtp" になります。このパラメータが存在しなければなりません。 「maxRedundantFrames」が続くことができるが、値が送信されない場合、受信機は、「15」のデフォルト値をとるべきです。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
o The Media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
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（ペイロードフォーマット名）メディアサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。これは、（RTPクロックレートなど）「は、sampleRate」が続くされるべきであり、その後、チャネルの実際の数にかかわらずchannelIDパラメータ。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
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. The "channelID" parameter MUST be the next entry. The receiver MUST assume a default value of "15" for "maxRedundantFrames".
O任意の残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプ文字列から直接コピーすることにより、SDPの「a =のfmtp」属性に行きます。 「基層」パラメータは、この行の最初のエントリでなければなりません。 「channelID」パラメータは次のエントリでなければなりません。受信機は、「maxRedundantFrames」の「15」のデフォルト値を仮定しなければなりません。
o The Media type ("audio") goes in SDP "m=" as the media name.
Oメディアタイプ（「オーディオ」）は、メディア名としてSDP「m =」に進みます。
o The Media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. This MUST be followed by the "sampleRate" (as the RTP clock rate), and then the actual number of channels regardless of the channelID parameter.
O（ペイロードフォーマット名）メディアサブタイプは、符号化名としてSDPの「a = rtpmap」に進みます。これは、（RTPクロックレートなど）「は、sampleRate」が続く必要があり、その後、チャネルの実際の数にかかわらずchannelIDパラメータ。
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
Oパラメータの "PTIME" と "maxptime" は、それぞれ、 "A = PTIME" と "A = maxptimeは" 属性SDPに行きます。
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.
O任意の残りのパラメータは、パラメータ=値のペアをセミコロンで区切ったリストで、メディアタイプ文字列から直接コピーすることにより、SDPの「a =のfmtp」属性に行きます。
On this line, the parameters "baseLayer" and "blockLength" MUST be present in this order.
この行では、パラメータ「ベース層」および「ブロック長」とは、この順番に存在しなければなりません。
The value of "blockLength" MUST be one of 1024 and 2048, for using ATRAC3 and ATRAC-X as baselayer, respectively. If "baseLayer=0" (means standard mode), "blockLength" MUST be one of either 512, 1024, or 2048. The "channelID" parameter MUST be the next entry . The receiver MUST assume a default value of "15" for "maxRedundantFrames".
「ブロック長」の値は、それぞれ、ベース層としてATRAC3とATRAC-Xを使用するための1024 2048のいずれかでなければなりません。 「= 0ベースレイヤーは、」（標準モードを意味する）場合、「ブロック長は」512 1024、または2048のいずれか一方「channelID」パラメータでなければなりません、次のエントリでなければなりません。受信機は、「maxRedundantFrames」の「15」のデフォルト値を仮定しなければなりません。
Some options for encoding and decoding ATRAC audio data will require either or both of the sender and receiver complying with certain specifications. In order to establish an interoperable transmission framework, an Offer/Answer negotiation in SDP MUST observe the following considerations. (See [14].)
エンコードとデコードATRACオーディオデータのためのいくつかのオプションは、特定の仕様に準拠送信者と受信者のいずれかまたは両方が必要になります。相互運用可能な伝送フレームワークを確立するためには、SDPでオファー/回答ネゴシエーションは、以下の注意事項を遵守しなければなりません。 （[14]参照）。
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 44100 kHz, more than two channels), the offerer SHOULD 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.
O RTPペイロードのトランスポートフォーマット設定パラメータ（ベース層及びブロック長、は、sampleRate、channelID）の各組合せは、そのビットパターンで一意と任意の他の組み合わせと互換性がありません。より高度な機能（44100 kHz以上のサンプル・レート、二つ以上のチャネル）を使用することを望むアプリケーションにオファーを作成する場合、提供者はまた、必要な要件のみ最小セットを含むペイロードタイプを提供すべきです。複数の構成がアプリケーションに関心がある場合、それらはすべて提供されることがあります。
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 RFC 3264. The "maxptime" parameter MUST be handled in the same way.
Oパラメータの「maxptime」と「PTIMEは、」ほとんどの場合、相互運用性には影響しません。しかし、パラメータの設定は、アプリケーションのパフォーマンスに影響を与えることができます。 「PTIME」パラメータのSDPオファー/アンサー処理は「maxptime」パラメータが同様に処理されなければならないRFC 3264に記載されています。
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.
Oの申し出を受けて、「ベース層」のサブセットをダウングレードも可能です。しかし、最高のパフォーマンスを得るために、我々は、提供可能な限り最高の値が含まれている答えを示唆しています。
o In response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For best performance, an answer MUST NOT contain any values requiring further capabilities than the offer contains, but it SHOULD provide values as close as possible to those in the offer.
Oオファーに応答して、「は、sampleRate」、「ベース層」のサブセットをダウングレード、および「channelID」可能です。最高のパフォーマンスを実現するために、オファーが含まれているよりも、答えはさらに能力を必要とする任意の値を含めることはできませんが、それは申し出のものにできるだけ近い値を提供する必要があります。
o The "maxRedundantFrames" is a suggested minimum. This value MAY be increased in an answer (with a maximum of 15), but MUST NOT be reduced.
「maxRedundantFrames」O示唆した最小値です。この値は、（15の最大で）答えに増加させることができるが、減少してはなりません。
o The optional parameter "delayMode" is non-negotiable. If the Answerer cannot comply with the offered value, the session MUST be deemed inoperable.
Oオプションのパラメータ「delayModeは」譲渡禁止です。回答が提供された値に準拠することができない場合、セッションは動作不能とみなされなければなりません。
o In response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For best performance, an answer MUST NOT contain any values requiring further capabilities than the offer contains, but it SHOULD provide values as close as possible to those in the offer.
Oオファーに応答して、「は、sampleRate」、「ベース層」のサブセットをダウングレード、および「channelID」可能です。最高のパフォーマンスを実現するために、オファーが含まれているよりも、答えはさらに能力を必要とする任意の値を含めることはできませんが、それは申し出のものにできるだけ近い値を提供する必要があります。
o There are no requirements when negotiating "blockLength", other than that both parties must be in agreement.
「ブロック長」を交渉するときO何ら要件は両当事者が合意でなければならないこと以外、ありません。
o The "maxRedundantFrames" is a suggested minimum. This value MAY be increased in an answer (with a maximum of 15), but MUST NOT be reduced.
「maxRedundantFrames」O示唆した最小値です。この値は、（15の最大で）答えに増加させることができるが、減少してはなりません。
o For transmission of scalable multi-session streaming of ATRAC Advanced Lossless content, the attributes of media stream identification, group information, and decoding dependency between base layer stream and enhancement layer stream MUST be signaled in SDP by the Offer/Answer model. In this case, the attribute of
O ATRAC高度ロスレスコンテンツのスケーラブルなマルチセッションストリーミングの伝送のために、メディアストリーム識別、グループ情報、及びベースレイヤストリームとエンハンスメントレイヤストリーム間の復号化依存性の属性は、オファー/アンサーモデルによってSDPでシグナリングされなければなりません。この場合には、属性
"group", "mid", and "depend" followed by the appropriate parameter MUST be used in SDP [7] [8] in order to indicate layered coding dependency. The attribute of "group" followed by "DDP" parameter is used for indicating the relationship between the base and the enhancement layer stream with decoding dependency. Each stream is identified by "mid" attribute, and the dependency of enhancement layer stream is defined by the "depend" attribute, as the enhancement layer is only useful when the base layer is available. Examples for signaling ATRAC Advanced Lossless decoding dependency are described in Sections 7.8 and 7.9.
階層化符号化依存性を示すために、「グループ」、「中」、および適切なパラメータが続く、「依存」SDPで使用されなければならない[7] [8]。 「DDP」パラメータが続く、「グループ」の属性が復号依存性ベース及びエンハンスメントレイヤストリームとの関係を示すために使用されます。各ストリームは、「中間」属性によって識別され、エンハンスメントレイヤがベースレイヤが利用可能である場合にのみ有用であるとしてエンハンスメントレイヤストリームの依存性は、「依存」属性によって定義されます。 ATRAC高度可逆復号化依存性シグナリングの例はセクション7.8および7.9に記載されています。
In declarative usage, like SDP in Real-Time Streaming Protocol (RTSP) [15] or Session Announcement Protocol (SAP) [16], the parameters MUST be interpreted as follows:
次のように宣言用法では、リアルタイムストリーミングプロトコル（RTSP）[15]またはセッションアナウンスメントプロトコル（SAP）におけるSDP [16]のように、パラメータは解釈されなければなりません。
o The payload format configuration parameters (baseLayer, sampleRate, channelID) are all declarative and a participant MUST use the configuration(s) 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ペイロードフォーマット設定パラメータ（ベース層、は、sampleRate、channelID）は、すべての宣言され、参加者は、セッションのために設けられた構成（複数可）を使用しなければなりません。以上の構成は、複数のRTPペイロードタイプを宣言することで、必要に応じて提供されてもよいです。しかし、種類の数が小さく保たれるべきです。
o Any "maxptime" and "ptime" values SHOULD be selected with care to ensure that the session's participants can achieve reasonable performance.
O任意の「maxptime」と「PTIME」の値は、セッションの参加者が合理的な性能を達成できることを保証するために注意して選択する必要があります。
o The attribute of "mid", "group", and "depend" MUST be used for indicating the relationship and dependency of the base layer and the enhancement layer in scalable multi-session streaming of ATRAC ADVANCED LOSSLESS content, as described in Sections 7.6, 7.8, and 7.9.
「中」、「グループ」の属性O、およびセクション7.6に記載したように、ATRAC ADVANCEDロスレスコンテンツのスケーラブルなマルチセッションストリーミングにおけるベースレイヤとエンハンスメントレイヤの関係と依存性を示すために使用しなければなりません「依存」 、7.8、および7.9。
Example usage of ATRAC-X with stereo at 44100 Hz:
44100 HzでステレオとATRAC-Xの使用例：
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=ATRAC-X Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 m=audio 49120 RTP/AVP 99 a=rtpmap:99 ATRAC-X/44100/2 a=fmtp:99 baseLayer=128; channelID=2; delayMode=2 a=maxptime:47
V = 0 0 = ATRAC IP4のservice.example.com S = ATRAC-XストリーミングC IN 2465317890 2465317890 = IP4 IN 192.0.2.1/127 T = 3409539540 3409543140メートル=オーディオ49120 RTP / AVP 99 = rtpmap：99 ATRAC-X / 2分の44100 A =のfmtp：99ベースレイヤー= 128。 channelID = 2。 delayMode = 2、A = maxptime：47
Example usage of ATRAC-X with 5.1 setup at 48000 Hz:
48000 Hzで5.1セットアップとATRAC-Xの使用例：
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=ATRAC-X 5.1ch Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 m=audio 49120 RTP/AVP 99 a=rtpmap:99 ATRAC-X/48000/6 a=fmtp:99 baseLayer=320; channelID=5 a=maxptime:43
V = 0 0 = ATRAC 2465317890 2465317890 IN IP4 service.example.com S = ATRAC-X 5.1chのストリーミングC = IP4 IN 192.0.2.1/127 T = 3409539540 3409543140メートル=オーディオ49120 RTP / AVP 99 = rtpmap：99 ATRAC -X / 6分の48000 A =のfmtp：99ベースレイヤー= 320。 channelID = 5 A = maxptime：43
Example usage of ATRAC-Advanced-Lossless in multiplexed High-Speed Transfer mode:
多重高速転送モードでATRAC-アドバンスト・ロスレスの使用例：
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=AAL Multiplexed Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 m=audio 49200 RTP/AVP 96 a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2 a=maxptime:47
V = 0 0 = ATRAC 2465317890 2465317890 IN IP4 service.example.com S = AAL多重ストリーミングC = IP4 IN 192.0.2.1/127 T = 3409539540 3409543140メートル=オーディオ49200 RTP / AVP 96 = rtpmap：96 ATRAC、詳細設定ロスレス/ 2分の44100 =のfmtp：96ベースレイヤー= 128。ブロック長= 2048; channelID = 2、A = maxptime：47
Example usage of ATRAC-Advanced-Lossless in multi-session High-Speed Transfer mode. In this case, the base layer and the enhancement layer stream are identified by L1 and L2, respectively, and L2 depends on L1 in decoding.
マルチセッション高速転送モードでATRAC-アドバンスト・ロスレスの使用例。この場合、ベース層とエンハンスメントレイヤストリームは、それぞれ、L1およびL2によって識別され、そしてL2は、復号にL1に依存します。
v=0 o=atrac 2465317890 2465317890 IN IP4 service.example.com s=AAL Multi Session Streaming c=IN IP4 192.0.2.1/127 t=3409539540 3409543140 a=group:DDP L1 L2 m=audio 49200 RTP/AVP 96 a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2 a=maxptime:47 a=mid:L1 m=audio 49202 RTP/AVP 97 a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2 a=maxptime:47 a=mid:L2 a=depend:97 lay L1:96
V = 0 0 = ATRAC 2465317890 2465317890 IN IP4 service.example.com S = AALマルチセッションストリーミングC = IP4 IN 192.0.2.1/127 T = 3409539540 3409543140 A =基：DDP L1 L2のM =オーディオ49200 RTP / AVP 96 = rtpmap：96 ATRAC-ADVANCEDロスレス/ 2分の44100 =のfmtp：96ベースレイヤー= 128。ブロック長= 2048; channelID = 2、A = maxptime：47 =ミッド：L1のM =オーディオ49202 RTP / AVP 97 = rtpmap：97 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：97ベースレイヤー= 0。ブロック長= 2048; channelID = 2、A = maxptime：47 =ミッド：L2のA =は依存：97は、L1を築く：96
Example usage of ATRAC-Advanced-Lossless in Standard mode:
標準モードでのATRAC-アドバンスト・ロスレスの使用例：
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:24
M =オーディオ49200 RTP / AVP 99 = rtpmap：99 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：99ベースレイヤー= 0。ブロック長= 1024; channelID = 2、A = maxptime：24
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/2 a=fmtp:99 baseLayer=160; channelID=2
M =オーディオ49170 RTP / AVP 98 99 = rtpmap：98 ATRAC-X / 6分の44100 =のfmtp：98ベースレイヤー= 320。 channelID = 5 A = rtpmap：99 ATRAC-X / 2分の44100 =のfmtp：99ベースレイヤー= 160。 channelID = 2
Answer:
回答：
m=audio 49170 RTP/AVP 99 a=rtpmap:99 ATRAC-X/44100/2 a=fmtp:99 baseLayer=160; channelID=2
M =オーディオ49170 RTP / AVP 99 = rtpmap：99 ATRAC-X / 2分の44100 =のfmtp：99ベースレイヤー= 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
M =オーディオ49170 RTP / AVP 97 98 99 = rtpmap：97 ATRAC-X / 2分の44100 =のfmtp：97ベースレイヤー= 128。 channelID = 2、A = rtpmap：98 ATRAC-X / 6分の44100 =のfmtp：98ベースレイヤー= 128。 channelID = 5 A = rtpmap：99 ATRAC-X / 6分の48000 =のfmtp：99ベースレイヤー= 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
M =オーディオ49170 RTP / AVP 97 98 = rtpmap：97 ATRAC-X / 2分の44100 =のfmtp：97ベースレイヤー= 128。 channelID = 2、A = rtpmap：98 ATRAC-X / 6分の44100 =のfmtp：98ベースレイヤー= 128。 channelID = 5
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.
以下のオファー/例回答はATRAC-アドバンスト・ロスレスを使用して解決しようとするで交換を示します。マルチセッション高速転送モード、多重高速転送モード、標準モード：オファーは3つのオプションが含まれています。
Offer:
提供：
// Multi-session High-Speed Transfer mode, L1 and L2 correspond to the base layer and the enhancement layer, respectively, and L2 depends on L1 in decoding.
//マルチセッション高速転送モード、L1およびL2は、それぞれ、ベース・レイヤとエンハンスメント・レイヤに対応し、L2は、復号にL1に依存します。
a=group:DDP L1 L2 m=audio 49200 RTP/AVP 96 a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:96 baseLayer=132; blockLength=1024; channelID=2 a=maxptime:24 a=mid:L1
A =グループ：DDP L1 L2 M =オーディオ49200 RTP / AVP 96 = rtpmap：96 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：96ベースレイヤー= 132。ブロック長= 1024; channelID = 2、A = maxptime：24 =中旬：L1
m=audio 49202 RTP/AVP 97 a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2 a=maxptime:24 a=mid:L2 a=depend:97 lay L1:96
M =オーディオ49202 RTP / AVP 97 = rtpmap：97 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：97ベースレイヤー= 0。ブロック長= 2048; channelID = 2、A = maxptime：24 =ミッド：L2のA =は依存：97は、L1を築く：96
// Multiplexed High-Speed Transfer mode m=audio 49200 RTP/AVP 98 a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2 a=maxptime:47
//多重高速転送モードm =オーディオ49200 RTP / AVP 98 = rtpmap：98 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：98ベースレイヤー= 256。ブロック長= 2048; channelID = 2、A = maxptime：47
// Standard mode m=audio 49200 RTP/AVP 99 a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:99 baseLayer=0; blockLength=2048; channelID=2 a=maxptime:47
//標準モードm =オーディオ49200 RTP / AVP 99 = rtpmap：99 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：99ベースレイヤー= 0。ブロック長= 2048; channelID = 2、A = maxptime：47
Answer:
回答：
a=group:DDP L1 L2 m=audio 49200 RTP/AVP 94 a=rtpmap:94 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:94 baseLayer=132; blockLength=1024; channelID=2 a=maxptime:24 a=mid:L1 m=audio 49202 RTP/AVP 95 a=rtpmap:95 ATRAC-ADVANCED-LOSSLESS/44100/2 a=fmtp:95 baseLayer=0; blockLength=2048; channelID=2 a=maxptime:24 a=mid:L2 a=depend:95 lay L1:94
A =グループ：DDP L1 L2 M =オーディオ49200 RTP / AVP 94 = rtpmap：94 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：94ベースレイヤー= 132。ブロック長= 1024; channelID = 2、A = maxptime：24 =ミッド：L1のM =オーディオ49202 RTP / AVP 95 = rtpmap：95 ATRAC-ADVANCEDロスレス/ 2分の44100 A =のfmtp：95ベースレイヤー= 0。ブロック長= 2048; channelID = 2、A = maxptime：24 =ミッド：L2のA =は依存：95は、L1を築く：94
Note that the names of payload format (encoding) and Media subtypes 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.
ペイロード形式（符号化）及びメディアサブタイプの名前は大文字と小文字を区別しない両方の場所であることに留意されたいです。同様に、パラメータ名はメディアタイプにし、SDPのA =のfmtp属性にデフォルトのマッピングの両方で大文字と小文字を区別しません。
Three new Media subtypes, audio/ATRAC3, audio/ATRAC-X, and audio/ATRAC-ADVANCED-LOSSLESS, have been registered (see Section 7).
三つの新しいメディアサブタイプ、オーディオ/ ATRAC3、オーディオ/ ATRAC-X、およびオーディオ/ ATRAC-ADVANCED-ロスレス、登録されている（セクション7を参照）。
The payload format as described in this document is subject to the security considerations defined in RFC 3550 [1] and any applicable profile, for example, RFC 3551 [3]. Also, the security of Media type registration MUST be taken into account as described in Section 5 of RFC 4855 [6].
この文書に記載されているように、ペイロード・フォーマットは、RFC 3550で定義されたセキュリティ上の考慮の対象となる[1]および該当するプロファイル、例えば、RFC 3551 [3]。 RFC 4855のセクション5に記載されているように、また、メディアタイプ登録のセキュリティを考慮しなければならない[6]。
The payload for ATRAC family consists solely of compressed audio data to be decoded and presented as sound, and the standard specifications of ATRAC3, ATRAC-X, and ATRAC Advanced Lossless [9] [10] [11] strictly define the bit stream syntax and the buffer model in decoder side for each codec. So they can not carry "active content" that could impose malicious side effects upon the receiver, and they do not cause any problem of illegal resource consumption in receiver side, as far as the bit streams are conforming to their standard specifications.
ATRACファミリーが音としてデコードおよび提示される圧縮オーディオデータ、及びATRAC3、ATRAC-X、およびATRAC高度ロスレスの標準仕様のみで構成するためのペイロード[9] [10] [11]は、厳密にビットストリーム構文を定義し各コーデックのデコーダ側のバッファモデル。そこで彼らは、受信時に悪質な副作用を課す可能性があり、「アクティブコンテンツ」を運ぶことができない、と彼らは限りビットストリームは、その標準仕様に準拠しているように、受信機側で違法なリソース消費のいずれかの問題が発生することはありません。
This payload format does not implement any security mechanisms of its own. Confidentiality, integrity protection, and authentication have to be provided by a mechanism external to this payload format, e.g., SRTP RFC 3711 [13].
このペイロード形式は、独自のセキュリティメカニズムを実装していません。機密性、完全性保護、及び認証がSRTPのRFC 3711 [13]、例えば、このペイロードフォーマットに外部機構によって提供されなければなりません。
Verification of the received encoded audio packets MUST be performed so as to ensure correct decoding of the packets. As a most primitive implementation, the comparison of the packet size and payload length can be taken into account. If the UDP packet length is longer than the RTP packet length, the packet can be accepted, but the extra bytes MUST be ignored. In case of receiving a shorter UDP packet or improperly encoded packets, the packets MUST be discarded.
パケットの正しい復号を保証するように、受信した符号化オーディオパケットの検証が行われなければなりません。最も原始的な実装として、パケットサイズとペイロード長の比較を考慮することができます。 UDPパケット長がRTPパケットの長さを超える場合、パケットは受け入れられるが、余分なバイトは無視しなければなりません。短いUDPパケットまたは不適切に符号化されたパケットを受信した場合、パケットは廃棄されなければなりません。
Also, validity checking of the received audio packets MUST be performed. It can be carried out by the decoding process, as the ATRAC format is designed so that the validity of data frames can be determined by decoding the algorithm. The required decoder response to a malformed frame is to discard the malformed data and conceal the errors in the audio output until a valid frame is detected and decoded. This is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks.
また、受信した音声パケットの妥当性検査を実行しなければなりません。データフレームの有効性は、アルゴリズムを復号化することによって決定することができるように、ATRACフォーマットが設計されているように、それは、復号処理により行うことができます。不正な形式のフレームに必要なデコーダ応答が不正な形式のデータを廃棄し、有効なフレームが検出され、デコードされるまで、オーディオ出力のエラーを隠蔽することです。これは、エラーや攻撃に応答して、クラッシュやその他の異常なデコーダの動作を防止することが期待されます。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[3] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[5]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[6] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[6]、RFC 4855、2007年2月Casner、S.、 "RTPペイロード形式のメディアタイプ登録を"。
[7] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[7]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月します。
[8] Schierl, T., and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[8] Schierl、T.、およびS.ウェンガー、 "セッション記述プロトコルにおけるシグナリングメディアのデコード依存（SDP）"、RFC 5583、2009年7月。
[9] ATRAC3 Standard Specification ver.1.1, Sony Corporation, 2003.
[9] ATRAC3標準仕様Ver.1.1の、ソニー株式会社、2003年。
[10] ATRAC-X Standard Specification ver.1.2, Sony Corporation, 2004.
[10] ATRAC-Xの標準仕様ver.1.2、ソニー株式会社、2004。
[11] ATRAC Advanced Lossless Standard Specification ver.1.1, Sony Corporation, 2007.
[11] ATRAC高度なロスレス標準仕様Ver.1.1に、ソニー株式会社、2007。
[12] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[12]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[14]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[16] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[16]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
Authors' Addresses
著者のアドレス
Mitsuyuki Hatanaka Sony Corporation, Japan 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
みつゆき はたなか そｎｙ こｒぽらちおん、 じゃぱん １ー７ー１ こなん みなとーく ときょ １０８ー００７５ じゃぱん
EMail: actech@jp.sony.com
メールアドレス：actech@jp.sony.com
Jun Matsumoto Sony Corporation, Japan 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
じゅん まつもと そｎｙ こｒぽらちおん、 じゃぱん １ー７ー１ こなん みなとーく ときょ １０８ー００７５ じゃぱん
EMail: actech@jp.sony.com
メールアドレス：actech@jp.sony.com