Network Working Group A. Li, Ed.
Request for Comments: 5109 December 2007
Obsoletes: 2733, 3009
Category: Standards Track
RTP Payload Format for Generic Forward Error Correction
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 specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009.
このドキュメントは、RTPにカプセル化されたメディアデータのための一般的な前方誤り訂正（FEC）のペイロード形式を指定します。これは、排他的論理和（パリティ）の操作に基づいています。この文書に記載されたペイロードフォーマットは、異なるメディアやチャネル特性に適応するために、様々な保護グループサイズを使用することに加えて、エンドシステムは、様々な保護の長さとレベルを使用して保護を適用することを可能にします。これは、保護されたパケットまたはパケット損失の状況に応じて、ペイロードの重要な部分の部分的な回復の完全な回復を可能にします。この方式は、非FEC-対応ホストと完全に互換性があるので、FECを実装していないマルチキャストグループ内の受信機は、まだ単に保護データを無視して作業することができます。この仕様はRFC 2733およびRFC 3009を廃止この文書で指定されたFECは、RFC 2733およびRFC 3009との下位互換性はありません。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Basic Operation .................................................6
4. Parity Codes ....................................................7
5. Uneven Level Protection (ULP) ...................................7
6. RTP Media Packet Structure ......................................9
7. FEC Packet Structure ............................................9
7.1. Packet Structure ...........................................9
7.2. RTP Header for FEC Packets ................................10
7.3. FEC Header for FEC Packets ................................11
7.4. FEC Level Header for FEC Packets ..........................12
8. Protection Operation ...........................................15
8.1. Generation of the FEC Header ..............................15
8.2. Generation of the FEC Payload .............................16
9. Recovery Procedures ............................................16
9.1. Reconstruction of the RTP Header ..........................16
9.2. Reconstruction of the RTP Payload .........................18
10. Examples ......................................................19
10.1. An Example Offers Similar Protection as RFC 2733 .........19
10.2. An Example with Two Protection Levels ....................21
10.3. An Example with FEC as Redundant Coding ..................26
11. Security Considerations .......................................29
12. Congestion Considerations .....................................30
13. IANA Considerations ...........................................31
13.1. Registration of audio/ulpfec .............................31
13.2. Registration of video/ulpfec .............................32
13.3. Registration of text/ulpfec ..............................34
13.4. Registration of application/ulpfec .......................35
14. Multiplexing of FEC ...........................................36
14.1. FEC as a Separate Stream .................................36
14.2. FEC as Redundant Encoding ................................38
14.3. Offer / Answer Consideration .............................39
15. Application Statement .........................................40
16. Acknowledgments ...............................................42
17. References ....................................................42
17.1. Normative References .....................................42
17.2. Informative References ...................................43
The nature of real-time applications implies that they usually have more stringent delay requirements than normal data transmissions. As a result, retransmission of the lost packets is generally not a valid option for such applications. In these cases, a better method to attempt recovery of information from packet loss is through Forward Error Correction (FEC). FEC is one of the main methods used to protect against packet loss over packet-switched networks [9, 10]. In particular, the use of traditional error correcting codes, such as parity, Reed-Solomon, and Hamming codes, has seen much application. To apply these mechanisms, protocol support is required. RFC 2733 [9] and RFC 3009 [11] defined one of such FEC protocols. However, in these two RFCs a few fields (the P, X, and CC fields) in the RTP header are specified in ways that are not consistent as they are designed in RTP [1]. This prevents the payload-independent validity check of the RTP packets.
リアルタイムアプリケーションの性質は、彼らは通常、通常のデータ伝送よりも厳しい遅延要件を持っていることを意味します。その結果、失われたパケットの再送信は、一般的な用途のための有効なオプションではありません。これらのケースでは、パケット損失からの情報の回復を試みるためのより良い方法は、前方誤り訂正（FEC）を介してです。 FECは、パケット交換ネットワーク上でパケット損失から保護するために使用される主な方法の一つ[9、10]です。特に、このようなパリティ、リードソロモン、およびハミング符号のような従来の誤り訂正符号の使用は、多くのアプリケーションを見ています。これらのメカニズムを適用するには、プロトコルのサポートが必要です。 RFC 2733 [9]およびRFC 3009 [11]そのようなFECプロトコルのいずれかを定義しました。しかしながら、これらの二つのRFCでRTPヘッダ内のいくつかのフィールド（P、X、およびCCフィールドは）それらはRTP [1]に設計されているように一貫していない方法で指定されています。これは、RTPパケットのペイロードに依存しない妥当性チェックを防ぎます。
This document extends the FEC defined in RFC 2733 and RFC 3009 to include unequal error protection on the payload data. It specifies a general algorithm with the two previous RFCs as its special cases. This specification also fixes the above-mentioned inconsistency with RFC 2733 and RFC 3009, and will obsolete those two previous RFCs. Please note that the payload specified in this document is not backward compatible with RFC 2733 and RFC 3009. Because the payload specified in this document is signaled by different MIMEs from those of RFC 3009, there is no concern of misidentification of different parity FEC versions in capacity exchange. For parity FECs specified here and in RFC 2733 and RFC 3009, the payload data are unaltered and additional FEC data are sent along to protect the payload data. Hence, the communication of the payload data would flow without problem between hosts of different parity FEC versions and hosts that did not implement parity FEC. The receiving hosts with incompatible FEC from the sending host would not be able to benefit from the additional FEC data, so it is recommended that existing host implementing RFC 2733 and RFC 3009 should be updated to follow this specification when possible.
この文書では、ペイロードデータの不均一誤り保護を含めるためにRFC 2733およびRFC 3009で定義されたFECを拡張します。それは、その特殊な例として、前の2つのRFCとの一般的なアルゴリズムを指定します。また、この仕様はRFC 2733およびRFC 3009で、上記の矛盾を修正し、それらの前の2つのRFCの意志時代遅れ。この文書で指定されたペイロードは、RFC 3009のものとは異なるMIMESによって通知されるため、この文書で指定されたペイロードは、RFC 2733およびRFC 3009との下位互換性がないことに注意してください、異なるパリティFECバージョンの誤認の心配ではありません能力交換。ここで指定されたパリティのFECのためにと、RFC 2733およびRFC 3009で、ペイロードデータは、ペイロードデータを保護するために沿って送られ、変更されていないと、追加FECデータです。したがって、ペイロードデータの通信は、パリティFECを実装しなかった異なるパリティFECバージョンとホストのホストとの間で問題なく流れることになります。 RFC 2733およびRFC 3009を実装し、既存のホストが可能な場合、この仕様に従うように更新されなければならないことが推奨されるように、送信側ホストからの互換性のないFECと受信ホストは、追加のFECデータの恩恵を受けることができないだろう。
This document defines a payload format for RTP [1] that 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 configurations; (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.
この文書は、リアルタイムメディアの一般的な順方向誤り訂正を可能にする[1] RTPのペイロードのフォーマットを定義します。この文脈において、一般的な手段は、FECプロトコルは、（1）媒体の性質とは無関係に保護されていること、それは、オーディオ、ビデオ、または他の方法です。 （2）FEC多種多様な構成をサポートするのに十分な柔軟性。 （3）FEC技術は、アウトオブバンドシグナリングせずに容易に変更することができるように、適応のために設計されました。 （4）FECパケットを輸送するための異なるメカニズムの数の支援。
Furthermore, in many scenarios the bandwidth of the network connections is a very limited resource. On the other hand, most of the traditional FEC schemes are not designed for optimal utilization of the limited bandwidth resource. An often used improvement is unequal error protection that provides different levels of protection for different parts of the data stream, which vary in importance. The unequal error protection schemes can usually make more efficient use of bandwidth to provide better overall protection of the data stream against the loss. Proper protocol support is essential for realizing these unequal error protection mechanisms. The application of most of the unequal error protection schemes requires having the knowledge of the importance for different parts of the data stream. For that reason, most of such schemes are designed for particular types of media according to the structure of the media protected, and as a result, are not generic.
さらに、多くのシナリオでのネットワーク接続の帯域幅が非常に限られたリソースです。一方、伝統的なFECスキームのほとんどは、限られた帯域幅のリソースの最適な利用のために設計されていません。頻繁に使用される改善は、重要性が異なり、データストリームの異なる部分の保護の異なるレベルを提供する不均一誤り保護です。不均一誤り保護方式は、通常、損失に対するデータ・ストリームのより全体的な保護を提供するために、帯域幅をより効率的に利用することができます。適切なプロトコルのサポートは、これらの不均一誤り保護メカニズムを実現するために不可欠です。不均一誤り保護方式のほとんどのアプリケーションは、データ・ストリームの異なる部分のために重要な知識を持つ必要です。そのため、このようなスキームの大部分は保護されたメディアの構造に応じて媒体の特定のタイプのために設計され、その結果、一般的なものではありません。
The FEC algorithm and protocol are defined in this document for generic forward error correction with unequal error protection for real-time media. The particular algorithm defined here is called the Uneven Level Protection (ULP). The payload data are protected by one or more protection levels. Lower protection levels can provide greater protection by using smaller group sizes (compared to higher protection levels) for generating the FEC packet. As we will discuss below, audio/video applications would generally benefit from unequal error protection schemes that give more protection to the beginning part of each packet such as ULP. The data that are closer to the beginning of the packet are in general more important and tend to carry more information than the data farther behind in the packet.
FECアルゴリズムとプロトコルは、リアルタイムメディアのための不均一誤り保護を持つ一般的な前方誤り訂正のために、この文書で定義されています。ここで定義された特定のアルゴリズムは、不均一なレベルの保護（ULP）と呼ばれています。ペイロードデータは、一つ以上の保護レベルによって保護されています。より低い保護レベルは、FECパケットを生成するための（より高い保護レベルと比較して）より小さなグループサイズを使用して、より大きな保護を提供することができます。私たちは、以下の議論れるように、オーディオ/ビデオアプリケーションは、一般的なULPなど各パケットの先頭部分に、より多くの保護を与える不均一誤り保護方式の恩恵を受けるだろう。パケットの先頭に近いデータは、一般的に、より重要であり、パケット内の遠くの背後にあるデータよりも多くの情報を運ぶ傾向にあります。
It is well known that in many multimedia streams the more important parts of the data are always at the beginning of the data packet. This is the common practice in codec design since the beginning of the packet is closer to the re-synchronization marker at the header and thus is more likely to be correctly decoded. In addition, almost all media formats have the frame headers at the beginning of the packet, which is the most vital part of the packet.
それも多くのマルチメディアデータのより重要な部分は、データ・パケットの先頭に常に流れていることが知られています。パケットの先頭には、ヘッダの再同期マーカに近いので、正しく復号される可能性が高いので、これはコーデック設計で一般的に行われています。また、ほぼすべてのメディアフォーマットは、パケットの最も重要な部分であるパケットの先頭にフレームヘッダを持っています。
For video streams, most modern formats have optional data partitioning modes to improve error resilience in which the video macroblock header data, motion vector data, and Discrete Cosine Transform (DCT) coefficient data are separated into their individual partitions. For example, in ITU-T H.263 version 3, there is the optional data partitioned syntax of Annex V. In MPEG-4 Visual Simple Profile, there is the optional data partitioning mode. When these modes are enabled, the video macroblock (MB) header and motion vector partitions (which are much more important to the quality of the video reconstruction) are transmitted in the partition(s) at the beginning of the video packet while residue DCT coefficient partitions (which are less important) are transmitted in the partition close to the end of the packet. Because the data is arranged in descending order of importance, it would be beneficial to provide more protection to the beginning part of the packet in transmission.
ビデオストリームの場合、最新のフォーマットは、ビデオマクロブロックヘッダ情報、動きベクトルデータ、及び離散コサイン変換する誤り耐性を改善するために、オプションのデータ分割モードを有する（DCT）係数データは、個々のパーティションに分離されます。例えば、ITU-T H.263バージョン3では、MPEG-4ビジュアルシンプルプロファイルでアネックスVの構文を分配任意のデータは、任意のデータ分割モードがあるがあります。これらのモードを有効にすると、（はるかに重要ビデオ再生の品質にある）は、ビデオマクロブロック（MB）ヘッダと動きベクトルパーティションは残留DCT係数ながらビデオパケットの先頭にパーティション（複数可）に送信されます。 （あまり重要でない）パーティションは、パケットの終わりに近いパーティションに送信されます。データが重要で降順に配置されているので、伝送中のパケットの先頭部分に、より多くの保護を提供することは有益です。
For audio streams, the bitstreams generated by many of the new audio codecs also contain data with different classes of importance. These different classes are then transmitted in order of descending importance. Applying more protection to the beginning of the packet would also be beneficial in these cases. Even for uniform-significance audio streams, various time shifting and stretching techniques can be applied to the partially recovered audio data packets.
オーディオストリームのために、新しいオーディオコーデックの多くによって生成されたビットストリームはまた、重要性の異なるクラスのデータが含まれています。これらの異なるクラスは、その後の重要性の高い順に送信されます。パケットの先頭に、より多くの保護を適用することも、これらの場合に有益であろう。均一有意オーディオストリームに対して、種々の時間シフト及び延伸技術は、部分的に復元されたオーディオ・データ・パケットに適用することができます。
Audio/video applications would generally benefit from the FEC algorithms specified in this document. With ULP, the efficiency of the protection of the media payload can potentially be further improved. This document specifies the protocol and algorithm for applying the generic FEC to the RTP media payloads.
オーディオ/ビデオアプリケーションは、一般的に、この文書で指定されたFECアルゴリズムの恩恵を受けるだろう。 ULPと、メディアペイロードの保護の効率は、潜在的にさらに向上させることができます。この文書では、RTPメディアペイロードにジェネリックFECを適用するためのプロトコルとアルゴリズムを指定します。
The following terms are used throughout this document:
以下の用語は、この文書全体で使用されています。
Media Payload: The raw, unprotected user data that are transmitted from the sender. The media payload is placed inside of an RTP packet.
メディアペイロード：送信者から送信された生、保護されていないユーザデータ。メディアペイロードは、RTPパケットの内側に配置されます。
Media Header: 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 FEC algorithms at the transmitter take the media packets as an input. They output both the media packets that they are passed, and newly generated packets called FEC packets, which contain redundant media data used for error correction. The FEC packets are formatted according to the rules specified in this document.
FECパケット送信機におけるFECアルゴリズムは、入力としてメディアパケットを取ります。彼ら出力の両方のエラー訂正のために使用された冗長メディアデータが含まれているメディア、彼らが渡されたパケット、及びFECパケットと呼ばれる、新たに生成されたパケット、。 FECパケットは、この文書で指定されたルールに従ってフォーマットされます。
FEC Header: The header information contained in an FEC packet.
FECヘッダー：FECパケットに含まれるヘッダ情報。
FEC Level Header: The header information contained in an FEC packet for each level.
FECレベルヘッダー：各レベルのFECパケットに含まれるヘッダ情報。
FEC Payload: The payload of an FEC packet. It may be divided into multiple levels.
FECペイロード：FECパケットのペイロード。これは、複数のレベルに分割されてもよいです。
Associated: A FEC packet is said to be "associated" with one or more media packets (or vice versa) when those media packets are used to generate the FEC packet (by use of the exclusive-or operation). It refers to only those packets used to generate the level 0 FEC payload, if not explicitly stated otherwise.
関連：FECパケットは、それらのメディアパケットが（排他的論理和演算を使用することによって）FECパケットを生成するために使用される場合、1つまたは複数のメディアパケット（またはその逆）と「関連」していると言われています。特に明記しない場合は、レベル0 FECペイロードを生成するために使用されるパケットのみを指します。
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 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
The payload format described here is used when the sender in an RTP session would like to protect the media stream it is sending with generic parity FEC. The FEC supported by this format is based on simple exclusive-or (XOR) parities operation. The sender takes the packets from the media stream requiring protection and determines the protection levels for these packets and the protection length for each level. The data are grouped together as described below in Section 7. The XOR operation is applied across the payload to generate the FEC information. The results following the procedures defined here are RTP packets containing FEC information. These packets can be used at the receiver to recover the packets or parts of the packets used to generate the FEC information.
RTPセッションにおける送信者は、それが一般的なパリティFECで送信されたメディアストリームを保護したいとき、ここで説明したペイロードフォーマットが使用されています。この形式でサポートされているFECは、単純な排他的論理和（XOR）パリティ演算に基づいています。送信者は、保護を必要とするメディアストリームからパケットを受け取り、これらのパケットの保護レベルおよび各レベルの保護の長さを決定します。 XOR動作はFEC情報を生成するためにペイロードに印加される第7で以下に説明するようにデータがグループ化されます。ここで定義された手順を以下の結果は、FEC情報を含むRTPパケットです。これらのパケットはFEC情報を生成するために使用されるパケットのパケットまたは一部を回復するために受信機で使用することができます。
The payload format for FEC contains information that allows the sender to tell the receiver exactly which media packets are protected by the FEC packet, and the protection levels and lengths for each of the levels. Specifically, each FEC packet contains an offset mask m(k) for each protection level k. If the bit i in the mask m(k) is set to 1, then media packet number N + i is protected by this FEC packet at level k. N is called the sequence number base, and is sent in the FEC packet as well. The amount of data that is protected at level k is indicated by L(k), which is also sent in the FEC packet. The protection length, offset mask, payload type, and sequence number base fully identify the parity code applied to generate the FEC packet with little overhead. A set of rules is described in Section 7.4 that defines how the mask should be set for different protection levels, with examples in Section 10.
FECのためのペイロード・フォーマットは、送信者がメディアパケットがFECパケットにより保護されて正確に受信機に指示することができ、及びレベルの各々のための保護レベルおよび長さ情報を含んでいます。具体的には、各FECパケットは、各保護レベルkのオフセットマスクM（k）を含んでいます。マスクM（K）におけるビットiは1に設定されている場合、メディアパケット番号N + iがレベルkにおけるこのFECパケットにより保護されています。 Nは、シーケンス番号のベースと呼ばれ、同様にFECパケットで送信されます。レベルkで保護されるデータの量はまた、FECパケットで送信されるL（k）は、によって示されています。保護長、完全パリティコードが少ないオーバーヘッドでFECパケットを生成するために適用される特定のマスク、ペイロードタイプ、および順序番号ベースをオフセット。ルールのセットは、マスクは、セクション10の例で、異なる保護レベルに設定されるべき方法を定義セクション7.4に記載されています。
This document also describes procedures on transmitting all the protection operation parameters in-band. This allows the sender great flexibility; the sender can adapt the protection to current network conditions and be certain the receivers can still make use of the FEC for recovery.
また、このドキュメントでは、帯域内のすべての保護動作パラメータを送信する手順を説明します。これは、送信者に大きな柔軟性を可能にします。送信者は、現在のネットワーク状態に保護を適応し、受信機がまだ回復のためのFECを利用することができ、特定することができます。
At the receiver, both the FEC and original media are received. If no media packets are lost, the FEC packets can be ignored. In the event of a loss, the FEC packets can be combined with other received media to recover all or part of the missing media packets.
受信機において、FECとオリジナルのメディアの両方が受信されます。何のメディアパケットが失われていない場合、FECパケットを無視することができます。損失の場合には、FECパケットが欠落したメディアパケットの全部または一部を回復するために他の受信されたメディアと組み合わせることができます。
For brevity, we define the function f(x,y,..) to be the XOR (parity) operator applied to the data blocks x,y,... The output of this function is another block, called the parity block. For simplicity, we assume here that the parity block is computed as the bitwise XOR of the input blocks. The exact procedure is specified in Section 8.
簡潔にするために、我々は、関数f（x、y、...）XOR（パリティ）オペレータは、...この関数の出力は別のブロックであるデータブロックX、Yに印加されるパリティブロックと呼ばれるようにを定義します。簡単にするために、我々は、パリティブロックが入力ブロックのビットごとの排他的論理和として計算されていることを、ここで想定しています。正確な手順は、セクション8で指定されています。
Protection of data blocks using parity codes is accomplished by generating one or more parity blocks over a group of data blocks. To be most effective, the parity blocks must be generated by linearly independent combinations of data blocks. The particular combination is called a parity code. The payload format uses XOR parity codes.
パリティ符号を用いてデータブロックの保護は、データ・ブロックのグループを介して1つまたは複数のパリティブロックを生成することによって達成されます。最も効果的であるために、パリティブロックは、データブロックの線形独立な組み合わせによって生成されなければなりません。特定の組み合わせは、パリティ符号と呼ばれています。ペイロード形式は、XORパリティコードを使用しています。
For example, consider a parity code that generates a single parity block over two data blocks. If the original media packets are a,b,c,d, the packets generated by the sender are:
例えば、2つのデータブロックにわたる単一のパリティブロックを生成するパリティ符号を考えます。元のメディアパケットは、B、C、Dである場合、送信者によって生成されたパケットです。
a b c d <-- media stream f(a,b) f(c,d) <-- FEC stream
bはC D < - メディアストリームF（a、b）はF（C、D）< - FECストリーム
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を回復するために使用することができます。
It may be useful to point out that there are many other types of forward error correction codes that can also be used to protect the payload besides the XOR parity code. One notable example is Reed-Solomon code, and there are many others [12]. However, XOR parity code is used here because of its effectiveness and simplicity in both protocol design and implementation. This is particularly important for implementation in nodes with limited resources.
また、XORパリティコードに加えてペイロードを保護するために使用することができ、順方向誤り訂正符号の他の多くの種類があることを指摘することが有用であり得ます。一つの注目すべき例は、リードソロモンコードであり、他の多くの[12]があります。しかし、XORパリティコードがあるため、プロトコルの設計と実装の両方でその有効性とシンプルさをここで使用されます。これは、限られた資源を持つノードでの実装のために特に重要です。
As we can see from the simple example above, the protection on the data depends on the size of the group. In the above example, the group size is 2. So if any one of the three packets (two payload packets and one FEC packet) is lost, the original payload data can still be recovered.
我々は上記の簡単な例からわかるように、データの保護は、グループのサイズに依存します。上記の例では、グループのサイズは、元のペイロードデータがまだ回復することができ、したがって、3つのパケット（二ペイロードパケットおよび1つのFECパケット）のいずれか1つが2で失われます。
In general, the FEC protection operation is a trade-off between the bandwidth and the protection strength. The more FEC packets that are generated as a fraction of the source media packets, the stronger the protection against loss but the greater the bandwidth consumed by the combined stream.
一般に、FEC保護動作は、帯域幅と保護強度との間のトレードオフです。よりFECソース・メディア・パケットの一部分として生成されたパケット、より強力な損失に対する保護が、合成ストリームによって消費される帯域幅が大きいです。
As is the common case in most of the media payload, not all the parts of the packets are of the same importance. Using this property, one can potentially achieve more efficient use of the channel bandwidth using unequal error protection, i.e., applying different protection for different parts of the packet. More bandwidth is spent on protecting the more important parts, while less bandwidth on the less important parts.
メディアペイロードのほとんどで一般的な場合と同様に、パケットのないすべての部分が同じ重要です。このプロパティを使用して、一つは、潜在的にパケットの異なる部分に異なる保護を適用すること、すなわち、不均一誤り保護を使用して、チャネル帯域幅のより効率的な使用を達成することができます。より多くの帯域幅はそれほど重要な部分に少ない帯域幅ながら、より多くの重要な部分を保護することに費やされています。
The packets are separated into sections of decreasing importance, and protection of different strength is applied to each portion - the sections are known as "levels". The protection operation is applied independently at each level. A single FEC packet can carry parity data for multiple levels. This algorithm is called uneven level protection, or ULP.
パケットは、重要性を減少させるのセクションに分離され、異なる強度の保護を各部分に適用される - セクションは「レベル」として知られています。保護動作は、各レベルで独立して適用されます。単一のFECパケットは、複数のレベルのためのパリティデータを運ぶことができます。このアルゴリズムは、不均一なレベルの保護、またはULPと呼ばれています。
The protection of ULP is illustrated in Figure 1 below. In this example, two ULP FEC packets are protecting four payload packets.
ULPの保護は、以下の図1に示されています。この例では、2つのULP FECパケットは、4つのペイロード・パケットを保護しています。
ULP FEC packet #1 has only one level, which protects packets A and B. Instead of applying parity operation to the entire packets of A and B, it only protects a length of data of both packets. The length, which can be chosen and changed dynamically during a session, is called the protection length.
ULP FECパケット＃1は、その代わりにAとBの全パケットにパリティ演算を適用することにより、それが唯一の両方のパケットのデータの長さを保護するパケットAおよびBを保護する唯一のレベルを有しています。選択された、セッション中に動的に変更することができる長さは、保護長さと呼ばれます。
ULP FEC packet #2 has two protection levels. The level 0 protection is the same as for ULP FEC packet #1 except that it is operating on packets C and D. The level 1 protection is using parity operation applied on data from packets A, B, C, and D. Note that level 1 protection operates on a different set of packets from level 0 and has a different protection length from level 0, so are any other levels. Information is all conveyed in-band through the protocols specified in this document.
ULP FECパケット＃2は、2つの保護レベルがあります。レベル0の保護は、レベル1保護はパリティ演算を使用して、パケットCおよびD上で動作していることを除いて、ULP FECパケット＃1と同じであるパケットAからのデータに適用され、B、C、およびDは、そのレベルに注意してください1つの保護は、レベル0からのパケットの異なるセット上で動作し、レベル0から異なる保護長さを有しているので、他の任意のレベルです。情報はすべて、この文書で指定されたプロトコルを使用して、帯域内に搬送されます。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Figure 1: Unequal Level Protection
図1：不平等なレベルの保護
As we have discussed in the introduction, media streams usually have the more important parts at the beginning of the packet. It is usually useful to have the stronger protection in the levels closer to the beginning of the packet, and weaker protection in the levels farther back. ULP algorithm provides such FEC protection.
我々は導入で説明したように、メディアストリームは、通常、パケットの先頭に、より重要な部分を持っています。遠くバックレベルのパケットの先頭に近いレベルでの強力な保護、および弱い保護を持っているために、通常は便利です。 ULPアルゴリズムは、このようなFEC保護を提供します。
ULP FEC not only provides more protection to the beginning of the packet (which is more important), it also avoids as much as possible the less efficient scenarios that an earlier section of a packet is unrecoverable while a later section can be recovered (and often has to be discarded).
ULP FECは、（より重要である）、パケットの先頭に、より多くの保護を提供するだけでなく、それはまた、後のセクションは、多くの場合、回復（とすることができるが、パケットの前のセクションが回復不能であることをあまり効率的なシナリオを可能な限り回避します）、廃棄する必要があります。
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.
メディアパケットのフォーマットは、FECによる影響を受けません。 FECは、別々のストリームとして送信されている場合は何もFECがなかったかのように、メディアパケットが送信されます。
This approach has the advantage that media packets can be interpreted by receivers that do not support FEC. This compatibility with non-FEC capable receivers is particularly useful in the multicast scenarios. The overhead for using the FEC scheme is only present in FEC packets, and can be easily monitored and adjusted by tracking the amount of FEC in use.
このアプローチは、メディアパケットは、FECをサポートしていない受信機によって解釈することができるという利点があります。非FEC可能な受信機とのこの互換性は、マルチキャストシナリオで特に有用です。 FECスキームを使用するためのオーバーヘッドは、FECパケットにのみ存在し、かつ容易に使用中のFECの量を追跡することによって監視し調整することができます。
A FEC packet is constructed by placing an FEC header and one or more levels of FEC header and payload into the RTP payload, as shown in Figure 2:
図2に示すように、FECパケットは、FECヘッダ及びRTPペイロードにFECヘッダ及びペイロードの1つ以上のレベルを配置することによって構成されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (12 octets or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header (10 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Packet Structure
図2：FECパケット構造
The RTP header for FEC packets is only used when the FEC are sent in a separate stream from the protected payload stream (as defined in Section 14). Hence, much of the discussion below applies only to that scenario. All the fields in the RTP header of FEC packets are used according to RFC 3550 [1], with some of them further clarified below.
FECは、（セクション14で定義されるように）保護されたペイロードストリームから別のストリームで送信される場合、FECパケットのRTPヘッダにのみ使用されます。そこで、以下の議論の多くはそのシナリオに適用されます。それらのいくつかは、以下でさらに明らかとFECパケットのRTPヘッダ内のすべてのフィールドは、[1] RFC 3550に従って使用されます。
Marker: This field is not used for this payload type, and SHALL be set to 0.
マーカー：このフィールドは、このペイロードタイプのために使用されず、0に設定されなければなりません。
Synchronization Source (SSRC): The SSRC value SHALL be the same as the SSRC value of the media stream it protects.
同期ソース（SSRC）：SSRC値は、それが保護するメディアストリームのSSRC値と同じでなければなりません。
Sequence Number (SN): The sequence number has the standard definition - it MUST be one higher than the sequence number in the previously transmitted FEC packet.
シーケンス番号（SN）：シーケンス番号は、標準的な定義を持っている - それは、以前に送信FECパケット内のシーケンス番号より1高くなければなりません。
Timestamp (TS): The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted. Thus, the TS value in FEC packets is always monotonically increasing.
タイムスタンプ（TS）：タイムスタンプは、FECパケットが送信される瞬間にメディアRTPクロックの値に設定しなければなりません。このように、FECパケット内のTS値は常に単調に増加しています。
Payload type: The payload type for the FEC packets is determined through dynamic, out-of-band means. According to RFC 3550 [1], RTP participants that cannot recognize a payload type must discard it. This provides backward compatibility. The FEC mechanisms can then be used in a multicast group with mixed FEC-capable and FEC-incapable receivers, particularly when the FEC protection is sent as redundant encoding (see Section 14). In such cases, the FEC protection will have a payload type that is not recognized by the FEC-incapable receivers, and will thus be disregarded.
ペイロードタイプ：FECパケットのペイロードタイプは、ダイナミック、アウトオブバンド手段によって決定されます。 RFC 3550によれば、[1]、ペイロードタイプを認識できないRTPの参加者は、それを捨てなければなりません。これは、下位互換性を提供します。 FECメカニズムは、次いでFEC保護が冗長符号化として送信され、特にFEC対応混合し、FEC非対応の受信機、（セクション14を参照）を有するマルチキャストグループに使用することができます。このような場合には、FEC保護は、FEC非対応受信機によって認識されないペイロードタイプを持つことになり、したがって、無視されるであろう。
The FEC header is 10 octets. The format of the header is shown in Figure 3 and consists of extension flag (E bit), long-mask flag (L bit), P recovery field, X recovery field, CC recovery field, M recovery field, PT recovery field, SN base field, TS recovery field, and length recovery field.
FECヘッダは10オクテットです。ヘッダのフォーマットは、図3に示されており、拡張フラグ（Eビット）、ロングマスクフラグ（Lビット）、P回復フィールド、X回復フィールド、CC回復フィールド、M回復フィールド、PT回復フィールド、SNから構成されていますベースフィールド、TS回復フィールド、および長さの回復フィールド。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X| CC |M| PT recovery | SN base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Header Format
図3：FECヘッダー形式
The E bit is the extension flag reserved to indicate any future extension to this specification. It SHALL be set to 0, and SHOULD be ignored by the receiver.
Eビットは、この明細書の任意の将来の拡張を示すために予約拡張フラグです。これは、0に設定されなければならない、と受信機によって無視されるべきです。
The L bit indicates whether the long mask is used. When the L bit is not set, the mask is 16 bits long. When the L bit is set, the mask is then 48 bits long.
Lビットは、長いマスクが使用されているかどうかを示します。 Lビットが設定されていない場合、マスクは16ビット長です。 Lビットがセットされている場合、マスクは、次いで、48ビット長です。
The P recovery field, the X recovery field, the CC recovery field, the M recovery field, and the PT recovery field are obtained via the protection operation applied to the corresponding P, X, CC, M, and PT values from the RTP header of the media packets associated with the FEC packet.
P回復フィールド、X回復フィールド、CC回復フィールド、M回復フィールド、及びPT回復フィールドは、対応するPに印加される保護動作を介して取得され、X、RTPヘッダからCC、M、およびPT値FECパケットに関連したメディアパケットの。
The SN base field MUST be set to the lowest sequence number, taking wrap around into account, of those media packets protected by FEC (at all levels). This allows for the FEC operation to extend over any string of at most 16 packets when the L field is set to 0, or 48 packets when the L field is set to 1, and so on.
SNベースフィールドは、FECにより保護されているもののメディアパケット（すべてのレベルで）で、周りの口座にラップを取って、最低のシーケンス番号に設定しなければなりません。これにはLフィールドが0に設定されている最大で16のパケット、またはLフィールドが1に設定されている48個のパケットの任意の文字列を跨ってFEC演算を可能にし、。
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 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 each of the media packets associated with this FEC packet (in other words, the CSRC list, RTP extension, and padding of the media payload packets, if present, are "counted" as part of the payload). This allows the FEC procedure to be applied even when the lengths of the protected media packets are not identical. For example, assume that an FEC packet is being generated by xor'ing two media packets together. The length of the payload of two media packets is 3 (0b011) and 5 (0b101) bytes, respectively. The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
長さの回復フィールドは、任意の回復されたパケットの長さを決定するために使用されます。なお、このFECパケットに関連するメディアパケットのそれぞれのメディアペイロード、CSRCリスト、拡張及びパディングの（バイト単位）の長さの和の符号なしのネットワーク順の16ビット表現に適用される保護動作を介して計算されます。 （換言すれば、CSRCリスト、RTPの拡張、およびメディアペイロードパケットのパディングは、存在する場合、ペイロードの一部として「カウント」されます）。これは、保護されたメディアパケットの長さが同一でない場合でも、FEC手順が適用されることを可能にします。例えば、FECパケットは、2つのメディアパケットを一緒にXORしにより生成されていると仮定する。 2つのメディアパケットのペイロードの長さは、それぞれ、3（0b011）であり、図5（0b101）バイト。長回復フィールドは、次に0b011 XOR 0b101 = 0b110として符号化されます。
The FEC level header is 4 or 8 octets (depending on the L bit in the FEC header). The formats of the headers are shown in Figure 4.
FECレベルのヘッダが（FECヘッダ内のLビットに応じて）4つの又は8オクテットです。ヘッダのフォーマットは、図4に示されています。
The FEC level headers consist of a protection length field and a mask field. The protection length field is 16 bits long. The mask field is 16 bits long (when the L bit is not set) or 48 bits long (when the L bit is set).
FECレベルヘッダーは保護長フィールド及びマスクフィールドから成ります。保護長フィールドは16ビット長です。マスクフィールドは、（Lビットが設定されていない場合）、または48ビット長（Lビットが設定されている場合）は、16ビット長です。
The mask field in the FEC level header indicates which packets are associated with the FEC packet at the current level. It is either 16 or 48 bits depending on the value of the L bit. 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 most significant bit of the mask corresponds to i=0, and the least significant to i=15 when the L bit is set to 0, or i=47 when the L bit is set to 1.
FECレベルヘッダーのマスクフィールドは、現在のレベルのFECパケットに関連付けられているパケットを示します。これは、Lビットの値に応じて、16または48ビットのいずれかです。マスクのビットiは1に設定されている場合、シーケンス番号Nを有するメディアパケットが+ I Nは、FECパケットヘッダのSNベースフィールドであるこのFECパケットに関連しています。マスクの最上位ビットは、I = 0、及びIの最下位が= 15をLビットが0に設定されている場合、またはI = 47がLビットが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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask cont. (present only when L = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULP Level Header Format
図4：ULPレベルヘッダー形式
The setting of the mask field shall follow the following rules: a. A media packet SHALL be protected only once at each protection level higher than level 0. A media packet MAY be protected more than once at level 0 by different packets, providing the protection lengths of level 0 of these packets are equal.
マスクフィールドの設定は、次の規則に従わなければなりません。メディアパケットは、各保護レベルに一度だけ保護しなければならないレベル0より高いメディアパケットはこれらのパケットのレベル0の保護の長さが等しい提供する、異なるパケットがレベル0で複数回保護されていてもよいです。
b. For a media packet to be protected at level p, it MUST also be protected at level p-1 in any FEC packets. Please note that the protection level p for a media packet can be in an FEC packet that is different from the one that contains protection level p-1 for the same media packet.
B。レベルpで保護されるメディアパケットのために、それはまた、任意のFECパケットにレベルp-1で保護されなければなりません。メディアパケットの保護レベルpは同じメディアパケットの保護レベルp-1が含まれているものとは異なるFECパケットにすることができますのでご注意ください。
c. If a ULP FEC packet contains protection at level p, it MUST also contain protection at level p-1. Note that the combination of payload packets that are protected in level p may be different from those of level p-1.
C。 ULP FECパケットがレベルpでの保護が含まれている場合、それはまた、レベルp-1での保護を含まなければなりません。レベルPで保護されたペイロードパケットの組み合わせがレベルp-1のものと異なっていてもよいことに留意されたいです。
The rationale for rule (a) is that multiple protection increases the complexity of the recovery implementation. At higher levels, the multiple protection offers diminishing benefit, so its application is restricted to level 0 for simpler implementation. The rationale for rule (b) is that the protection offset (for each associated packet) is not explicitly signaled in the protocol. With this restriction, the offset can be easily deducted from protection lengths of the levels. The rationale of rule (c) is that the level of protection is not explicitly indicated. This rule is set to implicitly specify the levels.
（a）は、ルールの理論的根拠は、複数の保護、回復の実装の複雑さを増加させることです。そのアプリケーションは、シンプルな実装のためにレベル0に制限されているので、より高いレベルでは、複数の保護は、減少の利益を提供しています。ルールの論理的根拠（b）は（関連する各パケットに対して）保護オフセットを明示的プロトコルでシグナリングされないことです。この制限により、オフセット容易レベルの保護の長さから控除することができます。ルール（C）の理論的根拠は、保護のレベルが明示されていないことです。このルールは、暗黙的にレベルを指定するために設定されています。
One example of the protection combinations is illustrated in Figure 5 below. It is the same example as shown in Figure 1. This same example is also shown in more detail in Section 10.2 to illustrate how the fields in the headers are set.
保護の組み合わせの一例を以下の図5に示されています。また、ヘッダー内のフィールドが設定されている方法を説明するために、セクション10.2で詳細に示されている図1この同じ例に示すように、同じ例です。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
Payload packet # | ULP FEC packet that protects at level
| L0 L1
---------------------+---------------------------------------
A | #1 #2
B | #1 #2
C | #2 #2
D | #2 #2
Figure 5: An Example of Protection Combination
図5：保護組み合わせの例
In this example, ULP FEC packet #1 only has protection level 0. ULP FEC packet #2 has protection levels 0 and 1. Read across the table, it is shown that payload packet A is protected by ULP FEC packet #1 at level 0, by ULP FEC packet #2 at level 1, and so on. Also, it can be easily seen from the table that ULP FEC packet #2 protects at level 0 payload packets C and D, at level 1 payload packets A-D, and so on. For additional examples with more details, please refer to Section 10, "Examples".
ULP FECパケット＃1のみ保護レベル0 ULP FECパケット＃2は、保護レベル0と1台の両端のリードを有している。この例では、ペイロードパケットAがレベル0でULP FECパケット＃1によって保護されることが示されています、ようにULP FECパケットレベル1で＃2、及びによって。また、容易ULP FECパケット＃2は、レベル0ペイロードパケットC及びDを保護し、レベル1ペイロードように-Dをパケット、そのテーブルから分かります。詳細とその他の例については、第10、「例」を参照してください。
The payload of the ULP FEC packets of each level is the protection operation (XOR) applied to the media payload and padding of the media packets associated with the ULP FEC packet at that level. Details are described in Section 8 on the protection operation.
各レベルのULP FECパケットのペイロードは、保護動作（XOR）はそのレベルでULP FECパケットに関連するメディアパケットのメディアペイロードおよびパディングに適用されます。詳細については、保護動作のセクション8に記載されています。
The size of the ULP FEC packets is determined by the protection lengths chosen for the protection operation. In the above example, ULP FEC packet #1 has length L0 (plus the header overhead). ULP FEC packet #2 with two levels has length L0+L1 (plus the header overhead). It is longer than some of the packets it protects (packets B and C in this example), and is shorter than some of the packets it protects (packets A and D in this example).
ULP FECパケットのサイズは、保護動作のために選択された保護の長さによって決定されます。上記の例では、ULP FECパケット＃1は、長さL0（プラスヘッダーオーバーヘッド）を有しています。 2つのレベルのULP FECパケット＃2は、長さL0 + L1（プラスヘッダーオーバーヘッド）を有しています。これは、より長いそれは（この例ではパケットB及びC）を保護パケットのいくつかよりも、それは（この例ではパケットAおよびD）を保護パケットのいくつかよりも短くなっています。
Note that it's possible for the FEC packet (non-ULP and ULP) to be larger than the longest media packets it protects because of the overhead from the headers and/or if a large protection length is chosen for ULP. 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パケット（非ULPとULP）が最長のメディアパケットよりも大きくすることは、それがためにヘッダとからオーバーヘッドの保護が可能であるということに注意してください/または大きな保護長はULPのために選択された場合。これは、それが送信される経路の最大伝送ユニットサイズを超えたFECパケットにつながる場合、これは困難を引き起こす可能性があります。
FEC packets are formed from an "FEC bit string" that is generated from the data of the protected media RTP packets. More specifically, the FEC bit string is the bitwise exclusive OR of the "protected bit strings" of the protected media RTP packets.
FECパケットが保護されたメディアRTPパケットのデータから生成される「FECビット列」から形成されます。具体的には、FECビット列は、ビット単位の排他的論理和保護されたメディアRTPパケットの「保護されたビット列」です。
The following procedure MAY be followed for the protection operation. Other procedures MAY be used, but the end result MUST be identical to the one described here.
次の手順では、保護動作のために続いてもよいです。他の手順を使用することができるが、最終的な結果は、ここで説明したものと同じでなければなりません。
In the case of the FEC header, the protected bit strings (80 bits in length) are generated for each media packet to be protected at FEC level 0. It is formed by concatenating the following fields together in the order specified:
各メディアパケットは、それが指定された順序で一緒に以下のフィールドを連結することによって形成されるFECレベル0で保護するためにFECヘッダの場合には、保護されたビット列（長さが80ビット）が生成されます。
o The first 64 bits of the RTP header (64 bits)
RTPヘッダの最初の64ビット（64ビット）○
o Unsigned network-ordered 16-bit representation of the media packet length in bytes minus 12 (for the fixed RTP header), i.e., the sum of the lengths of all the following if present: the CSRC list, extension header, RTP payload, and RTP padding (16 bits)
O（固定RTPヘッダの）メディアパケットのバイト単位の長さマイナス12の符号なしネットワーク順の16ビット表現、すなわち、の長さの和以下のすべて存在する場合：CSRCリスト、拡張ヘッダ、RTPペイロードそしてRTPパディング（16ビット）
After the FEC bit string is formed by applying parity operation on the protected bit strings, the FEC header is generated from the FEC bit string as follows:
FECビット列が保護ビット列にパリティ演算を適用することによって形成された後、次のように、FECヘッダは、FECビット列から生成されます。
The first (most significant) 2 bits in the FEC bit string are skipped. The next bit in the FEC bit string is written into the P recovery bit of the FEC header in the FEC packet. The next bit in the FEC bit string is written into the E recovery bit of the FEC header. The next 4 bits of the FEC bit string are written into the CC recovery field of the FEC header. The next bit is written into the M recovery bit of the FEC header. The next 7 bits of the FEC bit string are written into the PT recovery field in the FEC header. The next 16 bits are skipped. The next 32 bits of the FEC bit string are written into the TS recovery field in the FEC header. The next 16 bits are written into the length recovery field in the packet header.
FECビット列の最初（最上位）2ビットはスキップされます。 FECビット列の次のビットは、FECパケットにFECヘッダのP回復ビットに書き込まれます。 FECビット列の次のビットは、FECヘッダのE回復ビットに書き込まれます。 FECビット列の次の4ビットは、FECヘッダのCC回復フィールドに書き込まれます。次のビットは、FECヘッダのM回復ビットに書き込まれます。 FECビット列の次の7ビットは、FECヘッダ内PT回復フィールドに書き込まれます。次の16ビットはスキップされます。 FECビット列の次の32ビットは、FECヘッダにTS回復フィールドに書き込まれます。次の16ビットは、パケットヘッダの長さ回復フィールドに書き込まれます。
For generation of the FEC payload, the protected bit strings are simply the protected RTP packets. The FEC bit string is thus the bitwise exclusive OR of these protected media RTP packets. Such FEC bit strings need to be generated for each level, as the group of protected payload packets may be different for each level. If the lengths of the protected RTP packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0 at the end.
FECペイロードを生成するために、保護されたビット列は、保護されたRTPパケットは、単純です。 FECビット列は、このようにビットごとの排他的論理和これらの保護されたメディアRTPパケットです。保護されたペイロードパケットのグループは、レベルごとに異なっていてもよく、このようなFECビット列は、各レベルのために生成される必要があります。保護されたRTPパケットの長さが等しくない場合、各短いパケットは、端部にオクテット0を追加することにより、最長のパケットの長さにパディングされなければなりません。
For protection level n (n = 0, 1, ...), only Ln octets of data are set as the FEC level n payload data after the level n ULP header. The data is the Ln octets of data starting with the (Sn + 13)th octet in the FEC bit string, where:
保護レベルnについて（N = 0、1、...）、データのオクテットがレベルN ULPヘッダーの後FECレベルnのペイロードデータとして設定されているだけLN。データは、FECビット列におけるオクテット目（SN + 13）で始まるデータのLnのオクテットです。
Sn = sum(Li : 0 <= i < n).
SN = SUM（リー：0 <= iがn <）。
Li is the protection length of level i, and S0 is defined to be 0. The reason for omitting the first 12 octets is that that information is protected by the FEC header already.
LiはIレベルの保護の長さであり、S0が第12オクテットを省略する理由0であると定義されると、その情報が既にFECヘッダによって保護されることです。
The FEC packets allow end systems to recover from the loss of media packets. This section describes the procedure for performing this recovery.
FECパケットは、エンドシステムは、メディアパケットの損失から回復することができます。このセクションでは、この回復を実行するための手順を説明します。
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 trade-off between complexity and the ability to recover missing packets, if possible.
回復は、2つの異なる操作が必要です。最初は、欠落パケットを回復するために合成されなければならないパケット（メディア及びFEC）を決定します。これが完了すると、第二のステップは、実際にデータを再構築することです。以下に説明するように、第2工程を実施しなければなりません。最初のステップは、実装者によって選択された任意のアルゴリズムに基づいてもよいです。異なるアルゴリズムが複雑さと、可能な場合、欠落したパケットを回復する能力とのトレードオフになります。
The lost payload packets may be recovered in full or in parts depending on the data-loss situation due to the nature of unequal error protection (when it is used). The partial recovery of the packet can be detected by checking the recovery length of the packet retrieved from the FEC header against the actual length of the recovered payload data.
失われたペイロードパケットが原因（それが使用される）不均一誤り保護の性質に完全に、またはデータ損失の状況に応じて部品に回収することができます。パケットの部分的な回復を回収ペイロードデータの実際の長さに対するFECヘッダから取り出されたパケットの回復の長さをチェックすることによって検出することができます。
Let T be the list of packets (FEC and media) that can be combined to recover some media packet xi at level 0. The procedure is as follows:
Tレベル以下のように手順が0でいくつかのメディアパケットXIを回復するために組み合わせることができるパケット（FEC及びメディア）のリストとします。
1. For the media packets in T, compute the first 80 bits of the protected bit string following the procedure as described for generating the FEC header in the previous section.
Tにおけるメディアパケットの場合1、前のセクションでFECヘッダを生成するための記載された手順を以下の保護ビット列の最初の80ビットを計算します。
2. For the FEC packet in T, the FEC bit string is the 80-bit FEC header.
TにおけるFECパケット2.、FECビット列は、80ビットのFECヘッダです。
3. Calculate the recovery bit string as the bitwise exclusive OR of the protected bit string generated from all the media packets in T and the FEC bit string generated from all the FEC packets in T.
3.ビット単位の排他的OR T内のすべてのメディアパケットから生成された保護されたビット列とTのすべてのFECパケットから生成されたFECビット列のように回復ビット列を計算します
4. Create a new packet with the standard 12-byte RTP header and no payload.
4.標準の12バイトのRTPヘッダ及びペイロードなしで新しいパケットを作成します。
5. Set the version of the new packet to 2. Skip the first 2 bits in the recovery bit string.
5.回復ビット列の最初の2ビットをスキップ2に、新たなパケットのバージョンを設定します。
6. Set the Padding bit in the new packet to the next bit in the recovery bit string.
6.回復ビット列の次のビットへの新しいパケットにパディングビットを設定します。
7. Set the Extension bit in the new packet to the next bit in the recovery bit string.
7.回復ビット列の次のビットへの新しいパケットに拡張ビットを設定します。
8. Set the CC field to the next 4 bits in the recovery bit string.
8.回復ビット列の次の4ビットにCCフィールドを設定します。
9. Set the marker bit in the new packet to the next bit in the recovery bit string.
9.回復ビット列の次のビットへの新しいパケットにマーカービットを設定します。
10. Set the payload type in the new packet to the next 7 bits in the recovery bit string.
10.回復ビット列の次の7ビットに新たなパケット内のペイロードタイプを設定します。
11. Set the SN field in the new packet to xi. Skip the next 16 bits in the recovery bit string.
11. XIへの新しいパケットにSNフィールドを設定します。回復ビット列の次の16ビットをスキップします。
12. Set the TS field in the new packet to the next 32 bits in the recovery bit string.
12.回復ビット列の次の32ビットへの新しいパケット内のTSフィールドを設定します。
13. 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 the padding of the RTP payload.
13.回復ビット列の次の16ビットを取ります。これは（仮定ネットワーク-順）を表す符号なし整数が何であれ、回復ビット列から多くのバイトを取り、新しいパケットにそれらを追加します。これは、CSRCリスト、拡張、ペイロード、およびRTPペイロードのパディングを表します。
14. Set the SSRC of the new packet to the SSRC of the media stream it's protecting, i.e., the SSRC of the media stream to which the FEC stream is associated.
メディアのSSRCに新たなパケットのSSRCを設定14.それは、すなわち、FECストリームが関連付けられているメディアストリームのSSRCを保護だストリーム。
This procedure will recover the header of an RTP packet up to the SSRC field.
この手順は、SSRCフィールドにRTPパケットまでのヘッダを回復します。
Let T be the list of packets (FEC and media) that can be combined to recover some media packet xi at a certain protection level. The procedure is as follows:
Tは、特定の保護レベルでいくつかのメディアパケットXIを回復するために組み合わせることができ、パケット（FECとメディア）のリストとします。手順は以下の通りです。
1. Assume that we are reconstructing the data for level n, the first step is to get the protection length of level n (Ln) from the ULP header of level n.
1.我々はレベルnのデータを再構築していると仮定し、最初のステップは、レベルnのULPヘッダからレベルn（LN）の保護の長さを取得することです。
2. For the FEC packets in T, the FEC bit string of level n is FEC level n payload, i.e., the Ln octets of data following the ULP header of level n.
TにおけるFECパケットの場合2、レベルnのFECビット列がFECレベルnのペイロード、すなわちされ、レベルnのULPヘッダに続くデータのLnのオクテット。
3. For the media packets in T, the protected bit string of level n is Ln octets of data starting with the (Sn + 13)th octet of the packet. Sn is the same as defined in Section 8.2. Note that the protection of level 0 starts from the 13th octet of the media packet after the SSRC field. The information of the first 12 octets are protected by the FEC header.
Tにおけるメディアパケットについて3は、レベルnの保護されたビット列は、パケットのオクテット目（SN + 13）で始まるデータのLnのオクテットです。 Snが8.2節で定義されたものと同じです。 SSRCフィールドの後、メディアパケットの13オクテットからレベルの保護が0開始することに注意してください。最初の12オクテットの情報は、FECヘッダによって保護されています。
4. If any of the protected bit strings of level n generated from the media packets are shorter than the protection length of the current level, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string.
4.メディアパケットから生成されたレベルの保護されたビット列のどれであれば、その長さにパッドそれらを現在のレベルの保護の長さよりも短いです。オクテット0のパディングビット列の最後に追加されなければなりません。
5. Calculate the recovery bit string as the bitwise exclusive OR of the protected bit string of level n generated from all the media packets in T and the FEC bit string of level n generated from all the FEC packets in T.
5ビット単位の排他的ORレベルの保護されたビット列のように回復ビット列を計算するn個すべてのTにおけるメディアパケットレベルのFECビット列から生成されたN Tの全てのFECパケットから生成されました
6. The recovery bit string of the current protection level as generated above is combined through concatenation with the recovery bit string of all the other levels to form the (fully or partially) recovered media packet. Note that the recovery bit string of each protection level MUST be placed at the correct location in the recovered media packet for that level based on protection length settings.
6.上記生成されたすべての他のレベルの回復ビット列との連結を介して結合されているように、現在の保護レベルの回復ビット列は、（完全にまたは部分的に）回収されたメディアパケットを形成します。各保護レベルの回復ビット列は、保護長さの設定に基づいて、そのレベルの回復したメディアパケット内の正しい位置に配置しなければならないことに留意されたいです。
7. The total length of the recovered media packet is recovered from the recovery operation at protection level 0 of the recovered media packet. This information can be used to check if the complete recovery operation (of all levels) has recovered the packet to its full length.
7.回収メディアパケットの全長は回収メディアパケットの保護レベル0での回復動作から回収されます。この情報は、（すべてのレベルの）完全な回復操作はその全長にパケットを回復したかどうかを確認するために使用することができます。
The data protected at the lower protection level is recoverable in a majority of the cases if the higher-level protected data is recoverable. This procedure (together with the procedure for the lower protection levels) will usually recover both the header and payload of an RTP packet up to the protection length of the current level.
より高いレベルの保護されたデータが回復可能である場合に下部保護レベルで保護されたデータは、多くの場合に回復可能です。 （共に低い保護レベルのための手順）この手順は、通常、現在のレベルの保護の長さまでのRTPパケットのヘッダとペイロードの両方を回復します。
In the first two examples considered below (Sections 10.1 and 10.2), we assume that the FEC streams are sent through a separate RTP session as described in Section 14.1. For these examples, we assume that four media packets are to be sent, A, B, C, and D, from SSRC 2. Their sequence numbers are 8, 9, 10, and 11, respectively, and have timestamps of 3, 5, 7, and 9, respectively. Packets A and C use payload type 11, and packets B and D use payload type 18. Packet A has 200 bytes of payload, packet B 140, packet C 100, and packet D 340. Packets A and C have their marker bit set.
（セクション10.1および10.2）について考察最初の2つの例では、我々は、セクション14.1に記載されているようにFECストリームは別々のRTPセッションを介して送信されると仮定する。これらの例のために、我々は、4つのメディアパケットが送信されると仮定し、A、B、C、およびD、SSRC 2からそのシーケンス番号はそれぞれ、8、9、10、及び11、であり、そして3のタイムスタンプを有する、5それぞれ、7、および9、。パケットAとCの使用ペイロードタイプ11、及びパケットBおよびDを使用ペイロードタイプ18パケットAは、パケットA及びCは、それらのマーカビットが設定されているペイロード、パケットB 140、パケットC 100、及びパケットD 340の200のバイトを有します。
The third example (Section 10.3) is to illustrate when the FEC data is sent as redundant data with the payload packets.
第三の例（10.3）は、FECデータをペイロードパケットと、冗長データとして送信されたときに示すことです。
We can protect the four payload packets to their full length in one single level with one FEC packet. This offers similar protection as RFC 2733. The scheme is as shown in Figure 6.
私たちは、1つのFECパケットを持つ1つのレベルで自分の全長に4つのペイロードパケットを保護することができます。これは、図6に示すようなスキームがあるRFC 2733.と同様の保護を提供しています。
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
Figure 6: FEC Scheme with Single-Level Protection
図6：単一レベルの保護とFECスキーム
An FEC packet is generated from these four packets. We assume that payload type 127 is used to indicate an FEC packet. The resulting RTP header is shown in Figure 7.
FECパケットは、これらの4つのパケットから生成されます。私たちは、ペイロードタイプ127は、FECパケットを示すために使用されていることを前提としています。得られたRTPヘッダーは図7に示されています。
The FEC header in the FEC packet is shown in Figure 8.
FECパケットにFECヘッダは、図8に示されています。
The FEC level header for level 0 is shown in Figure 9.
レベル0のためのFECレベルヘッダーが図9に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|0|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 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 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 2 Padding: 0 Extension: 0 Marker: 0 PT: 127 SN: 1 TS: 9 SSRC: 2
バージョン：2パディング：0エクステンション：0マーカー：0 PT：127 SN：1 TS：9 SSRC：2
Figure 7: RTP Header of FEC Packet
図7：FECパケットの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 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 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification] L: 0 [short 16-bit mask] P rec.: 0 [0 XOR 0 XOR 0 XOR 0] X rec.: 0 [0 XOR 0 XOR 0 XOR 0] CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] M rec.: 0 [1 XOR 0 XOR 1 XOR 0] PT rec.: 0 [11 XOR 18 XOR 11 XOR 18] SN base: 8 [min(8,9,10,11)] TS rec.: 8 [3 XOR 5 XOR 7 XOR 9] len. rec.: 372 [200 XOR 140 XOR 100 XOR 340]
E：0 [本明細書] L：[短い16ビットマスク] PのREC：0 [0 XOR 0 XOR 0 XOR 0] XのREC：0 [0 XOR 0 XOR 0 XOR 0] CCのREC：0 [0 XOR 0 XOR 0 XOR 0] MのREC：0 [1つのXOR 0 XOR 1つのXOR 0] PT REC：0 [XOR XOR XOR 11、18、11、18] SNベース：8 [分（8,9,10、 11）] TS REC：8 3 5 7 9] XOR XOR XOR LEN。 REC：372 200 140 100 340 XOR XOR XOR]
Figure 8: FEC Header of FEC Packet
図8：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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 340 [the longest of 200, 140, 100, and 340] mask: 61440 [with Bits 1, 2, 3, and 4 marked accordingly for Packets 8, 9, 10, and 11]
L0：340 [200、140、100、及び340の最長]マスク：61440 [パケット8、9、10のために応じてマークされたビット1、2、3、及び4と、11]
The payload length for level 0 is 340 bytes.
レベル0のペイロード長は340バイトです。
Figure 9: FEC Level Header (Level 0)
図9：FECレベルヘッダ（レベル0）
A more complex example is to use FEC at two levels. The level 0 FEC will provide greater protection to the beginning part of the payload packets. The level 1 FEC will apply additional protection to the rest of the packets. This is illustrated in Figure 10. In this example, L0 = 70 and L1 = 90.
より複雑な例では、2つのレベルでFECを使用することです。レベル0 FECは、ペイロードパケットの先頭部分に大きな保護を提供します。レベル1のFECパケットの残りの部分に追加の保護を適用します。これは、90 = L0 = 70とL1、本例では図10に示されています。
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
Figure 10: ULP FEC Scheme with Protection Level 0 and Level 1
図10：ULP FECスキームで保護レベル0とレベル1
This will result in two FEC packets - #1 and #2.
＃1、＃2 - これは、二つのFECパケットになります。
The resulting ULP FEC packet #1 will have the RTP header as shown in Figure 11. The FEC header for ULP FEC packet #1 will be as shown in Figure 12. The level 0 ULP header for #1 will be as shown in Figure 13.
ULP FECパケット＃1のFECヘッダは＃1のレベル0 ULPヘッダは図13に示されるように、図12に示されるように、図11に示すように、得られたULP FECパケット＃1は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 PT: 127 SN: 1 TS: 5 SSRC: 2
バージョン：2パディング：0エクステンション：0マーカー：1 PT：127 SN：1 TS：5 SSRC：2
Figure 11: RTP Header of FEC Packet #1
図11：FECパケット＃1の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 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 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification] L: 0 [short 16-bit mask] P rec.: 0 [0 XOR 0 XOR 0 XOR 0] X rec.: 0 [0 XOR 0 XOR 0 XOR 0] CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] M rec.: 0 [1 XOR 0 XOR 1 XOR 0] PT rec.: 25 [11 XOR 18] SN base: 8 [min(8,9)] TS rec.: 6 [3 XOR 5] len. rec.: 68 [200 XOR 140]
E：0 [本明細] L：0 [短い16ビットマスク] PのREC：0 [0 XOR 0 XOR 0 XOR 0] XのREC：0 [0 XOR 0 XOR 0 XOR 0] CCのREC：0 [0 XOR 0 XOR 0 XOR 0] MのREC：0 [1 XOR 0 XOR 1 XOR 0] PTのREC：25 [11 XOR 18] SNベース：8 [分（8,9）]をREC：6をTS [3 XOR 5] LEN。 REC：68 [200 XOR 140]
Figure 12: FEC Header of ULP FEC Packet #1
図12：ULP FECパケット＃1の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70 mask: 49152 [with Bits 1 and 2 marked accordingly for Packets 8 and 9]
L0：70マスク：49152 [ビット1及び2を有するパケット8のために応じてマークされ、9]
The payload length for level 0 is 70 bytes.
レベル0のペイロード長は70バイトです。
Figure 13: FEC Level Header (Level 0) for FEC Packet #1
図13：FECパケット＃1のFECヘッダレベル（レベル0）
The resulting FEC packet #2 will have the RTP header as shown in Figure 14. The FEC header for FEC packet #2 will be as shown in Figure 15. The level 0 ULP header for #2 will be as shown in Figure 16. The level 1 ULP header for #2 will be as shown in Figure 17.
FECパケット＃2のFECヘッダは＃2のレベル0 ULPヘッダーは図16.で示されるように、図15に示されるように、図14に示すように、得られたFECパケット＃2は、RTPヘッダを有することになります図17に示すように、＃2のレベル1 ULPヘッダがあろう。
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 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 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 PT: 127 SN: 2 TS: 9 SSRC: 2
バージョン：2パディング：0エクステンション：0マーカー：1 PT：127 SN：2 TS：9 SSRC：2
Figure 14: RTP Header of FEC Packet #2
図14：FECパケット＃2の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 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 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification] L: 0 [short 16-bit mask] P rec.: 0 [0 XOR 0 XOR 0 XOR 0] X rec.: 0 [0 XOR 0 XOR 0 XOR 0] CC rec.: 0 [0 XOR 0 XOR 0 XOR 0] M rec.: 0 [1 XOR 0 XOR 1 XOR 0] PT rec.: 25 [11 XOR 18] SN base: 8 [min(8,9,10,11)] TS rec.: 14 [7 XOR 9] len. rec.: 304 [100 XOR 340]
E：0 [本明細] L：0 [短い16ビットマスク] PのREC：0 [0 XOR 0 XOR 0 XOR 0] XのREC：0 [0 XOR 0 XOR 0 XOR 0] CCのREC：0 [0 XOR 0 XOR 0 XOR 0] MのREC：0 [1つのXOR 0 XOR 1つのXOR 0] PTのREC：25 [11 XOR 18] SNベース：8 [分（8,9,10,11）] TS REC：14 [7 XOR 9] LEN。 REC：304 [100 XOR 340]
Figure 15: FEC Header of FEC Packet #2
図15：FECパケット＃2の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0|0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L0: 70 mask: 12288 [with Bits 3 and 4 marked accordingly for Packets 10 and 11]
L0：70マスク：12288 [ビット3と4とのパケット10と11のためにそれに応じてマーク]
The payload length for level 0 is 70 bytes.
レベル0のペイロード長は70バイトです。
Figure 16: FEC Level Header (Level 0) for FEC Packet #2
図16：FECパケット＃2のFECヘッダレベル（レベル0）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0|1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L1: 90 mask: 61440 [with Bits 1, 2, 3, and 4 marked accordingly for Packets 8, 9, 10, and 11]
L1：90マスク：61440 [ビット1、2、3、及び4と11のパケット8、9、10のために応じてマークされ、そして]
The payload length for level 1 is 90 bytes.
レベル1のペイロード長は90バイトです。
Figure 17: FEC Level Header (Level 1) for FEC Packet #2
図17：FECパケット＃2のFECレベルヘッダ（レベル1）
This example illustrates FEC sent as redundant coding in the same stream as the payload. We assume that five media packets are to be sent, A, B, C, D, and E, from SSRC 2. Their sequence numbers are 8, 9, 10, 11, and 12, respectively, and have timestamps of 3, 5, 7, 9, and 11, respectively. All the media data is coded with primary coding (and FEC as redundant coding only protects the primary coding) and uses payload type 11. Packet A has 200 bytes of payload, packet B 140, packet C 100, packet D 340, and packet E 160. Packets A and C have their marker bit set.
この例では、FECペイロードと同じストリームに冗長コードを送信示します。我々は、B、C、D、A、5つのメディアパケットが送信されると仮定し、及びEは、SSRC 2からそれらの配列番号は、それぞれ、8、9、10、11、及び12であり、及び3のタイムスタンプを有する、5それぞれ、7,9、および11、。すべてのメディアデータは、一次符号化で符号化され、ペイロードタイプを使用して（及びFEC冗長だけプライマリコードを保護コーディング）11.パケットAペイロードの200バイト、パケットB 140、パケットC 100、パケットD 340、及びパケットEを有しています160パケットAとCは、そのマーカービットが設定されています。
The FEC scheme we use will be with one level as illustrated by Figure 6 in Section 10.1. The protection length L0 = 340 octets.
セクション10.1の図6で示すように、我々が使用するFEC方式は、一つのレベルであろう。保護長= 340オクテットL0。
A redundant coding packetization is used with payload type 100. The payload type of the FEC is assumed to be 127. The first four RED packets, RED #1 through RED #4, each contains an individual media packet, A, B, C, or D, respectively. The FEC data protecting the media data in the first four media packets is generated. The fifth packet, RED #5, contains this FEC data as redundant coding along with media packet E.
冗長符号化パケットは、ペイロードタイプ100で使用されるFECのペイロードタイプは127最初の4つのREDのパケット、RED＃4までRED＃1であると仮定され、それぞれが個別のメディアパケット、A、B、Cが含まれまたは、それぞれD、。最初の4つのメディアパケットにメディアデータを保護するFECデータが生成されます。第五のパケット、RED＃5は、メディアパケットE.と共に冗長符号としてこのFECデータを含みます
RED Packet #1: Media Packet A RED Packet #2: Media Packet B RED Packet #3: Media Packet C RED Packet #4: Media Packet D RED Packet #5: FEC Packet, Media Packet E
REDパケット＃1：メディアパケットA REDパケット＃2：メディアパケットB REDパケット＃3：メディアパケットC REDパケット＃4：メディアパケットD REDパケット＃5：FECパケット、メディアパケットE
RED packets #1 through #4 will have the structure as shown in Figure 18. The RTP header of the RED packet #1 is as shown in Figure 19, with all the other RED packets in similar format with corresponding sequence numbers and timestamps. The primary encoding block header of the RED packets is as shown in Figure 20.
対応するシーケンス番号とタイムスタンプと同様のフォーマット内の他のすべてのREDパケットと、図19に示すようにREDパケット＃1の図18. RTPヘッダに示すように＃4を介して、REDパケット＃1は、以下の構造を有することになります。図20に示すように、REDパケットの一次符号化ブロック・ヘッダです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: RED Packet Structure - Media Data Only
図18：REDパケットの構造 - メディアのデータのみ
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|1 1 0 0 1 0 0|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: 0 [Even though media packet A has marker set] PT: 100 [Payload type for RED] SN: 1 TS: 5 SSRC: 2
バージョン：2パディング：0エクステンション：0マーカー：100 [REDのためのペイロードタイプ] SN：1つのTS：5 SSRC：2 0 PT [メディアパケットAは、マーカーセットを有していても】
Figure 19: RTP Header of RED Packet #1
図19：REDパケット＃1のRTPヘッダ
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
F bit: 0 [This is the primary coding data] Block PT: 11 [The payload type of media]
Fビット：0 [これは、一次符号化データである]ブロックPT：11 [メディアのペイロードタイプ]
Figure 20: Primary Encoding Block Header
図20：プライマリエンコーディングブロックヘッダー
The FEC data is generated not directly from the RED packets, but from the virtual RTP packets containing the media packet data. Those virtual RTP packets can be very easily generated from the RED packets both with and without redundant coding included. The conversion from RED packets to virtual RTP packets is simply done by (1) removing any RED block headers and redundant coding data, and (2) replacing the PT in the RTP header with the PT of the primary coding.
FECデータは、REDのパケットから、しかし、メディアパケットデータを含む仮想RTPパケットから直接ではなく生成されます。これらの仮想RTPパケットは非常に簡単で、付属の冗長符号化することなく両方のREDパケットから生成することができます。仮想RTPパケットにREDパケットからの変換は、単に（1）ブロックヘッダと、冗長符号化データの任意のREDを除去し、（2）一次符号化PTのRTPヘッダ内のPTを交換することによって行われます。
Note: In the payload format for redundant coding as specified by RFC 2198, the marker bit is lost as soon as the primary coding is carried in the RED packets. So the marker bit cannot be recovered regardless of whether or not the FEC is used.
注：RFC 2198で指定された冗長符号化のためのペイロード・フォーマットでは、マーカービットは、すぐ一次符号化がREDパケットで運ばれるように失われます。だから、マーカービットは関係なく、FECが使用されているかどうかの回復することはできません。
As mentioned above, RED packet #5 will contain the FEC data (that protects media packets A, B, C, and D) as well as the data of media packet E. The structure of RED packet #5 is as illustrated in Figure 21.
上述したように、REDパケット＃5は、FECデータを含むことになるだけでなく、REDパケット＃5の構造は、図21に示すように、メディアパケットE.のデータ（すなわち、メディアパケットA、B、C、及びDを保護します） 。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redundant Encoding Block Header (RED) - 4 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: RED Packet Structure - With FEC Data
図21：REDパケットの構造 - FECデータ付き
The RTP header of the RED packets with FEC included is the same as shown in Figure 19, with their corresponding sequence numbers and timestamps.
FECとREDパケットのRTPヘッダが含まれ、それらの対応するシーケンス番号とタイムスタンプと、図19に示すものと同じです。
In RED packet #5, the redundant encoding block header for the FEC packet data block is as shown below in Figure 22. It will be followed by the FEC packet data, which, in this case, includes an FEC header (10 octets as shown in Figure 8), ULP level 0 header (4 octets as shown in Figure 9), and the ULP level 0 data (340 octets as set for level 0). These are followed by the primary encoding block that contains the data of media packet E.
REDパケット＃5において、FECパケット・データ・ブロックのための冗長符号化ブロックヘッダが図22に以下に示されるように、示されるように、この場合には、FECヘッダ（10個のオクテットを含む、FECパケットデータが続きます図8）において、ULPレベル0ヘッダ（図9）に示すように4つのオクテット、及びULPレベル0データ（レベル0に設定された340個のオクテットとして）。これらは、メディアパケットE.のデータを含む一次符号化ブロックが続いています
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|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 1 0 1 1 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit: 1 [This is the redundant coding data] Block PT: 127 [The dynamic payload type for FEC] TS Offset: 0 [The instance at which the FEC data is transmitted] Block Len: 354 [FEC header (10 octets) plus ULP level 0 header (4 octets) and ULP level 0 data (340 octets)]
Fビット：1 [これは、冗長符号化データである]ブロックPT：127 [FECのためのダイナミックペイロードタイプ] TSオフセット：0 [FECデータが送信されるインスタンス]ブロックレン：354 [FECヘッダ（10オクテット）プラスULPレベル0ヘッダ（4つのオクテット）とULPレベル0データ（340オクテット）]
Figure 22: Redundant Encoding Block Header
図22：冗長符号化ブロックのヘッダー
There are two ways to use FEC with encryption in secure communications: one way is to apply the FEC on already encrypted payloads, and the other way is to apply the FEC before the encryption. The first case is encountered when FEC is needed by a not trusted node during transmission after the media data is encrypted. The second case is encountered when media data is protected by FEC before it is transmitted through a secured transport.
セキュアな通信で暗号化してFECを使用する方法は2つあります。一つの方法は、すでに暗号化されたペイロードにFECを適用することで、他の方法は、暗号化の前にFECを適用することです。メディア・データが暗号化された後、FECが送信中に信頼されていないノードによって必要とされたときに最初のケースに遭遇します。それが保護されたトランスポートを介して送信される前にメディアデータがFECによって保護されているときに、第2の場合に遭遇します。
Since the protected payload of this FEC is RTP packets, applying FEC on encrypted payloads is primarily applicable in the case of secure RTP (SRTP) [13]. Because the FEC applies XOR across the payload, the FEC packets should be cryptographically as secure as the original payload. In such cases, additional encryption of the FEC packets is not necessary.
このFECの保護されたペイロードは、RTPパケットであるため、暗号化されたペイロードにFECを適用する[13]セキュアRTP（SRTP）の場合に主に適用可能です。 FECは、ペイロード全体にXORを適用されるため、FECパケットは、元のペイロードとして暗号学的に安全でなければなりません。このような場合には、FECパケットの追加の暗号化は必要ありません。
In the following discussion, it is assumed that the FEC is applied to the payload before the encryption. 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 combinations on the usage of encryption. These include:
以下の議論では、FECは、暗号化前のペイロードに適用されているものとします。 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.
FECストリームがないまま、oメディアストリームは、暗号化されてもよいです。
o The media stream and FEC stream are both encrypted, but using the same key.
OメディアストリームとFECストリームは、両方の暗号化されますが、同じキーを使用しています。
o The media stream and FEC stream are both encrypted, but using different keys.
OメディアストリームとFECストリームは、両方の暗号化されますが、異なるキーを使用しています。
The first three of these would require all application-level signaling protocols used to be aware of the usage of FEC, and to thus exchange keys and negotiate encryption 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 ULP FEC packets should be treated no differently than other RTP packets. Encrypting just one stream may also make certain known-plaintext attacks possible. For these reasons, applications utilizing encryption SHOULD encrypt both streams, i.e., the last two options.
これらの最初の3つはFECの使用を認識するために使用されるすべてのアプリケーションレベルのシグナリングプロトコルを必要とすることが交換鍵と別々にメディア及びFECストリームの暗号化の使用を交渉することになります。最後のケースでは、そのような追加のメカニズムが必要とされません。 ULP FECパケットが他のRTPパケットより全く異なって扱われるべきではないように、第1の2つのケースが、積層違反を提示します。ただ一つのストリームを暗号化することもある既知平文攻撃が可能になることがあります。これらの理由から、暗号化を利用するアプリケーションは、すなわち、最後の2つのオプションを両方のストリームを暗号化する必要があります。
Furthermore, because the encryption may potentially be weakened by the known relationship between the media payload and FEC data for certain ciphers, different encryption keys MUST be used for each stream when the media payload and the FEC data are sent in separate streams. Note that when SRTP [13] is used for security of the RTP sessions, different keys for each RTP session are required by the SRTP specification.
暗号化は、潜在的に特定の暗号のためのメディアペイロードと、FECデータとの間の既知の関係によって弱めることができるので、メディアペイロードと、FECデータが別個のストリームで送信されたときに更に、異なる暗号鍵は、各ストリームに使用されなければなりません。 SRTP [13]は、RTPセッションのセキュリティのために使用される場合、各RTPセッションのために異なる鍵がSRTP仕様によって必要とされることに留意されたいです。
The changing of encryption keys is another crucial issue that needs to be addressed. Consider the case where two packets a and b are sent along with the FEC packet that protects them. The keys used to encrypt a and b are different, so which key should be used to decode the FEC packet? In general, old keys need to be cached, so that when the keys change for the media stream, the old key can be used until it is determined that the key has changed for the ULP FEC packets as well. Furthermore, the new key SHOULD be used to encrypt the FEC packets that are generated from a combination of payload packets encrypted by the old and new keys. The sender and the receiver need to define how the encryption is performed and how the keys are used.
暗号化キーの変更が対処する必要があるもう一つの重要な問題です。二つのパケットaとbは、それらを保護FECパケットと一緒に送信されている場合を考えてみましょう。 aおよびbを暗号化するために使用される鍵は異なっているので、そのキーは、FECパケットを復号するために使用すべきか？キーは、メディアストリームのために変更したときに、古いキーを使用することができるように、キーが同様にULP FECパケットのために変化したと判定されるまで、一般的には、古いキーは、キャッシュする必要があります。さらに、新しいキーは、古いものと新しいキーで暗号化されたペイロードパケットの組み合わせから生成されたFECパケットを暗号化するために使用されるべきです。送信者と受信者は、暗号化が実行され、キーがどのように使用されている方法を定義する必要があります。
Altering the FEC data and packets can have a big impact on the reconstruction operation. An attack by changing some bits in the FEC data can have a significant effect on the calculation and the recovery of the payload packets. For example, changing the length recovery field can result in the recovery of a packet that is too long. Also, the computational complexity of the recovery can easily be affected for up to at least one order of magnitude. Depending on the application scenario, it may be helpful to perform a sanity check on the received payload and FEC data before performing the recovery operation and to determine the validity of the recovered data from the recovery operation before using them.
FECデータパケットを変更すると、再構成演算に大きな影響を持つことができます。 FECデータにいくつかのビットを変更することで攻撃が計算し、ペイロードパケットの回復に大きな影響を持つことができます。例えば、長さの回復フィールドを変更すると、長すぎるパケットの回復につながることができます。また、回復の計算の複雑さを簡単に少なくとも一桁までのために影響を受けることができます。アプリケーションのシナリオによっては、回復操作を実行する前に受信したペイロードとFECデータの健全性チェックを実行するために、それらを使用する前に、回復操作から回復されたデータの妥当性を判断するために役立つかもしれません。
Another issue with the use of FEC is its impact on network congestion. In many situations, the packet loss in the network is induced by congestions. In such scenarios, adding FEC when encountering increasing network losses should be avoided. If it is used on a widespread basis, this can result in increased congestion and eventual congestion collapse. The applications may include stronger protections while at the same time reduce the bandwidth for the payload packets. In any event, implementations MUST NOT substantially increase the total amount of bandwidth in use (including the payload and the FEC) as network losses increase.
FECの使用の別の問題は、ネットワークの混雑への影響です。多くの状況では、ネットワークにおけるパケット損失は、渋滞によって誘導されます。このようなシナリオで、遭遇増加ネットワークの損失は避けなければならないとき、FECを加えます。それは広範囲に基づき使用されている場合、これは増加混雑して最終的な輻輳崩壊につながることができます。同時に、ペイロードパケットのための帯域幅を低減しながら、アプリケーションは、より強力な保護を含んでいてもよいです。いずれにしても、実装は、実質的にネットワーク損失の増加として（ペイロードとFEC含む）の使用帯域の総量を増加させてはいけません。
The general congestion control considerations for transporting RTP data apply; see RTP [1] and any applicable RTP profile (e.g., RTP/AVP [14]). An additional requirement if best-effort service is being used is that users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
RTPデータを転送するための一般的な輻輳制御の考慮事項が適用されます。参照RTP [1]、該当RTPプロファイル（例えば、RTP / AVP [14]）。ベストエフォート型のサービスが使用されている場合、追加の要件は、このペイロード形式のユーザはパケットロス率が許容パラメータの範囲内にあることを保証するためにパケット損失を監視しなければならないということです。同一のネットワークパス、および同じネットワーク条件を経験横切るTCPフローは、合理的なタイムスケールで測定した平均スループットを達成する場合は、パケット損失が許容されると考えられる、すなわち、RTPフローが達成さ以上です。この条件は、伝送速度（又は層状マルチキャストセッションのために加入層数）を適合させるために、輻輳制御メカニズムを実装することで、または損失率が許容できないほど高い場合にセッションを終了するための受信機のために配置することによって満たすことができます。
Four new media subtypes have been registered with IANA, as described in this section. This registration is done using the registration template [3] and following RFC 3555 [4].
このセクションで説明するように、4つの新しいメディアサブタイプは、IANAに登録されています。この登録は登録テンプレート[3]を使用してRFC 3555 [4]以下に行われます。
Type name: audio
型名：オーディオ
Subtype name: ulpfec
サブタイプ名：ulpfec
Required parameters:
必須パラメータ：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz, to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz but is RECOMMENDED to match the rate of the media this stream protects.
レート：別のストリームにFECパケットの送信の時間をマークするために使用されるRTPタイムスタンプレート。それは別のストリームに冗長データとして送信された場合には、速度は、保護するために使用される一次符号化と同じでなければなりません。別のストリームで使用される場合、速度はRTCP操作に十分な解像度を提供するために、1000Hzのより大きくなければなりません。選択されたレートは、1000Hzの上記の任意の値であってもよいが、このストリームが保護メディアの速度と一致することをお勧めします。
Optional parameters:
オプションのパラメータ：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：これは、FEC保護の唯一のレベルが使用されているかどうかを指定します。許容値は、0と1 1が通知された場合、FEC保護の唯一のレベルはストリームに使用されるものです。 0が通知されている場合は、FEC保護の複数のレベルを使用することができます。省略した場合、それはデフォルト値の0を持っています。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
符号化の考慮事項：このフォーマットは、フレーム（[3]テンプレート文書内のセクション4.8を参照）、バイナリデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティの考慮事項：同じセキュリティ上の考慮事項は、RFC 5109で説明するように、彼らのためにペイロードに、これらのメディアタイプの登録に適用されます。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 5109
公開された仕様：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
メディア・ストリームと追加データを送信することにより、損失に対する弾力性を改善しようとマルチメディアアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@hyervision.com IETFオーディオ/ビデオ輸送ワーキンググループ
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media, type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用上の制限：このメディアは、タイプがRTPフレーミングに依存し、したがってのみRTPを介して転送するために定義されている[1]。これはRTPのための堅牢性メカニズムであるとして、他のフレーミングプロトコル内の交通は定義されないものとします。
Author: Adam Li adamli@hyervision.com
著者：アダム・リーadamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
Type name: video
型名：ビデオ
Subtype name: ulpfec
サブタイプ名：ulpfec
Required parameters:
必須パラメータ：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
レート：別のストリームにFECパケットの送信の時間をマークするために使用されるRTPタイムスタンプレート。それは別のストリームに冗長データとして送信された場合には、速度は、保護するために使用される一次符号化と同じでなければなりません。別のストリームで使用される場合、速度はRTCP操作に十分な解像度を提供するためには1000Hzよりも大きくなければなりません。選択されたレートは、1000Hzの上記の任意の値であってもよいが、このストリームが保護メディアの速度と一致することをお勧めします。
Optional parameters:
オプションのパラメータ：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：これは、FEC保護の唯一のレベルが使用されているかどうかを指定します。許容値は、0と1 1が通知された場合、FEC保護の唯一のレベルはストリームに使用されるものです。 0が通知されている場合は、FEC保護の複数のレベルを使用することができます。省略した場合、それはデフォルト値の0を持っています。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
符号化の考慮事項：このフォーマットは、フレーム（[3]テンプレート文書内のセクション4.8を参照）、バイナリデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティの考慮事項：同じセキュリティ上の考慮事項は、RFC 5109で説明するように、彼らのためにペイロードに、これらのメディアタイプの登録に適用されます。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 5109
公開された仕様：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
メディア・ストリームと追加データを送信することにより、損失に対する弾力性を改善しようとマルチメディアアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@hyervision.com IETFオーディオ/ビデオ輸送ワーキンググループ
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用上の制限：このメディアタイプは、RTP [1]を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。これはRTPのための堅牢性メカニズムであるとして、他のフレーミングプロトコル内の交通は定義されないものとします。
Author: Adam Li adamli@hyervision.com
著者：アダム・リーadamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
Type name: text
型名：テキスト
Subtype name: ulpfec
サブタイプ名：ulpfec
Required parameters:
必須パラメータ：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
レート：別のストリームにFECパケットの送信の時間をマークするために使用されるRTPタイムスタンプレート。それは別のストリームに冗長データとして送信された場合には、速度は、保護するために使用される一次符号化と同じでなければなりません。別のストリームで使用される場合、速度はRTCP操作に十分な解像度を提供するためには1000Hzよりも大きくなければなりません。選択されたレートは、1000Hzの上記の任意の値であってもよいが、このストリームが保護メディアの速度と一致することをお勧めします。
Optional parameters:
オプションのパラメータ：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：これは、FEC保護の唯一のレベルが使用されているかどうかを指定します。許容値は、0と1 1が通知された場合、FEC保護の唯一のレベルはストリームに使用されるものです。 0が通知されている場合は、FEC保護の複数のレベルを使用することができます。省略した場合、それはデフォルト値の0を持っています。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
符号化の考慮事項：このフォーマットは、フレーム（[3]テンプレート文書内のセクション4.8を参照）、バイナリデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティの考慮事項：同じセキュリティ上の考慮事項は、RFC 5109で説明するように、彼らのためにペイロードに、これらのメディアタイプの登録に適用されます。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 5109
公開された仕様：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
メディア・ストリームと追加データを送信することにより、損失に対する弾力性を改善しようとマルチメディアアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@hyervision.com IETFオーディオ/ビデオ輸送ワーキンググループ
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用上の制限：このメディアタイプは、RTP [1]を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。これはRTPのための堅牢性メカニズムであるとして、他のフレーミングプロトコル内の交通は定義されないものとします。
Author: Adam Li adamli@hyervision.com
著者：アダム・リーadamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
Type name: application
型名：アプリケーション
Subtype name: ulpfec
サブタイプ名：ulpfec
Required parameters:
必須パラメータ：
rate: The RTP timestamp rate that is used to mark the time of transmission of the FEC packet in a separate stream. In cases in which it is sent as redundant data to another stream, the rate SHALL be the same as the primary encoding it is used to protect. When used in a separate stream, the rate SHALL be larger than 1000 Hz to provide sufficient resolution to RTCP operations. The selected rate MAY be any value above 1000 Hz, but is RECOMMENDED to match the rate of the media this stream protects.
レート：別のストリームにFECパケットの送信の時間をマークするために使用されるRTPタイムスタンプレート。それは別のストリームに冗長データとして送信された場合には、速度は、保護するために使用される一次符号化と同じでなければなりません。別のストリームで使用される場合、速度はRTCP操作に十分な解像度を提供するためには1000Hzよりも大きくなければなりません。選択されたレートは、1000Hzの上記の任意の値であってもよいが、このストリームが保護メディアの速度と一致することをお勧めします。
Optional parameters:
オプションのパラメータ：
onelevelonly: This specifies whether only one level of FEC protection is used. The permissible values are 0 and 1. If 1 is signaled, only one level of FEC protection SHALL be used in the stream. If 0 is signaled, more than one level of FEC protection MAY be used. If omitted, it has the default value of 0.
onelevelonly：これは、FEC保護の唯一のレベルが使用されているかどうかを指定します。許容値は、0と1 1が通知された場合、FEC保護の唯一のレベルはストリームに使用されるものです。 0が通知されている場合は、FEC保護の複数のレベルを使用することができます。省略した場合、それはデフォルト値の0を持っています。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
符号化の考慮事項：このフォーマットは、フレーム（[3]テンプレート文書内のセクション4.8を参照）、バイナリデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティの考慮事項：同じセキュリティ上の考慮事項は、RFC 5109で説明するように、彼らのためにペイロードに、これらのメディアタイプの登録に適用されます。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 5109
公開された仕様：RFC 5109
Applications that use this media type: Multimedia applications that seek to improve resiliency to loss by sending additional data with the media stream.
メディア・ストリームと追加データを送信することにより、損失に対する弾力性を改善しようとマルチメディアアプリケーション：このメディアタイプを使用するアプリケーション。
Additional information: none
追加情報：なし
Person & email address to contact for further information: Adam Li adamli@hyervision.com IETF Audio/Video Transport Working Group
人と詳細のために連絡する電子メールアドレス：アダム・リーadamli@hyervision.com IETFオーディオ/ビデオ輸送ワーキンググループ
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [1]. Transport within other framing protocols SHALL NOT be defined as this is a robustness mechanism for RTP.
使用上の制限：このメディアタイプは、RTP [1]を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。これはRTPのための堅牢性メカニズムであるとして、他のフレーミングプロトコル内の交通は定義されないものとします。
Author: Adam Li adamli@hyervision.com
著者：アダム・リーadamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IETFオーディオ/ビデオ輸送ワーキンググループがIESGから委任します。
The FEC packets can be sent to the receiver along with the protected payload primarily in one of two ways: as a separate stream, or in the same stream as redundant encoding. The configuration options MUST be indicated out of band. This section also describes how this can be accomplished using the Session Description Protocol (SDP), specified in RFC 2327 [8].
FECパケットは、主に2つの方法のいずれかで保護されたペイロードとともに受信機に送信することができる。別の流れとして、または冗長符号化と同じストリームに。設定オプションは、帯域外を示さなければなりません。このセクションでは、これは、RFC 2327で指定され、セッション記述プロトコル（SDP）を使用して達成することができる方法を説明[8]。
When the FEC packets are sent in a separate stream, several pieces of information must be conveyed:
FECパケットは別のストリームで送信される場合、いくつかの情報を搬送しなければなりません。
o The address and port to which the FEC is being sent
FECが送信される先のアドレスとポートO
o The payload type number for the FEC
FECのためのペイロードタイプ番号O
o Which media stream the FEC is protecting
Oのメディアは、FECが保護しているストリームどの
There is no static payload type assignment for FEC, so dynamic payload type numbers MUST be used. The SSRC of the FEC stream MUST be set to that of the protected payload stream. The association of the FEC stream with its corresponding stream is done by line grouping in SDP [5] with the FEC semantics [6] or other external means.
FECのための静的なペイロードタイプの割り当てはとてもダイナミックペイロードタイプ番号を使用する必要があり、存在しません。 FECストリームのSSRCは、保護されたペイロード・ストリームのものに設定しなければなりません。その対応するストリームとFECストリームの関連付けは、[5] FEC意味論[6]又は他の外部手段とSDPのライングループによって行われます。
Following the principles as discussed in Section 5.2 of RFC 3550 [1], multiplexing of the FEC stream and its associated payload stream is usually provided by the destination transport address (network address and port number), which is different for each RTP session. Sending FEC together with the payload in one single RTP session and multiplex only by SSRC or payload type precludes: (1) the use of different network paths or network resource allocations for the payload and the FEC protection data; (2) reception of a subset of the media if desired, particularly for the hosts that do not understand FEC; and (3) receiver implementations that use separate processes for the different media. In addition, multiplexing FEC with payload data streams will affect the timing and sequence number space of the original payload stream, which is usually undesirable. So the FEC stream and the payload stream SHOULD be sent through two separate RTP session, and multiplexing them by payload type into one single RTP session SHOULD be avoided. In addition, the FEC and the payload MUST NOT be multiplexed by SSRC into one single RTP session since they always have the same SSRC.
RFC 3550のセクション5.2で議論するように原則を以下の[1]、FECストリームとそれに関連するペイロード・ストリームの多重化は、通常、各RTPセッションのために異なっている、先のトランスポートアドレス（ネットワークアドレス及びポート番号）によって提供されます。単一のRTPセッションにおいてペイロードと一緒にFECを送信及びSSRCまたはペイロードタイプでのみ多重化することは不可能：ペイロードとFEC保護データ用の異なるネットワーク経路またはネットワークリソース割り当ての（1）を使用します。特にFECを理解していないホストのために、所望であれば、メディアのサブセットの（2）受信。 （3）異なるメディアの別個のプロセスを使用して受信機の実装。加えて、ペイロード・データ・ストリームと多重化FECは通常望ましくない元のペイロードストリームのタイミングとシーケンス番号空間に影響を与えます。だから、FECストリームとペイロードストリームは、2つの別々のRTPセッションを介して送信する必要があり、1つのRTPセッションにペイロードタイプによってそれらを多重化することは避けるべきです。彼らは常に同じSSRCを持っているのでまた、FECペイロードは、1つのRTPセッションにSSRCによって多重化されてはなりません。
Just like any media stream, the port number and the payload type number for the FEC stream are conveyed in their m line in the SDP. 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 "ulpfec". The address that the FEC stream is on is conveyed in its corresponding c line.
ちょうど任意のメディアストリームのように、FECストリームのポート番号とペイロードタイプ番号は、SDPでのMラインに搬送されます。 FECのための静的なペイロードタイプの割り当てはとてもダイナミックペイロードタイプ番号を使用する必要があり、存在しません。数に結合rtpmap属性によって示されます。この結合に使用される名前は「ulpfec」です。 FECストリームがオンになっているアドレスは、対応するC線に搬送されます。
The association relationship between the FEC stream and the payload stream it protects is conveyed through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6]. The FEC stream and the protected payload stream form an FEC group.
FECストリームとペイロードとの間の対応関係は、それをストリーミング保護SDP内のメディア・ライングループ（RFC 3388）を介して搬送される[5] FECセマンティクス（RFC 4756）を使用して、[6]。 FECストリームと保護ペイロードストリームはFECグループを形成します。
The following is an example SDP for FEC application in a multicast session:
以下は、マルチキャストセッションにおけるFEC適用のための例SDPあります。
v=0
o=adam 289083124 289083124 IN IP4 host.example.com
s=ULP FEC Seminar
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FEC 1 2
a=group:FEC 3 4
m=audio 30000 RTP/AVP 0
a=mid:1
m=application 30002 RTP/AVP 100
a=rtpmap:100 ulpfec/8000
a=mid:2
m=video 30004 RTP/AVP 31
a=mid:3
m=application 30004 RTP/AVP 101
c=IN IP4 224.2.17.13/127
a=rtpmap:101 ulpfec/8000
a=mid:4
The presence of two a=group lines in this SDP indicates that there are two FEC groups. The first FEC group, as indicated by the "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using PCM [14]) and stream 2 (the protecting FEC stream). The FEC stream is sent to the same multicast group and has the same Time to Live (TTL) as the audio, but on a port number two higher. The second FEC group, as indicated by the "a=group:FEC 3 4" line, consists of stream 3 (a video stream) and stream 4 (the protecting FEC stream). The FEC stream is sent to a different multicast address, but has the same port number (30004) as the payload video stream.
このSDP内の2つのグループ=線の存在は、二つのFECグループがあることを示しています。最初のFECグループは、「A =基：FEC 1 2」によって示されるように、ライン、ストリーム1（PCM [14]を使用して、オーディオストリーム）とストリーム2（保護FECストリーム）から構成されています。 FECストリームは、同一のマルチキャストグループに送信され、オーディオとして生きるために同じ時間（TTL）を有するが、ポート番号2に高くされています。第二のFECグループは、「A =基：FEC 3 4」によって示されるように、ライン、ストリーム3（ビデオストリーム）とストリーム4（保護FECストリーム）から構成されています。 FECストリームは、異なるマルチキャストアドレスに送信されたが、ペイロード・ビデオ・ストリームと同一のポート番号（30004）を有しています。
When the FEC stream is being sent as a secondary codec in the redundant encoding format, this must be signaled through SDP. To do this, the procedures defined in RFC 2198 [7] are used to signal the use of redundant encoding. The FEC payload type is indicated in the same fashion as any other secondary codec. The FEC MUST protect only the main codec, with the payload of FEC engine coming from virtual RTP packets created from the main codec data. The virtual RTP packets can be very easily converted from the RFC 2198 packets by simply (1) removing all the additional headers and the redundant coding data, and (2) replacing the payload type in the RTP header with that of the primary codec.
FECストリームは、冗長符号化フォーマットで二次コーデックとして送信されているとき、これは、SDPを介してシグナリングされなければなりません。これを行うには、RFC 2198 [7]で定義された手順は、冗長符号化の使用を通知するために使用されます。 FECペイロードタイプは、任意の他の二次コーデックと同じ様式で示されています。 FECは、FECエンジンのペイロードがメインコーデックデータから作成された仮想RTPパケットから来ると、本体のみのコーデックを保護する必要があります。仮想RTPパケットは非常に容易に単に（1）すべての追加ヘッダと冗長符号化データを除去することによって、RFC 2198パケットから変換され、（2）一次コーデックのそれとRTPヘッダ内のペイロードタイプを置換することができます。
Note: In the payload format for redundant coding as specified by RFC 2198, the marker bit is lost as soon as the primary coding is carried in the RED packets. So the marker bit cannot be recovered regardless of whether or not the FEC is used.
注：RFC 2198で指定された冗長符号化のためのペイロード・フォーマットでは、マーカービットは、すぐ一次符号化がREDパケットで運ばれるように失われます。だから、マーカービットは関係なく、FECが使用されているかどうかの回復することはできません。
Because the FEC data (including the ULP header) is sent in the same packets as the protected payload, the FEC data is associated with the protected payload by being bundled in the same stream.
（ULPヘッダを含む）FECデータを保護ペイロードと同じパケットで送信されるため、FECデータは同じストリームにバンドルされることにより保護されたペイロードに関連しています。
When the FEC stream is sent as a secondary codec in the redundant encoding format, this can be signaled through SDP. To do this, the procedures defined in RFC 2198 [7] are used to signal the use of redundant encoding. 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.
FECストリームは、冗長符号化フォーマットで二次コーデックとして送信される場合、これはSDPを介してシグナリングすることができます。これを行うには、RFC 2198 [7]で定義された手順は、冗長符号化の使用を通知するために使用されます。 FECペイロードタイプは、任意の他の二次コーデックと同じ様式で示されています。 rtpmap属性は、FECパケットのためのダイナミックペイロードタイプ番号を示すために使用されなければなりません。 FECは本体のみのコーデックを保護する必要があります。
For example:
例えば：
m=audio 12345 RTP/AVP 121 0 5 100 a=rtpmap:121 red/8000/1 a=rtpmap:100 ulpfec/8000 a=fmtp:121 0/5/100
M =オーディオ12345 RTP / AVP 121 0 5 100 = rtpmap：121赤/ 8000/1（a）= rtpmap：ulpfec / 8000 = 100の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 ulpfec 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.
このSDPは、PCM（メディアフォーマット0）、DVI（メディアフォーマット5）からなることができる単一のオーディオストリームが存在することを示し、（rtpmap属性によって赤色に結合されたメディアフォーマット121で示す）の冗長符号化、またはFEC（rtpmap属性によってulpfecに結合されたメディアフォーマット100）。 FEC形式は、このストリームのための可能なコードとして指定されているが、FECは、このストリームのために自身が送信してはいけません。非プライマリコーデックがここにリストされなければならないという理由だけで、M個の行におけるその存在はのfmtp属性は、第三級符号化などの二次符号化およびFECなどのDVIと、冗長符号化フォーマットを使用することができることを示しているRFC 2198.に応じて必要とされます。
Some considerations are needed when SDP is used for offer / answer [15] exchange.
SDPは、オファー/アンサー[15]交換のために使用されている場合、一部の配慮が必要とされています。
The "onelevelonly" parameter is declarative. For streams declared as sendonly, the value indicates whether only one level of FEC will be sent. For streams declared as recvonly or sendrecv, the value indicates what the receiver accepts to receive.
「onelevelonly」パラメータは、宣言です。 sendonlyのように宣言されたストリームの場合、値は、FECの一つだけレベルが送られるかどうかを示します。 recvonlyで又はSENDRECVとして宣言されたストリームの場合、値は、受信機が受信することを受け入れるものを示しています。
When the FEC is sent as a separate stream and signaled through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6], the offering side MUST implement both RFC 3388 and RFC 4756. The rules for offer / answer in RFC 3388 and RFC 4756 SHALL be followed with the below additional consideration. For all offers with FEC, the answerer MAY refuse the separate FEC session by setting the port to 0, and remove the "a=group" attribute that groups that FEC session with the RTP session being protected. If the answerer accepts the usage of FEC, the answerer simply accepts the FEC RTP session and the grouping in the offer by including the same grouping in the answer. Note that the rejection of the FEC RTP session does not prevent the media sessions from being accepted and used without FEC.
FECは、別個のストリームとして送信され、SDP（RFC 3388）にグループ化メディア回線を介して通知されたときに[5] FECセマンティクス（RFC 4756）を使用して、[6]、提供側は、RFC 3388及びRFC 4756.ための規則の両方を実装しなければなりませんRFC 3388およびRFC 4756でのオファー/アンサーは、以下の追加の考慮して従わなければなりません。 FECを持つすべての提供のために、回答は0にポートを設定することで、個別のFECセッションを拒否し、そしてグループはRTPセッションとFECセッションが保護されていることを「A =グループ」属性を削除することができます。回答は、FECの使用を受け入れた場合、回答は単純な答えで同じグループを含めることによって、FEC RTPセッションおよび提供でグループ化を受け入れます。 FEC RTPセッションの拒否は、FECなしで受け入れられ、使用されてからメディアセッションを妨げるものではないことに注意してください。
When the FEC stream is sent as a secondary codec in the redundant encoding format (RFC 2198) [7], the offering side can indicate the FEC stream as specified in Section 14.2. The answerer MAY reject the FEC stream by removing the payload type for the FEC stream. To accept the usage of FEC, the answerer must in the answer include the FEC payload type. Note that in cases in which the redundancy payload format [7] is used with FEC as the only secondary codec, when the FEC stream is rejected the redundant encoding payload type SHOULD also be removed.
FECストリームは、冗長符号化形式（RFC 2198）に二次コーデックとして送信された場合、セクション14.2で指定されるように[7]、提供側はFECストリームを示すことができます。回答はFECストリームのためのペイロードタイプを除去することによりFECストリームを拒否することがあります。 FECの使用を受け入れるには、回答が答えにFECペイロードタイプを含める必要があります。冗長ペイロードフォーマットの場合には[7] FECストリームは、冗長符号化ペイロードタイプも除去しなければならない拒否される唯一の二次コーデックとしてFECと共に使用されることに留意されたいです。
This document describes a generic protocol for Forward Error Correction supporting a wide range of short block parity FEC algorithms, such as simple and interleaved parity codes. The scheme is limited to interleaving parity codes over a distance of 48 packets. This FEC algorithm is fully compatible with hosts that are not FEC-capable. Since the media payload is not altered and the protection is sent as additional information, the receivers that are unaware of the generic FEC as specified in this document can simply ignore the additional FEC information and process the main media payload. This interoperability is particularly important for compatibility with existing hosts, and also in the scenario where many different hosts need to communicate with each other at the same time, such as during multicast.
この文書では、このようなシンプルでインターリーブパリティコードなどのショートブロックパリティFECアルゴリズムの広い範囲をサポートする前方誤り訂正のための汎用プロトコルを記述しています。スキーム48のパケットの距離にわたってパリティ符号をインターリーブに限定されています。このFECアルゴリズムは、FECに対応していないホストと完全に互換性があります。メディアペイロードが変更されておらず、保護を付加情報として送信されるので、この文書で指定されている一般的なFECを知らない受信機は、単に追加のFEC情報を無視して、メインメディアペイロードを処理することができます。この相互運用性は、既存のホストとの互換性のために、また、多くの異なるホストは、マルチキャスト中などに同時に相互に通信する必要があるシナリオで特に重要です。
The generic FEC algorithm specified in this document is also a generic protection algorithm with the following features: (1) it is independent of the nature of the media being protected, whether that media is audio, video, or otherwise; (2) it is flexible enough to support a wide variety of FEC mechanisms and settings; (3) it is designed for adaptivity, so that the FEC parameters can be modified easily without resorting to out-of-band signaling; and (4) it supports a number of different mechanisms for transporting the FEC packets.
この文書で指定されたジェネリックFECアルゴリズムは、以下の機能を備えた一般的な保護アルゴリズムである：（1）そのメディアは、オーディオ、ビデオ、またはそれ以外であるかどうか、保護されたメディアの性質とは無関係です。 （2）FECメカニズムと設定の広範囲をサポートするのに十分に柔軟です。 FECパラメータは、アウトオブバンドシグナリングに頼ることなく容易に変更することができるように、（3）には、適応性のために設計されています。 （4）それはFECパケットを搬送する異なる多数のメカニズムをサポートします。
The FEC specified here also provides the user with Unequal Error Protection capabilities. Some other algorithms may also provide the Unequal Error Protection capabilities through other means. For example, an Unequal Erasure Protection (UXP) scheme has been proposed in the AVT Working Group in "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams". The UXP scheme applies unequal error protection to the media payloads by interleaving the payload stream to be protected with the additional redundancy information obtained using Reed-Solomon operations.
ここで指定したFECはまた、不均一誤り保護機能をユーザに提供します。いくつかの他のアルゴリズムは、他の手段を介して不均一誤り保護機能を提供することができます。例えば、不平等消去保護（UXP）方式は、「プログレッシブマルチメディアストリームの消去、弾力性のある伝送のためのRTPペイロードフォーマット」でAVT作業部会で提案されています。 UXPスキームは、リード・ソロモン・オペレーションを使用して得られた付加的な冗長情報と保護されるべきペイロード・ストリームをインタリーブすることによりメディアペイロードに等しくないエラー保護を適用します。
By altering the structure of the protected media payload, the UXP scheme sacrifices the backward compatibility with terminals that do not support UXP. This makes it more difficult to apply UXP when backward compatibility is desired. In the case of ULP, however, the media payload remains unaltered and can always be used by the terminals. The extra protection can simply be ignored if the receiving terminals do not support ULP.
保護されたメディアペイロードの構造を変更することにより、UXP方式はUXPをサポートしていない端末との下位互換性を犠牲に。これは、下位互換性が必要とされるとき、それはより困難UXPを適用することができます。 ULPの場合には、しかしながら、メディアペイロードは不変のままであり、常に端末によって使用することができます。受信端末は、ULPをサポートしていない場合は、余分な保護は単に無視することができます。
At the same time, also because the structure of the media payload is altered in UXP, UXP offers the unique ability to change packet size independent of the original media payload structure and protection applied, and is only subject to the protocol overhead constraint. This property is useful in scenarios when altering the packet size of the media at transport level is desired.
同時に、メディアペイロードの構造はUXPで変更されているので、また、UXP適用元のメディアペイロード構造体と保護とは無関係パケットサイズを変更するユニークな能力を提供し、および唯一のプロトコルオーバーヘッド制約を受けます。このプロパティは、トランスポートレベルでのメディアの変更、パケットサイズが望まれる状況において有用です。
Because of the interleaving used in UXP, delays will be introduced at both the encoding and decoding sides. For UXP, all data within a transmission block need to arrive before encoding can begin, and a reasonable number of packets must be received before a transmission block can be decoded. The ULP scheme introduces little delay at the encoding side. On the decoding side, correctly received packets can be delivered immediately. Delay is only introduced in ULP when packet losses occur.
なぜならUXPで使用インターリーブ、遅延は、両方の符号化及び復号化側に導入されます。 UXPため、送信ブロック内のすべてのデータが符号化を開始する前に到着する必要があり、伝送ブロックを復号することができる前に、パケットの妥当な数が受信されなければなりません。 ULP方式は、符号化側で少しの遅延を導入します。復号側では、正しく受信されたパケットをすぐにお届けすることができます。パケットロスが発生した場合に遅延が唯一のULPで導入されます。
Because UXP is an interleaved scheme, the unrecoverable errors occurring in data protected by UXP usually result in a number of corrupted holes in the payload stream. In ULP, on the other hand, the unrecoverable errors due to packet loss in the bitstream usually appear as contiguous missing pieces at the end of the packets. Depending on the encoding of the media payload stream, many applications may find it easier to parse and extract data from a packet with only a contiguous piece missing at the end than a packet with multiple corrupted holes, especially when the holes are not coincident with the independently decodable fragment boundaries.
UXPがインターリーブ方式であるため、UXPによって保護されたデータに発生した回復不能エラーは、通常、ペイロードストリームにおける破損孔の数をもたらします。 ULPでは、他の一方で、ビットストリームにおけるパケット損失による回復不能なエラーは通常、パケットの最後に連続し欠けている部分として表示されます。メディアペイロードストリームのエンコーディングによっては、多くのアプリケーションは、穴が一致しない場合は特に、それが簡単に複数の壊れた穴を持つパケットよりも最後に唯一欠けている連続した作品で、パケットからのデータを解析して抽出することかもしれません独立して復号可能フラグメントの境界。
The exclusive-or (XOR) parity check operation used by ULP is simpler and faster than the more complex operations required by Reed-Solomon codes. This makes ULP more suitable for applications where computational cost is a constraint.
ULPが使用する排他的論理和（XOR）パリティチェック操作が簡単で、リード・ソロモン符号によって必要なより複雑な操作よりも高速です。これは、計算コストが制約されたアプリケーションのためのULPがより適しています。
As discussed above, both the ULP and the UXP schemes apply unequal error protection to the RTP media stream, but each uses a different technique. Both schemes have their own unique characteristics, and each can be applied to scenarios with different requirements.
上述したように、ULPとUXPスキームの両方は、RTPメディアストリームに不等エラー保護を適用するが、それぞれ異なる技術を使用します。どちらの方式では、独自のユニークな特徴を持っており、それぞれが異なる要件とシナリオに適用することができます。
The following authors have made significant contributions to this document: Adam H. Li, Fang Liu, John D. Villasenor, Dong-Seek Park, Jeong-Hoon Park, Yung-Lyul Lee, Jonathan D. Rosenberg, and Henning Schulzrinne. The authors would also like to acknowledge the suggestions from many people, particularly Stephen Casner, Jay Fahlen, Cullen Jennings, Colin Perkins, Tao Tian, Matthieu Tisserand, Jeffery Tseng, Mark Watson, Stephen Wenger, and Magnus Westerlund.
アダムH.リー、牙劉、ジョン・D. Villasenor、ドン・シーク公園、チョン・フンパーク、ヨン・Lyulリー、ジョナサンD.ローゼンバーグ、およびヘニングSchulzrinneと、次の作者はこのドキュメントへの重要な貢献をしました。著者らはまた、多くの人々、特にスティーブンCasner、ジェイFahlen、カレン・ジェニングス、コリンパーキンス、タオ天、マシューティスランド、ジェフリー・ツェン、マーク・ワトソン、スティーブン・ベンゲル監督、およびマグヌスウェスターからの提案を承認したいと思います。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[3]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[4] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[4]、RFC 4855、2007年2月Casner、S.、 "RTPペイロード形式のメディアタイプ登録を"。
[5] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[5]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月。
[6] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[6]李、A.、 "セッション記述プロトコルにおける前方誤り訂正グループ化セマンティクス"、RFC 4756、2006年11月。
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[7]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[9] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[9]ローゼンバーグ、J.とH. Schulzrinne、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 2733、1999年12月。
[10] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[10]パーキンス、C.およびO.ホドソン、 "ストリーミングメディアの修理のためのオプション"、RFC 2354、1998年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, November 2000.
[11]ローゼンバーグ、J.、およびH. Schulzrinneと、 "parityfec MIMEタイプの登録"、RFC 3009、2000年11月。
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[12]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[13] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[14] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[14] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[15]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
Editor's Address
編集者の住所
Adam H. Li 10194 Wateridge Circle #152 San Diego, CA 92121 USA Phone: +1 858 622 9038 EMail: adamli@hyervision.com
アダムH.リー10194 Wateridgeサークル＃152サンディエゴ、CA 92121 USA電話：+1 858 622 9038 Eメール：adamli@hyervision.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。