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