[要約] RFC 2733は、一般的な転送エラー訂正のためのRTPペイロード形式に関する規格です。このRFCの目的は、RTPパケットの転送エラーを訂正するための汎用的な方法を提供することです。
Network Working Group J. Rosenberg
Request for Comments: 2733 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
December 1999
An RTP Payload Format for Generic Forward Error Correction
一般的なフォワードエラー修正のための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) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions.
このドキュメントは、RTPにカプセル化されたメディアの一般的なフォワードエラー補正のペイロード形式を指定します。排他的または（パリティ）操作に基づいてFECアルゴリズム用に設計されています。ペイロード形式により、Endシステムは任意のブロック長とパリティスキームを使用して送信できます。また、ペイロードとクリティカルRTPヘッダーフィールドの両方の回復を可能にします。FECは別のストリームとして送信されるため、FECではないホストとの逆方向に互換性があるため、FECを実装したくない受信機は拡張機能を無視するだけです。
Table of Contents
目次
1 Introduction ........................................... 2
2 Terminology ............................................ 2
3 Basic Operation ........................................ 3
4 Parity Codes ........................................... 5
5 RTP Media Packet Structure ............................. 6
6 FEC Packet Structure ................................... 7
6.1 RTP Header of FEC Packets .............................. 7
6.2 FEC Header ............................................. 7
7 Protection Operation ................................... 9
8 Recovery Procedures .................................... 10
8.1 Reconstruction ......................................... 10
8.2 Determination of When to Recover ....................... 12
9 Example ................................................ 16
10 Use with Redundant Encodings ........................... 17
11 Indicating FEC Usage in SDP ............................ 20
11.1 FEC as a Separate Stream ............................... 20
11.2 Use with Redundant Encodings ........................... 21
11.3 Usage with RTSP ........................................ 22
12 Security Considerations ................................ 23
13 Acknowledgments ........................................ 24
14 Authors' Addresses ..................................... 24
15 Bibliography ........................................... 25
16 Full Copyright Statement ............................... 26
1 Introduction
1はじめに
The quality of packet voice on the Internet has been mediocre due, in part, to high packet loss rates. This is especially true on wide-area connections. Unfortunately, the strict delay requirements of real-time multimedia usually eliminate the possibility of retransmissions.
インターネット上のパケット音声の品質は、部分的には高いパケット損失率のために平凡でした。これは、広いエリア接続で特に当てはまります。残念ながら、リアルタイムマルチメディアの厳格な遅延要件は、通常、再送信の可能性を排除します。
It is for this reason that forward error correction (FEC) has been proposed to compensate for packet loss in the Internet [1] [2]. In particular, the use of traditional error correcting codes, such as parity, Reed-Solomon, and Hamming codes, has attracted attention. To support these mechanisms, protocol support is required.
このため、インターネットでのパケット損失を補うために、フォワードエラー補正（FEC）が提案されています[1] [2]。特に、パリティ、リードソロモン、ハミングコードなどの従来のエラー修正コードの使用が注目を集めています。これらのメカニズムをサポートするには、プロトコルサポートが必要です。
This document defines a payload format for RTP [3] which allows for generic forward error correction of real time media. In this context, generic means that the FEC protocol is (1) independent of the nature of the media being protected, be it audio, video, or otherwise, (2) flexible enough to support a wide variety of FEC mechanisms, (3) designed for adaptivity so that the FEC technique can be modified easily without out of band signaling, and (4) supportive of a number of different mechanisms for transporting the FEC packets.
このドキュメントでは、RTP [3]のペイロード形式を定義します。これにより、リアルタイムメディアの一般的なフォワードエラー補正が可能になります。これに関連して、ジェネリックとは、FECプロトコルが（1）オーディオ、ビデオ、またはその他のメディアの性質とは無関係であることを意味します。適応性のために設計されているため、FEC技術をバンドシグナリングなしで簡単に変更できるようになり、（4）FECパケットを輸送するためのさまざまなメカニズムをサポートします。
2 Terminology
2用語
The following terms are used throughout this document:
次の用語は、このドキュメント全体で使用されます。
Media Payload: is a piece of raw, un-protected user data which is to be transmitted from the sender. The media payload is placed inside of an RTP packet.
メディアペイロード：送信者から送信される未加工の無保護ユーザーデータです。メディアペイロードは、RTPパケットの内側に配置されます。
Media Header: is the RTP header for the packet containing the media payload.
メディアヘッダー：メディアペイロードを含むパケットのRTPヘッダーです。
Media Packet: The combination of a media payload and media header is called a media packet.
メディアパケット：メディアペイロードとメディアヘッダーの組み合わせは、メディアパケットと呼ばれます。
FEC Packet: The forward error correction algorithms at the transmitter take the media packets as an input. They output both the media packets that they are passed, and new packets called FEC packets. The FEC packets are formatted according to the rules specified in this document.
FECパケット：送信機でのフォワードエラー修正アルゴリズムは、メディアパケットを入力として取得します。それらは、渡されたメディアパケットと、FECパケットと呼ばれる新しいパケットの両方を出力します。FECパケットは、このドキュメントで指定されたルールに従ってフォーマットされます。
FEC Header: The FEC header is the header information contained in an FEC packet.
FECヘッダー：FECヘッダーは、FECパケットに含まれるヘッダー情報です。
FEC Payload: The FEC payload is the payload in an FEC packet.
FECペイロード：FECペイロードは、FECパケットのペイロードです。
Associated: An FEC packet is said to be "associated" with one or more media packets when those media packets are used to generate the FEC packet (by use of the exclusive or operation).
関連：FECパケットは、これらのメディアパケットを使用してFECパケットを生成する場合（排他的または操作を使用して）1つ以上のメディアパケットに「関連付けられている」と言われています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [4]に記載されているように解釈される。
3 Basic Operation
3基本操作
The payload format described here is used whenever a participant in an RTP session would like to protect a media stream it is sending with forward error correction (FEC). The FEC supported by the format are those codes based on simple exclusive or (xor) parities. The sender takes some set of packets from the media stream, and applies an xor operation across the payloads. The sender also applies the xor operation over components of the RTP headers. Based on the procedures defined here, the result is an RTP packet containing FEC information. This packet can be used at the receiver to recover any one of the packets used to generate the FEC packet. This document does not mandate the particular set of media packets combined to generate an FEC packet (such a set [is] referred to as a code). Use of differing sets results in a tradeoff between overhead, delay, and recoverability. Section 4 outlines some possible combinations.
ここで説明するペイロード形式は、RTPセッションの参加者が、フォワードエラー修正（FEC）で送信しているメディアストリームを保護したい場合に使用されます。フォーマットでサポートされているFECは、単純な排他的または（XOR）パリティに基づいたコードです。送信者は、メディアストリームからパケットのセットを取り、ペイロード全体にXOR操作を適用します。送信者は、RTPヘッダーのコンポーネント上にXOR操作も適用します。ここで定義されている手順に基づいて、結果はFEC情報を含むRTPパケットを導入しました。このパケットは、FECパケットを生成するために使用されるパケットのいずれかを回復するために、受信機で使用できます。このドキュメントでは、特定のメディアパケットセットを組み合わせてFECパケットを生成することは義務付けられていません（このようなセットはコードと呼ばれます）。異なるセットを使用すると、オーバーヘッド、遅延、回復可能性の間のトレードオフが生じます。セクション4では、いくつかの可能な組み合わせの概要を説明します。
The payload format contains information that allows the sender to tell the receiver exactly which media packets have been used to generate the FEC. Specifically, each FEC packet contains a bitmask, called the offset mask, containing 24 bits. If bit i in the mask is set to 1, the media packet with sequence number N + i was used to generate this FEC packet. N is called the sequence number base, and is sent in the FEC packet as well. The offset mask and payload type are sufficient to signal arbitrary parity based forward error correction schemes with little overhead.
ペイロード形式には、送信者がFECを生成するためにどのメディアパケットが使用されたかを正確に受信者に伝えることができる情報が含まれています。具体的には、各FECパケットには、24ビットを含むオフセットマスクと呼ばれるビットマスクが含まれています。マスク内のビットIが1に設定されている場合、シーケンス番号nのメディアパケットは、このFECパケットを生成するために使用されました。nはシーケンス番号ベースと呼ばれ、FECパケットでも送信されます。オフセットマスクとペイロードタイプは、頭上がほとんどない任意のパリティに基づいた前方エラー補正スキームを信号するのに十分です。
This document also describes procedures that allow the receiver to make use of the FEC without having to know the details of specific codes. This allows the sender much flexibility; it can adapt the code in use based on network conditions, and be certain the receivers can still make use of the FEC for recovery.
このドキュメントでは、特定のコードの詳細を知らずに受信者がFECを利用できるようにする手順についても説明しています。これにより、送信者は非常に柔軟になります。ネットワーク条件に基づいて使用されているコードを適応させることができ、受信機が回復のためにFECを利用できることを確認できます。
As the sender generates FEC packets, they are sent to the receivers. The sender still usually sends the original media stream, as if there were no FEC. This allows the media stream to still be used by receivers who are not FEC capable. However, some FEC codes do not require the original media to be sent; the FEC stream is sufficient for recovery. These codes have the drawback that all receivers must be FEC capable. However, they are supported by this format.
送信者がFECパケットを生成すると、レシーバーに送信されます。送信者は通常、FECがないかのように、通常、元のメディアストリームを送信します。これにより、メディアストリームは、FEC能力のないレシーバーが引き続き使用できます。ただし、一部のFECコードでは、元のメディアの送信を必要としません。FECストリームは回復には十分です。これらのコードには、すべての受信機がFECが能力を持っている必要があるという欠点があります。ただし、この形式でサポートされています。
The FEC packets are not sent in the same RTP stream as the media packets. They can be sent as a separate stream, or as a secondary codec in the redundant codec payload format [5]. When sent as a separate stream, the FEC packets have their own sequence number space. Although the timestamps for the FEC packets are derived from the media packets, they increment monotonically. FEC packet streams thus work well with any header compression mechanism which requires fixed deltas between fields in the packet header.
FECパケットは、メディアパケットと同じRTPストリームで送信されません。それらは、別のストリームとして、または冗長なコーデックペイロード形式のセカンダリコーデックとして送信できます[5]。別のストリームとして送信されると、FECパケットには独自のシーケンス番号スペースがあります。FECパケットのタイムスタンプはメディアパケットから派生していますが、単調に増加します。したがって、FECパケットストリームは、パケットヘッダー内のフィールド間の固定デルタを必要とするヘッダー圧縮メカニズムでうまく機能します。
This document does not prescribe the definition of "separate streams", but leaves this to applications and higher level protocols to define. For multicast, the separate stream may be implemented by separate multicast groups, different ports in the same group, or by a different SSRC within the same group/port. For unicast, different ports or different SSRC may be used. Each of these approaches has drawbacks and benefits which depend on the application.
このドキュメントは、「個別のストリーム」の定義を規定するものではありませんが、これをアプリケーションと高レベルのプロトコルに定義するためのより高いレベルのプロトコルに任せます。マルチキャストの場合、個別のストリームは、同じグループ内の異なるポート、または同じグループ/ポート内の異なるSSRCによって実装されます。ユニキャストの場合、異なるポートまたは異なるSSRCを使用できます。これらの各アプローチには、アプリケーションに依存する欠点と利点があります。
At the receiver, the FEC and original media are received. If no media packets are lost, the FEC can be ignored. In the event of loss, the FEC packets can be combined with other media and FEC packets that have been received, resulting in recovery of missing media packets. The recovery is exact; the payload is perfectly reconstructed, along with most components of the header.
受信機では、FECとオリジナルのメディアが受信されます。メディアパケットが失われない場合、FECは無視できます。損失が発生した場合、FECパケットは受信した他のメディアおよびFECパケットと組み合わせることができ、メディアパケットが欠落していることがあります。回復は正確です。ペイロードは、ヘッダーのほとんどのコンポーネントとともに完全に再構築されます。
RTP packets which contain data formatted according to this specification (i.e., FEC packets) are signaled using dynamic RTP payload types.
この仕様（つまり、FECパケット）に従ってフォーマットされたデータを含むRTPパケットは、動的なRTPペイロードタイプを使用してシグナル伝えられます。
4 Parity Codes
4つのパリティコード
For brevity, we define the function f(x,y,..) to be the XOR (parity) operator applied to the packets x,y,... The output of this function is another packet, called the parity packet. For simplicity, we assume here that the parity packet is computed as the bitwise XOR of the input packets. The exact procedure is specified in section 6.
簡潔にするために、パケットx、y、...この関数の出力はパリティパケットと呼ばれる別のパケットであるパケットx、y、... xor（parity）演算子であると機能f（x、y、..）を定義します。簡単にするために、ここでは、パリティパケットが入力パケットのビットワイズXORとして計算されていると仮定します。正確な手順は、セクション6で指定されています。
Recovery of data packets using parity codes is accomplished by generating one or more parity packets over a group of data packets. To be effective, the parity packets must be generated by linearly independent combinations of data packets. The particular combination is called a parity code. One class of codes takes a group of k data packets, and generates n-k parity packets. There are a large number of possible parity codes for a given n,k. The payload format does not mandate a particular code.
パリティコードを使用したデータパケットの回復は、データパケットのグループで1つ以上のパリティパケットを生成することにより実現されます。効果的であるためには、パリティパケットは、データパケットの直線的に独立した組み合わせによって生成される必要があります。特定の組み合わせはパリティコードと呼ばれます。コードの1つのクラスは、Kデータパケットのグループを採用し、N-Kパリティパケットを生成します。特定のn、kには多数の可能なパリティコードがあります。ペイロード形式は、特定のコードを義務付けません。
For example, consider a parity code which generates a single parity packet over two data packets. If the original media packets are a,b,c,d, the packets generated by the sender are:
たとえば、2つのデータパケットに単一のパリティパケットを生成するパリティコードを検討してください。元のメディアパケットがa、b、c、dの場合、送信者によって生成されたパケットは次のとおりです。
a b c d <-- media stream
f(a,b) f(c,d) <-- FEC stream
where time increases to the right. In this example, the error correction scheme (we use the terms scheme and code interchangeably) introduces a 50% overhead. But if b is lost, a and f(a,b) can be used to recover b.
時間が右に増加する場所。この例では、エラー補正スキーム（用語スキームとコードを互換性が高い）で50％のオーバーヘッドを導入します。ただし、Bが失われた場合、aおよびf（a、b）を使用してb。
Some additional codes are listed below. In each, the original media stream consists of packets a,b,c,d and so on.
いくつかの追加コードを以下に示します。それぞれで、元のメディアストリームは、パケットa、b、c、dなどで構成されています。
Scheme 1
--------
This scheme is the similar to the one in the example above. However, instead of sending b, followed by f(a,b), f(a,b) is sent before b. Doing this clearly requires additional delay at the sender. However, if allows some bursts of two consecutive packet losses to be recovered. The packets generated by the sender look like:
このスキームは、上記の例のスキームに似ています。ただし、bを送信する代わりに、f（a、b）が続くと、f（a、b）がbの前に送信されます。これを行うには、送信者に追加の遅延が必要です。ただし、2つの連続したパケット損失のバーストを回復させる場合。送信者によって生成されたパケットは次のように見えます。
a b c d e <-- media stream
f(a,b) f(b,c) f(c,d) f(d,e) <-- FEC stream
Scheme 2
--------
It is not strictly necessary for the original media stream to be transmitted. In this scheme, only FEC packets are transmitted. This scheme allows for recovery of all single packet losses and some consecutive packet losses, but with slightly less overhead than scheme 1. The packets generated by the sender look like:
元のメディアストリームを送信する必要はありません。このスキームでは、FECパケットのみが送信されます。このスキームにより、すべての単一パケット損失といくつかの連続したパケット損失の回復が可能になりますが、スキーム1よりもわずかにオーバーヘッドがあります。送信者によって生成されたパケットは次のように見えます。
f(a,b) f(a,c) f(a,b,c) f(c,d) f(c,e) f(c,d,e) <-- FEC stream
Scheme 3
--------
This scheme requires the receiver to wait an additional four packet intervals to recover the original media packets. However, it can recover from one, two or three consecutive packet losses. The packets generated by the sender look like:
このスキームでは、元のメディアパケットを回復するために、レシーバーが追加の4つのパケット間隔を待つ必要があります。ただし、1、2、3の連続したパケット損失から回復できます。送信者によって生成されたパケットは次のように見えます。
a b c d <-- media stream
f(a,b,c) f(a,c,d) f(a,b,d) <-- FEC stream
5 RTP Media Packet Structure
5 RTPメディアパケット構造
The formatting of the media packets is unaffected by FEC. If the FEC is sent as a separate stream, the media packets are sent as if there was no FEC. If the FEC is being sent as a redundant codec, the media packets are sent as the main codec as defined in RFC 2198 [5].
メディアパケットのフォーマットはFECの影響を受けません。FECが別のストリームとして送信されると、メディアパケットはFECがないかのように送信されます。FECが冗長コーデックとして送信されている場合、メディアパケットはRFC 2198で定義されているメインコーデックとして送信されます[5]。
This lends to a very efficient encoding. When little (or no) FEC is used, there are mostly media packets being sent. This means that the overhead (present in FEC packets only) tracks the amount of FEC in use.
これは非常に効率的なエンコードに役立ちます。Little（またはno）FECを使用すると、ほとんどのメディアパケットが送信されます。これは、オーバーヘッド（FECパケットのみに存在する）が使用中のFECの量を追跡することを意味します。
6 FEC Packet Structure
6 FECパケット構造
An FEC packet is constructed by placing an FEC header and FEC payload in the RTP payload, as shown in Figure 1:
FECパケットは、図1に示すように、RTPペイロードにFECヘッダーとFECペイロードを配置することによって構築されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Packet Structure
図1：FECパケット構造
The version field is set to 2. The padding bit is computed via the protection operation, defined below. The extension bit is also computed via the protection operation. The SSRC value will generally be the same as the SSRC value of the media stream it protects. It MAY be different if the FEC stream is being demultiplexed via the SSRC value. The CC value is computed via the protection operation. The CSRC list is never present, independent of the value of the CC field. The extension is never present, independent of the value of the X bit. The marker bit is computed via the protection operation.
バージョンフィールドは2に設定されています。パディングビットは、以下に定義する保護操作を介して計算されます。拡張ビットは、保護操作を介して計算されます。SSRC値は一般に、保護するメディアストリームのSSRC値と同じです。FECストリームがSSRC値を介して脱臼している場合、それは異なる場合があります。CC値は、保護操作を介して計算されます。CSRCリストは、CCフィールドの値とは無関係に存在することはありません。Xビットの値とは無関係に、拡張機能は決して存在しません。マーカービットは、保護操作を介して計算されます。
The sequence number has the standard definition: it MUST be one higher than the sequence number in the previously transmitted FEC packet. The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted. This results in the TS value in FEC packets to be monotonically increasing, independent of the FEC scheme.
シーケンス番号には標準の定義があります。以前に送信されたFECパケットのシーケンス番号よりも1つ高い必要があります。タイムスタンプは、FECパケットが送信される瞬間にメディアRTPクロックの値に設定する必要があります。これにより、FECパケットのTS値は、FECスキームとは無関係に、単調に増加します。
The payload type for the FEC packet is determined through dynamic, out of band means. According to RFC 1889 [3], RTP participants which cannot recognize a payload type must discard it. This provides backwards compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and FEC-incapable receivers.
FECパケットのペイロードタイプは、動的でバンドの手段によって決定されます。RFC 1889 [3]によると、ペイロードタイプを認識できないRTP参加者はそれを破棄する必要があります。これにより、逆方向の互換性が得られます。FECメカニズムは、FEC対応の混合レシーバーを備えたマルチキャストグループで使用できます。
This header is 12 bytes. The format of the header is shown in Figure 2, and consists of an SN base field, length recovery field, E field, PT recovery field, mask field and TS recovery field.
このヘッダーは12バイトです。ヘッダーの形式を図2に示し、SNベースフィールド、長さの回復フィールド、Eフィールド、PT回復フィールド、マスクフィールド、TS回復フィールドで構成されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base | length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| PT recovery | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Parity Header Format
図2：パリティヘッダー形式
The length recovery field is used to determine the length of any recovered packets. It is computed via the protection operation applied to the unsigned network-ordered 16 bit representation of the sums of the lengths (in bytes) of the media payload, CSRC list, extension and padding of media packets associated with this FEC packet (in other words, the CSRC list, extension, and padding, if present, are "counted" as part of the payload). This allows the FEC procedure to be applied even when the lengths of the media packets are not identical. For example, assume an FEC packet is being generated by xor'ing two media packets together. The length of the two media packets are 3 (0b011) and 5 (0b101) bytes, respectively. The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
長さの回復フィールドは、回収されたパケットの長さを決定するために使用されます。これは、メディアペイロードの長さ（バイト単位）の合計（CSRCリスト、拡張、およびこのFECパケットに関連付けられたメディアパケットのパディング）の合計の16ビット表現に適用された保護操作を介して計算されます（つまり、言います。、CSRCリスト、拡張機能、およびパディングは、存在する場合、ペイロードの一部として「カウント」されます）。これにより、メディアパケットの長さが同一でない場合でも、FEC手順を適用できます。たとえば、FECパケットが2つのメディアパケットを一緒にXORして生成されていると仮定します。2つのメディアパケットの長さは、それぞれ3（0B011）と5（0B101）バイトです。長さの回復フィールドは、0B011 XOR 0B101 = 0B110としてエンコードされます。
The E bit indicates a header extension. Implementations conforming to this version of the specification MUST set this bit to zero.
Eビットは、ヘッダー拡張機能を示します。このバージョンの仕様に準拠する実装は、このビットをゼロに設定する必要があります。
The PT recovery field is obtained via the protection operation applied to the payload type values of the media packets associated with the FEC packet.
PT回復フィールドは、FECパケットに関連付けられたメディアパケットのペイロードタイプの値に適用される保護操作を介して取得されます。
The mask field is 24 bits. If bit i in the mask is set to 1, then the media packet with sequence number N + i is associated with this FEC packet, where N is the SN Base field in the FEC packet header. The least significant bit corresponds to i=0, and the most significant to i=23.
マスクフィールドは24ビットです。マスク内のビットIが1に設定されている場合、シーケンス番号n Iを備えたメディアパケットは、このFECパケットに関連付けられています。ここで、NはFECパケットヘッダーのSNベースフィールドです。最も有意なビットはi = 0に対応し、I = 23に最も重要なビットに対応します。
The SN base field MUST be set to the minimum sequence number of those media packets protected by FEC. This allows for the FEC operation to extend over any string of at most 24 packets.
SNベースフィールドは、FECによって保護されているメディアパケットの最小シーケンス番号に設定する必要があります。これにより、FEC操作は、最大24個のパケットのあらゆる文字列に拡張できます。
The TS recovery field is computed via the protection operation applied to the timestamps of the media packets associated with this FEC packet. This allows the timestamp to be completely recovered.
TS回復フィールドは、このFECパケットに関連付けられたメディアパケットのタイムスタンプに適用される保護操作を介して計算されます。これにより、タイムスタンプを完全に回復できます。
The payload of the FEC packet is the protection operation applied to the concatenation of the CSRC list, RTP extension, media payload, and padding of the media packets associated with the FEC packet.
FECパケットのペイロードは、FECパケットに関連付けられたメディアパケットのCSRCリスト、RTP拡張機能、メディアペイロード、およびパディングの連結に適用される保護操作です。
Note that it's possible for the FEC packet to be slightly larger than the media packets it protects (due to the presence of the FEC header). This could cause difficulties if this results in the FEC packet exceeding the Maximum Transmission Unit size for the path along which it is sent.
FECパケットが保護するメディアパケットよりもわずかに大きくなる可能性があることに注意してください（FECヘッダーの存在により）。これにより、FECパケットが送信されるパスの最大送信ユニットサイズを超えると、困難が生じる可能性があります。
7 Protection Operation
7保護操作
The protection operation involves concatenating specific fields from the RTP header of the media packet, appending the payload, padding with zeroes, and then computing the xor across the resulting bit strings. The resulting bit string is used to generate the FEC packet.
保護操作には、メディアパケットのRTPヘッダーから特定のフィールドを連結し、ペイロードを追加し、ゼロでパディングし、結果のビット文字列全体にXORを計算することが含まれます。結果のビット文字列は、FECパケットを生成するために使用されます。
The following procedure MAY be followed for the protection operation. Other procedures MAY be followed, but the end result MUST be identical to the one described here. For each media packet to be protected, a bit string is generated by concatenating the following fields together in the order specifed:
保護操作のために、次の手順に従うことができます。他の手順に従うことができますが、最終結果はここで説明したものと同一でなければなりません。メディアパケットが保護されるごとに、指定された順序で次のフィールドを一緒に連結することにより、少し文字列が生成されます。
o Padding Bit (1 bit)
o パディングビット（1ビット）
o Extension Bit (1 bit)
o 拡張ビット（1ビット）
o CC bits (4 bits)
o CCビット（4ビット）
o Marker bit (1 bit)
o マーカービット（1ビット）
o Payload Type (7 bits)
o ペイロードタイプ（7ビット）
o Timestamp (32 bits)
o タイムスタンプ（32ビット）
o Unsigned network-ordered 16 bit representation of the sum of the lengths (in bytes) of the CSRC List, length of the padding, length of the extension, and length of the media payload (16 bits)
o CSRCリストの長さ（バイト単位）の合計、パディングの長さ、拡張長の長さ、メディアペイロードの長さ（16ビット）の16ビット表現のない署名されていないネットワーク命令16ビット表現
o if CC is nonzero, the CSRC List (variable length)
o CCがゼロではない場合、CSRCリスト（変数長）
o if X is 1, the Header Extension (variable length)
o xが1の場合、ヘッダー拡張（可変長）
o the payload (variable length)
o ペイロード（可変長）
o Padding, if present (variable length)
o パディング、存在する場合（可変長）
Note that the Padding Bit (first entry above) forms the most significant bit of the bit string.
パディングビット（上記の最初のエントリ）は、ビット文字列の最も重要なビットを形成することに注意してください。
If the lengths of the bit strings are not equal, each bit string that is shorter than the length of the longest, MUST be padded to the length of the longest. Any value for the pad may be used. The pad MUST be added at the end of the bit string.
ビット文字列の長さが等しくない場合、最長の長さよりも短い各ビット文字列は、最長の長さにパッドで埋めなければなりません。パッドの任意の値を使用できます。ビット文字列の端にパッドを追加する必要があります。
The parity operation is then applied across the bit strings. The result is the bit string used to build the FEC packet. Call this the FEC bit string.
パリティ操作は、ビット文字列に適用されます。その結果、FECパケットの構築に使用されるビット文字列が得られます。これをFECビット文字列と呼びます。
The first (most significant) bit in the FEC bit string is written into the Padding Bit of the FEC packet. The second bit in the FEC bit string is written into the Extension bit of the FEC packet. The next four bits of the FEC bit string are written into the CC field of the FEC packet. The next bit of the FEC bit string is written into the marker bit of the FEC packet. The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC packet header. The next 32 bits of the FEC bit string are written into the TS recovery field in the packet header. The next 16 bits are written into the length recovery field in the FEC packet header. The remaining bits are set to be the payload of the FEC packet.
FECビット文字列の最初の（最も重要な）ビットは、FECパケットのパディングビットに書き込まれます。FECビット文字列の2番目のビットは、FECパケットの拡張ビットに書き込まれます。FECビット文字列の次の4ビットは、FECパケットのCCフィールドに書き込まれます。FECビット文字列の次のビットは、FECパケットのマーカービットに書き込まれます。FECビット文字列の次の7ビットは、FECパケットヘッダーのPT回復フィールドに書き込まれます。FECビット文字列の次の32ビットは、パケットヘッダーのTS回復フィールドに書き込まれます。次の16ビットは、FECパケットヘッダーの長さの回復フィールドに書き込まれます。残りのビットは、FECパケットのペイロードに設定されています。
8 Recovery Procedures
8回の回復手順
The FEC packets allow end systems to recover from the loss of media packets. All of the header fields of the missing packets, including CSRC lists, extensions, padding bits, marker and payload type, are recoverable. This section describes the procedure for performing this recovery.
FECパケットにより、エンドシステムはメディアパケットの損失から回復できます。CSRCリスト、拡張機能、パディングビット、マーカー、ペイロードタイプなど、欠落しているパケットのヘッダーフィールドはすべて回復可能です。このセクションでは、この回復を実行する手順について説明します。
Recovery requires two distinct operations. The first determines which packets (media and FEC) must be combined in order to recover a missing packet. Once this is done, the second step is to actually reconstruct the data. The second step MUST be performed as described below. The first step MAY be based on any algorithm chosen by the implementer. Different algorithms result in a tradeoff between complexity and the ability to recover missing packets if at all possible.
回復には2つの異なる操作が必要です。最初に、欠落したパケットを回復するために、どのパケット（メディアとFEC）を組み合わせる必要があるかを決定します。これが完了したら、2番目のステップは実際にデータを再構築することです。2番目のステップは、以下に説明するように実行する必要があります。最初のステップは、実装者が選択したアルゴリズムに基づいている場合があります。異なるアルゴリズムは、可能であれば複雑さと欠落しているパケットを回復する能力との間のトレードオフをもたらします。
Let T be the list of packets (FEC and media) which can be combined to recover some media packet xi. The procedure is as follows:
Tを、組み合わせていくつかのメディアパケットXIを回復できるパケット（FECとメディア）のリストとします。手順は次のとおりです。
1. For the media packets in T, compute the bit string as described in the protection operation of the previous section.
1. Tのメディアパケットの場合、前のセクションの保護操作で説明されているように、ビット文字列を計算します。
2. For the FEC packet in T, compute the bit string in the same fashion, except use the PT Recovery instead of Payload Type, TS Recovery instead of Timestamp, and always set the CSRC list, extension, and padding to null.
2. TのFECパケットの場合、ペイロードタイプの代わりにPT回復、タイムスタンプの代わりにTS回復を使用し、常にCSRCリスト、拡張機能、およびパディングをNULLに設定します。
3. If any of the bit strings generated from the media packets are shorter than the bit string generated from the FEC packet, pad them to be the same length as the bit string generated from the FEC. The padding MUST be added at the end of the bit string, and MAY be of any value.
3. メディアパケットから生成されたビット文字列のいずれかが、FECパケットから生成されたビット文字列よりも短い場合、それらをパッドして、FECから生成されたビット文字列と同じ長さになります。パディングはビット文字列の最後に追加する必要があり、あらゆる価値がある場合があります。
4. Perform the exclusive or (parity) operation across the bit strings, resulting in a recovery bit string.
4. ビット文字列全体に排他的または（パリティ）操作を実行し、回復ビット文字列になります。
5. Create a new packet with the standard 12 byte RTP header and no payload.
5. 標準の12バイトRTPヘッダーとペイロードなしの新しいパケットを作成します。
6. Set the version of the new packet to 2.
6. 新しいパケットのバージョンを2に設定します。
7. Set the Padding bit in the new packet to the first bit in the recovery bit string.
7. 新しいパケットのパディングビットを、Recovery Bit Stringの最初のビットに設定します。
8. Set the Extension bit in the new packet to the second bit in the recovery bit string.
8. 新しいパケットの拡張ビットを、Recovery Bit Stringの2番目のビットに設定します。
9. Set the CC field to the next four bits in the recovery bit string.
9. Recoveryビット文字列の次の4ビットにCCフィールドを設定します。
10. Set the marker bit in the new packet to the next bit in the recovery bit string.
10. 新しいパケットのマーカービットを、Recoveryビット文字列の次のビットに設定します。
11. Set the payload type in the new packet to the next 7 bits in the recovery bit string.
11. 新しいパケットのペイロードタイプを、Recoveryビット文字列の次の7ビットに設定します。
12. Set the SN field in the new packet to xi.
12. 新しいパケットのSNフィールドをxiに設定します。
13. Set the TS field in the new packet to the next 32 bits in the recovery bit string.
13. 新しいパケットのTSフィールドを、Recovery Bit Stringの次の32ビットに設定します。
14. Take the next 16 bits of the recovery bit string. Whatever unsigned integer this represents (assuming network-order), take that many bytes from the recovery bit string and append them to the new packet. This represents the CSRC list, extension, payload, and padding.
14. Recovery Bit Stringの次の16ビットを取ります。これが表す（ネットワークオーダーを想定する）署名されていない整数が何であれ、Recovery Bit Stringから多くのバイトを取得し、新しいパケットに追加します。これは、CSRCリスト、拡張機能、ペイロード、およびパディングを表します。
15. Set the SSRC of the new packet to the SSRC of the media stream it's protecting.
15. 新しいパケットのSSRCを、保護しているメディアストリームのSSRCに設定します。
This procedure will completely recover both the header and payload of an RTP packet.
この手順は、RTPパケットのヘッダーとペイロードの両方を完全に回復します。
The previous section discussed how to recover a media packet with sequence number xi when all of the packets needed to recover it were available. The decision about whether to attempt recovery of some media packet xi, and how to determine if sufficient data is available to recover it, is left to the implementer. However, this section provides a simple algorithm which MAY be used for this purpose.
前のセクションでは、シーケンス番号XIでメディアパケットを回復する方法について説明しました。一部のメディアパケットXIの回復を試みるかどうか、およびそれを回復するのに十分なデータが利用可能かどうかを判断する方法に関する決定は、実装者に任されています。ただし、このセクションでは、この目的に使用できる簡単なアルゴリズムを提供します。
The algorithm is described below in C code. The code assumes that several functions exist. recover_packet() takes the sequence number of a packet, and an FEC packet. Using the FEC packet and data packets received previously, the data packet with the given sequence number is recovered. add_fec_to_pending_list() adds the given FEC packet to a linked list of FEC packets which have not yet been used for recovery. wait_for_packet() waits for a packet, FEC or data, from the network. remove_from_pending_list() removes the FEC packet from the pending list. The structure packet contains a boolean variable fec which is true when the packet is FEC, false if it's media. When its an FEC packet, the mask and snbase field contain those values from the FEC packet header. When it's a media packet, the sn variable contains the sequence number of the packet. The global array A indicates which media packets have been received, and which have not. It is indexed by the sequence number of the packet.
アルゴリズムについては、以下にCコードで説明します。コードは、いくつかの関数が存在すると想定しています。Recover_Packet（）は、パケットのシーケンス番号とFECパケットを取得します。以前に受信したFECパケットとデータパケットを使用して、指定されたシーケンス番号を持つデータパケットが回復します。ADD_FEC_TO_PENDING_LIST（）は、指定されたFECパケットを、まだ回復に使用されていないFECパケットのリンクリストに追加します。wait_for_packet（）は、ネットワークからパケット、FEC、またはデータを待ちます。remove_from_pending_list（）保留中のリストからFECパケットを削除します。構造パケットには、パケットがFECの場合に真のブール変数FECが含まれています。メディアの場合はfalseです。FECパケットの場合、マスクとSNBaseフィールドには、FECパケットヘッダーの値が含まれています。メディアパケットの場合、SN変数にはパケットのシーケンス番号が含まれます。グローバル配列Aは、どのメディアパケットが受信され、どのメディアパケットが受信されていないかを示しています。パケットのシーケンス番号によってインデックスが付けられます。
The function fec_recovery implements the algorithm. It waits for packets, and when it receives an FEC packet, calls recover_with_fec() to attempt to use it to recover. If no recovery is possible, the FEC packet is stored for later attempts. If the received packet was a media packet, its presence is noted, and any old FEC packets are checked to see if recovery is now possible. Recovered packets are treated as if they were received, triggering further attempts at recovery.
関数fec_recoveryはアルゴリズムを実装します。パケットが待機し、FECパケットを受信したら、Recover_with_fec（）を呼び出して回復しようとします。回復が不可能な場合、FECパケットは後の試みのために保存されます。受信したパケットがメディアパケットである場合、その存在が記録され、古いFECパケットがチェックされて、回復が可能かどうかを確認します。回収されたパケットは、それらが受信されたかのように扱われ、回復のさらなる試みをトリガーします。
A real implementation will need to use a circular buffer instead of the simple array (A in the code) in order to avoid running off the end of the buffer. In addition, the code below does not attempt to free up FEC packets that are old and were never used. Normally, such discarding is done based on time constraints introduced by the playout buffer. If an FEC data protects packets whose play time has elapsed, the FEC is no longer needed.
バッファの端からの実行を避けるために、実際の実装では、単純な配列（コード内のA）の代わりに円形バッファーを使用する必要があります。さらに、以下のコードは、古く、使用されていないFECパケットを解放しようとはしません。通常、そのような破棄は、プレイアウトバッファーによって導入された時間の制約に基づいて行われます。FECデータがプレイ時間が経過したパケットを保護する場合、FECは不要になります。
typedef struct packet_s {
typedef struct packet_s {
BOOLEAN fec; /* FEC or media */
int sn; /* SN of the packet, for media only */
BOOLEAN mask[24]; /* Mask, FEC only */
int snbase; /* SN Base, FEC only */
struct packet_s *next;
struct packet_s *next;
} packet;
} packet;
BOOLEAN A[65535]; packet *pending_list;
ブールA [65535];packet *pending_list;
packet *recover_with_fec(packet *fec_pkt) {
packet *data_pkt;
int pkts_present, /* number of packets from the mask that are
present */
pkts_needed, /* number of packets needed is the number of ones
in the mask minus 1 */
pkt_to_recover, /* sn of the packet we are recovering */
i;
pkts_present = 0;
pkts_present = 0;
/* The number of packets needed is the number of ones in the mask
minus 1. The code below increments pkts_needed by the number
of ones in the mask, so we initialize this to -1 so that the
final count is correct */
pkts_needed = -1;
/* Go through all 24 bits in the mask, and check if we have
all but one of the media packets */
for(i = 0; i < 24; i++) {
/* If the packet is here and in the mask, increment counter */
if(A[i+fec_pkt->snbase] && fec_pkt->mask[i]) pkts_present++;
/* Count the number of packets needed as well */
if(fec_pkt->mask[i]) pkts_needed++;
/* The packet to recover is the one with a bit in the
mask that's not here yet */
if(!A[i+fec_pkt->snbase] && fec_pkt->mask[i])
pkt_to_recover = i+fec_pkt->snbase;
}
/* If we can recover, do so. Otherwise, return NULL */
if(pkts_present == pkts_needed) {
data_pkt = recover_packet(pkt_to_recover, fec_pkt);
} else {
data_pkt = NULL;
}
return(data_pkt); }
return（data_pkt）;}
void fec_recovery() {
void fec_recovery（）{
packet *p, /* packet received or regenerated */
*fecp, /* fec packet from pending list */
*pnew; /* new packets recovered */
while(1) {
while（1）{
p = wait_for_packet(); /* get packet from network */
while(p) {
while（p）{
/* if it's an FEC packet, try to recover with it. If we can't,
store it for later potential use. If we can recover, act as
if the recovered packet is received and try to recover some
more. Otherwise, if it's a data packet, mark it as received,
and check if we can now recover a data packet with the list
of pending FEC packets */
if(p->fec == TRUE) {
pnew = recover_with_fec(p);
if(pnew)
if（pnew）
A[pnew->sn] = TRUE;
else
add_fec_to_pending_list(p);
/* We assign pnew to p since the while loop will continue
to recover based on p not being NULL */
p = pnew;
p = pnew;
} else {
} それ以外 {
/* Mark this data packet as here */
A[p->sn] = TRUE;
free(p);
p = NULL;
/* Go through pending list. Try and recover a packet using
each FEC. If we are successful, add the data packet to
the list of received packets, remove the FEC packet from
the pending list, since we've used it, and then try to
recover some more */
for(fecp = pending_list; fecp != NULL; fecp = fecp->next) {
pnew = recover_with_fec(fecp);
if(pnew) {
/* The packet is now here, as we've recovered it */
A[pnew->sn] = TRUE;
/* One FEC packet can only be used once to recover,
so remove it from the pending list */
remove_fec_from_pending_list(fecp);
remove_fec_from_pending_list（fecp）;
p = pnew;
p = pnew;
break; }
壊す;}
} /*for*/
} /*p->fec was false */
} /* while p*/
} /* while 1 */
}
}
9 Example
9つの例
Consider 2 media packets to be sent, x and y, from SSRC 2. Their sequence numbers are 8 and 9, respectively, with timestamps of 3 and 5, respectively. Packet x uses payload type 11, and packet y uses payload type 18. Packet x is has 10 bytes of payload, and packet y 11. Packet y has its marker bit set. The RTP headers for packets x and y are shown in Figures 3 and 4 respectively.
SSRC 2から送信される2つのメディアパケット、xとyを考慮してください。それらのシーケンス番号は、それぞれ3と5のタイムスタンプがあります。パケットxはペイロードタイプ11を使用し、パケットyはペイロードタイプ18を使用します。パケットxにはペイロードが10バイト、パケットy 11があります。パケットyにはマーカービットが設定されています。パケットXとYのRTPヘッダーをそれぞれ図3と4に示します。
Media Packet x
メディアパケットx
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|0|0 0 0 1 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 0 PTI: 11 SN: 8 TS: 3 SSRC: 2
バージョン：2パディング：0拡張：0マーカー：0 PTI：11 SN：8 TS：3 SSRC：2
Figure 3: RTP Header for Media Packet X
図3：メディアパケットxのRTPヘッダー
An FEC packet is generated from these two. We assume that payload type 127 is used to indicate an FEC packet. The resulting RTP header is shown in Figure 5.
これら2つからFECパケットが生成されます。ペイロードタイプ127がFECパケットを示すために使用されると仮定します。結果のRTPヘッダーを図5に示します。
The FEC header in the FEC packet is shown in Figure 6.
FECパケットのFECヘッダーを図6に示します。
11 Use with Redundant Encodings
11冗長エンコーディングで使用します
One can consider an FEC packet as a "redundant coding" of the media.
FECパケットをメディアの「冗長コーディング」と見なすことができます。
Media Packet y
メディアパケットy
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|1|0 0 1 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 1 PTI: 18 SN: 9 TS: 5 SSRC: 2
バージョン：2パディング：0拡張：0マーカー：1 PTI：18 SN：9 TS：5 SSRC：2
Figure 4: RTP Header for Media Packet Y
図4：メディアパケットyのRTPヘッダー
Because of this, the payload format for encoding of redundant audio data [5] can be used to carry the FEC data along with the media. The procedure for this is as follows.
このため、冗長なオーディオデータ[5]のエンコード用のペイロード形式を使用して、メディアとともにFECデータを運ぶことができます。これの手順は次のとおりです。
The FEC operation defined above acts on a stream of RTP media packets. The stream which is operated on is the stream before the encapsulation defined in RFC 2198 [5]. In other words, the media stream to be protected is encapsulated in standard RTP media packets. The FEC operation above is performed (with one minor change), generating a stream of FEC packets. The change to the procedure above is that if the RTP packets being protected contain an RTP extension, padding, or a CSRC list, these MUST be removed from the packets, and the CC field, Padding Bit, and Extension but MUST be set to zero, before the FEC operation is applied. These modified packets are used in the procedure above. Note that the sender MUST still send the original packets (with the CSRC list, padding, and extension in tact) as the primary encoding in RFC 2198. The removal of these fields only applies to the protection operation.
上記で定義されたFEC操作は、RTPメディアパケットのストリームに作用します。動作するストリームは、RFC 2198で定義されているカプセル化の前のストリームです[5]。つまり、保護されるメディアストリームは、標準のRTPメディアパケットにカプセル化されています。上記のFEC操作が実行され（1つの小さな変更があります）、FECパケットのストリームが生成されます。上記の手順の変更は、保護されているRTPパケットにRTP拡張機能、パディング、またはCSRCリストが含まれている場合、これらはパケットから削除する必要があり、CCフィールド、パディングビット、および拡張機能をゼロに設定する必要があることです。、FEC操作が適用される前に。これらの変更されたパケットは、上記の手順で使用されます。送信者は、RFC 2198での主要なエンコードとして、元のパケット（CSRCリスト、パディング、および拡張機能）を引き続き送信する必要があることに注意してください。これらのフィールドの削除は保護操作にのみ適用されます。
Once the FEC packets have been generated, the media payload is extracted from the media packets. This payload is used as the primary encoding as defined in RFC 2198. Then, the FEC header and payload of the FEC packets is extracted, and treated as a redundant encoding. Additional redundant encodings, besides FEC, MAY be added to the packet as well. These encodings will not be protected by FEC, however.
FECパケットが生成されると、メディアパケットがメディアパケットから抽出されます。このペイロードは、RFC 2198で定義されているプライマリエンコードとして使用されます。その後、FECパケットのFECヘッダーとペイロードが抽出され、冗長エンコードとして扱われます。FECに加えて、追加の冗長エンコーディングもパケットに追加できます。ただし、これらのエンコーディングはFECによって保護されません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 1 PTI: 127 SN: 1 TS: 5 SSRC: 2
バージョン：2パディング：0拡張：0マーカー：1 PTI：127 SN：1 TS：5 SSRC：2
Figure 5: RTP Header of FEC for Packets X and Y
図5：パケットXとYのFECのRTPヘッダー
The redundant encodings header for the primary codec is set as defined in RFC 2198. The redundant encodings header for the FEC data is set as follows. The block PT is set to the dynamic PT associated with the FEC format. The block length is set to the sum of the lengths of the FEC header and payload. The timestamp offset SHOULD be set to zero. The secondary coder payload includes the FEC header and FEC payload.
プライマリコーデックの冗長エンコーディングヘッダーは、RFC 2198で定義されているように設定されています。FECデータの冗長エンコーディングヘッダーは、次のように設定されます。ブロックPTは、FEC形式に関連付けられた動的PTに設定されます。ブロックの長さは、FECヘッダーとペイロードの長さの合計に設定されます。タイムスタンプのオフセットはゼロに設定する必要があります。セカンダリコーダーのペイロードには、FECヘッダーとFECペイロードが含まれます。
At the receiver, the primary codec and all secondary codecs are extracted as separate RTP packets. This is done by copying the sequence number, SSRC, marker bit, CC field, RTP version, and extension bit from the RTP header of the redundant encodings packet to the RTP header of each extracted packet. If the secondary codec contains FEC, the CC field, Extension Bit, and Padding Bit in the RTP header of the FEC packet MUST be set to zero instead. The payload type identifier in the extracted packet is copied from the block PT of the redundant encodings header. The timestamp of the extracted packet is the difference between the timestamp in the RTP header and the offset in the block header. The payload of the extracted packet is the data block. This will result in the FEC stream and media stream being extracted.
受信機では、プライマリコーデックとすべてのセカンダリコーデックが個別のRTPパケットとして抽出されます。これは、シーケンス番号、SSRC、マーカービット、CCフィールド、RTPバージョン、および拡張ビットを冗長エンコーディングパケットのRTPヘッダーから、抽出された各パケットのRTPヘッダーにコピーすることによって行われます。セカンダリコーデックにFECが含まれている場合、FECパケットのRTPヘッダーのCCフィールド、拡張ビット、およびパディングビットを代わりにゼロに設定する必要があります。抽出されたパケットのペイロードタイプ識別子は、冗長エンコーディングヘッダーのブロックPTからコピーされます。抽出されたパケットのタイムスタンプは、RTPヘッダーのタイムスタンプとブロックヘッダーのオフセットの違いです。抽出されたパケットのペイロードはデータブロックです。これにより、FECストリームとメディアストリームが抽出されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SN base: 8 [min(8,9)]
len. rec.: 1 [8 xor 9]
E: 0
PTI rec.: 25 [11 xor 18]
mask: 3
TS rec.: 6 [3 xor 5]
The payload length is 11 bytes.
ペイロード長は11バイトです。
Figure 6: FEC Header of Result
図6：結果のFECヘッダー
To use the FEC and media packets for recovery, the CSRC list, extension, and padding MUST be removed from the media packets, if present, and the CC field, Extension Bit, and Padding Bit MUST be set to zero. These modified media packets, along with the FEC packets, are then used to recover based on the procedures in section 8. The recovered media packets will always have no extension, padding, or CSRC list. An implementation MAY copy these fields into the recovered packet from another media packet, if available.
FECおよびメディアパケットを回復に使用するには、存在する場合はCSRCリスト、拡張機能、およびパディングをメディアパケットから削除する必要があり、CCフィールド、拡張ビット、およびパディングビットをゼロに設定する必要があります。これらの変更されたメディアパケットは、FECパケットとともに、セクション8の手順に基づいて回復するために使用されます。回復したメディアパケットには、常に拡張機能、パディング、またはCSRCリストがありません。実装は、利用可能な場合、これらのフィールドを別のメディアパケットから回復したパケットにコピーする場合があります。
Using the redundant encodings payload format also implies that the marker bit may not be recovered correctly. Applications MUST set the marker bit to zero in media packets reconstructed using FEC encapsulated in RFC 2198 redundancy.
冗長エンコーディングの使用ペイロード形式を使用すると、マーカービットが正しく回復しないことを意味します。アプリケーションは、RFC 2198冗長性でカプセル化されたFECを使用して再構築されたメディアパケットでマーカービットをゼロに設定する必要があります。
An advantage of this approach is a reduction in the overhead for sending FEC packets.
このアプローチの利点は、FECパケットを送信するためのオーバーヘッドの削減です。
11 Indicating FEC Usage in SDP
11 SDPでのFEC使用量を示す
FEC packets contain RTP packets with dynamic payload type values. In addition, the FEC packets can be sent on separate multicast groups or separate ports from the media. The FEC can even be carried in packets containing media, using the redundant encodings payload format [5]. These configuration options must be indicated out of band. This section describes how this can be accomplished using the Session Description Protocol (SDP), specified in RFC 2327 [6].
FECパケットには、動的なペイロードタイプの値を持つRTPパケットが含まれています。さらに、FECパケットは、メディアから個別のマルチキャストグループまたは個別のポートで送信できます。FECは、冗長なエンコーディングペイロードフォーマット[5]を使用して、メディアを含むパケットで運ぶこともできます。これらの構成オプションは、バンドから表示する必要があります。このセクションでは、RFC 2327 [6]で指定されたセッション説明プロトコル（SDP）を使用してこれを達成する方法について説明します。
In the first case, the FEC packets are sent as a separate stream. This can mean they are sent on a different port and/or multicast group from the media. When this is done, several pieces of information must be conveyed:
最初のケースでは、FECパケットは別のストリームとして送信されます。これは、メディアから別のポートおよび/またはマルチキャストグループで送信されることを意味します。これが行われた場合、いくつかの情報を伝える必要があります。
o The address and port where the FEC is being sent to
o FECが送信されているアドレスとポート
o The payload type number for the FEC
o FECのペイロードタイプ番号
o Which media stream the FEC is protecting
o FECが保護しているメディアストリーミング
The payload type number for the FEC is conveyed in the m line of the media it is protecting, listed as if it were another valid encoding for the stream. There is no static payload type assignment for FEC, so dynamic payload type numbers MUST be used. The binding to the number is indicated by an rtpmap attribute. The name used in this binding is "parityfec".
FECのペイロードタイプ番号は、保護しているメディアのm行で伝えられ、ストリームの別の有効なエンコードであるかのようにリストされています。FECの静的なペイロードタイプの割り当てはないため、動的なペイロードタイプ番号を使用する必要があります。数値へのバインディングは、RTPMAP属性によって示されます。このバインディングで使用される名前は「パリティフェック」です。
The presence of the payload type number in the m line of the media it is protecting does not mean the FEC is sent to the same address and port as the media. Instead, this information is conveyed through an fmtp attribute line. The presence of the FEC payload type on the m line of the media serves only to indicate which stream the FEC is protecting.
保護しているメディアのm行にペイロードタイプ番号が存在することは、FECがメディアと同じアドレスとポートに送信されるという意味ではありません。代わりに、この情報はFMTP属性行を介して伝えられます。メディアのM行にFECペイロードタイプの存在は、FECがどのストリームを保護しているかを示すだけです。
The format for the fmtp line for FEC is:
FECのFMTP行の形式は次のとおりです。
a=fmtp:<number> <port> <network type> <addresss type> <connection
address>
where 'number' is the payload type number present in the m line. Port is the port number where the FEC is sent to. The remaining three items - network type, address type, and connection address - have the same syntax and semantics as the c line from SDP. This allows the fmtp line to be partially parsed by the same parser used on the c lines. Note that since FEC cannot be hierarchically encoded, the <number of addresses> parameter MUST NOT appear in the connection address.
ここで、「番号」はM行に存在するペイロードタイプ番号です。ポートは、FECが送信されるポート番号です。ネットワークタイプ、アドレスタイプ、および接続アドレス - の残りの3つの項目は、SDPのC行と同じ構文とセマンティクスを持っています。これにより、FMTPラインをCラインで使用する同じパーサーによって部分的に解析できます。FECを階層的にエンコードできないため、<アドレスの数>パラメーターは接続アドレスに表示されないことに注意してください。
The following is an example SDP for FEC:
以下は、FECのSDPの例です。
v=0
o=hamming 2890844526 2890842807 IN IP4 126.16.64.4
s=FEC Seminar
c=IN IP4 224.2.17.12/127
t=0 0
m=audio 49170 RTP/AVP 0 78
a=rtpmap:78 parityfec/8000
a=fmtp:78 49172 IN IP4 224.2.17.12/127
m=video 51372 RTP/AVP 31 79
a=rtpmap:79 parityfec/8000
a=fmtp:79 51372 IN IP4 224.2.17.13/127
The presence of two m lines in this SDP indicates that there are two media streams - one audio and one video. The media format of 0 indicates that the audio uses PCM, and is protected by FEC with payload type number 78. The FEC is sent to the same multicast group and TTL as the audio, but on a port number two higher (49172). The video is protected by FEC with payload type number 79. The FEC appears on the same port as the video (51372), but on a different multicast address.
このSDPに2つのMラインが存在することは、2つのメディアストリームがあることを示しています。1つのオーディオと1つのビデオです。0のメディア形式は、オーディオがPCMを使用し、ペイロードタイプ番号78でFECによって保護されていることを示します。FECはオーディオと同じマルチキャストグループとTTLに送信されますが、ポート2が高い（49172）。ビデオは、ペイロードタイプ番号79のFECによって保護されています。FECは、ビデオ（51372）と同じポートに表示されますが、異なるマルチキャストアドレスに表示されます。
When the FEC stream is being sent as a secondary codec in the redundant encodings format, this must be signaled through SDP. To do this, the procedures defined in RFC 2198 are used to signal the use of redundant encodings. The FEC payload type is indicated in the same fashion as any other secondary codec. An rtpmap attribute MUST be used to indicate a dynamic payload type number for the FEC packets. The FEC MUST protect only the main codec. In this case, the fmtp attribute for the FEC MUST NOT be present.
FECストリームが冗長エンコーディング形式でセカンダリコーデックとして送信されている場合、これはSDPを介して通知する必要があります。これを行うには、RFC 2198で定義されている手順を使用して、冗長エンコーディングの使用を知らせます。FECペイロードタイプは、他のセカンダリコーデックと同じ方法で示されています。RTPMAP属性を使用して、FECパケットの動的なペイロードタイプ番号を示す必要があります。FECはメインコーデックのみを保護する必要があります。この場合、FECのFMTP属性が存在しないでください。
For example:
例えば：
m=audio 12345 RTP/AVP 121 0 5 100 a=rtpmap:121 red/8000/1 a=rtpmap:100 parityfec/8000 a=fmtp:121 0/5/100 This SDP indicates that there is a single audio stream, which can consist of PCM (media format 0) , DVI (media format 5), the redundant encodings (indicated by media format 121, which is bound to red through the rtpmap attribute), or FEC (media format 100, which is bound to parityfec through the rtpmap attribute). Although the FEC format is specified as a possible coding for this stream, the FEC MUST NOT be sent by itself for this stream. Its presence in the m line is required only because non-primary codecs must be listed here according to RFC 2198. The fmtp attribute indicates that the redundant encodings format can be used, with DVI as a secondary coding and FEC as a tertiary encoding.
M =オーディオ12345 RTP/AVP 121 0 5 100 A = RTPMAP：121 RED/8000/1 A = RTPMAP：100 PARITYFEC/8000 A = FMTP：121 0/5/100このSDPは、単一のオーディオストリームがあることを示しています。PCM（メディア形式0）、DVI（メディア形式5）、冗長エンコーディング（RTPMAP属性を介して赤に結合するメディア形式121で示されています）、またはFEC（メディア形式100、RTPMAP属性を介したパリティフェック）。FEC形式は、このストリームの可能性のあるコーディングとして指定されていますが、FECはこのストリームに対して単独で送信する必要はありません。Mラインでの存在は、RFC 2198に従って非プリマリーコーデックをここにリストする必要があるためにのみ必要です。FMTP属性は、冗長エンコーディング形式を使用できることを示しています。
RTSP [7] can be used to request FEC packets to be sent as a separate stream. When SDP is used with RTSP, the Session Description does not include a connection address and port number for each stream. Instead, RTSP uses the concept of a "Control URL". Control URLs are used in SDP in two distinct ways.
RTSP [7]を使用して、FECパケットをリクエストして別のストリームとして送信できます。SDPをRTSPで使用する場合、セッションの説明には、各ストリームの接続アドレスとポート番号が含まれていません。代わりに、RTSPは「コントロールURL」の概念を使用します。コントロールURLは、2つの異なる方法でSDPで使用されます。
1. There is a single control URL for all streams. This is referred to as "aggregate control". In this case, the fmtp line for the FEC stream is omitted.
1. すべてのストリームに単一のコントロールURLがあります。これは「集計制御」と呼ばれます。この場合、FECストリームのFMTPラインは省略されています。
2. There is a Control URL assigned to each stream. This is referred to as "non-aggregate control". In this case, the fmtp line specifies the Control URL for the stream of FEC packets. The URL may be used in a SETUP command by an RTSP client.
2. 各ストリームに割り当てられたコントロールURLがあります。これは「非凝集制御」と呼ばれます。この場合、FMTPラインは、FECパケットのストリームのコントロールURLを指定します。URLは、RTSPクライアントがセットアップコマンドで使用できます。
The format for the fmtp line for FEC with RTSP and non-aggregate control is:
RTSPおよび非凝集制御を備えたFECのFMTPラインの形式は次のとおりです。
a=fmtp:<number> <control URL>
where 'number' is the payload type number present in the m line. Control URL is the URL used to control the stream of FEC packets. Note that the Control URL does not need to be an absolute URL. The rules for converting a relative Control URL to an absolute URL are given in RFC 2326, Section C.1.1.
ここで、「番号」はM行に存在するペイロードタイプ番号です。制御URLは、FECパケットのストリームを制御するために使用されるURLです。コントロールURLは絶対URLである必要はないことに注意してください。相対コントロールURLを絶対URLに変換するためのルールは、RFC 2326、セクションC.1.1に記載されています。
12 Security Considerations
12のセキュリティ上の考慮事項
The use of FEC has implications on the usage and changing of keys for encryption. As the FEC packets do consist of a separate stream, there are a number of permutations on the usage of encryption. In particular:
FECの使用は、暗号化のためのキーの使用と変更に影響を与えます。FECパケットは別のストリームで構成されているため、暗号化の使用に関する多くの順列があります。特に：
o The FEC stream may be encrypted, while the media stream is not.
o FECストリームは暗号化される場合がありますが、メディアストリームは暗号化されていません。
o The media stream may be encrypted, while the FEC stream is not.
o メディアストリームは暗号化される場合がありますが、FECストリームは暗号化されていません。
o The media stream and FEC stream are both encrypted, but using different keys.
o メディアストリームとFECストリームはどちらも暗号化されていますが、異なるキーを使用しています。
o The media stream and FEC stream are both encrypted, but using the same key.
o メディアストリームとFECストリームは両方とも暗号化されていますが、同じキーを使用しています。
The first three of these would require any application level signaling protocols to be aware of the usage of FEC, and to thus exchange keys for it and negotiate its usage on the media and FEC streams separately. In the final case, no such additional mechanisms are needed. The first two cases present a layering violation, as FEC packets should really be treated no differently than other RTP packets. Encrypting just one may also make certain known-plaintext attacks possible. For these reasons, applications utilizing encryption SHOULD encrypt both streams.
これらの最初の3つでは、アプリケーションレベルのシグナリングプロトコルがFECの使用を認識し、そのためにキーを交換し、メディアとFECの使用を別々に交渉する必要があります。最後のケースでは、そのような追加のメカニズムは必要ありません。最初の2つのケースは、FECパケットを他のRTPパケットと実際には違った扱いを行う必要があるため、レイヤー違反を示しています。1つだけを暗号化すると、特定の既知のプレーンテキスト攻撃が可能になる場合もあります。これらの理由により、暗号化を使用するアプリケーションは両方のストリームを暗号化する必要があります。
However, the changing of keys becomes problematic. For example, if two packets a and b are sent, and FEC packet f(a,b) is sent, and the keys used for a and b are different, which key should be used to decode f(a,b)? In general, old keys will likely need to be cached, so that when the keys change for the media stream, the old key is kept, and used, until it is determined that the key has changed on the FEC packets as well.
ただし、キーの変更には問題があります。たとえば、2つのパケットAとBが送信され、FECパケットF（A、B）が送信され、AとBに使用されるキーが異なる場合、F（A、B）をデコードするためにどのキーを使用する必要がありますか？一般に、古いキーをキャッシュする必要がある可能性が高いため、メディアストリームのキーが変更されると、古いキーが維持され、FECパケットでキーが変更されたと判断されるまで使用されます。
Another issue with the use of FEC is its impact on network congestion. Adding FEC in the face of increasing network losses is a bad idea, as it can lead to increased congestion and eventual congestion collapse if done on a widespread basis. As a result, implementers MUST NOT substantially increase the amount of FEC in use as network losses increase.
FECの使用に関するもう1つの問題は、ネットワークの混雑への影響です。ネットワーク損失の増加に直面してFECを追加することは、広範囲にわたって行われた場合、混雑の増加と最終的な輻輳崩壊につながる可能性があるため、悪い考えです。その結果、実装者は、ネットワークの損失が増加するにつれて、使用中のFECの量を大幅に増やしてはなりません。
13 Acknowledgments
13謝辞
This work is based on an earlier draft on FEC, submitted by Budge and Mackenzie in 1997. We would also like to thank Steve Casner, Mark Handley, Orion Hodson and Colin Perkins for their comments. Thanks to Anders Klemets who wrote the section on usage with RTSP.
この作業は、1997年にBudgeとMackenzieが提出したFECの以前のドラフトに基づいています。また、Steve Casner、Mark Handley、Orion Hodson、Colin Perkinsのコメントにも感謝します。RTSPで使用に関するセクションを書いたAnders Klemetsに感謝します。
14 Authors' Addresses
14の著者のアドレス
Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07046
Jonathan Rosenberg Dynamicsoft 200エグゼクティブドライブスイート120ウェストオレンジ、ニュージャージー07046
Email: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401, 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401、1214 Amsterdam Ave. New York、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
15 Bibliography
15書誌
[1] J.C. Bolot and A. V. Garcia, "Control mechanisms for packet audio in the internet," in Proceedings of the Conference on Computer Communications (IEEE Infocom) , (San Francisco, California), Mar. 1996.
[1] J.C. BolotおよびA. V. Garcia、「インターネットでのパケットオーディオの制御メカニズム」、コンピューター通信会議（IEEE Infocom）の議事録、（カリフォルニア州サンフランシスコ）、1996年3月。
[2] Perkins, C. and O. Hodson, "Options for Repair of Streaming media", RFC 2354, June 1998.
[2] Perkins、C。and O. Hodson、「ストリーミングメディアの修理のオプション」、RFC 2354、1998年6月。
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[3] Schulzrinne、H.、Casner、S.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[5] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.C.、Vega-Garcia、A。and S. Fosse-Parisis、「冗長なオーディオデータのためのRTPペイロード」、RFC 2198、1997年9月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[7] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[7] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。