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