[要約] RFC 5109は、一般的な転送エラー訂正のためのRTPペイロード形式を定義しています。このRFCの目的は、RTPストリームの転送エラーを検出し、訂正するためのメカニズムを提供することです。
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
一般的なフォワードエラー補正用のRTPペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document 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およびRFC3009を廃止します。このドキュメントで指定された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は、パケット交換ネットワーク上のパケット損失から保護するために使用される主要な方法の1つです[9、10]。特に、パリティ、リードソロモン、ハミングコードなどの従来のエラー修正コードの使用には、多くのアプリケーションが見られます。これらのメカニズムを適用するには、プロトコルサポートが必要です。RFC 2733 [9]およびRFC 3009 [11]は、そのようなFECプロトコルの1つを定義しました。ただし、これら2つの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 2733およびRFC 3009との後方互換ではないことに注意してください。このドキュメントで指定されたペイロードは、RFC 3009のものとは異なるMimeによって知られているため、異なるパリティFECバージョンの誤認の懸念はありません。容量交換。ここおよびRFC 2733およびRFC 3009で指定されているパリティFECの場合、ペイロードデータは変更されておらず、ペイロードデータを保護するために追加のFECデータが送信されます。したがって、ペイロードデータの通信は、異なるパリティFECバージョンのホストとパリティFECを実装しなかったホストの間で問題なく流れます。送信ホストからの互換性のないFECを持つ受信ホストは、追加のFECデータから利益を得ることができないため、RFC 2733およびRFC 3009を実装する既存のホストを可能にする場合、この仕様に従うように更新することをお勧めします。
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.
このドキュメントでは、RTP [1]のペイロード形式を定義し、リアルタイムメディアの一般的なフォワードエラー補正を可能にします。これに関連して、汎用とは、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アルゴリズムとプロトコルは、このドキュメントで、リアルタイムメディアの不均等なエラー保護を伴う一般的なフォワードエラー補正のために定義されています。ここで定義されている特定のアルゴリズムは、Unevenレベル保護（ULP）と呼ばれます。ペイロードデータは、1つ以上の保護レベルで保護されています。低い保護レベルは、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には、Annex Vのオプションのデータパーティション化された構文があります。MPEG-4視覚的な簡単なプロファイルには、オプションのデータパーティションモードがあります。これらのモードを有効にすると、ビデオマクロブロック（MB）ヘッダーとモーションベクトルパーティション（ビデオ再建の品質にとってはるかに重要です）は、ビデオパケットの開始時にパーティションに送信されます。パーティション（重要性が低い）は、パケットの端に近いパーティションに送信されます。データは重要な順序で配置されているため、送信のパケットの最初の部分により多くの保護を提供することが有益です。
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を使用すると、メディアペイロードの保護の効率をさらに改善する可能性があります。このドキュメントは、一般的なFECをRTPメディアペイロードに適用するためのプロトコルとアルゴリズムを指定します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は、Simple Exclusive-OR（XOR）パリティの運用に基づいています。送信者は、保護を必要とするメディアストリームからパケットを取得し、これらのパケットの保護レベルと各レベルの保護長を決定します。データは、セクション7で説明するように一緒にグループ化されています。FEC情報を生成するために、XOR操作がペイロード全体に適用されます。ここで定義されている手順に続く結果は、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で保護されているデータの量は、L（k）で示され、FECパケットでも送信されます。保護長、オフセットマスク、ペイロードタイプ、およびシーケンス番号ベースは、オーバーヘッドがほとんどない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.
簡潔にするために、データブロックx、y、...この関数の出力はパリティブロックと呼ばれる別のブロックに適用されるxor（パリティ）演算子であると、関数f（x、y、..）を定義します。簡単にするために、ここでは、パリティブロックが入力ブロックのビットワイズXORとして計算されていると仮定します。正確な手順は、セクション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つのデータブロックで単一のパリティブロックを生成するパリティコードを検討してください。元のメディアパケットがa、b、c、dの場合、送信者によって生成されたパケットは次のとおりです。
a b c d <-- media stream
f(a,b) f(c,d) <-- FEC stream
where time increases to the right. In this example, the error correction scheme (we use the terms scheme and code interchangeably) introduces a 50% overhead. But if b is lost, a and f(a,b) can be used to recover b.
時間が右に増加する場所。この例では、エラー補正スキーム（用語スキームとコードを互換性が高い）で50％のオーバーヘッドを導入します。ただし、Bが失われた場合、aおよびf（a、b）を使用してb。
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パリティコード以外にペイロードを保護するためにも使用できる他の多くのタイプのフォワードエラー補正コードがあることを指摘することは有用かもしれません。注目すべき例の1つはReed-Solomonコードであり、他にも多くあります[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.
上記の簡単な例からわかるように、データの保護はグループのサイズに依存します。上記の例では、グループサイズは2です。したがって、3つのパケットのいずれか（2つのペイロードパケットと1つのFECパケット）が失われた場合、元のペイロードデータを回復できます。
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を保護するレベルが1つしかありません。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保護は、パケットCとDで動作していることを除いて、ULP FECパケット＃1の場合と同じです。レベル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:
FECパケットは、図2に示すように、FECヘッダーと1つ以上のレベルのFECヘッダーとペイロードをRTPペイロードに配置することによって構築されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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対応の混合レシーバーを備えたマルチキャストグループで使用できます（セクション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回復フィールドは、RTPヘッダーからの対応するP、X、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に設定されている場合、Lフィールドが1に設定されている場合は48パケットの最大16パケットの任意の文字列に拡張できます。
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.
長さの回復フィールドは、回収されたパケットの長さを決定するために使用されます。これは、メディアペイロードの長さ（バイト）の合計（CSRCリスト、拡張、およびこのFECパケットに関連付けられた各メディアパケットのパディング）の未署名ネットワーク順序付けされた16ビット表現に適用される保護操作を介して計算されます。（言い換えれば、CSRCリスト、RTP拡張機能、およびメディアペイロードパケットのパディングは、存在する場合、ペイロードの一部として「カウント」されます）。これにより、保護されたメディアパケットの長さが同一でない場合でも、FEC手順を適用できます。たとえば、2つのメディアパケットを一緒にXORしてFECパケットが生成されていると仮定します。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レベルのヘッダーは4オクテットまたは8オクテットです（FECヘッダーのLビットに応じて）。ヘッダーの形式を図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ビットです。マスクフィールドは、長さ16ビット（Lビットが設定されていない場合）または長さ48ビット（Lビットが設定されている場合）です。
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を持つメディアパケットは、このFECパケットに関連付けられています。ここで、NはFECパケットヘッダーのSNベースフィールドです。マスクの最も重要なビットはi = 0に対応し、Lビットが0に設定されている場合はi = 15に最も重要ではない、またはLビットが1に設定されている場合はi = 47。
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よりも高い各保護レベルで1回のみ保護されなければなりません。メディアパケットは、レベル0で異なるパケットで2回以上保護できます。これらのパケットのレベル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.
保護の組み合わせの1つの例を以下の図5に示します。これは、図1に示すように同じ例です。この同じ例は、ヘッダーのフィールドがどのように設定されているかを示すために、セクション10.2の詳細についても示しています。
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には保護レベルがあります。ULPFECパケット＃2には保護レベル0と1があります。テーブルを横切って読み、ペイロードパケットAはレベル0のULP FECパケット＃1によって保護されていることが示されています。、レベル1のULP FECパケット＃2など。また、ULP FECパケット＃2がレベル0のペイロードパケットCおよびDで保護すること、レベル1ペイロードパケットA-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パケットのペイロードは、そのレベルでのULP FECパケットに関連するメディアパケットのメディアペイロードとパディングに適用される保護操作（XOR）です。詳細については、保護操作のセクション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に大きな保護長が選択されているため、保護する最長のメディアパケットよりも大きくなる可能性があることに注意してください。これにより、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ヘッダーの場合、保護されたビット文字列（長さ80ビット）は、FECレベル0で保護される各メディアパケットに対して生成されます。指定された順序で次のフィールドを連結することにより形成されます。
o The first 64 bits of the RTP header (64 bits)
o 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 バイトマイナス12（固定RTPヘッダーの場合）のメディアパケット長の符号なしのネットワーク命令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パケットの長さが等しくない場合、各短いパケットは、最後にOctet 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ペイロードデータとして設定されます。データは、FECビット文字列の（sn 13）thオクテットから始まるデータのlnオクテットです。
Sn = sum(Li : 0 <= i < n).
sn = sum（li：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は0であると定義されています。最初の12オクテットを省略する理由は、その情報がすでに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番目のステップは実際にデータを再構築することです。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.
1. Tのメディアパケットの場合、前のセクションでFECヘッダーを生成するために説明されているように、手順に従って保護されたビット文字列の最初の80ビットを計算します。
2. For the FEC packet in T, the FEC bit string is the 80-bit FEC header.
2. TのFECパケットの場合、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. Tのすべてのメディアパケットから生成されたBitWiseの排他的または保護されたビット文字列のRecovery Bit Stringを計算し、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. 新しいパケットのパッディングビットを、Recovery Bit Stringの次のビットに設定します。
7. Set the Extension bit in the new packet to the next bit in the recovery bit string.
7. 新しいパケットの拡張ビットを、Recoveryビット文字列の次のビットに設定します。
8. Set the CC field to the next 4 bits in the recovery bit string.
8. Recoveryビット文字列の次の4ビットにCCフィールドを設定します。
9. Set the marker bit in the new packet to the next bit in the recovery bit string.
9. 新しいパケットのマーカービットを、Recoveryビット文字列の次のビットに設定します。
10. Set the payload type in the new packet to the next 7 bits in the recovery bit string.
10. 新しいパケットのペイロードタイプを、Recoveryビット文字列の次の7ビットに設定します。
11. Set the SN field in the new packet to xi. Skip the next 16 bits in the recovery bit string.
11. 新しいパケットのSNフィールドをxiに設定します。Recovery Bit Stringで次の16ビットをスキップします。
12. Set the TS field in the new packet to the next 32 bits in the recovery bit string.
12. 新しいパケットのTSフィールドを、Recovery Bit Stringの次の32ビットに設定します。
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. Recovery Bit Stringの次の16ビットを取ります。これが表す（ネットワークオーダーを想定する）署名されていない整数が何であれ、Recovery Bit Stringから多くのバイトを取得し、新しいパケットに追加します。これは、RTPペイロードのCSRCリスト、拡張機能、ペイロード、およびパディングを表します。
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.
14. 新しいパケットのSSRCを保護するメディアストリームのSSRCに設定します。つまり、FECストリームが関連付けられているメディアストリームのSSRCです。
This procedure will recover the header of an RTP packet up to the SSRC field.
この手順は、RTPパケットのヘッダーをSSRCフィールドまで回復します。
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のレベルn（LN）の保護長をレベルnのULPヘッダーから取得することです。
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.
2. TのFECパケットの場合、レベル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.
3. Tのメディアパケットの場合、レベルnの保護されたビット文字列は、パケットの（SN 13）Thオクテットから始まるデータのlnオクテットです。SNは、セクション8.2で定義されているものと同じです。レベル0の保護は、SSRCフィールドの後にメディアパケットの13番目のオクテットから始まることに注意してください。最初の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. メディアパケットから生成されたレベルnの保護されたビット文字列のいずれかが、現在のレベルの保護長よりも短い場合は、その長さにパッドします。Octet 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. Tのすべてのメディアパケットから生成されたレベルnのビットワイズ排他的または保護されたビット文字列のリカバリビット文字列を、TのすべてのFECパケットから生成されたレベルnの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.
以下で説明する最初の2つの例（セクション10.1および10.2）では、FECストリームはセクション14.1で説明されているように別のRTPセッションで送信されると想定しています。これらの例では、SSRC 2から4つのメディアパケット、A、B、C、およびDが送信されると仮定します。シーケンス番号はそれぞれ8、9、10、および11で、3、5のタイムスタンプがあります。、7と9のそれぞれ。パケットAおよびCはペイロードタイプ11を使用し、パケットBとDはペイロードタイプ18を使用します。パケットAには、ペイロード、パケットB 140、パケットC 100、およびパケットD 340の200バイトがあります。パケットAとCにはマーカービットが設定されています。
The third example (Section 10.3) is to illustrate when the FEC data is sent as redundant data with the payload packets.
3番目の例（セクション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つのペイロードパケットを1つのレベルで完全に保護できます。これは、RFC 2733と同様の保護を提供します。スキームは図6に示すとおりです。
+-------------------+ :
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.
これらの4つのパケットからFECパケットが生成されます。ペイロードタイプ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]
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、および11にそれに応じてマークされたビット1、2、3、および4]
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は、残りのパケットに追加の保護を適用します。これを図10に示します。この例では、L0 = 70およびL1 = 90です。
+------:--------:---+
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：保護レベル0とレベル1のULP FECスキーム
This will result in two FEC packets - #1 and #2.
これにより、2つのFECパケット（＃1と＃2）になります。
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には、図11に示すようにRTPヘッダーがあります。ULPFECパケット＃1のFECヘッダーは図12に示すとおりです。＃1のレベル0 ULPヘッダーは、図13に示すとおりです。。
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]
Figure 12: FEC Header of ULP FEC Packet #1
図12：ULP FECパケットのFECヘッダー＃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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 [パケット8および9にそれに応じてマークされたビット1および2で]
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には、図14に示すようにRTPヘッダーがあります。FECパケット＃2のFECヘッダーは、図15に示すとおりです。＃2のレベル0 ULPヘッダーは、図16に示すとおりです。＃2のレベル1 ULPヘッダーは、図17に示すとおりです。
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]
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 [パケット10および11にそれに応じてマークされたビット3および4で]
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 [パケット8、9、10、および11にそれに応じてマークされたビット1、2、3、および4]
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を示しています。SSRC 2から5つのメディアパケットをA、B、C、D、およびEを送信すると仮定します。それらのシーケンス番号はそれぞれ8、9、10、11、および12で、3、5のタイムスタンプがあります。、それぞれ7、9、および11。すべてのメディアデータはプライマリコーディング（および冗長コーディングがプライマリコーディングのみを保護するためのFEC）でコーディングされ、ペイロードタイプ11を使用します。パケットAには、ペイロード、パケット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.
使用するFECスキームは、セクション10.1の図6に示すように、1つのレベルになります。保護長l0 = 340オクテット。
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つの赤いパケット、赤1〜レッド＃4、それぞれに個別のメディアパケット、A、B、Cが含まれています。またはそれぞれD。最初の4つのメディアパケットのメディアデータを保護するFECデータが生成されます。5番目のパケット、Red＃5には、このFECデータが冗長なコーディングとしてメディアパケットEを含めています。
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 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.
赤いパケット＃1から＃4には、図18に示すように構造があります。赤パケット＃1のRTPヘッダーは図19に示すとおり、他のすべての赤いパケットは、対応するシーケンス番号とタイムスタンプを持つ同様の形式です。赤いパケットの主要なエンコーディングブロックヘッダーは、図20に示すとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (RED) - 6 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Encoding Block Header (RED) - 1 octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Media Packet Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: RED Packet Structure - Media Data Only
図18：赤いパケット構造 - メディアデータのみ
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マーカー：0 [メディアパケットAにマーカーセットがある場合でも] PT：100 [赤のペイロードタイプ] SN：1 TS：5 SSRC：2
Figure 19: RTP Header of RED Packet #1
図19：Red Packet＃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データは、赤いパケットからではなく、メディアパケットデータを含む仮想RTPパケットから生成されます。これらの仮想RTPパケットは、冗長コーディングを含む場合となしの両方で赤いパケットから非常に簡単に生成できます。赤いパケットから仮想RTPパケットへの変換は、（1）赤いブロックヘッダーと冗長コーディングデータを削除し、（2）RTPヘッダーのPTをプライマリコーディングの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.
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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：赤いパケット構造 - 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.
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)]
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つの方法があります。1つの方法は、すでに暗号化されたペイロードにFECを適用することです。もう1つの方法は、暗号化の前にFECを適用することです。最初のケースは、メディアデータが暗号化された後、送信中に信頼されていないノードによってFECが必要な場合に発生します。2番目のケースは、メディアデータがFECが保護された輸送を介して送信する前に保護されている場合に発生します。
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を適用することは、主に安全なRTP（SRTP）の場合に適用されます[13]。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.
o メディアストリームは暗号化される場合がありますが、FECストリームは暗号化されていません。
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パケットとは違う扱いを行う必要があるため、最初の2つのケースはレイヤー化違反を示しています。1つのストリームのみを暗号化すると、特定の既知のプレーンテキスト攻撃が可能になる場合があります。これらの理由により、暗号化を使用するアプリケーションは、両方のストリーム、つまり最後の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.
暗号化キーの変更は、対処する必要があるもう1つの重要な問題です。2つのパケット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データの一部のビットを変更することによる攻撃は、ペイロードパケットの計算と回復に大きな影響を与える可能性があります。たとえば、長さの回復フィールドを変更すると、長すぎるパケットが回復する可能性があります。また、回復の計算の複雑さは、少なくとも最大1桁まで簡単に影響を受ける可能性があります。アプリケーションシナリオに応じて、回復操作を実行する前に受信したペイロードと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の使用に関するもう1つの問題は、ネットワークの混雑への影響です。多くの状況では、ネットワーク内のパケットの損失は混雑によって誘発されます。このようなシナリオでは、ネットワーク損失の増加に遭遇したときに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フローが同じネットワーク条件を経験している場合、合理的なタイムスケールで測定された平均スループットを達成する場合、パケット損失は許容できると見なされます。この条件は、透過速度（または層状マルチキャストセッションにサブスクライブされるレイヤー数）を適応させるための輻輳制御メカニズムを実装すること、または損失率が容認できないほど高い場合にセッションを去るように配置することにより、満たすことができます。
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操作に十分な解像度を提供するために、レートは1000 Hzを超えるものとします。選択されたレートは、1000 Hzを超える任意の値になる場合がありますが、このストリームが保護するメディアのレートと一致するように推奨されます。
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保護のレベルが1つしか使用されていないかどうかを指定します。許容値は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.
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
詳細については、連絡先への個人およびメールアドレス：adam li adamli@hyervision.com ietfオーディオ/ビデオトランスポートワーキンググループ
Intended usage: 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
著者：adam li adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
Type name: video
タイプ名：ビデオ
Subtype name: ulpfec Required parameters:
サブタイプ名：ULPFEC必須パラメーター：
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操作に十分な解像度を提供するために、レートは1000 Hzを超えるものとします。選択されたレートは、1000 Hzを超える任意の値になる場合がありますが、このストリームが保護するメディアのレートと一致するように推奨されます。
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保護のレベルが1つしか使用されていないかどうかを指定します。許容値は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
詳細については、連絡先への個人およびメールアドレス：adam li adamli@hyervision.com ietfオーディオ/ビデオトランスポートワーキンググループ
Intended usage: 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.
Author: Adam Li adamli@hyervision.com
著者：adam li adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：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操作に十分な解像度を提供するために、レートは1000 Hzを超えるものとします。選択されたレートは、1000 Hzを超える任意の値になる場合がありますが、このストリームが保護するメディアのレートと一致するように推奨されます。
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保護のレベルが1つしか使用されていないかどうかを指定します。許容値は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.
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
追加情報：連絡先の人と電子メールアドレス詳細については、adam li adamli@hyervision.com ietfオーディオ/ビデオトランスポートワーキンググループ
Intended usage: 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
著者：adam li adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：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操作に十分な解像度を提供するために、レートは1000 Hzを超えるものとします。選択されたレートは、1000 Hzを超える任意の値になる場合がありますが、このストリームが保護するメディアのレートと一致するように推奨されます。
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保護のレベルが1つしか使用されていないかどうかを指定します。許容値は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
詳細については、連絡先への個人およびメールアドレス：adam li adamli@hyervision.com ietfオーディオ/ビデオトランスポートワーキンググループ
Intended usage: 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
著者：adam li adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：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 [8]で指定されたセッション説明プロトコル（SDP）を使用してこれをどのように達成できるかについても説明します。
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
o
o The payload type number for the FEC
o FECのペイロードタイプ番号
o Which media stream the FEC is protecting 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.
o FECが保護しているメディアストリームは、FECの静的なペイロードタイプの割り当てがないため、動的なペイロードタイプ番号を使用する必要があります。FECストリームのSSRCは、保護されたペイロードストリームのSSRCに設定する必要があります。FECストリームとの対応するストリームとの関連は、SDP [5]のライングループ化によってFECセマンティクス[6]または他の外部平均によって行われます。
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 [1]のセクション5.2で説明した原則に従って、FECストリームとその関連するペイロードストリームの多重化は、通常、各RTPセッションで異なる宛先輸送アドレス（ネットワークアドレスとポート番号）によって提供されます。1つのRTPセッションでPayloadと一緒にFECを送信し、SSRCまたはペイロードタイプの排除によってのみマルチプレックスを送信します。（1）ペイロードおよびFEC保護データの異なるネットワークパスまたはネットワークリソース割り当ての使用。（2）必要に応じて、特にFECを理解していないホストのメディアのサブセットの受信。（3）異なるメディアに個別のプロセスを使用する受信機の実装。さらに、ペイロードデータストリームを使用した多重化FECは、通常は望ましくない元のペイロードストリームのタイミングとシーケンス番号スペースに影響します。したがって、FECストリームとペイロードストリームは2つの個別のRTPセッションを通じて送信され、ペイロードタイプでそれらを多重化して1つのRTPセッションに避ける必要があります。さらに、FECとペイロードは、常に同じSSRCを持っているため、SSRCによって1つのRTPセッションに多重化されてはなりません。
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セマンティクス（RFC 4756）[6]を使用して、FECストリームと保護するペイロードストリームとの関連関係は、SDP（RFC 3388）[5]のメディアライングループ（RFC 3388）[5]を通じて伝えられます。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つのA =グループラインの存在は、2つのFECグループがあることを示しています。「A =グループ：FEC 1 2」行で示される最初のFECグループは、ストリーム1（PCM [14]を使用したオーディオストリーム）とストリーム2（FECストリームの保護）で構成されています。FECストリームは同じマルチキャストグループに送信され、オーディオと同じ時間（TTL）がありますが、ポート番号は2つ高くなります。2番目のFECグループは、「A =グループ：FEC 3 4」ラインで示されているように、ストリーム3（ビデオストリーム）とストリーム4（Protecting 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はメインコーデックのみを保護する必要があり、メインコーデックデータから作成された仮想RTPパケットからFECエンジンのペイロードが供給されます。仮想RTPパケットは、（1）すべての追加ヘッダーと冗長コーディングデータを削除し、（2）RTPヘッダーのペイロードタイプをプライマリコーデックのペイロードタイプに置き換えるだけで、RFC 2198パケットから非常に簡単に変換できます。
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.
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.
FECデータ（ULPヘッダーを含む）は保護されたペイロードと同じパケットで送信されるため、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
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ラインでの存在は、RFC 2198に従って非プリマリーコーデックをここにリストする必要があるためにのみ必要です。FMTP属性は、冗長エンコーディング形式を使用できることを示しています。
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の1つのレベルのみが送信されるかどうかを示します。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.
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）[7]のセカンダリコーデックとして送信されると、提供側はセクション14.2で指定されているようにFECストリームを示すことができます。ASWNERは、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メカニズムと設定をサポートするのに十分な柔軟性があります。（3）FECパラメーターを帯域外シグナリングに頼らずに簡単に変更できるように、適応性のために設計されています。（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は、ユーザーに不平等なエラー保護機能を提供します。他のいくつかのアルゴリズムは、他の手段を通じて不均等なエラー保護機能を提供する場合があります。たとえば、AVTワーキンググループでは、「プログレッシブマルチメディアストリームの消去依存性伝送のためのRTPペイロード形式」で、AVTワーキンググループでは、不均等な消去保護（UXP）スキームが提案されています。UXPスキームは、Reed-Solomon操作を使用して取得した追加の冗長情報でペイロードストリームをインターリーで保護することにより、メディアペイロードに不平等なエラー保護を適用します。
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）パリティチェック操作は、Reed-Solomonコードで必要な複雑な操作よりもシンプルで高速です。これにより、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.
次の著者は、この文書に大きな貢献をしています：Adam H. Li、Fang Liu、John D. Villasenor、Dong-Hoon Park、Jeong-Hoon Park、Yung-Liul Lee、Jonathan D. Rosenberg、Henning Schulzrinne。著者はまた、多くの人々、特にスティーブン・カスナー、ジェイ・ファーレン、カレン・ジェニングス、コリン・パーキンス、タオ・ティアン、マティュー・ティセランド、ジェフリー・ツェン、マーク・ワトソン、スティーブン・ウェンガー、マグナス・ウェスタルランドからの提案を認めたいと思います。
[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.、Frederick、R。、およびV. Jacobson、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[3] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[4] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[4] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[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] Camarillo、G.、Eriksson、G.、Holler、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] Li、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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-Parisis、 "RTP Payload for Redundant Audioデータ」、RFC 2198、1997年9月。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[8] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Rosenberg、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] Perkins、C。and O. Hodson、「ストリーミングメディアの修理のオプション」、RFC 2354、1998年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, November 2000.
[11] Rosenberg、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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（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.、McGrew、D.、Naslund、M.、Carrara、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
Editor's Address
編集者のアドレス
Adam H. Li 10194 Wateridge Circle #152 San Diego, CA 92121 USA Phone: +1 858 622 9038 EMail: adamli@hyervision.com
Adam H. Li 10194 Wateridge Circle＃152 San Diego、CA 92121 USA電話：1 858 622 9038メール：adamli@hyervision.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。