RFC5109 日本語訳
5109 RTP Payload Format for Generic Forward Error Correction. A. Li,Ed.. December 2007. (Format: TXT=100538 bytes) (Obsoletes RFC2733, RFC3009) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Li, Ed. Request for Comments: 5109 December 2007 Obsoletes: 2733, 3009 Category: Standards Track
ワーキンググループのA.李、エドをネットワークでつないでください。コメントのために以下を要求してください。 5109 2007年12月は以下を時代遅れにします。 2733、3009カテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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でカプセル化されたメディアデータとしてジェネリックForward Error Correction(FEC)にペイロード形式を指定します。 それは排他的論理和(同等)操作に基づいています。 エンドシステムは本書では説明されたペイロード形式で様々な保護の長さとレベルを使用することで保護を当てはまることができます、異なったメディアとチャネル特性に順応するのに様々な保護グループサイズを使用することに加えて。 それはパケット損失状況に依存する保護されたパケットの全快かペイロードの重要な一部分の部分的な回復を可能にします。 この体系はできる非FECホストと完全に互換性があるので、FECを実装しないマルチキャストグループにおける受信機は単に保護データを無視することによって、まだ動作できます。 この仕様はRFC2733とRFC3009を時代遅れにします。 本書では指定されたFECはRFC2733とRFC3009と互換性があった状態で後方ではありません。
Li Standards Track [Page 1] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[1ページ]。
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
1. 序論…2 2. 用語…5 3. 基本的な操作…6 4. パリティコード…7 5. 不ぞろいなレベル保護(ULP)…7 6. RTPメディア向けの資料セット構造…9 7. FECパケット構造…9 7.1. パケット構造…9 7.2. FECパケットのためのRTPヘッダー…10 7.3. FECパケットのためのFECヘッダー…11 7.4. FECはFECパケットのためにヘッダーを平らにします…12 8. 保護操作…15 8.1. FECヘッダーの世代…15 8.2. FEC有効搭載量の世代…16 9. 回復手順…16 9.1. RTPヘッダーの再建…16 9.2. RTP有効搭載量の再構成…18 10. 例…19 10.1. 例はRFC2733として同様の保護を提供します…19 10.2. 2つの保護レベルがある例…21 10.3. 余分なコード化としてのFECがある例…26 11. セキュリティ問題…29 12. 混雑問題…30 13. IANA問題…31 13.1. オーディオ/ulpfecの登録…31 13.2. ビデオ/ulpfecの登録…32 13.3. テキスト/ulpfecの登録…34 13.4. アプリケーション/ulpfecの登録…35 14. FECのマルチプレクシング…36 14.1. 別々のストリームとしてのFEC…36 14.2. 余分なコード化としてのFEC…38 14.3. 考慮に提供するか、または答えてください…39 15. アプリケーション声明…40 16. 承認…42 17. 参照…42 17.1. 標準の参照…42 17.2. 有益な参照…43
1. Introduction
1. 序論
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
リアルタイムのアプリケーションの本質は、通常、それらには正常なデータ伝送より厳しい遅れ要件があるのを含意します。 その結果、一般に、無くなっているパケットの「再-トランスミッション」はそのようなアプリケーションのための妥当な選択肢ではありません。 これらの場合には、Forward Error Correction(FEC)を通してパケット損失から情報の回復を試みるより良いメソッドがあります。 FECはメソッドが以前はよくそうしていたメインのひとりです。
Li Standards Track [Page 2] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[2ページ]。
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.
パケット交換網[9、10]の上のパケット損失から守ってください。 特に、同等などの伝統的な誤り検出方式の使用(リード-ソロモン、およびハミングコード)は、多くのアプリケーションを見ました。 これらのメカニズムを適用するために、プロトコルサポートが必要です。 RFC2733[9]とRFC3009[11]はそのようなFECプロトコルの1つを定義しました。 しかしながら、これらの2RFCsでは、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.
このドキュメントはペイロードデータで不平等な誤り保護を含むようにRFC2733とRFC3009で定義されたFECを広げています。 それは前の2RFCsと共に特別なケースとして一般的なアルゴリズムを指定します。 この仕様も、RFC2733とRFC3009との上記の矛盾を修理して、それらの前の2RFCsを時代遅れにするでしょう。 本書では指定されたペイロードはRFC2733とRFC3009と互換性があった状態で後方ではありません。 本書では指定されたペイロードがRFC3009のものと異なったMIMEsによって合図されるので、容量交換における、異なったパリティFECバージョンの誤認の関心が全くありません。 ここで指定されたパリティFECsとRFC2733とRFC3009では、ペイロードデータを非変更します、そして、ペイロードデータを保護するために追加FECデータを送ります。 したがって、ペイロードデータに関するコミュニケーションは異なったパリティFECバージョンのホストの間の問題なしで流れるでしょう、そして、それがしたホストは同等がFECであると実装しません。 送付ホストからの非互換なFECの受信ホストは追加FECデータの利益を得ることができないでしょう、そして、したがって、RFCが2733であると実装するその既存のホストにそれを推薦します、そして、可能であるときに、この仕様に従うためにRFC3009をアップデートするべきです。
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のテクニックが容易にバンドの外なしで変更されたシグナリングになって、設計されています。 そして、FECパケットを輸送するのにおいて、多くの異なったメカニズムを支持している(4)。
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
その上、多くのシナリオでは、ネットワーク接続の帯域幅は非常に限られたリソースです。 他方では、伝統的なFEC体系の大部分は限られた帯域幅リソースの最適の利用のために設計されていません。 しばしば使用された改良は重要性において異なるデータ・ストリームの異なった一部分のための異なったレベルの保護を提供する不平等な誤り保護です。 不平等な誤り保護体系は、データの、より良い総合的な保護を提供するために通常帯域幅の、より効率的な使用をすることができます。
Li Standards Track [Page 3] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[3ページ]。
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.
損失に対して流れてください。 これらの不平等な誤り保護メカニズムがわかるのに、適切なプロトコルサポートは不可欠です。不平等な誤り保護体系の大部分のアプリケーションは、知識を持っているのをデータ・ストリームの異なった一部分に重要性を要求します。 その理由で、そのような体系の大部分は、保護されたメディアの構造と、結果として特定のタイプのメディアのために設計されていて、ジェネリックではありません。
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 Level Protection(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.
ビデオストリームのために、ほとんどの現代の形式には、ビデオmacroblockヘッダー・データ、動きベクトルデータ、およびDiscrete Cosine Transform(DCT)係数データが彼らの個々のパーティションに切り離される誤り弾力を改良するためにモードを仕切る任意のデータがあります。 例えば、Annex V.In MPEG-4Visual Simple Profileの任意のデータ仕切られた構文がITU-T H.263バージョン3にあって、任意のデータ仕切りのモードがあります。 これらのモードがビデオパケットの始めに可能にされるとき、残りDCT係数パーティション(それほど重要でない)はパケットの端の近くときのパーティションで伝えられますが、ビデオmacroblock(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
また、オーディオストリームのために、新しいオーディオコーデックの多くによって生成されたbitstreamsは異なったクラスの重要性があるデータを含んでいます。 そして、これらの異なったクラスは下ることの順に伝えられます。
Li Standards Track [Page 4] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[4ページ]。
importance. Applying more protection to the beginning of the packet would also be beneficial in these cases. Even for uniform- significance audio streams, various time shifting and stretching techniques can be applied to the partially recovered audio data packets.
重要性。 また、より多くの保護をパケットの始まりに適用するのもこれらの場合で有益でしょう。 ユニフォーム意味オーディオストリームにおいてさえ、様々な時間、部分的に回復しているオーディオデータ・パケットにテクニックを移行して、伸ばすのを適用できます。
Audio/video applications would generally benefit from the FEC algorithms specified in this document. With ULP, the efficiency of the protection of the media payload can potentially be further improved. This document specifies the protocol and algorithm for applying the generic FEC to the RTP media payloads.
一般に、オーディオ/ビデオ・アプリケーションは本書では指定されたFECアルゴリズムの利益を得るでしょう。 ULPと共に、メディアペイロードの保護の効率を潜在的にさらに高められることができます。 このドキュメントはRTPメディアペイロードにジェネリックFECを適用するためのプロトコルとアルゴリズムを指定します。
2. Terminology
2. 用語
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つ以上のメディア向けの資料セット(逆もまた同様である)に「関連している」と言われています。 それは別の方法で明らかに述べられないなら0FECペイロードをレベルに生成するのに使用されるそれらのパケットだけについて言及します。
Li Standards Track [Page 5] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[5ページ]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
3. Basic Operation
3. 基本的な操作
The payload format described here is used when the sender in an RTP session would like to protect the media stream it is sending with generic parity FEC. The FEC supported by this format is based on simple exclusive-or (XOR) parities operation. The sender takes the packets from the media stream requiring protection and determines the protection levels for these packets and the protection length for each level. The data are grouped together as described below in Section 7. The XOR operation is applied across the payload to generate the FEC information. The results following the procedures defined here are RTP packets containing FEC information. These packets can be used at the receiver to recover the packets or parts of the packets used to generate the FEC information.
RTPセッションにおける送付者がそれがジェネリックパリティFECと共に送るメディアストリームを保護したがっているとき、ここで説明されたペイロード形式は使用されています。 この形式によってサポートされたFECは簡単な排他的論理和(XOR)parities操作に基づいています。 送付者は、保護を必要とするメディアストリームからパケットを取って、これらのパケットのための保護レベルと各レベルのための保護の長さを測定します。 データはセクション7で以下で説明されるように一緒に分類されます。 XOR操作は、FECが情報であると生成するためにペイロードの向こう側に適用されます。 手順に従うのがここで定義した結果は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はこのFECパケットによってレベルkで保護されます。 Nを一連番号ベースと呼んで、また、FECパケットで送ります。 レベルkで保護されるデータ量はL(k)によって示されます。(また、L(k)はFECパケットで送られます)。 保護の長さ、オフセットマスク、ペイロードタイプ、および一連番号ベースは少ないオーバーヘッドで生成するコードがFECパケットを当てはまった同等を完全に特定します。 1セットの規則はマスクがどう異なった保護レベルに設定されるべきであるかを定義するセクション7.4で説明されます、例がセクション10にある状態で。
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パケットを結合できます。
Li Standards Track [Page 6] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[6ページ]。
4. Parity Codes
4. パリティコード
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)を定義します… この機能の出力はパリティブロックと呼ばれる別のブロックです。 簡単さのために、私たちは、ここでパリティブロックが入力ブロックのbitwise 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:
例えば、同等が1つのパリティブロックが2データ・ブロック以上であると生成するコードであると考えてください。 オリジナルのメディア向けの資料セットがa、b、c、dであるなら、送付者によって生成されたパケットは以下の通りです。
a b c d <-- media stream
f(a,b) f(c,d) <-- FEC stream
b c d<--メディアストリームf(a、b)f(c、d)<--FECは流れます。
where time increases to the right. In this example, the error correction scheme (we use the terms scheme and code interchangeably) introduces a 50% overhead. But if b is lost, a and f(a,b) can be used to recover b.
時間が右に増加するところ。 この例では、エラー修正体系(私たちは用語体系とコードを互換性を持って使用する)は50%のオーバーヘッドを導入します。 しかし、bが無くなるなら、bを回復するのに、aとf(a、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つの注目に値する例がリードソロモンコードです、そして、多くの他のもの[12]がいます。 しかしながら、XORパリティコードはその有効性と簡単さのためにプロトコルデザインと実装の両方でここで使用されます。 ノードの実装には、これは限りある資源によって特に重要です。
5. Uneven Level Protection (ULP)
5. 不規則な平らな保護(ULP)
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パケットが多ければ多いほど、損失に対する保護にもかかわらず、よりすばらしいのは帯域幅が結合したストリームで消費したより強いです。
Li Standards Track [Page 7] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[7ページ]。
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.
メディアペイロードの大部分におけるよくある例のように、パケットのすべての一部が同じくらい重要であるというわけではありません。 この特性を使用して、1つは、すなわち、パケットの異なった一部のための異なった保護を適用しながら不平等な誤り保護を使用することで潜在的にチャンネル帯域幅の、より効率的な使用を実現できます。 より多くの帯域幅がそれほど重要でない部分におけるより少ない帯域幅である間、より重要な部分を保護するのに費やされます。
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には、1つのレベルしかなくて、それは両方のパケットに関するデータの長さを保護するだけです。(レベルは適用パリティ演算のパケットAとB.Insteadを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保護は、レベル0からULP FECパケット#1に、パケットCとD.の上でレベル1を操作しているのを除いて、保護がパケットAからのデータで適用されたパリティ演算を使用しています、B、C、1つの保護を平らにするD.Noteが異なったセットのパケットを作動させるのと同じであり、レベル0と異なった保護の長さを持って、いかなる他のレベルもそうです。 情報はすべて運ばれたこれで指定されたプロトコルを通したバンドのドキュメントです。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
パケットA#####################: : パケットB###############: : : ULP FECパケット#1@@@@@@@@: : : パケットC###########: : : パケットD###################################: : ULP FECパケット#2@@@@@@@@@@@@@@@@@: : : :<L0>: <--L1-->:
Figure 1: Unequal Level Protection
図1: 不平等な平らな保護
Li Standards Track [Page 8] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[8ページ]。
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はパケット(より重要である)の始まりまで、より多くの保護を提供するだけではありません、また、それが、より少ない効率的なシナリオをできるだけ避けます。後のセクションを回収できますが(そして、しばしば捨てられなければなりません)、パケットの以前のセクションは復しません。
6. RTP Media Packet Structure
6. RTPメディア向けの資料セット構造
The formatting of the media packets is unaffected by FEC. If the FEC is sent as a separate stream, the media packets are sent as if there was no FEC.
メディア向けの資料セットの形式は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パケットに存在していて、容易にモニターして、調整できます。
7. FEC Packet Structure
7. FECパケット構造
7.1. Packet Structure
7.1. パケット構造
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パケットはFECヘッダーと1つ以上のレベルのFECヘッダーとペイロードをRTPペイロードに置くことによって、組み立てられます、図2に示されるように:
Li Standards Track [Page 9] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[9ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header(12以上の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Header(10の八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FECレベル0 ヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FECレベル0 有効搭載量| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FECレベル1 ヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FECレベル1 有効搭載量| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cont。 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Packet Structure
図2: FECパケット構造
7.2. RTP Header for FEC Packets
7.2. FECパケットのためのRTPヘッダー
The RTP header for FEC packets is only used when the FEC are sent in a separate stream from the protected payload stream (as defined in Section 14). Hence, much of the discussion below applies only to that scenario. All the fields in the RTP header of FEC packets are used according to RFC 3550 [1], with some of them further clarified below.
保護されたペイロードストリームから別々のストリームでFECを送るときだけ(セクション14で定義されるように)、FECパケットのためのRTPヘッダーを使用します。 したがって、以下の議論の多くがそのシナリオだけに適用されます。 RFC3550[1]によると、FECパケットのRTPヘッダーのすべての分野が使用されます、それらのいくつかが以下でさらにはっきりさせられている状態で。
Marker: This field is not used for this payload type, and SHALL be set to 0.
マーカー: この分野はこのペイロードタイプ、およびSHALLに使用されません。0に設定されます。
Synchronization Source (SSRC): The SSRC value SHALL be the same as the SSRC value of the media stream it protects.
同期ソース(SSRC): SSRCはSSRCと同じくらいがそれが保護するメディアの流れの値であったならSHALLを評価します。
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
有効搭載量タイプ: FECパケットのためのペイロードタイプはダイナミックで、バンドで出ている手段で決定します。 RFC3550[1]によると、ペイロードタイプを認めることができないRTP関係者はそれを捨てなければなりません。 これは後方の互換性を提供します。 その時、FECメカニズムがあることができます。
Li Standards Track [Page 10] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[10ページ]。
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保護を送るとき(セクション14を見てください)、マルチキャストグループでは、混ぜられたFECできてFEC不可能な受信機で、使用します。 そのような場合、FEC保護には、FEC不可能な受信機によって認識されないで、その結果無視されるペイロードタイプがあるでしょう。
7.3. FEC Header for FEC Packets
7.3. 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回復分野、回復分野、PT回復分野、SNベース分野、TS回復分野、および長さの回復がさばくM。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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回復| SNベース| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS回復| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さの回復| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、およびSHOULDにはセットがあります。それ、SHALL、受信機で、無視されます。
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回復分野、対応するP、X、CC、Mに適用されて、太平洋標準時の操作がFECパケットに関連しているメディア向けの資料セットのRTPヘッダーから評価する保護で回復がさばくMと、回復がさばく太平洋標準時を得ます。
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、または48のパケットに設定されるときL分野が1などに設定されるとき高々16のパケットのどんなストリングの上にも広げるFEC操作を考慮します。
Li Standards Track [Page 11] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[11ページ]。
The TS recovery field is computed via the protection operation applied to the timestamps of the media packets associated with this FEC packet. This allows the timestamp to be completely recovered.
TS回復分野はこのFECパケットに関連しているメディア向けの資料セットに関するタイムスタンプに適用された保護操作で計算されます。 これで、タイムスタンプは完全に回復します。
The length recovery field is used to determine the length of any recovered packets. It is computed via the protection operation applied to the unsigned network-ordered 16-bit representation of the sums of the lengths (in bytes) of the media payload, CSRC list, extension and padding of each of the media packets associated with this FEC packet (in other words, the CSRC list, RTP extension, and padding of the media payload packets, if present, are "counted" as part of the payload). This allows the FEC procedure to be applied even when the lengths of the protected media packets are not identical. For example, assume that an FEC packet is being generated by xor'ing two media packets together. The length of the payload of two media packets is 3 (0b011) and 5 (0b101) bytes, respectively. The length recovery field is then encoded as 0b011 xor 0b101 = 0b110.
長さの回復分野は、どんな回復しているパケットの長さも測定するのに使用されます。 それはこのFECパケットに関連づけられたそれぞれのメディア向けの資料セットのメディアペイロード、CSRCリスト、拡大、および詰め物の長さ(バイトによる)の合計の無記名のネットワークによって規則正しい16ビットの表現に適用された保護操作で計算されます(言い換えれば、存在しているなら、メディアペイロードパケットのCSRCリスト、RTP拡張子、および詰め物はペイロードの一部として「数えられます」)。 保護されたメディア向けの資料セットの長さが同じでないときにさえ、これは、FEC手順が適用されるのを許容します。 例えば、FECパケットがxor'ing twoメディア向けの資料セットで一緒に発生していると仮定してください。 2つのメディア向けの資料セットのペイロードの長さは(0b011)と5(0b101)バイトと、それぞれ3です。 そして、0b011 xor 0b101が0b110と等しいときに、長さの回復分野はコード化されます。
7.4. FEC Level Header for FEC Packets
7.4. FECはFECパケットのためにヘッダーを平らにします。
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パケットに関連しているかを示します。 それは、16ビットかLビットの価値に応じた48ビットです。 マスクのビットiが1に設定されるなら、一連番号N+iがあるメディア向けの資料セットはこのFECパケットに関連しています、NがFECパケットのヘッダーのSN基地の分野であるところで。 マスクの最も重要なビットはi=0に対応しています、そして、Lに噛み付いたとき、Lに噛み付いたとき、i=15に最も重要でないのが0に設定されるか、またはi=47は1に用意ができています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask cont. (present only when L = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 保護の長さ| マスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contにマスクをかけてください。 (現在L=1である場合にだけ)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULP Level Header Format
図4: ULPはヘッダー形式を平らにします。
The setting of the mask field shall follow the following rules:
マスク分野の設定は以下の規則に従うものとします:
Li Standards Track [Page 12] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[12ページ]。
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.
a。 メディア向けの資料セットSHALL、レベル0より高いそれぞれの保護レベルで一度だけ保護されてください。 メディア向けの資料セットはこれらのパケットのレベル0の保護の長さが異なったパケット、提供によるレベル0でかつて等しいというよりも保護されるかもしれません。
b. For a media packet to be protected at level p, it MUST also be
protected at level p-1 in any FEC packets. Please note that the
protection level p for a media packet can be in an FEC packet that
is different from the one that contains protection level p-1 for
the same media packet.
b。 また、メディア向けの資料セットがレベルpで保護されるために、どんなFECパケットのレベルp-1にもそれを保護しなければなりません。 メディア向けの資料セットのための保護レベルpが同じメディア向けの資料セットのための保護レベルp-1を含むものと異なったFECパケットにあることができます。
c. If a ULP FEC packet contains protection at level p, it MUST also
contain protection at level p-1. Note that the combination of
payload packets that are protected in level p may be different
from those of level p-1.
c。 また、ULP FECパケットがレベルpに保護を含んでいるなら、それはレベルp-1に保護を含まなければなりません。 レベルpに保護されるペイロードパケットの組み合わせがレベルp-1のものと異なるかもしれないことに注意してください。
The rationale for rule (a) is that multiple protection increases the complexity of the recovery implementation. At higher levels, the multiple protection offers diminishing benefit, so its application is restricted to level 0 for simpler implementation. The rationale for rule (b) is that the protection offset (for each associated packet) is not explicitly signaled in the protocol. With this restriction, the offset can be easily deducted from protection lengths of the levels. The rationale of rule (c) is that the level of protection is not explicitly indicated. This rule is set to implicitly specify the levels.
規則(a)のための原理は多重防護が回復実現の複雑さを増加させるということです。 より高いレベルでは、多重防護が減少している利益を提供するので、アプリケーションは、より簡単な実現のためにレベル0に制限されます。 規則(b)のための原理はプロトコルで明らかに保護オフセット(それぞれの関連パケットのための)に合図しないということです。 この制限で、レベルの保護の長さからオフセットを容易に差し引くことができます。 規則(c)の原理は保護のレベルが明らかに示されないということです。 この規則がそれとなくレベルを指定するように設定されます。
One example of the protection combinations is illustrated in Figure 5 below. It is the same example as shown in Figure 1. This same example is also shown in more detail in Section 10.2 to illustrate how the fields in the headers are set.
保護組み合わせに関する1つの例が以下の図5で例証されます。 それは図1に示されるように同じ例です。 また、この同じ例は例証するセクション10.2にヘッダーの分野がどのように設定されるかがさらに詳細に示されます。
Li Standards Track [Page 13] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[13ページ]。
Packet A #####################
: :
Packet B ############### :
: :
ULP FEC Packet #1 @@@@@@@@ :
: :
Packet C ########### :
: :
Packet D ###################################
: :
ULP FEC Packet #2 @@@@@@@@@@@@@@@@@
: : :
:<-L0->:<--L1-->:
パケットA#####################: : パケットB###############: : : ULP FECパケット#1@@@@@@@@: : : パケットC###########: : : パケットD###################################: : ULP FECパケット#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
有効搭載量パケット#| レベルで保護されるULP FECパケット| L0 L1---------------------+--------------------------------------- A| #1 #2 B| #1 #2 C| #2 #2 D| #2 #2
Figure 5: An Example of Protection Combination
図5: 保護組み合わせに関する例
In this example, ULP FEC packet #1 only has protection level 0. ULP FEC packet #2 has protection levels 0 and 1. Read across the table, it is shown that payload packet A is protected by ULP FEC packet #1 at level 0, by ULP FEC packet #2 at level 1, and so on. Also, it can be easily seen from the table that ULP FEC packet #2 protects at level 0 payload packets C and D, at level 1 payload packets A-D, and so on. For additional examples with more details, please refer to Section 10, "Examples".
この例では、ULP FECパケット#1は保護レベル0を持っているだけです。 ULP FECパケット#2には、保護レベル0と1があります。 テーブルの向こう側に読まれて、ペイロードパケットAがレベル0でULP FECパケット#1によって保護されるのが示されます、レベル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パケットのペイロードはメディアペイロードに適用された保護操作(XOR)です、そして、メディア向けの資料セットの詰め物はおまけにULP FECパケットにレベルを関連づけました。 詳細は保護操作のときにセクション8で説明されます。
The size of the ULP FEC packets is determined by the protection lengths chosen for the protection operation. In the above example, ULP FEC packet #1 has length L0 (plus the header overhead). ULP FEC packet #2 with two levels has length L0+L1 (plus the header overhead). It is longer than some of the packets it protects (packets B and C in this example), and is shorter than some of the packets it protects (packets A and D in this example).
保護操作に選ばれた保護の長さに従って、ULP FECパケットのサイズは決定しています。 上記の例では、ULP FECパケット#1は長さのL0(ヘッダーオーバーヘッド)を持っています。 2つのレベルがあるULP FECパケット#2には、長さのL0+L1(ヘッダーオーバーヘッド)があります。 それは、それが保護するパケット(この例のパケットBとC)のいくつかより長く、それが保護するパケット(この例のパケットAとD)のいくつかより短いです。
Li Standards Track [Page 14] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[14ページ]。
Note that it's possible for the FEC packet (non-ULP and ULP) to be larger than the longest media packets it protects because of the overhead from the headers and/or if a large protection length is chosen for ULP. This could cause difficulties if this results in the FEC packet exceeding the Maximum Transmission Unit size for the path along which it is sent.
FECパケット(非ULPとULP)がヘッダーと大きい保護の長さがULPに選ばれているかどうかからオーバーヘッドのために保護する中で最も長いメディア向けの資料セットより大きいのが、可能であることに注意してください。 それが送られる経路にMaximum Transmission Unitサイズを超えているFECパケットをもたらすなら、これは困難を引き起こす場合がありました。
8. Protection Operation
8. 保護操作
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ビット列がそうである、bitwiseする、保護されたメディア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.
以下の手順は保護操作のために従われるかもしれません。 他の手順は用いられるかもしれませんが、結末はここで説明されたものと同じであるに違いありません。
8.1. Generation of the FEC Header
8.1. FECヘッダーの世代
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ビット列のビットが回復がFECヘッダーでさばく太平洋標準時まで書かれている次の7。 次の16ビットはスキップされます。 FECビット列の次の32ビットはFECヘッダーのTS回復分野に書かれています。 次の16ビットはパケットのヘッダーの長さの回復分野に書かれています。
Li Standards Track [Page 15] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[15ページ]。
8.2. Generation of the FEC Payload
8.2. FEC有効搭載量の世代
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ビット列がそうである、bitwiseする、これらの排他的論理和はメディアRTPパケットを保護しました。 そのようなFECビット列は、各レベルのために発生する必要があります、各レベルにおいて、保護されたペイロードパケットのグループが異なっているとき。 保護されたRTPパケットの長さが等しくないなら、終わりに八重奏0を加えることによって、最も長いパケットの長さにそれぞれのより脆いパケットを水増ししなければなりません。
For protection level n (n = 0, 1, ...), only Ln octets of data are set as the FEC level n payload data after the level n ULP header. The data is the Ln octets of data starting with the (Sn + 13)th octet in the FEC bit string, where:
保護レベルn(n=0、1、…)において、FECが平らなn ULPヘッダーの後のnペイロードデータを平らにするとき、データのLn八重奏だけが設定されます。 データが(Sn+13)から始まるデータのLn八重奏である、第FECビット列における八重奏、どこ:
Sn = sum(Li : 0 <= i < n).
Snは合計(李: i0<=<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.
李はレベルiの保護の長さです、そして、S0は、0になるように定義されます。 最初の12の八重奏を省略する理由はその情報がFECヘッダーによって既に保護されるということです。
9. Recovery Procedures
9. リカバリ手順
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つの異なった操作を必要とします。 1番目は、なくなったパケットを回復するために、どのパケット(メディアとFEC)を結合しなければならないかを決定します。 これがいったん完了していると、第2ステップは実際にデータを再建することです。 以下で説明されるとして第2ステップを実行しなければなりません。 第一歩はimplementerによって選ばれたどんなアルゴリズムにも基づくかもしれません。 可能であるなら、異なったアルゴリズムは複雑さとなくなったパケットを回復する能力の間のトレードオフをもたらします。
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ヘッダーから検索されたパケットの回復の長さをチェックすることによって、パケットの部分的な回復を検出できます。
9.1. Reconstruction of the RTP Header
9.1. RTPヘッダーの再建
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でいくらかのメディア向けの資料セットξを回復するために結合できるパケット(FECとメディア)のリストであることをさせてください。 手順は以下の通りです:
Li Standards Track [Page 16] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[16ページ]。
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. 回復ビット列について計算する、bitwiseする、すべてのメディア向けの資料セットからTとFECビット列で発生する保護されたビット列の排他的論理和はTですべてから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. 回復ビット列で次のビットへの新しいパケットにPaddingビットをはめ込んでください。
7. Set the Extension bit in the new packet to the next bit in the
recovery bit string.
7. 回復ビット列で次のビットへの新しいパケットにExtensionビットをはめ込んでください。
8. Set the CC field to the next 4 bits in the recovery bit
string.
8. 回復ビット列で次の4ビットにCC分野を設定してください。
9. Set the marker bit in the new packet to the next bit in the
recovery bit string.
9. 回復ビット列で次のビットへの新しいパケットにマーカービットをはめ込んでください。
10. Set the payload type in the new packet to the next 7 bits in
the recovery bit string.
10. 回復ビット列で次の7ビットへの新しいパケットにペイロードタイプをはめ込んでください。
11. Set the SN field in the new packet to xi. Skip the next 16
bits in the recovery bit string.
11. ξへの新しいパケットにSN分野をはめ込んでください。 回復ビット列で次の16ビットをスキップしてください。
12. Set the TS field in the new packet to the next 32 bits in the
recovery bit string.
12. 回復ビット列で次の32ビットへの新しいパケットにTS分野をはめ込んでください。
13. Take the next 16 bits of the recovery bit string. Whatever
unsigned integer this represents (assuming network-order),
take that many bytes from the recovery bit string and append
them to the new packet. This represents the CSRC list,
extension, payload, and the padding of the RTP payload.
13. 回復ビット列の次の16ビット取ってください。 これが表す(ネットワークオーダーを仮定します)どんな符号のない整数にも、回復ビット列からのそんなに多くのバイト取ってください、そして、新しいパケットにそれらを追加してください。 これは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。
Li Standards Track [Page 17] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[17ページ]。
This procedure will recover the header of an RTP packet up to the SSRC field.
この手順はRTPパケットのヘッダーをSSRC分野まで回収するでしょう。
9.2. Reconstruction of the RTP Payload
9.2. RTP有効搭載量の再構成
Let T be the list of packets (FEC and media) that can be combined to recover some media packet xi at a certain protection level. The procedure is as follows:
Tが、ある保護レベルでいくらかのメディア向けの資料セットξを回復するために結合できるパケット(FECとメディア)のリストであることをさせてください。 手順は以下の通りです:
1. Assume that we are reconstructing the data for level n, the
first step is to get the protection length of level n (Ln)
from the ULP header of level n.
1. 第一歩が私たちがレベルnのためのデータを再建していて、レベルnのULPヘッダーからレベルn(Ln)の保護の長さを得ることであると仮定してください。
2. For the FEC packets in T, the FEC bit string of level n is FEC
level n payload, i.e., the Ln octets of data following the ULP
header of level n.
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)から始まるデータの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の保護されたビット列のどれかが現在のレベルの保護の長さより短いなら、その長さにそれらを水増ししてください。 ビット列の終わりで八重奏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. 回復ビット列について計算する、bitwiseする、Tのすべてのメディア向けの資料セットから発生するレベルnの保護されたビット列とレベルnのFECビット列の排他的論理和はTですべてからFECパケットを発生させました。
6. The recovery bit string of the current protection level as
generated above is combined through concatenation with the
recovery bit string of all the other levels to form the (fully
or partially) recovered media packet. Note that the recovery
bit string of each protection level MUST be placed at the
correct location in the recovered media packet for that level
based on protection length settings.
6. 上で発生する現在の保護レベルの回復ビット列は、(完全か部分的に)回復しているメディア向けの資料セットを形成するために連結で他のすべてのレベルの回復ビット列に結合されます。 保護長さの設定に基づくそのレベルのために回復しているメディア向けの資料セットにそれぞれの保護レベルの回復ビット列を正しい位置に置かなければならないことに注意してください。
7. The total length of the recovered media packet is recovered
from the recovery operation at protection level 0 of the
recovered media packet. This information can be used to check
if the complete recovery operation (of all levels) has
recovered the packet to its full length.
7. 回復しているメディア向けの資料セットの保護レベル0で回復しているメディア向けの資料セットの全長から回復動作を取り戻します。 全快操作(すべてのレベルの)が完全な長さにパケットを回復したかどうかチェックするのにこの情報を使用できます。
Li Standards Track [Page 18] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[18ページ]。
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パケットのペイロードの両方を現在のレベルの保護の長さまで回収するでしょう。
10. Examples
10. 例
In the first two examples considered below (Sections 10.1 and 10.2), we assume that the FEC streams are sent through a separate RTP session as described in Section 14.1. For these examples, we assume that four media packets are to be sent, A, B, C, and D, from SSRC 2. Their sequence numbers are 8, 9, 10, and 11, respectively, and have timestamps of 3, 5, 7, and 9, respectively. Packets A and C use payload type 11, and packets B and D use payload type 18. Packet A has 200 bytes of payload, packet B 140, packet C 100, and packet D 340. Packets A and C have their marker bit set.
(セクション10.1と10.2)の下で考えられた最初の2つの例では、私たちは、FEC小川がセクション14.1で説明されるように別々のRTPセッションで送られると思います。 これらの例に関しては、私たちは、それがパケットが送られることになっている4つのメディアと、Aと、Bと、Cと、Dであると思います、SSRC2から。 それらの一連番号は、それぞれ8と、9と、10と、11であり、それぞれ3、5、7、および9に関するタイムスタンプを持っています。 パケットAとCはペイロードタイプ11を使用します、そして、パケットBとDはペイロードタイプ18を使用します。 パケットAには、ペイロード、パケットB140、パケットC100、およびパケットD340の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データがいつペイロードパケットと共に冗長データとして送られるかを例証することです。
10.1. An Example Offers Similar Protection as RFC 2733
10.1. 例はRFC2733として同様の保護を提供します。
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つのペイロードパケットを保護できます。 これはRFC2733として同様の保護を提供します。 計画が図6に示されるようにあります。
+-------------------+ :
Packet A | | :
+-------------+-----+ :
Packet B | | :
+---------+---+ :
Packet C | | :
+---------+-----------------------+
Packet D | |
+---------------------------------+
:
+---------------------------------+
Packet FEC | |
+---------------------------------+
: :
:<------------- L0 -------------->:
+-------------------+ : パケットA| | : +-------------+-----+ : パケットB| | : +---------+---+ : パケットC| | : +---------+-----------------------+ パケットD| | +---------------------------------+ : +---------------------------------+ パケットFEC| | +---------------------------------+ : : :<。------------- L0-------------->:
Figure 6: FEC Scheme with Single-Level Protection
図6: FECはただ一つのレベル保護で計画します。
Li Standards Track [Page 19] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[19ページ]。
An FEC packet is generated from these four packets. We assume that payload type 127 is used to indicate an FEC packet. The resulting RTP header is shown in Figure 7.
FECパケットはこれらの4つのパケットから発生します。 私たちは、ペイロードタイプ127がFECパケットを示すのに使用されると思います。 結果として起こるRTPヘッダーは図7で見せられます。
The FEC header in the FEC packet is shown in Figure 8.
FECパケットのFECヘッダーは図8で見せられます。
The FEC level header for level 0 is shown in Figure 9.
レベル0のためのFECの平らなヘッダーは図9で見せられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|0|0|0 0 0 0|0|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 127SN: 1t: 9SSRC: 2
Figure 7: RTP Header of FEC Packet
図7: FECパケットのRTPヘッダー
Li Standards Track [Page 20] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[20ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0 0 0 0|0|0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1 0 1 1 1 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 0 [11 XOR 18 XOR 11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 8 [3 XOR 5 XOR 7 XOR 9]
len. rec.: 372 [200 XOR 140 XOR 100 XOR 340]
E: 0[この仕様]L: 0[短い16ビットのマスク]P rec、: 0[0XOR0XOR0XOR0]X rec、: 0 [0XOR0XOR0XOR0]がrecをCCする、: 0[0XOR0XOR0XOR0]Mのrec、: 0 太平洋標準時の[1XOR0のXOR1XOR0]がrecする、: 0 [11XOR18XOR11XOR18] SNは以下を基礎づけます。 8[分(8、9、10、11)]TS rec、: 8[3XOR5XOR7XOR9]len. rec、: 372 [200XOR140XOR100XOR340]
Figure 8: FEC Header of FEC Packet
エイト環: 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [Bits1、2、3、および4がPackets8、9、10、および11のためにそれに従って、マークされている]
The payload length for level 0 is 340 bytes.
レベル0のためのペイロード長は340バイトです。
Figure 9: FEC Level Header (Level 0)
図9: FECはヘッダーを平らにします。(レベル0)
10.2. An Example with Two Protection Levels
10.2. 2つの保護レベルがある例
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を使用することです。 平らな0FECはペイロードパケットの始めの一部により大きい保護を提供するでしょう。 平らな1FECが追加保護をパケットの残りに適用するでしょう。 これは図10で例証されます。 この例では、L0は70とL1=90と等しいです。
Li Standards Track [Page 21] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[21ページ]。
+------:--------:---+
Packet A | : : |
+------:------+-:---+
Packet B | : | :
+------:--+---+ :
: :
+------+ :
ULP #1 | | :
+------+ :
: :
+------:--+ :
Packet C | : | :
+------:--+-----:-----------------+
Packet D | : : |
+------:--------:-----------------+
: :
+------:--------+
ULP #2 | : |
+------:--------+
: : :
:<-L0->:<--L1-->:
+------:--------:---+ パケットA| : : | +------:------+-:---+ パケットB| : | : +------:--+---+ : : : +------+ : ULP#1| | : +------+ : : : +------:--+ : パケットC| : | : +------:--+-----:-----------------+ パケットD| : : | +------:--------:-----------------+ : : +------:--------+ ULP#2| : | +------:--------+ : : : :<L0>: <--L1-->:
Figure 10: ULP FEC Scheme with Protection Level 0 and Level 1
図10: ULP FECは保護レベル0とレベル1で計画します。
This will result in two FEC packets - #1 and #2.
これは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には、RTPヘッダーが図11に示されるようにあるでしょう。 ULP FECパケット#1のためのFECヘッダーが図12に示されるようにあるでしょう。 #1のための平らな0ULPヘッダーが図13に示されるようにあるでしょう。
Li Standards Track [Page 22] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[22ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 127SN: 1t: 5SSRC: 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9)]
TS rec.: 6 [3 XOR 5]
len. rec.: 68 [200 XOR 140]
E: 0[この仕様]L: 0[短い16ビットのマスク]P rec、: 0[0XOR0XOR0XOR0]X rec、: 0 [0XOR0XOR0XOR0]がrecをCCする、: 0[0XOR0XOR0XOR0]Mのrec、: 0 太平洋標準時の[1XOR0のXOR1XOR0]がrecする、: 25 [11XOR18] SNは以下を基礎づけます。 8[分(8、9)]TS rec、: 6[3XOR5]len. rec、: 68 [200XOR140]
Figure 12: FEC Header of ULP FEC Packet #1
図12: ULP FECパケット#1のFECヘッダー
Li Standards Track [Page 23] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[23ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [Bits1と2がPackets8と9のためにそれに従って、マークされている]
The payload length for level 0 is 70 bytes.
レベル0のためのペイロード長は70バイトです。
Figure 13: FEC Level Header (Level 0) for FEC Packet #1
図13: FECはFECパケット#1のために、ヘッダー(レベル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には、RTPヘッダーが図14に示されるようにあるでしょう。 FECパケット#2のためのFECヘッダーが図15に示されるようにあるでしょう。 #2のための平らな0ULPヘッダーが図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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: 127SN: 2t: 9SSRC: 2
Figure 14: RTP Header of FEC Packet #2
図14: FECパケット#2のRTPヘッダー
Li Standards Track [Page 24] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[24ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0 0 0 0|0|0 0 1 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: 0 [this specification]
L: 0 [short 16-bit mask]
P rec.: 0 [0 XOR 0 XOR 0 XOR 0]
X rec.: 0 [0 XOR 0 XOR 0 XOR 0]
CC rec.: 0 [0 XOR 0 XOR 0 XOR 0]
M rec.: 0 [1 XOR 0 XOR 1 XOR 0]
PT rec.: 25 [11 XOR 18]
SN base: 8 [min(8,9,10,11)]
TS rec.: 14 [7 XOR 9]
len. rec.: 304 [100 XOR 340]
E: 0[この仕様]L: 0[短い16ビットのマスク]P rec、: 0[0XOR0XOR0XOR0]X rec、: 0 [0XOR0XOR0XOR0]がrecをCCする、: 0[0XOR0XOR0XOR0]Mのrec、: 0 太平洋標準時の[1XOR0のXOR1XOR0]がrecする、: 25 [11XOR18] SNは以下を基礎づけます。 8[分(8、9、10、11)]TS rec、: 14[7XOR9]len. rec、: 304 [100XOR340]
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [Bits3と4がPackets10と11のためにそれに従って、マークされている]
The payload length for level 0 is 70 bytes.
レベル0のためのペイロード長は70バイトです。
Figure 16: FEC Level Header (Level 0) for FEC Packet #2
図16: FECはFECパケット#2のために、ヘッダー(レベル0)を平らにします。
Li Standards Track [Page 25] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[25ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [Bits1、2、3、および4がPackets8、9、10、および11のためにそれに従って、マークされている]
The payload length for level 1 is 90 bytes.
レベル1のためのペイロード長は90バイトです。
Figure 17: FEC Level Header (Level 1) for FEC Packet #2
図17: FECはFECパケット#2のために、ヘッダー(レベル1)を平らにします。
10.3. An Example with FEC as Redundant Coding
10.3. 余分なコード化としてのFECがある例
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を例証します。 私たちは、それがSSRC2からパケットが送られることになっている5つのメディア、A、B、C、D、およびE離れたところにいると思います。 それらの一連番号は、それぞれ8と、9と、10と、11と、12であり、それぞれ3、5、7、9、および11に関するタイムスタンプを持っています。 すべてのメディアデータが、プライマリコード化(余分なコード化としてのFECはプライマリコード化を保護するだけである)でコード化されて、ペイロードタイプ11を使用します。 パケットAには、200バイトのペイロード、パケットB140、パケットC100、パケットD340、およびパケットが160Eあります。 パケット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体系が1つのレベルと共にセクション10.1の図6によって例証されるようにあるでしょう。 保護の長さの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.
余分なコード化packetizationはペイロードタイプ100で使用されます。 FECのペイロードタイプは127であると思われます。 最初の4つのREDパケット、RED#4を通したRED#1、それぞれがそれぞれ個々のメディア向けの資料セット、A、B、C、またはDを含んでいます。 最初の4つのメディア向けの資料セットにメディアデータを保護するFECデータは発生しています。 5番目のパケット(RED#5)は余分であるとしてのメディア向けの資料セットと共にEをコード化するこのFECデータを含んでいます。
RED Packet #1: Media Packet A RED Packet #2: Media Packet B RED Packet #3: Media Packet C RED Packet #4: Media Packet D RED Packet #5: FEC Packet, Media Packet E
赤パケット#1: メディア向けの資料セットA赤パケット#2: メディア向けの資料セットB赤パケット#3: メディア向けの資料セットC赤パケット#4: メディア向けの資料セットD赤パケット#5: FECパケット、メディア向けの資料セットE
RED packets #1 through #4 will have the structure as shown in Figure 18. The RTP header of the RED packet #1 is as shown in Figure 19, with all the other RED packets in similar format with corresponding sequence numbers and timestamps. The primary encoding block header of the RED packets is as shown in Figure 20.
#4を通したREDパケット#1には、構造が図18に示されるようにあるでしょう。 同様の形式にはREDパケット#1のRTPヘッダーが対応する一連番号とタイムスタンプで図19に示される他のすべてのREDパケットをもってあります。 REDパケットのブロックヘッダーをコード化する予備選挙が図20に示されるようにあります。
Li Standards Track [Page 26] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[26ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header (RED) - 6 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Encoding Block Header (RED) - 1 octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Packet Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header(RED)--6つの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プライマリEncoding Block Header(RED)--1つの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メディア向けの資料セットデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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でマーカーを用意ができさせますが] 太平洋標準時: 100[REDのための有効搭載量タイプ]SN: 1t: 5SSRC: 2
Figure 19: RTP Header of RED Packet #1
図19: 赤パケット#1のRTPヘッダー
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0 0 0 1 0 1 1|
+-+-+-+-+-+-+-+-+
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 [これはプライマリコード化データです] 太平洋標準時のブロック: 11 [メディアのペイロードタイプ]
Figure 20: Primary Encoding Block Header
図20: ブロックヘッダーをコード化する予備選挙
The FEC data is generated not directly from the RED packets, but from the virtual RTP packets containing the media packet data. Those virtual RTP packets can be very easily generated from the RED packets both with and without redundant coding included. The conversion from RED packets to virtual RTP packets is simply done by (1) removing any RED block headers and redundant coding data, and (2) replacing the PT in the RTP header with the PT of the primary coding.
FECデータは直接REDパケットから生成されるのではなく、メディア向けの資料セットデータを含む仮想のRTPパケットから生成されます。 ともに余分なコード化を含んでいることのあるなしにかかわらずREDパケットからそれらの仮想のRTPパケットを非常に容易に生成することができます。 (1)は、RTPヘッダーの太平洋標準時をプライマリコード化の太平洋標準時に取り替えながらどんなREDブロックヘッダーと余分なコード化データ、および(2)も取り除きながら、REDパケットから仮想のRTPパケットまで単に変換します。
Li Standards Track [Page 27] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[27ページ]。
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.
以下に注意してください。 RFC2198による指定されるとしての余分なコード化のためにペイロード形式では、プライマリコード化がREDパケットで運ばれるとすぐに、マーカービットは無くなっています。 それで、FECが使用されているかどうかにかかわらずマーカービットを回収できません。
As mentioned above, RED packet #5 will contain the FEC data (that protects media packets A, B, C, and D) as well as the data of media packet E. The structure of RED packet #5 is as illustrated in Figure 21.
以上のように、REDパケット#5はメディア向けの資料セットE.に関するデータと同様にFECデータを含むでしょう(それはメディア向けの資料セットA、B、C、およびDを保護します)。REDパケット#5の構造は図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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header(RED)--6つの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 余分なEncoding Block Header(RED)--4つの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FECパケットデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プライマリEncoding Block Header(RED)--1つの八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メディア向けの資料セットデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
REDパケット#5に、FECパケットデータ・ブロックにブロックヘッダーをコード化する余分が図22に以下に示されるようにあります。 FECパケットデータはそれのあとに続くでしょう。(この場合、データはFECヘッダー(図8に示される10の八重奏)、ULPレベル0ヘッダー(図9に示される4つの八重奏)、およびULPレベル0データ(レベル0に設定される340の八重奏)を含んでいます)。 メディア向けの資料セットEに関するデータを含むブロックをコード化する予備選挙はこれらのあとに続いています。
Li Standards Track [Page 28] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[28ページ]。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 1 0 1 1 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit: 1 [This is the redundant coding data]
Block PT: 127 [The dynamic payload type for FEC]
TS Offset: 0 [The instance at which the FEC data is
transmitted]
Block Len: 354 [FEC header (10 octets) plus ULP level 0 header
(4 octets) and ULP level 0 data (340 octets)]
Fに噛み付きました: 1 [これは余分なコード化データです] 太平洋標準時のブロック: 127[FECのためのダイナミックなペイロードタイプ]TS Offset: 0 [FECデータが送られるインスタンス] レンを妨げてください: 354 [FECヘッダー(10の八重奏)とULPレベル0ヘッダー(4つの八重奏)とULPレベル0データ(340の八重奏)]
Figure 22: Redundant Encoding Block Header
図22: 余分なコード化しているブロックヘッダー
11. Security Considerations
11. セキュリティ問題
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を適用することであり、暗号化の前にFECを適用することです。 メディアデータが暗号化されていた後にFECがトランスミッションの間信じられなかったノードによって必要とされるとき、最初のケースは遭遇します。 それが機密保護している輸送で伝えられる前にメディアデータがFECによって保護されるとき、2番目のケースは遭遇します。
Since the protected payload of this FEC is RTP packets, applying FEC on encrypted payloads is primarily applicable in the case of secure RTP (SRTP) [13]. Because the FEC applies XOR across the payload, the FEC packets should be cryptographically as secure as the original payload. In such cases, additional encryption of the FEC packets is not necessary.
このFECの保護されたペイロードがRTPパケットであるので、暗号化されたペイロードにFECを適用するのは安全な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ストリームは、ともに暗号化されますが、異なったキーを使用しています。
Li Standards Track [Page 29] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[29ページ]。
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の使用法を意識していて、その結果、キーを交換して、暗号化用法を交渉するのに使用されるプロトコルに合図しながら、すべてのアプリケーションレベルを必要とするでしょう。 最終的な場合では、そのようなどんな追加メカニズムも必要ではありません。 最初の2つのケースがレイヤリング違反を提示します、ULP FECパケットが他のRTPパケットと異なった扱われたノーであるべきであるので。 また、ちょうど1つのストリームを暗号化するのに、ある知られている平文攻撃は可能になるかもしれません。 これらの理由で、暗号化SHOULDを利用するアプリケーションがすなわち、ストリーム、最後のオプションの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.
暗号化キーの変化は扱われる必要がある別の極めて重要な課題です。 2つのパケットaとbがそれらを保護するFECパケットと共に送られるケースを考えてください。 aとbを暗号化するのに使用されるキーは異なっています、それのキーがFECパケットを解読するのにおいて使用されているべきであるそう? 一般に、古いキーは、キャッシュされる必要があります、キーがメディアストリームのために変化するとき、キーがまた、ULP FECパケットのために変化したのが、決定するまで古いキーを使用できるように。 その上、新しさはSHOULDを合わせます。使用されて、古くて新しいキーによって暗号化されたペイロードパケットの組み合わせから生成される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データに健全度チェックを実行して、それらを使用する前に回復動作から回復しているデータの正当性を決定するのは役立っているかもしれません。
12. Congestion Considerations
12. 混雑問題
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
FECの使用の別の問題はネットワークの混雑でのその影響です。 多くの状況で、ネットワークのパケット損失は渋滞によって引き起こされています。 そのようなシナリオでは、増加するネットワークの損失に遭遇するときFECを加えるのは避けられるべきです。 それがそうなら
Li Standards Track [Page 30] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[30ページ]。
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を含んでいる)の総量を大幅には増強してはいけません。
The general congestion control considerations for transporting RTP data apply; see RTP [1] and any applicable RTP profile (e.g., RTP/AVP [14]). An additional requirement if best-effort service is being used is that users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
RTPデータを輸送するための一般的な輻輳制御問題は適用されます。 RTP[1]とあらゆる適切なRTPプロフィールを見てください。(例えば、RTP/AVP[14])。 ベストエフォート型サービスが利用されているなら、追加要件はこのペイロード形式のユーザが許容できるパラメタの中にパケット損失率があるのを保証するためにパケット損失をモニターしなければならないということです。 同じネットワーク経路、および同じネットワークが条件とさせる経験の向こう側のTCP流動が妥当なスケールで測定された少なくとも流れが実現しているRTPである平均したスループットを実現するなら、パケット損失は許容できると考えられます。 通信速度(層の数は層にされたマルチキャストセッションのために申し込まれた)を適合させるために混雑制御機構を実装するか、または損失率が容認できないほど高いなら受信機がセッションを出発するように手配することによって、この状態を満たすことができます。
13. IANA Considerations
13. IANA問題
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]を使用して、RFC3555[4]に続き終わっています。
13.1. Registration of audio/ulpfec
13.1. オーディオ/ulpfecの登録
Type name: audio
型名: オーディオ
Subtype name: ulpfec
Subtypeは以下を命名します。 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タイムスタンプレート。 冗長データとしてそれがどれであるかで別のストリーム、レートSHALLに送られた場合では、それをコード化する予備選挙が保護するのに使用されるのと同じにしてください。 いつが別々のストリーム、レートにSHALLを使用したか。十分な解決をRTCP操作に提供するために1000Hzより大きくいてください。 選択されたレートは、1000Hzの上のどんな値であるかもしれませんが、このストリームが保護するメディアのレートを合わせるRECOMMENDEDです。
Li Standards Track [Page 31] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月にジェネリックFECのためにRFC5109RTP有効搭載量形式を追跡します[31ページ]。
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: これは、1つのレベルのFEC保護だけが使用されているかどうか指定します。 許容値は、0と1です。 1は合図されて、1つのレベルの唯一のFEC保護はSHALLです。ストリームでは、使用されます。 0が合図されていて、1つ以上のレベルの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.
セキュリティ問題: 問題がこれらのメディアに適用する同じセキュリティはそれらのためにペイロードに関して登録証明書をタイプします、RFC5109で詳しく述べられるように。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5109
広められた仕様: RFC5109
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
詳細のために連絡する人とEメールアドレス: アダム李 adamli@hyervision.com IETFオーディオ/Video輸送作業部会
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]を通して定義されるだけです。 他の縁どりの中でプロトコルSHALL NOTを輸送してください。これと定義されているのが、RTPのための丈夫さメカニズムであるということになってください。
Author:
Adam Li adamli@hyervision.com
以下を書いてください。 アダム李 adamli@hyervision.com
Change controller:
IETF Audio/Video Transport Working Group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
13.2. Registration of video/ulpfec
13.2. ビデオ/ulpfecの登録
Type name: video
型名: ビデオ
Subtype name: ulpfec
Subtypeは以下を命名します。 ulpfec
Li Standards Track [Page 32] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[32ページ]。
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タイムスタンプレート。 冗長データとしてそれがどれであるかで別の流れ、レートSHALLに送られた場合では、それをコード化する予備選挙が保護するのに使用されるのと同じにしてください。 いつがRTCPへの提供する1000Hzより大きい十分な解決が操作であったなら別々の流れ、レートにSHALLを使用しましたか? 選択されたレートは、1000Hzの上のどんな値であるかもしれませんが、この流れが保護するメディアのレートを合わせるRECOMMENDEDです。
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: これは、1つのレベルのFEC保護だけが使用されているかどうか指定します。 許容値は、0と1です。 1は合図されて、1つのレベルの唯一のFEC保護はSHALLです。流れでは、使用されます。 0が合図されていて、1つ以上のレベルのFEC保護が使用されるかもしれないということであるなら。 省略されるなら、それには、0のデフォルト値があります。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
問題をコード化します: この形式は縁どられます。(テンプレートドキュメント[3])のセクション4.8を見て、2進のデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティ問題: 問題がこれらのメディアに適用する同じセキュリティはそれらのためにペイロードに関して登録証明書をタイプします、RFC5109で詳しく述べられるように。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5109
広められた仕様: RFC5109
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
詳細のために連絡する人とEメールアドレス: アダム李 adamli@hyervision.com IETFオーディオ/Video輸送作業部会
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]を通して定義されるだけです。 他の縁どりの中でプロトコルSHALL NOTを輸送してください。これと定義されているのが、RTPのための丈夫さメカニズムであるということになってください。
Li Standards Track [Page 33] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[33ページ]。
Author:
Adam Li adamli@hyervision.com
以下を書いてください。 アダム李 adamli@hyervision.com
Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
13.3. Registration of text/ulpfec
13.3. テキスト/ulpfecの登録
Type name: text
型名: テキスト
Subtype name: ulpfec
Subtypeは以下を命名します。 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タイムスタンプレート。 冗長データとしてそれがどれであるかで別の流れ、レートSHALLに送られた場合では、それをコード化する予備選挙が保護するのに使用されるのと同じにしてください。 いつがRTCPへの提供する1000Hzより大きい十分な解決が操作であったなら別々の流れ、レートにSHALLを使用しましたか? 選択されたレートは、1000Hzの上のどんな値であるかもしれませんが、この流れが保護するメディアのレートを合わせるRECOMMENDEDです。
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: これは、1つのレベルのFEC保護だけが使用されているかどうか指定します。 許容値は、0と1です。 1は合図されて、1つのレベルの唯一のFEC保護はSHALLです。流れでは、使用されます。 0が合図されていて、1つ以上のレベルのFEC保護が使用されるかもしれないということであるなら。 省略されるなら、それには、0のデフォルト値があります。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
問題をコード化します: この形式は縁どられます。(テンプレートドキュメント[3])のセクション4.8を見て、2進のデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティ問題: 問題がこれらのメディアに適用する同じセキュリティはそれらのためにペイロードに関して登録証明書をタイプします、RFC5109で詳しく述べられるように。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5109
広められた仕様: RFC5109
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
追加情報: なし
Li Standards Track [Page 34] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[34ページ]。
Person & email address to contact for further information:
Adam Li adamli@hyervision.com
IETF Audio/Video Transport Working Group
詳細のために連絡する人とEメールアドレス: アダム李 adamli@hyervision.com IETFオーディオ/Video輸送作業部会
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]を通して定義されるだけです。 他の縁どりの中でプロトコルSHALL NOTを輸送してください。これと定義されているのが、RTPのための丈夫さメカニズムであるということになってください。
Author:
Adam Li adamli@hyervision.com
以下を書いてください。 アダム李 adamli@hyervision.com
Change controller:
IETF Audio/Video Transport Working Group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
13.4. Registration of application/ulpfec
13.4. アプリケーション/ulpfecの登録
Type name: application
型名: アプリケーション
Subtype name: ulpfec
Subtypeは以下を命名します。 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タイムスタンプレート。 冗長データとしてそれがどれであるかで別の流れ、レートSHALLに送られた場合では、それをコード化する予備選挙が保護するのに使用されるのと同じにしてください。 いつがRTCPへの提供する1000Hzより大きい十分な解決が操作であったなら別々の流れ、レートにSHALLを使用しましたか? 選択されたレートは、1000Hzの上のどんな値であるかもしれませんが、この流れが保護するメディアのレートを合わせるRECOMMENDEDです。
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: これは、1つのレベルのFEC保護だけが使用されているかどうか指定します。 許容値は、0と1です。 1は合図されて、1つのレベルの唯一のFEC保護はSHALLです。流れでは、使用されます。 0が合図されていて、1つ以上のレベルのFEC保護が使用されるかもしれないということであるなら。 省略されるなら、それには、0のデフォルト値があります。
Encoding considerations: This format is framed (see Section 4.8 in the template document [3]) and contains binary data.
問題をコード化します: この形式は縁どられます。(テンプレートドキュメント[3])のセクション4.8を見て、2進のデータを含んでいます。
Security considerations: The same security considerations apply to these media type registrations as to the payloads for them, as detailed in RFC 5109.
セキュリティ問題: 問題がこれらのメディアに適用する同じセキュリティはそれらのためにペイロードに関して登録証明書をタイプします、RFC5109で詳しく述べられるように。
Li Standards Track [Page 35] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[35ページ]。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 5109
広められた仕様: RFC5109
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
詳細のために連絡する人とEメールアドレス: アダム李 adamli@hyervision.com IETFオーディオ/Video輸送作業部会
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]を通して定義されるだけです。 他の縁どりの中でプロトコルSHALL NOTを輸送してください。これと定義されているのが、RTPのための丈夫さメカニズムであるということになってください。
Author:
Adam Li adamli@hyervision.com
以下を書いてください。 アダム李 adamli@hyervision.com
Change controller:
IETF Audio/Video Transport Working Group delegated from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
14. Multiplexing of FEC
14. FECのマルチプレクシング
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].
主として2つの方法の1つで保護されたペイロードに伴う受信機にFECパケットを送ることができます: 別々の流れ、または余分なコード化と同じ流れで。 バンドから設定オプションを示さなければなりません。 また、このセクションはRFC2327[8]で指定されたSession記述プロトコル(SDP)を使用することでどうこれを達成できるかを説明します。
14.1. FEC as a Separate Stream
14.1. 別々の流れとしてのFEC
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 FECが送られるアドレスとポート
o The payload type number for the FEC
o FECのペイロード形式数
o Which media stream the FEC is protecting
o FECはどのメディアの流れを保護していますか。
Li Standards Track [Page 36] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[36ページ]。
There is no static payload type assignment for FEC, so dynamic payload type numbers MUST be used. The SSRC of the FEC stream MUST be set to that of the protected payload stream. The association of the FEC stream with its corresponding stream is done by line grouping in SDP [5] with the FEC semantics [6] or other external means.
ダイナミックなペイロード形式数を使用しなければならなくて、FECのためのどんな静的なペイロードタイプ課題もありません。 FECの流れのSSRCは保護されたペイロードの流れのものに用意ができなければなりません。 [6] 何らかのFEC意味論が外部であることの形でSDP[5]で分類するのが意味する線は対応する流れによるFECの流れの協会をします。
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.
送付先輸送アドレス(ネットワーク・アドレスとポートナンバー)で通常、RFC3550[1]のセクション5.2で議論する原則、FECの流れのマルチプレクシング、およびその関連ペイロードの流れに続くのを提供します。(それは、それぞれのRTPセッションのために異なっています)。 ペイロードと共に1個のただ一つのRTPセッションとマルチプレックスで単にSSRCかペイロードタイプでFECを送ると、以下は排除されます。 (1) 異なったネットワーク経路かネットワーク資源配分のペイロードとFEC保護データの使用。 (2) 特に望まれているFECを理解していないホストのためのメディアの部分集合のレセプション。 (3) そして、異なったメディアに別々の過程を使用する受信機実現。 さらに、ペイロードデータ・ストリームと共にFECを多重送信すると、元のペイロードの流れのタイミングと一連番号スペースは影響されるでしょう。(通常、流れは望ましくありません)。 したがって、FECの流れとペイロードは、2の別々のRTPセッションで送られて、ペイロードタイプで1つのシングルのRTPセッションSHOULDまでそれらを多重送信しながら、SHOULDを流します。避けられます。 さらに、彼らがいつも同じSSRCを持っているので、FECとペイロードは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の流れのどんなメディアの流れ、ポートナンバー、およびペイロード形式数もまさしくそうように、それらのmを運ばれて、SDPに立ち並んでください。 ダイナミックなペイロード形式数を使用しなければならなくて、FECのためのどんな静的なペイロードタイプ課題もありません。 数との結合はrtpmap属性によって示されます。 この結合に使用される名前は"ulpfec"です。 FECの流れがあるアドレスは対応するc線で伝えられます。
The association relationship between the FEC stream and the payload stream it protects is conveyed through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6]. The FEC stream and the protected payload stream form an FEC group.
FECの流れとそれが保護するペイロードの流れとの協会関係は、SDP(RFC3388)で分類しながら、メディア線を通して[5] FEC意味論(RFC4756)[6]を使用することで伝えられます。 FECの流れと保護されたペイロードの流れはFECグループを結成します。
Li Standards Track [Page 37] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[37ページ]。
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
=グループ: FECあたりv=0 o=adam289083124 289083124IN IP4 host.example.com s=ULP FEC Seminar t=0 0c=IN IP4 224.2.17.12/127、1 2、= 分類してください: FEC=オーディオの30000RTP/AVP0 3 4m aは: 1mの中間の=アプリケーション30002RTP/AVP100a=rtpmap: 100ulpfec/8000とa=中間であることで等しいです: 2mがビデオと等しい、30004RTP/AVP31aが: 3mの中間の=アプリケーション30004RTP/AVPと等しい、101、c、=IN IP4 224.2.17.13/127a=rtpmap: 101 ulpfec/8000a=中間:、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の存在は、2つのFECグループがあるのを示します。 最初のFECが示されるとして分類する、「aがグループ: FEC1の2インチの線と等しく、流れ1から成る、(PCM[14])を使用するオーディオストリームと流れ2(FECが流す保護)、」 しかし、FECの流れは、ポートナンバーツーにより高く同じマルチキャストグループに送られて、オーディオとしてLive(TTL)に同じTimeを持っています。 第2FECは分類します、「aは、グループ: FEC3の4インチの線と等しく、流れ3(aビデオストリーム)と流れ4(FECが流す保護)から成ること」によって示されるように。 FECの流れには、異なったマルチキャストアドレスに送りますが、ペイロードビデオストリームと同じポートナンバー(30004)があります。
14.2. FEC as Redundant Encoding
14.2. 余分なコード化としてのFEC
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を通してこれに合図しなければなりません。 これをするなら、RFC2198[7]で定義された手順は、余分なコード化の使用に合図するのに用いられます。 FECペイロードタイプはいかなる他の二次コーデックとも同じファッションで示されます。FEC MUSTは主なコーデックだけを保護します、仮想のRTPパケットからのFECエンジンの来ることのペイロードが主なコーデックデータから作成されている状態で。 単に(1)は、すべての追加ヘッダー、余分なコード化データ、およびRTPヘッダーというペイロードタイプを第一のコーデックのものに置き換える(2)を取り除きながら、2198年のRFCパケットから仮想のRTPパケットを非常に容易に変換できます。
Li Standards Track [Page 38] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[38ページ]。
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.
以下に注意してください。 RFC2198による指定されるとしての余分なコード化のためにペイロード形式では、第一のコード化がREDパケットで運ばれるとすぐに、マーカービットは無くなっています。 それで、FECが使用されているかどうかにかかわらずマーカービットを回収できません。
Because the FEC data (including the ULP header) is sent in the same packets as the protected payload, the FEC data is associated with the protected payload by being bundled in the same stream.
保護されたペイロードと同じパケットで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を通してこれに合図できます。 これをするなら、RFC2198[7]で定義された手順は、余分なコード化の使用に合図するのに用いられます。 FECペイロードタイプはいかなる他の二次コーデックとも同じファッションで示されます。FECパケットのダイナミックなペイロード形式数を示すのにrtpmap属性を使用しなければなりません。 FEC MUSTは主なコーデックだけを保護します。
For example:
例えば:
m=audio 12345 RTP/AVP 121 0 5 100
a=rtpmap:121 red/8000/1
a=rtpmap:100 ulpfec/8000
a=fmtp:121 0/5/100
m=オーディオの12345RTP/AVP121 0 5 100a=rtpmap: 121赤/8000/1a=rtpmap: 100ulpfec/8000a=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は、ただ一つのオーディオストリームがあるのを示します(メディアは100をフォーマットします(rtpmap属性を通してulpfecに縛られます))。(ストリームはPCM(メディアは0をフォーマットする)、DVI(メディアは5をフォーマットする)、余分なencodings(メディアで、rtpmap属性を通して赤に縛られる書式121を示す)、またはFECから成ることができます)。 FECですが、形式はこの流れのための可能なコード化として指定されます、FEC MUST NOT。それ自体で、この流れのために、送ります。 m線における存在が、RFC2198に従ってここに非第一のコーデックを記載するだけでよいので、必要です。 fmtp属性は、余分なencodings形式を使用できるのを示します、二次コード化としてのDVIと第三としてのFECがコード化していて。
14.3. Offer / Answer Consideration
14.3. 申し出/答えの考慮
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に関しては、値は受信機が受信するために受け入れるものを示します。
Li Standards Track [Page 39] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[39ページ]。
When the FEC is sent as a separate stream and signaled through media line grouping in SDP (RFC 3388) [5] using FEC semantics (RFC 4756) [6], the offering side MUST implement both RFC 3388 and RFC 4756. The rules for offer / answer in RFC 3388 and RFC 4756 SHALL be followed with the below additional consideration. For all offers with FEC, the answerer MAY refuse the separate FEC session by setting the port to 0, and remove the "a=group" attribute that groups that FEC session with the RTP session being protected. If the answerer accepts the usage of FEC, the answerer simply accepts the FEC RTP session and the grouping in the offer by including the same grouping in the answer. Note that the rejection of the FEC RTP session does not prevent the media sessions from being accepted and used without FEC.
FECがSDPで[5] FEC意味論(RFC4756)[6]を使用することで(RFC3388)を分類しながら別々の流れとして送られて、メディア線を通して合図されるとき、提供側はRFC3388とRFC4756の両方を実行しなければなりません。 申し出/のための規則にRFC3388とRFC4756SHALLで答えます。以下の追加的約因で、従われています。 FECとのすべての申し出のために、answererは0にポートを設定することによって別々のFECセッションを拒否して、RTPセッションが保護されている状態で、「=は分類する」というそのFECセッションのときに分類される属性を取り除くかもしれません。 answererがFECの使用法を受け入れるなら、answererは、答えで分類しながら同じくらい含んでいることによって、単にFEC RTPセッションと申し出における組分けを受け入れます。 FEC RTPセッションの拒絶が、メディアセッションがFECなしで受け入れられて、使用されるのを防がないことに注意してください。
When the FEC stream is sent as a secondary codec in the redundant encoding format (RFC 2198) [7], the offering side can indicate the FEC stream as specified in Section 14.2. The answerer MAY reject the FEC stream by removing the payload type for the FEC stream. To accept the usage of FEC, the answerer must in the answer include the FEC payload type. Note that in cases in which the redundancy payload format [7] is used with FEC as the only secondary codec, when the FEC stream is rejected the redundant encoding payload type SHOULD also be removed.
二次コーデックとして余分なコード化形式(RFC2198)[7]でFEC小川を送るとき、提供側はセクション14.2で指定されているとしてFECの流れを示すことができます。 answererは、FECの流れのためのペイロードタイプを外すことによって、FECの流れを拒絶するかもしれません。 FECの使用法を受け入れるために、answererは答えにFECペイロードタイプを含まなければなりません。 FECの流れが拒絶されるとき、冗長ペイロード形式[7]がFECと共に唯一の二次コーデックとして使用される場合では、余分なコード化ペイロードがSHOULDをタイプすることに注意してください、そして、また、取り除いてください。
15. Application Statement
15. アプリケーション声明
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アルゴリズムを支持するForward Error Correctionのために一般的なプロトコルについて説明します、簡単ではさみ込まれたパリティコードなどのように。 計画はパリティコードを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
また、本書では指定された一般的なFECアルゴリズムは以下の特徴がある一般的な保護アルゴリズムです: (1) それはそのメディアがオーディオである、ビデオ、またはそうでないことにかかわらず保護されるメディアの本質から独立しています。 (2) それはさまざまなFECメカニズムと設定をサポートするほどフレキシブルです。 (3) それはそうです。
Li Standards Track [Page 40] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[40ページ]。
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パラメタを変更できて、設計されています。 (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はUnequal Error Protection能力をユーザに提供します。 また、ある他のアルゴリズムは他の手段でUnequal Error Protection能力を提供するかもしれません。 例えば、Unequal Erasure Protection(UXP)計画は「進歩的なマルチメディアの流れの消去立ち直りの早いトランスミッションのためのRTP有効搭載量形式」でAVT作業部会で提案されました。 UXP計画は、リード-ソロモンの操作を使用することで追加冗長情報を得ていて保護されるためにペイロードの流れをはさみ込むことによって、不平等な誤り保護をメディアペイロードに適用します。
By altering the structure of the protected media payload, the UXP scheme sacrifices the backward compatibility with terminals that do not support UXP. This makes it more difficult to apply UXP when backward compatibility is desired. In the case of ULP, however, the media payload remains unaltered and can always be used by the terminals. The extra protection can simply be ignored if the receiving terminals do not support ULP.
保護されたメディアペイロードの構造を変更することによって、UXP計画はUXPを支持しない端末との後方の互換性を犠牲にします。 これで、後方の互換性が望まれているときUXPを適用するのは、より難しくなります。 ULPの場合では、しかしながら、メディアペイロードは、非変更されたままで残っていて、端末でいつも使用できます。 受信端末がULPを支持しないなら、単に特別な防護措置を無視できます。
At the same time, also because the structure of the media payload is altered in UXP, UXP offers the unique ability to change packet size independent of the original media payload structure and protection applied, and is only subject to the protocol overhead constraint. This property is useful in scenarios when altering the packet size of the media at transport level is desired.
メディアペイロードの構造がUXPでまた、変更されるので同時に、UXPが元のメディアペイロード構造の如何にかかわらずパケットサイズを変える特異な才能を提供して、保護は、適用して、単にプロトコルオーバーヘッド規制を受けることがあります。 輸送レベルにおけるメディアのパケットサイズを変更するのが必要であるときに、この特性はシナリオで役に立ちます。
Because of the interleaving used in UXP, delays will be introduced at both the encoding and decoding sides. For UXP, all data within a transmission block need to arrive before encoding can begin, and a reasonable number of packets must be received before a transmission block can be decoded. The ULP scheme introduces little delay at the encoding side. On the decoding side, correctly received packets can be delivered immediately. Delay is only introduced in ULP when packet losses occur.
UXPで使用されるインターリービングのために、両方のコード化していて解読している側で遅れを導入するでしょう。 UXPのために、コード化が始まることができて、トランスミッションブロックを解読できる前に相当な数のパケットを受け取らなければならない前にトランスミッションブロックの中のすべてのデータが、到着する必要があります。 ULP計画はコード化側でほとんど遅れを導入しません。 解読側では、すぐに、正しく容認されたパケットを果たすことができます。 パケット損失が起こるときだけ、ULPで遅れを導入します。
Because UXP is an interleaved scheme, the unrecoverable errors occurring in data protected by UXP usually result in a number of corrupted holes in the payload stream. In ULP, on the other hand, the unrecoverable errors due to packet loss in the bitstream usually appear as contiguous missing pieces at the end of the packets. Depending on the encoding of the media payload stream, many applications may find it easier to parse and extract data from a
UXPがはさみ込まれた計画であるので、通常、UXPによって保護されたデータに起こる回復不能エラーはペイロードの流れで多くの崩壊した穴をもたらします。 他方では、ULPでは、通常、bitstreamのパケット損失による回復不能エラーは隣接のなくなった断片としてパケットの端に現れます。 メディアペイロードの流れのコード化であることによって、多くのアプリケーションが、aからデータを分析して、抜粋するのが、より簡単であることがわかるかもしれません。
Li Standards Track [Page 41] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[41ページ]。
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.
特に穴が複数の崩壊した穴があるパケットコインシデンスでないことの終わりに独自に解読可能な断片限界でなくなった隣接の断片だけがあるパケット。
The exclusive-or (XOR) parity check operation used by ULP is simpler and faster than the more complex operations required by Reed-Solomon codes. This makes ULP more suitable for applications where computational cost is a constraint.
ULPによって使用された排他的論理和(XOR)パリティチェック操作は、より複雑な操作がリードソロモン符号が必要であるというよりもさらに簡単であって、速いです。 これで、ULPはコンピュータの費用が規制であるアプリケーションにより適するようになります。
As discussed above, both the ULP and the UXP schemes apply unequal error protection to the RTP media stream, but each uses a different technique. Both schemes have their own unique characteristics, and each can be applied to scenarios with different requirements.
上で議論するように、ULPとUXP計画の両方が不平等な誤り保護をRTPメディアの流れに適用しますが、それぞれが異なったテクニックを使用します。 両方の計画には、それら自身のユニークな特性があります、そして、異なった要件でそれぞれはシナリオに適用できます。
16. Acknowledgments
16. 承認
The following authors have made significant contributions to this document: Adam H. Li, Fang Liu, John D. Villasenor, Dong-Seek Park, Jeong-Hoon Park, Yung-Lyul Lee, Jonathan D. Rosenberg, and Henning Schulzrinne. The authors would also like to acknowledge the suggestions from many people, particularly Stephen Casner, Jay Fahlen, Cullen Jennings, Colin Perkins, Tao Tian, Matthieu Tisserand, Jeffery Tseng, Mark Watson, Stephen Wenger, and Magnus Westerlund.
以下の作者はこのドキュメントへの重要な貢献をしました: アダム・H.李、Fangリュウ、ジョンD.Villasenorは公園、Jeong-Hoon公園、ヨン-Lyulリー、ジョナサン・D.ローゼンバーグ、およびヘニングSchulzrinneをドングで探します。 また、作者は多くの人々、特にスティーブンCasner、ジェイFahlen、Cullenジョニングス、コリン・パーキンス、タオティエン、Matthieuティスラン、ジェフェリーTseng、マーク・ワトソン、スティーブンWenger、およびマグヌスWesterlundから提案を承諾したがっています。
17. References
17. 参照
17.1. Normative References
17.1. 引用規格
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[3]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[4] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[4]Casner、S.、「メディアはRTP有効搭載量形式の登録をタイプする」RFC4855、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]キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[6] Li, A., "Forward Error Correction Grouping Semantics in Session
Description Protocol", RFC 4756, November 2006.
[6] 李、A.、「セッション記述プロトコルの意味論を分類する前進型誤信号訂正」、RFC4756、2006年11月。
Li Standards Track [Page 42] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[42ページ]。
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[7] パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ-ガルシア、A.、およびS.堀-Parisis、「余分なオーディオデータのためのRTP有効搭載量」、RFC2198(1997年9月)。
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[8] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
17.2. Informative References
17.2. 有益な参照
[9] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[9] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
[10] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[10] パーキンスとC.とO.ホドソン、「ストリーミング・メディアの修理のためのオプション」、RFC2354、1998年6月。
[11] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec
MIME types", RFC 3009, November 2000.
[11] ローゼンバーグとJ.とH.Schulzrinne、「parityfec MIMEの種類の登録」、RFC3009、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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(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.
2004年の[13]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[15] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、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
Wateridge円#152カリフォルニア92121サンディエゴ(米国)が電話をするアダムH.李10194: +1 9038年の858 622メール: adamli@hyervision.com
Li Standards Track [Page 43] RFC 5109 RTP Payload Format for Generic FEC December 2007
李Standardsは2007年12月に一般的なFECのためにRFC5109RTP有効搭載量形式を追跡します[43ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Li Standards Track [Page 44]
李標準化過程[44ページ]
一覧
スポンサーリンク
