[要約] RFC 5215は、VorbisエンコードされたオーディオのRTPペイロード形式に関する仕様です。このRFCの目的は、VorbisオーディオをRTPパケットに効率的にエンコードするための標準化を提供することです。
Network Working Group L. Barbato
Request for Comments: 5215 Xiph
Category: Standards Track August 2008
RTP Payload Format for Vorbis Encoded Audio
Vorbisエンコードオーディオ用の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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
このドキュメントでは、Vorbisエンコードされたオーディオを輸送するためのRTPペイロード形式について説明します。これは、生のボルビスデータのRTPカプセル化メカニズムと、デコーダー確率モデル（コードブックと呼ばれる）の配信メカニズム、およびその他のセットアップ情報を詳述しています。
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP).
また、このメモには、メディアタイプの登録と、セッション説明プロトコル（SDP）でVorbisを使用するために必要な詳細が含まれています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conformance and Document Conventions . . . . . . . . . . . 3
2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8
3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9
3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10
3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12
3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12
3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13
4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13
5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14
5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15
5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19
7. SDP Related Considerations . . . . . . . . . . . . . . . . . . 20
7.1. Mapping Media Type Parameters into SDP . . . . . . . . . . 20
7.1.1. SDP Example . . . . . . . . . . . . . . . . . . . . . 21
7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 22
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Vorbis is a general purpose perceptual audio codec intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bit rates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as MPEG-4 AAC. Vorbis is also intended for lower and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
Vorbisは、最大のエンコーダーの柔軟性を可能にすることを目的とした汎用知覚オーディオコーデックであり、非常に幅広いビットレートにわたって競合的にスケーリングできるようにします。スケールの高品質/ビットレート端（CDまたはDATレートステレオ、16/24ビット）では、MPEG-4 AACと同じリーグにあります。Vorbisは、より低いサンプルレート（8kHzテレフォニーから192kHzデジタルマスターまで）およびさまざまなチャネル表現（モナル、ポリフォニック、ステレオ、クアドラフォン、5.1、アンビゾニック、または最大255個の離散チャネル）を対象としています。
Vorbis encoded audio is generally encapsulated within an Ogg format bitstream [RFC3533], which provides framing and synchronization. For the purposes of RTP transport, this layer is unnecessary, and so raw Vorbis packets are used in the payload.
Vorbisエンコードされたオーディオは、一般にOGG形式のBitStream [RFC3533]内にカプセル化されており、フレーミングと同期を提供します。RTPトランスポートの目的で、このレイヤーは不要であるため、ペイロードで生のVorbisパケットが使用されます。
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 BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、[RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。特に明記しない限り、要件はすべての実装に適用されます。
An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type.
実装は、このドキュメントで定義されているメディアタイプの1つをサポートするソフトウェアモジュールです。ソフトウェアモジュールは複数のメディアタイプをサポートする場合がありますが、各タイプの適合性は個別に考慮されます。
Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant".
1つまたは複数の「マスト」要件を満たさない実装は、非準拠と見なされます。すべての「必須」の要件を満たすが、1つ以上の「要件は「要件」が必要である必要がある」と言われる実装は、「条件付きで準拠している」と言われています。他のすべての実装は「無条件に準拠」です。
For RTP-based transport of Vorbis-encoded audio, the standard RTP header is followed by a 4-octet payload header, and then the payload data. The payload headers are used to associate the Vorbis data with its associated decoding codebooks as well as indicate if the following packet contains fragmented Vorbis data and/or the number of whole Vorbis data frames. The payload data contains the raw Vorbis bitstream information. There are 3 types of Vorbis data; an RTP payload MUST contain just one of them at a time.
VorbisエンコードオーディオのRTPベースのトランスポートの場合、標準のRTPヘッダーの後に4オクテットペイロードヘッダーが続き、次にペイロードデータが続きます。ペイロードヘッダーは、Vorbisデータを関連するデコードコードブックに関連付けるために使用され、次のパケットに断片化されたVorbisデータおよび/またはVorbisデータフレーム全体の数が含まれているかどうかを示します。ペイロードデータには、生のVorbisビットストリーム情報が含まれています。Vorbisデータには3種類があります。RTPペイロードには、一度にそのうちの1つだけが含まれている必要があります。
The format of the RTP header is specified in [RFC3550] and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は[RFC3550]で指定され、図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 1: RTP Header
図1：RTPヘッダー
The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see [RFC3550] and [RFC3551] for details). For Vorbis RTP, the following values are used.
RTPヘッダーは、詳細については、特殊なRTPの使用をサポートするために、フィールドのオクテット（V、P、X、およびCC）から始まります。Vorbis RTPの場合、次の値が使用されます。
Version (V): 2 bits
バージョン（v）：2ビット
This field identifies the version of RTP. The version used by this specification is two (2).
このフィールドは、RTPのバージョンを識別します。この仕様で使用されるバージョンは2つです。
Padding (P): 1 bit
パディング（P）：1ビット
Padding MAY be used with this payload format according to Section 5.1 of [RFC3550].
[RFC3550]のセクション5.1に従って、このペイロード形式でパディングを使用できます。
Extension (X): 1 bit
拡張（x）：1ビット
The Extension bit is used in accordance with [RFC3550].
拡張ビットは[RFC3550]に従って使用されます。
CSRC count (CC): 4 bits
CSRCカウント（CC）：4ビット
The CSRC count is used in accordance with [RFC3550].
CSRCカウントは[RFC3550]に従って使用されます。
Marker (M): 1 bit
マーカー（M）：1ビット
Set to zero. Audio silence suppression is not used. This conforms to Section 4.1 of [VORBIS-SPEC-REF].
ゼロに設定します。オーディオサイレンスの抑制は使用されません。これは、[Vorbis-Spec-Ref]のセクション4.1に準拠しています。
Payload Type (PT): 7 bits
ペイロードタイプ（PT）：7ビット
An RTP profile for a class of applications is expected to assign a payload type for this format, or a dynamically allocated payload type SHOULD be chosen that designates the payload as Vorbis.
アプリケーションのクラスのRTPプロファイルは、この形式にペイロードタイプを割り当てることが期待されます。または、ペイロードをVorbisとして指定する動的に割り当てられたペイロードタイプを選択する必要があります。
Sequence number: 16 bits
シーケンス番号：16ビット
The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore the packet sequence. This field is detailed further in [RFC3550].
送信されたRTPデータパケットごとにシーケンス番号の増分が1つずつ、受信機がパケットの損失を検出し、パケットシーケンスを復元するために使用できます。このフィールドは、[RFC3550]でさらに詳細に説明されています。
Timestamp: 32 bits
タイムスタンプ：32ビット
A timestamp representing the sampling time of the first sample of the first Vorbis packet in the RTP payload. The clock frequency MUST be set to the sample rate of the encoded audio data and is conveyed out-of-band (e.g., as an SDP parameter).
RTPペイロードの最初のVorbisパケットの最初のサンプルのサンプリング時間を表すタイムスタンプ。クロック周波数は、エンコードされたオーディオデータのサンプルレートに設定し、帯域外（例えば、SDPパラメーターとして）を伝達する必要があります。
SSRC/CSRC identifiers:
SSRC/CSRC識別子：
These two fields, 32 bits each with one SSRC field and a maximum of 16 CSRC fields, are as defined in [RFC3550].
これらの2つのフィールド、それぞれ1つのSSRCフィールドと最大16のCSRCフィールドを備えた32ビットは、[RFC3550]で定義されています。
The 4 octets following the RTP Header section are the Payload Header. This header is split into a number of bit fields detailing the format of the following payload data packets.
RTPヘッダーセクションに続く4オクテットは、ペイロードヘッダーです。このヘッダーは、次のペイロードデータパケットの形式を詳述する多くのビットフィールドに分割されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | F |VDT|# pkts.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Payload Header
図2：ペイロードヘッダー
Ident: 24 bits
識別：24ビット
This 24-bit field is used to associate the Vorbis data to a decoding Configuration. It is stored as a network byte order integer.
この24ビットフィールドは、Vorbisデータをデコード構成に関連付けるために使用されます。ネットワークバイトオーダー整数として保存されます。
Fragment type (F): 2 bits This field is set according to the following list:
フラグメントタイプ（f）：2ビットこのフィールドは、次のリストに従って設定されています。
0 = Not Fragmented
1 = Start Fragment
2 = Continuation Fragment
3 = End Fragment
Vorbis Data Type (VDT): 2 bits
Vorbisデータ型（VDT）：2ビット
This field specifies the kind of Vorbis data stored in this RTP packet. There are currently three different types of Vorbis payloads. Each packet MUST contain only a single type of Vorbis packet (e.g., you must not aggregate configuration and comment packets in the same RTP payload).
このフィールドは、このRTPパケットに保存されているVorbisデータの種類を指定します。現在、Vorbisペイロードには3つの異なるタイプがあります。各パケットには、単一のタイプのVorbisパケットのみが含まれている必要があります（たとえば、同じRTPペイロードで構成とコメントパケットを集約しないでください）。
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
2 = Legacy Vorbis Comment payload
3 = Reserved
The packets with a VDT of value 3 MUST be ignored.
値3のVDTを持つパケットは無視する必要があります。
The last 4 bits represent the number of complete packets in this payload. This provides for a maximum number of 15 Vorbis packets in the payload. If the payload contains fragmented data, the number of packets MUST be set to 0.
最後の4ビットは、このペイロード内の完全なパケットの数を表します。これにより、ペイロード内の最大数のVorbisパケットが提供されます。ペイロードに断片化データが含まれている場合、パケットの数は0に設定する必要があります。
Raw Vorbis packets are currently unbounded in length; application profiles will likely define a practical limit. Typical Vorbis packet sizes range from very small (2-3 bytes) to quite large (8-12 kilobytes). The reference implementation [LIBVORBIS] typically produces packets less than ~800 bytes, except for the setup header packets, which are ~4-12 kilobytes. Within an RTP context, to avoid fragmentation, the Vorbis data packet size SHOULD be kept sufficiently small so that after adding the RTP and payload headers, the complete RTP packet is smaller than the path MTU.
生のボルビスパケットは現在、長さが束縛されていません。アプリケーションプロファイルは、実用的な制限を定義する可能性があります。典型的なVorbisパケットサイズは、非常に小さな（2〜3バイト）から非常に大きな（8〜12キロバイト）までの範囲です。参照実装[libvorbis]は通常、〜4〜12キロバイトのセットアップヘッダーパケットを除き、約800バイト未満のパケットを生成します。RTPコンテキスト内で、フラグメンテーションを回避するために、Vorbisデータパケットサイズを十分に小さく保ち、RTPとペイロードヘッダーを追加した後、完全なRTPパケットがPATH MTUよりも小さくなるようにします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Payload Data Header
図3：ペイロードデータヘッダー
Each Vorbis payload packet starts with a two octet length header, which is used to represent the size in bytes of the following data payload, and is followed by the raw Vorbis data padded to the nearest byte boundary, as explained by the Vorbis I Specification [VORBIS-SPEC-REF]. The length value is stored as a network byte order integer.
各Vorbisペイロードパケットは、次のデータペイロードのバイトのサイズを表すために使用される2オクテットの長さのヘッダーで始まり、Vorbis Iの仕様で説明されているように、最も近いバイト境界にパッドが付けられた生のVorbisデータが続きます[Vorbis-spec-ref]。長さの値は、ネットワークバイトオーダー整数として保存されます。
For payloads that consist of multiple Vorbis packets, the payload data consists of the packet length followed by the packet data for each of the Vorbis packets in the payload.
複数のVorbisパケットで構成されるペイロードの場合、ペイロードデータはパケットの長さで構成され、その後にペイロード内のVorbisパケットの各パケットデータが続きます。
The Vorbis packet length header is the length of the Vorbis data block only and does not include the length field.
Vorbisパケット長ヘッダーは、Vorbisデータブロックのみの長さであり、長さフィールドは含まれていません。
The payload packing of the Vorbis data packets MUST follow the guidelines set out in [RFC3551], where the oldest Vorbis packet occurs immediately after the RTP packet header. Subsequent Vorbis packets, if any, MUST follow in temporal order.
Vorbisデータパケットのペイロードパッキングは、RTPパケットヘッダーの直後に最古のVorbisパケットが発生する[RFC3551]に記載されているガイドラインに従う必要があります。後続のVorbisパケットは、ある場合は、時間的に従う必要があります。
Audio channel mapping is in accordance with the Vorbis I Specification [VORBIS-SPEC-REF].
オーディオチャネルマッピングは、Vorbis I Specification [Vorbis-spec-ref]に従っています。
Here is an example RTP payload containing two Vorbis packets.
2つのVorbisパケットを含むRTPペイロードの例を次に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0|0| 0 |0| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (in sample rate units) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronisation source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | next vorbis packet data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example Raw Vorbis Packet
図4：Raw Vorbisパケットの例
The payload data section of the RTP packet begins with the 24-bit Ident field followed by the one octet bit field header, which has the number of Vorbis frames set to 2. Each of the Vorbis data frames is prefixed by the two octets length field. The Packet Type and Fragment Type are set to 0. The Configuration that will be used to decode the packets is the one indexed by the ident value.
RTPパケットのペイロードデータセクションは、24ビットの識別フィールドから始まり、その後に1 Octetビットフィールドヘッダーが続きます。これには、Vorbisフレームの数が2に設定されています。各Vorbisデータフレームには、2オクテットの長さフィールドが付いています。。パケットタイプとフラグメントタイプは0に設定されています。パケットのデコードに使用される構成は、識別値によってインデックス付けされたものです。
Unlike other mainstream audio codecs, Vorbis has no statically configured probability model. Instead, it packs all entropy decoding configuration, Vector Quantization and Huffman models into a data block that must be transmitted to the decoder with the compressed data. A decoder also requires information detailing the number of audio channels, bitrates, and similar information to configure itself for a particular compressed data stream. These two blocks of information are often referred to collectively as the "codebooks" for a Vorbis stream, and are included as special "header" packets at the start of the compressed data. In addition, the Vorbis I specification [VORBIS-SPEC-REF] requires the presence of a comment header packet that gives simple metadata about the stream, but this information is not required for decoding the frame sequence.
他の主流のオーディオコーデックとは異なり、Vorbisには静的に構成された確率モデルがありません。代わりに、すべてのエントロピーデコード構成、ベクトル量子化、およびハフマンモデルを、圧縮データを使用してデコーダーに送信する必要があるデータブロックに詰めます。また、デコーダーには、特定の圧縮データストリームに合わせて自らを構成するために、オーディオチャネル、ビットレート、および同様の情報の数を詳述する情報も必要です。これらの2つのブロックのブロックは、多くの場合、Vorbisストリームの「コードブック」と総称され、圧縮データの開始時に特別な「ヘッダー」パケットとして含まれています。さらに、Vorbis I Specification [Vorbis-Spec-Ref]には、ストリームに関する単純なメタデータを提供するコメントヘッダーパケットの存在が必要ですが、この情報はフレームシーケンスのデコードには必要ありません。
Thus, these two codebook header packets must be received by the decoder before any audio data can be interpreted. These requirements pose problems in RTP, which is often used over unreliable transports.
したがって、これらの2つのコードブックヘッダーパケットは、オーディオデータを解釈する前に、デコーダーによって受信する必要があります。これらの要件は、信頼できない輸送でよく使用されるRTPに問題を引き起こします。
Since this information must be transmitted reliably and, as the RTP stream may change certain configuration data mid-session, there are different methods for delivering this configuration data to a client, both in-band and out-of-band, which are detailed below. In order to set up an initial state for the client application, the configuration MUST be conveyed via the signalling channel used to set up the session. One example of such signalling is SDP [RFC4566] with the Offer/Answer Model [RFC3264]. Changes to the configuration MAY be communicated via a re-invite, conveying a new SDP, or sent in-band in the RTP channel. Implementations MUST support an in-band delivery of updated codebooks, and SHOULD support out-of-band codebook update using a new SDP file. The changes may be due to different codebooks as well as different bitrates of the RTP stream.
この情報は確実に送信する必要があり、RTPストリームが特定の構成データの途中で変更される可能性があるため、この構成データをインバンドとバンド外の両方のクライアントに配信するためのさまざまな方法があります。。クライアントアプリケーションの初期状態を設定するには、セッションのセットアップに使用される信号チャネルを介して構成を伝達する必要があります。このようなシグナル伝達の1つの例は、オファー/回答モデル[RFC3264]を使用したSDP [RFC4566]です。構成の変更は、REインバイト、新しいSDPの伝達、またはRTPチャネルでインバンドを送信して通信する場合があります。実装は、更新されたコードブックの帯域内配信をサポートする必要があり、新しいSDPファイルを使用してバンド外のコードブックの更新をサポートする必要があります。変更は、RTPストリームのさまざまなビットレートと同様に、異なるコードブックによるものである可能性があります。
For non-chained streams, the recommended Configuration delivery method is inside the Packed Configuration (Section 3.1.1) in the SDP as explained the Mapping Media Type Parameters into SDP (Section 7.1).
非チェーンストリームの場合、推奨される構成配信方法は、SDPのマッピングメディア型パラメーター（セクション7.1）へのマッピングメディアタイプパラメーターを説明したように、SDPの詰められた構成（セクション3.1.1）内にあります。
The 24-bit Ident field is used to map which Configuration will be used to decode a packet. When the Ident field changes, it indicates that a change in the stream has taken place. The client application MUST have in advance the correct configuration. If the client detects a change in the Ident value and does not have this information, it MUST NOT decode the raw associated Vorbis data until it fetches the correct Configuration.
24ビットの識別フィールドは、パケットのデコードに使用する構成をマッピングするために使用されます。識別フィールドが変化すると、ストリームの変化が起こったことを示します。クライアントアプリケーションには、事前に正しい構成が必要です。クライアントが識別値の変更を検出し、この情報がない場合、正しい構成を取得するまで、生の関連するVorbisデータをデコードしてはなりません。
The Packed Configuration (Section 3.1.1) Payload is sent in-band with the packet type bits set to match the Vorbis Data Type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission of [RFC4588] the configuration headers. The RTP timestamp value MUST reflect the transmission time of the first data packet for which this configuration applies.
パックされた構成（セクション3.1.1）ペイロードは、Vorbisデータ型に一致するように設定されたパケットタイプビットでバンド内で送信されます。クライアントは、[RFC4588]構成ヘッダーの断片化と定期的な再送信に対処できる必要があります。RTPタイムスタンプ値は、この構成が適用される最初のデータパケットの送信時間を反映する必要があります。
A Vorbis Packed Configuration is indicated with the Vorbis Data Type field set to 1. Of the three headers defined in the Vorbis I specification [VORBIS-SPEC-REF], the Identification and the Setup MUST be packed as they are, while the Comment header MAY be replaced with a dummy one.
Vorbis Packed構成は、Vorbis I Specification [Vorbis-spec-ref]で定義されている3つのヘッダーのうち1に設定されたVorbisデータ型フィールドで示されます。ダミーのものに置き換えることができます。
The packed configuration stores Xiph codec configurations in a generic way: the first field stores the number of the following packets minus one (count field), the next ones represent the size of the headers (length fields), and the headers immediately follow the list of length fields. The size of the last header is implicit.
梱包された構成はxiphコーデック構成を一般的な方法で保存します：最初のフィールドは次のパケットの数を1つ（カウントフィールド）から保存し、次のパケットはヘッダーのサイズ（長さフィールド）を表し、ヘッダーはすぐにリストに従います。長さのフィールドの。最後のヘッダーのサイズは暗黙的です。
The count and the length fields are encoded using the following logic: the data is in network byte order; every byte has the most significant bit used as a flag, and the following 7 bits are used to store the value. The first 7 most significant bits are stored in the first byte. If there are remaining bits, the flag bit is set to 1 and the subsequent 7 bits are stored in the following byte. If there are remaining bits, set the flag to 1 and the same procedure is repeated. The ending byte has the flag bit set to 0. To decode, simply iterate over the bytes until the flag bit is set to 0. For every byte, the data is added to the accumulated value multiplied by 128.
カウントフィールドと長さフィールドは、次のロジックを使用してエンコードされます。データはネットワークバイトの順序です。すべてのバイトにはフラグとして使用される最も重要なビットがあり、次の7ビットを使用して値を保存します。最初の7つの最も重要なビットは、最初のバイトに保存されます。残りのビットがある場合、フラグビットは1に設定され、その後の7ビットは次のバイトに保存されます。残りのビットがある場合は、フラグを1に設定し、同じ手順が繰り返されます。エンディングバイトのフラグビットは0に設定されています。デコードするために、フラグビットが0に設定されるまでバイトを繰り返します。バイトごとに、データは蓄積された値に128を掛けます。
The headers are packed in the same order as they are present in Ogg [VORBIS-SPEC-REF]: Identification, Comment, Setup.
ヘッダーは、ogg [Vorbis-spec-ref]に存在するのと同じ順序で梱包されています：識別、コメント、セットアップ。
The 2 byte length tag defines the length of the packed headers as the sum of the Configuration, Comment, and Setup lengths.
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 | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | n. of headers | length1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length2 | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Identification | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment | Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packed Configuration Figure
図5：パックされた構成図
The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 because the packet bears the full Packed configuration. The number of the packet is set to 1.
識別フィールドは、この構成に対処するために生のペイロードパケットによって使用される値で設定されます。パケットには完全な構成が付いているため、フラグメントタイプは0に設定されています。パケットの数は1に設定されています。
The following packet definition MUST be used when Configuration is inside in the SDP.
構成がSDPの内部にある場合、次のパケット定義を使用する必要があります。
As mentioned above, the RECOMMENDED delivery vector for Vorbis configuration data is via a retrieval method that can be performed using a reliable transport protocol. As the RTP headers are not required for this method of delivery, the structure of the configuration data is slightly different. The packed header starts with a 32-bit (network-byte ordered) count field, which details the number of packed headers that are contained in the bundle. The following shows the Packed header payload for each chained Vorbis stream.
上記のように、Vorbis構成データに推奨される配信ベクトルは、信頼できる輸送プロトコルを使用して実行できる検索方法を介して行われます。この配信方法にはRTPヘッダーは必要ないため、構成データの構造はわずかに異なります。パックされたヘッダーは、32ビット（ネットワークバイトの順序付け）カウントフィールドから始まります。これは、バンドルに含まれるパックヘッダーの数を詳しく説明します。以下は、各チェーンボルビスストリームのパックヘッダーペイロードを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packed headers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packed header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packed Headers Overview
図6：パックヘッダーの概要
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | length ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | n. of headers | length1 | length2 ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Identification Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. | Comment Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Header ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................................................................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Setup Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Packed Headers Detail
図7：パックヘッダーの詳細
The key difference between the in-band format and this one is that there is no need for the payload header octet. In this figure, the comment has a size bigger than 127 bytes.
インバンド形式とこれの主な違いは、ペイロードヘッダーオクテットが必要ないことです。この図では、コメントのサイズは127バイトよりも大きくなっています。
Unlike the loss of raw Vorbis payload data, loss of a configuration header leads to a situation where it will not be possible to successfully decode the stream. Implementations MAY try to recover from an error by requesting again the missing Configuration or, if the delivery method is in-band, by buffering the payloads waiting for the Configuration needed to decode them. The baseline reaction SHOULD either be reset or end the RTP session.
生のVorbisペイロードデータの損失とは異なり、構成ヘッダーの損失は、ストリームを正常にデコードすることができない状況につながります。実装は、不足している構成を再度要求することにより、または配信方法がバンド内の場合、それらをデコードするのに必要な構成を待っているペイロードをバッファリングすることにより、エラーから回復しようとする場合があります。ベースライン反応は、RTPセッションをリセットまたは終了する必要があります。
Vorbis Data Type flag set to 2 indicates that the packet contains the comment metadata, such as artist name, track title, and so on. These metadata messages are not intended to be fully descriptive but rather to offer basic track/song information. Clients MAY ignore it completely. The details on the format of the comments can be found in the Vorbis I Specification [VORBIS-SPEC-REF].
2に設定されたVorbisデータ型フラグは、パケットにアーティスト名、トラックタイトルなどのコメントメタデータが含まれていることを示しています。これらのメタデータメッセージは、完全に説明することではなく、基本的なトラック/曲情報を提供することを目的としています。クライアントはそれを完全に無視する場合があります。コメントの形式の詳細は、Vorbis I Specification [Vorbis-Spec-Ref]にあります。
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 | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. Comment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Comment Packet
図8：コメントパケット
The 2-byte length field is necessary since this packet could be fragmented.
このパケットは断片化される可能性があるため、2バイトの長さフィールドが必要です。
Each RTP payload contains either one Vorbis packet fragment or an integer number of complete Vorbis packets (up to a maximum of 15 packets, since the number of packets is defined by a 4-bit value).
各RTPペイロードには、1つのVorbisパケットフラグメントまたは整数数の完全なVorbisパケットが含まれています（パケットの数は4ビット値で定義されるため）。
Any Vorbis data packet that is less than path MTU SHOULD be bundled in the RTP payload with as many Vorbis packets as will fit, up to a maximum of 15, except when such bundling would exceed an application's desired transmission latency. Path MTU is detailed in [RFC1191] and [RFC1981].
PATH MTUよりも少ないVorbisデータパケットは、そのようなバンドルがアプリケーションの望ましい伝送レイテンシを超える場合を除き、最大15個までの数のVorbisパケットを使用してRTPペイロードにバンドルする必要があります。PATH MTUは[RFC1191]および[RFC1981]で詳しく説明されています。
A fragmented packet has a zero in the last four bits of the payload header. The first fragment will set the Fragment type to 1. Each fragment after the first will set the Fragment type to 2 in the payload header. The consecutive fragments MUST be sent without any other payload being sent between the first and the last fragment. The RTP payload containing the last fragment of the Vorbis packet will have the Fragment type set to 3. To maintain the correct sequence for fragmented packet reception, the timestamp field of fragmented packets MUST be the same as the first packet sent, with the sequence number incremented as normal for the subsequent RTP payloads; this will affect the RTCP jitter measurement. The length field shows the fragment length.
断片化されたパケットは、ペイロードヘッダーの最後の4ビットでゼロになります。最初のフラグメントは、フラグメントタイプを1に設定します。最初のフラグメントは、ペイロードヘッダーのフラグメントタイプを2に設定します。連続したフラグメントは、最初と最後のフラグメントの間に他のペイロードを送信せずに送信する必要があります。Vorbisパケットの最後のフラグメントを含むRTPペイロードは、フラグメントタイプを3に設定します。断片化されたパケット受信の正しいシーケンスを維持するには、断片化されたパケットのタイムスタンプフィールドは、シーケンス番号とともに送信された最初のパケットと同じでなければなりません。後続のRTPペイロードの場合、通常どおりに増加します。これは、RTCPジッター測定に影響します。長さフィールドは、フラグメントの長さを示しています。
Here is an example of a fragmented Vorbis packet split over three RTP payloads. Each of them contains the standard RTP headers as well as the 4-octet Vorbis headers.
以下は、3つのRTPペイロードにわたって断片化されたVorbisパケット分割の例です。それらのそれぞれには、標準のRTPヘッダーと4-OCTET Vorbisヘッダーが含まれています。
Packet 1:
パケット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 | 1000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 1 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example Fragmented Packet (Packet 1)
図9：断片化されたパケットの例（パケット1）
In this payload, the initial sequence number is 1000 and the timestamp is 12345. The Fragment type is set to 1, the number of packets field is set to 0, and as the payload is raw Vorbis data, the VDT field is set to 0.
このペイロードでは、初期シーケンス番号は1000、タイムスタンプは12345です。フラグメントタイプは1に設定され、パケットフィールドの数は0に設定され、ペイロードは生のVorbisデータであるため、VDTフィールドは0に設定されます。。
Packet 2:
パケット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 | 1001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example Fragmented Packet (Packet 2)
図10：断片化されたパケットの例（パケット2）
The Fragment type field is set to 2, and the number of packets field is set to 0. For large Vorbis fragments, there can be several of these types of payloads. The maximum packet size SHOULD be no greater than the path MTU, including all RTP and payload headers. The sequence number has been incremented by one, but the timestamp field remains the same as the initial payload.
フラグメントタイプフィールドは2に設定され、パケットフィールドの数は0に設定されています。大きなVorbisフラグメントの場合、これらのタイプのペイロードのいくつかがあります。最大パケットサイズは、すべてのRTPおよびペイロードヘッダーを含むPath MTUよりも大きくなければなりません。シーケンス番号は1つずつ増加しましたが、タイムスタンプフィールドは初期ペイロードと同じままです。
Packet 3:
パケット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 | 1002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ident | 3 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example Fragmented Packet (Packet 3)
図11：断片化されたパケットの例（パケット3）
This is the last Vorbis fragment payload. The Fragment type is set to 3 and the packet count remains set to 0. As in the previous payloads, the timestamp remains set to the first payload timestamp in the sequence and the sequence number has been incremented.
これは最後のVorbisフラグメントペイロードです。フラグメントタイプは3に設定され、パケットカウントは0に設定されたままになります。前のペイロードのように、タイムスタンプはシーケンスの最初のペイロードタイムスタンプに設定されたままで、シーケンス番号が増加しました。
As there is no error correction within the Vorbis stream, packet loss will result in a loss of signal. Packet loss is more of an issue for fragmented Vorbis packets as the client will have to cope with the handling of the Fragment Type. In case of loss of fragments, the client MUST discard all the remaining Vorbis fragments and decode the incomplete packet. If we use the fragmented Vorbis packet example above and the first RTP payload is lost, the client MUST detect that the next RTP payload has the packet count field set to 0 and the Fragment type 2 and MUST drop it. The next RTP payload, which is the final fragmented packet, MUST be dropped in the same manner. If the missing RTP payload is the last, the two fragments received will be kept and the incomplete Vorbis packet decoded.
Vorbisストリーム内にエラー補正がないため、パケットの損失は信号の損失になります。クライアントはフラグメントタイプの処理に対処する必要があるため、断片化されたVorbisパケットのパケット損失は問題です。フラグメントが喪失した場合、クライアントは残りのすべてのVorbisフラグメントを破棄し、不完全なパケットをデコードする必要があります。上記の断片化されたVorbisパケットの例を使用し、最初のRTPペイロードが紛失した場合、クライアントは次のRTPペイロードのパケットカウントフィールドが0に設定され、フラグメントタイプ2に設定され、ドロップする必要があることを検出する必要があります。最後の断片化されたパケットである次のRTPペイロードは、同じ方法で削除する必要があります。欠落しているRTPペイロードが最後の場合、受信した2つのフラグメントが保持され、不完全なVorbisパケットが解読されます。
Loss of any of the Configuration fragment will result in the loss of the full Configuration packet with the result detailed in the Loss of Configuration Headers (Section 3.3) section.
構成フラグメントのいずれかを失うと、完全な構成パケットが失われ、結果が構成ヘッダーの損失（セクション3.3）セクションで詳述されます。
Type name: audio
タイプ名：オーディオ
Subtype name: vorbis
サブタイプ名：Vorbis
Required parameters:
必要なパラメーター：
rate: indicates the RTP timestamp clock rate as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].
レート：最小限のコントロール[RFC3551]のオーディオおよびビデオ会議のRTPプロファイルで説明されているRTPタイムスタンプクロックレートを示します。
channels: indicates the number of audio channels as described in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551].
チャネル：最小限の制御[RFC3551]のオーディオおよびビデオ会議のRTPプロファイルで説明されているオーディオチャネルの数を示します。
configuration: the base64 [RFC4648] representation of the Packed Headers (Section 3.2.1).
構成：Base64 [RFC4648]パックヘッダーの表現（セクション3.2.1）。
Encoding considerations:
考慮事項のエンコード：
This media type is framed and contains binary data.
このメディアタイプはフレーム化されており、バイナリデータが含まれています。
Security considerations:
セキュリティ上の考慮事項：
See Section 10 of RFC 5215.
RFC 5215のセクション10を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
None
なし
Published specification:
公開された仕様：
RFC 5215
RFC 5215
Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/
Ogg Vorbis I仕様：コーデックのセットアップとパケットデコード。XIPH Webサイトhttp://xiph.org/から入手できます
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Audio streaming and conferencing tools
オーディオストリーミングおよび会議ツール
Additional information:
追加情報：
None
なし
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Luca Barbato: <lu_zero@gentoo.org>
IETF Audio/Video Transport Working Group
Intended usage:
意図された使用法：
COMMON
一般
Restriction on usage:
使用法の制限：
This media type depends on RTP framing, hence is only defined for transfer via RTP [RFC3550].
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。
Author:
著者：
Luca Barbato
ルカバルバト
Change controller:
Change Controller：
IETF AVT Working Group delegated from the IESG
IESGから委任されたIETF AVTワーキンググループ
The following IANA considerations refers to the split configuration Packed Headers (Section 3.2.1) used within RFC 5215.
次のIANAの考慮事項は、RFC 5215内で使用される分割構成パックヘッダー（セクション3.2.1）を指します。
Type name: audio
タイプ名：オーディオ
Subtype name: vorbis-config
サブタイプ名：Vorbis-Config
Required parameters:
必要なパラメーター：
None
なし
Optional parameters:
オプションのパラメーター：
None
なし
Encoding considerations:
考慮事項のエンコード：
This media type contains binary data.
このメディアタイプには、バイナリデータが含まれています。
Security considerations:
セキュリティ上の考慮事項：
See Section 10 of RFC 5215.
RFC 5215のセクション10を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
None
なし
Published specification:
公開された仕様：
RFC 5215
RFC 5215
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Vorbis encoded audio, configuration data
Vorbisエンコードされたオーディオ、構成データ
Additional information:
追加情報：
None
なし
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Luca Barbato: <lu_zero@gentoo.org>
IETF Audio/Video Transport Working Group
Intended usage: COMMON
意図された使用法：共通
Restriction on usage:
使用法の制限：
This media type doesn't depend on the transport.
このメディアタイプは輸送に依存しません。
Author:
著者：
Luca Barbato
ルカバルバト
Change controller:
Change Controller：
IETF AVT Working Group delegated from the IESG
IESGから委任されたIETF AVTワーキンググループ
The following paragraphs define the mapping of the parameters described in the IANA considerations section and their usage in the Offer/Answer Model [RFC3264]. In order to be forward compatible, the implementation MUST ignore unknown parameters.
次の段落では、IANAの考慮事項セクションで説明されているパラメーターのマッピングと、オファー/回答モデル[RFC3264]での使用法を定義します。互換性のある前方になるためには、実装は不明なパラメーターを無視する必要があります。
The information carried in the Media Type specification has a specific mapping to fields in the Session Description Protocol (SDP) [RFC4566], which is commonly used to describe RTP sessions. When SDP is used to specify sessions, the mapping are as follows: o The type name ("audio") goes in SDP "m=" as the media name.
メディアタイプの仕様に掲載されている情報には、セッション説明プロトコル（SDP）[RFC4566]のフィールドへの特定のマッピングがあります。これは、RTPセッションを記述するために一般的に使用されます。SDPを使用してセッションを指定する場合、マッピングは次のとおりです。oタイプ名（ "audio"）は、メディア名としてSDP "m ="になります。
o The subtype name ("vorbis") goes in SDP "a=rtpmap" as the encoding name.
o サブタイプ名（ "Vorbis"）は、sdp "a = rtpmap"にエンコーディング名として移動します。
o The parameter "rate" also goes in "a=rtpmap" as the clock rate.
o パラメーター「レート」も、クロックレートとして「a = rtpmap」にも含まれます。
o The parameter "channels" also goes in "a=rtpmap" as the channel count.
o パラメーター「チャネル」も、チャネルカウントとして「a = rtpmap」にも含まれます。
o The mandated parameters "configuration" MUST be included in the SDP "a=fmtp" attribute.
o 義務付けられたパラメーター「構成」は、SDP "a = fmtp"属性に含める必要があります。
If the stream comprises chained Vorbis files and all of them are known in advance, the Configuration Packet for each file SHOULD be passed to the client using the configuration attribute.
ストリームがChained Vorbisファイルで構成され、それらのすべてが事前に既知である場合、各ファイルの構成パケットを構成属性を使用してクライアントに渡す必要があります。
The port value is specified by the server application bound to the address specified in the c= line. The channel count value specified in the rtpmap attribute SHOULD match the current Vorbis stream or should be considered the maximum number of channels to be expected. The timestamp clock rate MUST be a multiple of the sample rate; a different payload number MUST be used if the clock rate changes. The Configuration payload delivers the exact information, thus the SDP information SHOULD be considered a hint. An example is found below.
ポート値は、c = lineで指定されたアドレスにバインドされたサーバーアプリケーションによって指定されます。RTPMAP属性で指定されているチャネルカウント値は、現在のVorbisストリームと一致するか、予想されるチャネルの最大数と見なす必要があります。タイムスタンプのクロックレートは、サンプルレートの複数でなければなりません。クロックレートが変更された場合、別のペイロード番号を使用する必要があります。構成ペイロードは正確な情報を提供するため、SDP情報はヒントと見なされる必要があります。例を以下に示します。
The following example shows a basic SDP single stream. The first configuration packet is inside the SDP; other configurations could be fetched at any time from the URIs provided. The following base64 [RFC4648] configuration string is folded in this example due to RFC line length limitations.
次の例は、基本的なSDPシングルストリームを示しています。最初の構成パケットはSDP内にあります。他の構成は、提供されたURIからいつでもフェッチすることができます。次のBase64 [RFC4648]構成文字列は、RFCラインの長さの制限により、この例で折り畳まれています。
c=IN IP4 192.0.2.1
C = IP4 192.0.2.1
m=audio RTP/AVP 98
M =オーディオRTP/AVP 98
a=rtpmap:98 vorbis/44100/2
a = rtpmap：98 vorbis/44100/2
a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...;
Note that the payload format (encoding) names are commonly shown in uppercase. Media Type subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in Media Type types and in the default mapping to the SDP a=fmtp attribute. The a=fmtp line is a single line, even if it is shown as multiple lines in this document for clarity.
ペイロード形式（エンコード）名は一般に大文字で表示されることに注意してください。メディアタイプのサブタイプは、一般的に小文字で示されています。これらの名前は、両方の場所でケースに依存しません。同様に、パラメーター名は、メディアタイプタイプとデフォルトのマッピングの両方で、SDP A = FMTP属性の両方でケース非感受性です。A = FMTP行は、明確にするためにこのドキュメントに複数の行として表示されていても、単一の行です。
There are no negotiable parameters. All of them are declarative.
交渉可能なパラメーターはありません。それらはすべて宣言的です。
The general congestion control considerations for transporting RTP data apply to Vorbis audio over RTP as well. See the RTP specification [RFC3550] and any applicable RTP profile (e.g., [RFC3551]). Audio data can be encoded using a range of different bit rates, so it is possible to adapt network bandwidth by adjusting the encoder bit rate in real time or by having multiple copies of content encoded at different bit rates.
RTPデータを輸送するための一般的な混雑制御の考慮事項は、RTPよりもVorbisオーディオにも適用されます。RTP仕様[RFC3550]および該当するRTPプロファイル（[RFC3551]など）を参照してください。オーディオデータは、さまざまなビットレートの範囲を使用してエンコードできます。そのため、エンコーダビットレートをリアルタイムで調整するか、異なるビットレートでエンコードされたコンテンツの複数のコピーを使用することにより、ネットワーク帯域幅を適合させることができます。
The following example shows a common usage pattern that MAY be applied in such a situation. The main scope of this section is to explain better usage of the transmission vectors.
次の例は、そのような状況で適用される可能性のある一般的な使用パターンを示しています。このセクションの主な範囲は、送信ベクトルのより良い使用法を説明することです。
This is one of the most common situations: there is one single server streaming content in multicast, and the clients may start a session at a random time. The content itself could be a mix of a live stream (as the webjockey's voice) and stored streams (as the music she plays).
これは最も一般的な状況の1つです。マルチキャストには1つのサーバーストリーミングコンテンツが1つあり、クライアントはランダムな時間にセッションを開始できます。コンテンツ自体は、（WebJockeyの声として）ライブストリームを組み合わせて、ストリーム（彼女が演奏する音楽として）を組み合わせている可能性があります。
In this situation, we don't know in advance how many codebooks we will use. The clients can join anytime and users expect to start listening to the content in a short time.
この状況では、使用するコードブックの数が事前にわかりません。クライアントはいつでも参加でき、ユーザーは短時間でコンテンツを聴き始めることを期待しています。
Upon joining, the client will receive the current Configuration necessary to decode the current stream inside the SDP so that the decoding will start immediately after.
参加すると、クライアントは、SDP内の現在のストリームをデコードするために必要な現在の構成を受信して、すぐにデコードを開始します。
When the streamed content changes, the new Configuration is sent in-band before the actual stream, and the Configuration that has to be sent inside the SDP is updated. Since the in-band method is unreliable, an out-of-band fallback is provided.
ストリーミングされたコンテンツが変更されると、新しい構成は実際のストリームの前にバンド内で送信され、SDP内で送信する必要がある構成が更新されます。帯域内の方法は信頼できないため、バンド外のフォールバックが提供されます。
The client may choose to fetch the Configuration from the alternate source as soon as it discovers a Configuration packet got lost in-band, or use selective retransmission [RFC3611] if the server supports this feature.
クライアントは、構成パケットが帯域内に迷子になったことを発見したらすぐに、代替ソースから構成を取得するか、サーバーがこの機能をサポートしている場合に選択的な再送信[RFC3611]を使用することを選択できます。
A server-side optimization would be to keep a hash list of the Configurations per session, which avoids packing all of them and sending the same Configuration with different Ident tags.
サーバー側の最適化は、セッションごとに構成のハッシュリストを保持することです。これにより、それらすべてが梱包され、同じ構成が異なる識別タグで送信されます。
A client-side optimization would be to keep a tag list of the Configurations per session and not process configuration packets that are already known.
クライアント側の最適化は、セッションごとの構成のタグリストを保持することであり、すでに既知のプロセス構成パケットではありません。
RTP packets using this payload format are subject to the security considerations discussed in the RTP specification [RFC3550], the base64 specification [RFC4648], and the URI Generic syntax specification [RFC3986]. Among other considerations, this implies that the confidentiality of the media stream is achieved by using encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data.
このペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]、Base64仕様[RFC4648]、およびURIジェネリック構文仕様[RFC3986]で説明されているセキュリティ上の考慮事項の対象となります。他の考慮事項の中でも、これは、暗号化を使用することにより、メディアストリームの機密性が達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、暗号化は圧縮データで実行される場合があります。
The authors agree to grant third parties the irrevocable right to copy, use, and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information.
著者は、別々の許可が認められない限り、修正されていない場合、修正なしで、修正の有無にかかわらず、修正の有無にかかわらず、修正の有無にかかわらず作業をコピー、使用、および配布するための取消不能な権利を第三者に付与することに同意します。バージョン、作品名、または承認情報。
This document is a continuation of the following documents:
このドキュメントは、次のドキュメントの継続です。
Moffitt, J., "RTP Payload Format for Vorbis Encoded Audio", February 2001.
Moffitt、J。、「Vorbis Encoded AudioのRTPペイロード形式」、2001年2月。
Kerr, R., "RTP Payload Format for Vorbis Encoded Audio", December 2004.
Kerr、R。、「Vorbis Encoded AudioのRTPペイロード形式」、2004年12月。
The Media Type declaration is a continuation of the following document:
メディアタイプの宣言は、次のドキュメントの継続です。
Short, B., "The audio/rtp-vorbis MIME Type", January 2008.
Short、B。、「オーディオ/RTP-Vorbis Mime Type」、2008年1月。
Thanks to the AVT, Vorbis Communities / Xiph.Org Foundation including Steve Casner, Aaron Colwell, Ross Finlayson, Fluendo, Ramon Garcia, Pascal Hennequin, Ralph Giles, Tor-Einar Jarnbjo, Colin Law, John Lazzaro, Jack Moffitt, Christopher Montgomery, Colin Perkins, Barry Short, Mike Smith, Phil Kerr, Michael Sparks, Magnus Westerlund, David Barrett, Silvia Pfeiffer, Stefan Ehmann, Gianni Ceccarelli, and Alessandro Salvatori. Thanks to the LScube Group, in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Dario Gallucci, and Juan Carlos De Martin.
AVTのおかげで、Steve Casner、Aaron Colwell、Ross Finlayson、Flyendo、Ramon Garcia、Pascal Hennequin、Ralph Giles、Tor-Einar Jarnbjo、Colin Law、John Lazzaro、Jack Montopopher Montopopher Montopher Montopher Montopher Montopher Montopherを含むVorbis Communities / Xiph.org Foundationコリン・パーキンス、バリー・ショート、マイク・スミス、フィル・カー、マイケル・スパークス、マグナス・ウェスターランド、デビッド・バレット、シルビア・ファイファー、ステファン・エーマン、ジャンニ・セッカレリ、アレッサンドロ・サルヴァトリ。LSCUBEグループ、特にFederico Ridolfo、Francesco Varano、Giampaolo Mancini、Dario Gallucci、Juan Carlos de Martinに感謝します。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[VORBIS-SPEC-REF] "Ogg Vorbis I specification: Codec setup and packet decode. Available from the Xiph website, http://xiph.org/vorbis/doc/Vorbis_I_spec.html".
[Vorbis-spec-ref] "Ogg Vorbis I Specification：Codec Setup and PacketDecode。XIPHWebサイトhttp://xiph.org/vorbis/doc/vorbis_i_spec.html"から入手できます。
[LIBVORBIS] "libvorbis: Available from the dedicated website, http://vorbis.com/".
[libvorbis] "libvorbis：専用のWebサイトhttp://vorbis.com/から入手できます。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3533] Pfeiffer、S。、「OGGカプセル化形式バージョン0」、RFC 3533、2003年5月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP再送信ペイロードフォーマット」、RFC 4588、2006年7月。
Author's Address
著者の連絡先
Luca Barbato Xiph.Org Foundation
Luca Barbato Xiph.org Foundation
EMail: lu_zero@gentoo.org
URI: http://xiph.org/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。