[要約] RFC 6695は、転送エラー訂正（FEC）フレームワークの設定情報を伝達するための方法についての規格です。このRFCの目的は、FECフレームワークの設定情報を効果的に伝達するための手法を提供することです。
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6695 Cisco Systems
Category: Informational August 2012
ISSN: 2070-1721
Methods to Convey Forward Error Correction (FEC) Framework Configuration Information
Forward Error Correction（FEC）フレームワーク構成情報を伝達する方法
Abstract
概要
The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
Forward Error Correction（FEC）フレームワークドキュメント（RFC 6363）は、FECフレームワークの動作に必要なFECフレームワーク構成情報を定義しています。このドキュメントでは、セッションアナウンスメントプロトコル（SAP）、セッション開始プロトコル（SIP）、リアルタイムストリーミングプロトコル（RTSP）などのシグナリングプロトコルを使用して、送信者とレシーバー。
This document doesn't define any new signaling protocol.
このドキュメントでは、新しいシグナリングプロトコルを定義していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6695.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6695で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification Language ..........................................3
3. Terminology/Abbreviations .......................................3
4. FEC Framework Configuration Information .........................4
4.1. Encoding Format ............................................5
5. Signaling Protocol Usage ........................................6
5.1. Signaling Protocol for Multicasting ........................7
5.1.1. Sender Procedure ....................................9
5.1.2. Receiver Procedure .................................11
5.2. Signaling Protocol for Unicasting .........................12
5.2.1. SIP ................................................12
5.2.2. RTSP ...............................................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgments ................................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
The FEC Framework document [RFC6363] defines the FEC Framework Configuration Information that governs the overall FEC Framework operation common to any FEC scheme. This information must be available at both the sender and receiver(s).
FECフレームワークドキュメント[RFC6363]は、すべてのFECスキームに共通のFECフレームワーク全体の運用を管理するFECフレームワーク構成情報を定義しています。この情報は、送信者と受信者の両方で利用できる必要があります。
This document describes how various signaling protocols such as the Session Announcement Protocol (SAP) [RFC2974], the Session Initiation Protocol (SIP) [RFC3261], the Real Time Streaming Protocol (RTSP) [RFC2326], etc. could be used by the FEC scheme (and/or the Content Delivery Protocol (CDP)) to communicate the configuration information between the sender and receiver(s). The configuration information may be encoded in any compatible format, such as the Session Description Protocol (SDP) [RFC4566], XML, etc., though this document refers to SDP encoding usage quite extensively.
このドキュメントでは、Session Announcement Protocol（SAP）[RFC2974]、Session Initiation Protocol（SIP）[RFC3261]、Real Time Streaming Protocol（RTSP）[RFC2326]などのさまざまなシグナリングプロトコルを、送信者と受信者の間で構成情報を通信するためのFECスキーム（および/またはコンテンツ配信プロトコル（CDP））。構成情報は、Session Description Protocol（SDP）[RFC4566]、XMLなど、互換性のある任意の形式でエンコードできますが、このドキュメントではSDPエンコードの使用法について詳しく説明しています。
Note that this document doesn't define any new signaling protocol; rather, it just provides examples of how existing protocols should be used. Also, the list of signaling protocols for unicast is not intended to be a complete list.
このドキュメントでは新しいシグナリングプロトコルを定義していないことに注意してください。むしろ、既存のプロトコルの使用方法の例を提供するだけです。また、ユニキャストのシグナリングプロトコルのリストは、完全なリストを意図したものではありません。
This document doesn't describe any FEC-Scheme-Specific Information (FSSI) (for example, how source blocks are constructed) or any sender- or receiver-side operation for a particular FEC scheme (for example, whether the receiver makes use of one or more repair flows that are received). Such FEC scheme specifics should be covered in separate document(s). This document doesn't mandate a particular encoding format for the configuration information either.
このドキュメントでは、FECスキーマ固有情報（FSSI）（たとえば、ソースブロックの構築方法）や、特定のFECスキームの送信側または受信側の操作（たとえば、受信側が受信された1つ以上の修復フロー）。このようなFECスキームの詳細は、別のドキュメントでカバーする必要があります。このドキュメントでは、構成情報の特定のエンコード形式も規定していません。
This document is structured as follows: Section 3 describes the terms used in this document, Section 4 describes the FEC Framework Configuration Information, Section 5 describes how to use signaling protocols for multicast and unicast applications, and Section 6 discusses security considerations.
このドキュメントの構成は次のとおりです。セクション3ではこのドキュメントで使用されている用語について説明し、セクション4ではFECフレームワーク構成情報について説明し、セクション5ではマルチキャストおよびユニキャストアプリケーションでシグナリングプロトコルを使用する方法について説明し、セクション6ではセキュリティに関する考慮事項について説明します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document makes use of the terms/abbreviations defined in the FEC Framework document [RFC6363] and defines the following additional terms:
このドキュメントは、FECフレームワークドキュメント[RFC6363]で定義されている用語/略語を利用し、次の追加の用語を定義しています。
o Media Sender - Node providing original media flow(s) to the 'FEC Sender'
o Media Sender-「FEC Sender」に元のメディアフローを提供するノード
o Media Receiver - Node performing the media decoding
o メディアレシーバー-メディアのデコードを実行するノード
o FEC Sender - Node performing the FEC encoding on the original media flow(s) to produce the FEC repair flow(s)
o FEC Sender-FEC修復フローを生成するために元のメディアフローでFECエンコードを実行するノード
o FEC Receiver - Node performing the FEC decoding, as needed, and providing the original media flow(s) to the Media Receiver
o FECレシーバー-必要に応じてFECデコードを実行し、元のメディアフローをメディアレシーバーに提供するノード
o Sender - Same as FEC Sender o Receiver - Same as FEC Receiver
o送信者-FEC送信者と同じo受信者-FEC受信者と同じ
o (Media) Flow - A single media instance, i.e., an audio stream or a video stream
o （メディア）フロー-単一のメディアインスタンス、つまりオーディオストリームまたはビデオストリーム
This document deliberately refers to the 'FEC Sender' and 'FEC Receiver' as the 'Sender' and 'Receiver', respectively.
このドキュメントでは、意図的に「FEC送信者」と「FEC受信者」をそれぞれ「送信者」と「受信者」と呼びます。
The FEC Framework [RFC6363] defines a minimum set of information that is communicated between the sender and receiver(s) for a proper operation of an FEC scheme. This information is referred to as "FEC Framework Configuration Information". This is the information that the FEC Framework needs in order to apply FEC protection to the transport flows.
FECフレームワーク[RFC6363]は、FECスキームが適切に動作するために送信者と受信者の間で通信される最小限の情報セットを定義します。この情報は「FECフレームワーク構成情報」と呼ばれます。これは、FEC保護をトランスポートフローに適用するためにFECフレームワークが必要とする情報です。
A single instance of the FEC Framework provides FEC protection for all packets of a specified set of source packet flows, by means of one or more packet flows consisting of repair packets. As per Section 5.5 of the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes the following for each FEC Framework instance:
FECフレームワークの単一のインスタンスは、修復パケットで構成される1つ以上のパケットフローによって、指定されたソースパケットフローのセットのすべてのパケットにFEC保護を提供します。 FECフレームワークドキュメント[RFC6363]のセクション5.5に従って、FECフレームワーク構成情報には、各FECフレームワークインスタンスについて次の情報が含まれています。
1. Identification of the repair flow(s)
1. 修理フローの識別
2. Identification of source flow(s)
2. ソースフローの識別
3. Identification of FEC scheme
3. FECスキームの識別
4. Length of Explicit Source FEC Payload ID
4. 明示的なソースFECペイロードIDの長さ
5. FSSI
5. FSSI
FSSI basically provides an opaque container to encode FEC-scheme-specific configuration information such as buffer size, decoding wait-time, etc. Please refer to the FEC Framework document [RFC6363] for more details.
FSSIは基本的に、バッファーサイズ、デコード待機時間などのFECスキーム固有の構成情報をエンコードするための不透明なコンテナーを提供します。詳細については、FECフレームワークドキュメント[RFC6363]を参照してください。
The usage of signaling protocols described in this document requires that the application layer responsible for the FEC Framework instance provide the value for each of the configuration information parameters (listed above) encoded as per the chosen encoding format. In case of failure to receive the complete information, the signaling protocol module must return an error for Operations, Administration, and Maintenance (OAM) purposes and optionally convey this error to the application layer. Please refer to Figure 1 of the FEC Framework document [RFC6363] for further illustration.
このドキュメントで説明されているシグナリングプロトコルを使用するには、FECフレームワークインスタンスを担当するアプリケーションレイヤーが、選択されたエンコード形式に従ってエンコードされた構成情報パラメーター（上記）のそれぞれに値を提供する必要があります。完全な情報の受信に失敗した場合、シグナリングプロトコルモジュールは、運用、管理、および保守（OAM）の目的でエラーを返し、オプションでこのエラーをアプリケーション層に伝える必要があります。詳細については、FECフレームワークドキュメント[RFC6363]の図1を参照してください。
This document does not make any assumption that the 'FEC Sender' and 'Media Sender' functionalities are implemented on the same device, though that may be the case. Similarly, this document does not make any assumption that 'FEC Receiver' and 'Media Receiver' functionalities are implemented on the same device, though that may be the case. There may also be more than one Media Sender.
このドキュメントでは、「FEC Sender」機能と「Media Sender」機能が同じデバイスに実装されていることを想定していませんが、そうである場合もあります。同様に、このドキュメントでは、「FECレシーバー」機能と「メディアレシーバー」機能が同じデバイスに実装されていることを想定していませんが、そうである場合もあります。複数のメディア送信者が存在する場合もあります。
The FEC Framework Configuration Information (listed above in Section 4) may be encoded in any format, such as SDP, XML, etc., as chosen or preferred by a particular FEC Framework instance. The selection of such encoding formats or syntax is independent of the signaling protocol and beyond the scope of this document.
FECフレームワーク構成情報（上記のセクション4に記載）は、特定のFECフレームワークインスタンスによって選択または優先される、SDP、XMLなどの任意の形式でエンコードできます。そのようなエンコード形式または構文の選択は、シグナリングプロトコルとは無関係であり、このドキュメントの範囲を超えています。
Any encoding format that is selected for a particular FEC Framework instance must be known to the signaling protocol. This is to provide a means (e.g., a field such as Payload Type) in the signaling protocol message(s) to convey the chosen encoding format for the configuration information so that the payload (i.e., configuration information) can be correctly parsed as per the semantics of the chosen encoding format at the receiver. Please note that the encoding format is not a negotiated parameter, but rather a property of a particular FEC Framework instance and/or its implementation.
特定のFECフレームワークインスタンス用に選択されたエンコード形式は、シグナリングプロトコルに認識されている必要があります。これは、ペイロード（つまり、構成情報）を正しく解析できるように、構成情報の選択されたエンコード形式を伝達する手段（たとえば、ペイロードタイプなどのフィールド）をシグナリングプロトコルメッセージに提供することです。受信側で選択されたエンコード形式のセマンティクス。エンコード形式はネゴシエートされたパラメーターではなく、特定のFECフレームワークインスタンスまたはその実装のプロパティであることに注意してください。
Additionally, the encoding format for each FEC Framework configuration parameter must be defined in terms of a sequence of octets that can be embedded within the payload of the signaling protocol message(s). The length of the encoding format must either be fixed or be derived by examining the encoded octets themselves. For example, the initial octets may include some kind of length indication.
さらに、各FECフレームワーク構成パラメーターのエンコード形式は、シグナリングプロトコルメッセージのペイロード内に埋め込むことができるオクテットのシーケンスに関して定義する必要があります。エンコード形式の長さは、固定であるか、エンコードされたオクテット自体を調べて導出する必要があります。たとえば、最初のオクテットには、ある種の長さの表示が含まれる場合があります。
Independent of the encoding formats supported by an FEC scheme, each instance of the FEC Framework must use a single encoding format to describe all of the configuration information associated with that instance. The signaling protocol specified in this document should not validate the encoded information, though it may validate the syntax or length of the encoded information.
FECスキームでサポートされるエンコード形式とは関係なく、FECフレームワークの各インスタンスは、そのインスタンスに関連付けられているすべての構成情報を記述するために、単一のエンコード形式を使用する必要があります。このドキュメントで指定されているシグナリングプロトコルでは、エンコードされた情報の検証は行われませんが、エンコードされた情報の構文や長さは検証される場合があります。
The reader may refer to the SDP elements document [RFC6364], which describes the usage of the 'SDP' encoding format as an example encoding format for the FEC Framework Configuration Information.
読者は、SDP要素のドキュメント[RFC6364]を参照できます。これは、FECフレームワーク構成情報のエンコード形式の例として「SDP」エンコード形式の使用法を説明しています。
The FEC Framework [RFC6363] requires that certain FEC Framework Configuration Information be available to both the sender and receiver(s). This configuration information is almost always formulated at the sender (or on behalf of the sender) and somehow made available at the receiver(s). While one may envision a static method to populate the configuration information at both the sender and receiver(s), it would not be optimal, since it would (a) require the knowledge of every receiver in advance, (b) require the time and means to configure each receiver and sender, and (c) increase the possibility of misconfiguration. Hence, there is a benefit in using a dynamic method (i.e., signaling protocol) to convey the configuration information between the sender and one or more receivers.
FECフレームワーク[RFC6363]では、送信者と受信者の両方が特定のFECフレームワーク構成情報を使用できる必要があります。この構成情報は、ほとんどの場合、送信側で（または送信側に代わって）作成され、何らかの形で受信側で使用可能になります。送信者と受信者の両方で設定情報を入力する静的な方法を想定することもできますが、（a）すべての受信者の事前の知識が必要であり、（b）時間と各受信者と送信者を構成することを意味し、（c）構成ミスの可能性を高めます。したがって、動的な方法（つまり、シグナリングプロトコル）を使用して、送信者と1つまたは複数の受信者の間で構成情報を伝達することには利点があります。
Since the configuration information may be needed at a particular receiver versus many receivers (depending on the multimedia stream being unicast (e.g., Video on Demand (VoD); or multicast, e.g., broadcast or IPTV), we need two types of signaling protocols -- one to deliver the configuration information to many receivers via multicasting (as described in Section 5.1), and the other to deliver the configuration information to one and only one receiver via unicasting (as described in Section 5.2).
特定のレシーバーと多くのレシーバーで構成情報が必要になる場合があるため（ユニキャスト（例：ビデオオンデマンド（VoD）、またはブロードキャスト（IPTV）などのマルチキャスト）に応じて、2種類のシグナリングプロトコルが必要です。 -構成情報をマルチキャスティングを介して多数のレシーバーに配信するセクション5.1で説明したように1つと、ユニキャストを介して構成情報を1つだけのレシーバーに配信するセクション5.2で説明したように1つ。
Figure 1 below illustrates a sample topology showing the FEC Sender and FEC Receiver (which may or may not be the Media Sender and Media Receiver, respectively) such that FEC_Sender1 is serving FEC_Receiver11, FEC_Receiver12, and FEC_Receiver13 via the multicast signaling protocol, whereas FEC_Sender2 is serving only FEC_Receiver2 via the unicast signaling protocol.
次の図1は、FEC_Sender1がマルチキャストシグナリングプロトコルを介してFEC_Receiver11、FEC_Receiver12、およびFEC_Receiver13を提供し、FEC_Sender2がFEC_Sender2であるような、FEC送信者およびFEC受信者を示すサンプルトポロジを示しています。ユニキャストシグナリングプロトコルを介してFEC_Receiver2のみを提供します。
FEC_Sender2---------| |--------FEC_Receiver2
| |
FEC_Sender1-------IP/MPLS network
|-----------FEC_Receiver11
|-----------FEC_Receiver12
|-----------FEC_Receiver13
Figure 1. Topology Using Sender and Receiver
図1.送信側と受信側を使用したトポロジ
The rest of the document continues to use the terms 'Sender' and 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver', respectively.
ドキュメントの残りの部分では、引き続き「送信者」および「受信者」という用語を使用して、それぞれ「FEC送信者」および「FEC受信者」を指します。
This specification describes using SAP version 2 [RFC2974] as the signaling protocol to multicast the configuration information from one sender to many receivers. The apparent advantage is that the server doesn't need to maintain any state for any receiver using SAP.
この仕様では、SAPバージョン2 [RFC2974]をシグナリングプロトコルとして使用して、1つの送信者から多くの受信者に構成情報をマルチキャストする方法について説明しています。明らかな利点は、サーバーがSAPを使用するレシーバーの状態を維持する必要がないことです。
SAP messages are carried over UDP over IP with destination UDP port 9875, as described in [RFC2974], and a source UDP port of any available number. The SAP message(s) MUST contain an authentication header using Pretty Good Privacy (PGP) authentication.
SAPメッセージは、[RFC2974]で説明されているように、宛先UDPポート9875、および使用可能な任意の番号の送信元UDPポートを使用して、UDP over IPを介して伝送されます。 SAPメッセージには、Pretty Good Privacy（PGP）認証を使用した認証ヘッダーが含まれている必要があります。
At the high level, a sender, acting as the SAP announcer, signals the FEC Framework Configuration Information for each FEC Framework instance available at the sender, using the SAP message(s). The configuration information, encoded in a suitable format as per Section 4.1, is carried in the payload of the SAP message(s). A receiver, acting as the SAP listener, listens on a well-known UDP port and at least one well-known multicast group IP address (as explained in Section 5.1.1). This enables the receiver to receive the SAP message(s) and obtain the FEC Framework Configuration Information for each FEC Framework instance.
高レベルでは、SAPアナウンサーとして機能する送信者は、SAPメッセージを使用して、送信者で使用可能な各FECフレームワークインスタンスのFECフレームワーク構成情報を通知します。セクション4.1に従って適切な形式でエンコードされた構成情報は、SAPメッセージのペイロードに含まれています。 SAPリスナーとして機能するレシーバーは、既知のUDPポートと少なくとも1つの既知のマルチキャストグループIPアドレス（セクション5.1.1で説明）でリッスンします。これにより、受信者はSAPメッセージを受信し、各FECフレームワークインスタンスのFECフレームワーク構成情報を取得できます。
Using the configuration information, the receiver becomes aware of available FEC protection options, corresponding multicast trees (S,G or *,G addresses), etc. The receiver may subsequently subscribe to one or more multicast trees to receive the FEC streams using out-of-band multicasting techniques such as PIM [RFC4601]. This, however, is outside the scope of this document.
構成情報を使用して、受信者は、利用可能なFEC保護オプション、対応するマルチキャストツリー（S、Gまたは*、Gアドレス）などを認識します。受信者は、1つまたは複数のマルチキャストツリーにサブスクライブして、 PIM [RFC4601]などの帯域外マルチキャスト技術。ただし、これはこのドキュメントの範囲外です。
Figure 2 below (reprinted from [RFC2974]) illustrates the SAP packet format.
下の図2（[RFC2974]から転載）は、SAPパケット形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. SAP Message Format
図2. SAPメッセージ形式
While [RFC2974] includes explanations for each field, it is worth discussing the 'Payload' and 'Payload Type' fields. The 'Payload' field is used to carry the FEC Framework Configuration Information. Subsequently, the optional 'Payload Type' field, which is a MIME content type specifier, is used to describe the encoding format used to encode the payload.
[RFC2974]には各フィールドの説明が含まれていますが、「ペイロード」および「ペイロードタイプ」フィールドについて説明する価値があります。 「ペイロード」フィールドは、FECフレームワーク構成情報を運ぶために使用されます。続いて、MIMEコンテンツタイプ指定子であるオプションの「ペイロードタイプ」フィールドを使用して、ペイロードのエンコードに使用されるエンコード形式を記述します。
For example, the 'Payload Type' field may be application/sdp if the FEC Framework Configuration Information is encoded in SDP format and carried in the SAP payload. Similarly, it would be application/xml if the FEC Framework Configuration Information were encoded in XML format.
たとえば、FECフレームワーク構成情報がSDP形式でエンコードされ、SAPペイロードで伝送される場合、「ペイロードタイプ」フィールドはapplication / sdpになります。同様に、FECフレームワーク構成情報がXML形式でエンコードされている場合は、application / xmlになります。
Section 5.1.1 describes the sender procedure, whereas Section 5.1.2 describes the receiver procedure in the context of config signaling using [RFC2974].
セクション5.1.1は送信側の手順を説明していますが、セクション5.1.2は[RFC2974]を使用した構成シグナリングのコンテキストでの受信側の手順を説明しています。
The sender signals the FEC Framework Configuration Information for each FEC Framework instance in a periodic SAP announcement message [RFC2974]. The SAP announcement message is sent to a well-known multicast IP address and UDP port, as specified in [RFC2974]. The announcement is multicast with the same scope as the session being announced.
送信者は、定期的なSAPアナウンスメッセージ[RFC2974]で各FECフレームワークインスタンスのFECフレームワーク構成情報を通知します。 [RFC2974]で指定されているように、SAPアナウンスメッセージは既知のマルチキャストIPアドレスとUDPポートに送信されます。アナウンスは、アナウンスされるセッションと同じスコープでマルチキャストされます。
The SAP module at the sender obtains the FEC Framework Configuration Information per instance from the 'FEC Framework' module and places that in the SAP payload accordingly. A single SAP (announcement) message must carry the FEC Framework Configuration Information for a single FEC Framework instance. The SAP message is then sent over UDP over IP.
送信側のSAPモジュールは、「FECフレームワーク」モジュールからインスタンスごとにFECフレームワーク構成情報を取得し、それに応じてSAPペイロードに配置します。単一のSAP（アナウンス）メッセージは、単一のFECフレームワークインスタンスのFECフレームワーク構成情報を伝える必要があります。その後、SAPメッセージはUDP over IPを介して送信されます。
While it is possible to aggregate multiple SAP (announcement) messages in a single UDP datagram as long as the resulting UDP datagram length is less than the IP MTU of the outgoing interface, this specification does not recommend it, since there is no length field in the SAP header to identify a SAP message boundary. Hence, this specification recommends that a single SAP announcement message be sent in a UDP datagram.
結果のUDPデータグラムの長さが発信インターフェイスのIP MTUよりも短い限り、複数のSAP（アナウンス）メッセージを単一のUDPデータグラムに集約することは可能ですが、この仕様では長さフィールドがないため、これを推奨していません。 SAPメッセージ境界を識別するためのSAPヘッダー。したがって、この仕様では、単一のSAPアナウンスメッセージをUDPデータグラムで送信することを推奨しています。
The IP packet carrying the SAP message must be sent to a destination IP address of one of the following, depending on the selected scope:
SAPメッセージを運ぶIPパケットは、選択したスコープに応じて、次のいずれかの宛先IPアドレスに送信する必要があります。
- 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 is selected for the FEC stream), or
- 224.2.127.254（FECストリームにIPv4グローバルスコープ224.0.1.0-238.255.255.255が選択されている場合）、または
- ff0x:0:0:0:0:0:2:7ffe (if IPv6 multicasting is selected for the FEC stream, where x is the 4-bit scope value), or
- ff0x：0：0：0：0：0：2：7ffe（IPv6マルチキャストがFECストリームに対して選択されている場合、xは4ビットのスコープ値です）、または
- the highest multicast address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0-239.255.255.255 is selected for the FEC stream)
- 関連する管理スコープゾーンの最大マルチキャストアドレス（たとえば、239.255.255.255）（FECストリームにIPv4管理スコープ239.0.0.0-239.255.255.255が選択されている場合）
As defined in [RFC2974], the IP packet carrying a SAP message must use destination UDP port 9875 and a source UDP port of any available number. The default IP Time to Live (TTL) value (or Hop Limit value) should be 255 at the sender, though the sender implementation may allow it to be any other value to implicitly create the multicast boundary for SAP announcements. The IP Differentiated Services Code Point (DSCP) field may be set to any value that indicates a desired QoS treatment in the IP network.
[RFC2974]で定義されているように、SAPメッセージを伝送するIPパケットは、宛先UDPポート9875および使用可能な任意の番号のソースUDPポートを使用する必要があります。デフォルトのIP存続時間（TTL）値（またはホップ制限値）は、送信側で255にする必要がありますが、送信側の実装では、SAPアナウンスのマルチキャスト境界を暗黙的に作成するために他の値にすることができます。 IP DiffServコードポイント（DSCP）フィールドは、IPネットワークでの望ましいQoS処理を示す任意の値に設定できます。
The IP packet carrying the SAP message must be sent with a source IP address that is reachable by the receiver. The sender may assign the same IP address in the 'originating source' field of the SAP message as that used in the source IP address of the IP packet.
SAPメッセージを運ぶIPパケットは、受信者が到達可能な送信元IPアドレスで送信する必要があります。送信者は、SAPパケットの「送信元」フィールドに、IPパケットの送信元IPアドレスで使用されているものと同じIPアドレスを割り当てることができます。
Furthermore, the FEC Framework Configuration Information must not include any of the reserved multicast group IP addresses for the FEC streams (i.e., source or repair flows), though it may use the same IP address as the 'originating source' address to identify the FEC streams (i.e., source or repair flows). Please refer to IANA assignments for multicast addresses.
さらに、FECフレームワーク構成情報には、FECストリーム（つまり、ソースフローまたは修復フロー）の予約済みマルチキャストグループIPアドレスを含めないでください。ただし、「発信元」アドレスと同じIPアドレスを使用してFECを識別できます。ストリーム（つまり、ソースまたは修復フロー）。マルチキャストアドレスについては、IANAの割り当てを参照してください。
The sender must periodically send the 'SAP announcement' message to ensure that the receiver doesn't purge the cached entry or entries from the database and doesn't trigger the deletion of the FEC Framework Configuration Information.
送信者は定期的に「SAPアナウンス」メッセージを送信して、受信者がキャッシュされたエントリをデータベースから削除せず、FECフレームワーク構成情報の削除をトリガーしないようにする必要があります。
While the time interval between repetitions of an announcement can be calculated as per the very sophisticated but complex method explained in [RFC2974], this document recommends a simpler method in which the user specifies the time interval in the range of 1-200 seconds, with a suggested default value of 60 seconds. In this method, the 'time interval' may be signaled in the SAP message payload, e.g., within the FEC Framework Configuration Information.
アナウンスの繰り返し間の時間間隔は、[RFC2974]で説明されている非常に洗練された複雑な方法に従って計算できますが、このドキュメントでは、ユーザーが1〜200秒の範囲で時間間隔を指定する簡単な方法を推奨しています。 60秒の推奨デフォルト値。この方法では、「時間間隔」は、たとえばFECフレームワーク構成情報内のSAPメッセージペイロードで通知されます。
Note that SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the usage of a simpler method requires that the time interval be included in the FEC Framework Configuration Information if the default time interval (60 seconds) for SAP message repetitions is not used. For example, the usage of the 'r=' (repeat time) field in SDP may convey the time interval value if the SDP encoding format is used.
SAPでは、時間間隔をSAPヘッダーで通知することはできません。したがって、SAPメッセージを繰り返すためのデフォルトの時間間隔（60秒）を使用しない場合、より簡単な方法を使用するには、時間間隔をFECフレームワーク構成情報に含める必要があります。たとえば、SDPエンコーディング形式が使用されている場合、SDPの「r =」（繰り返し時間）フィールドを使用すると、時間間隔の値を伝えることができます。
The time interval must be chosen to ensure that SAP announcement messages are sent out before the corresponding multicast routing entry, e.g., (S,G) or (*,G) (corresponding to the SAP multicast tree(s)) on the router(s) times out. (It is worth noting that the default timeout period for the multicast routing entry is 210 seconds, per the PIM specification [RFC4601], though the timeout period may be set to another value as allowed by the router implementation.)
ルーター上の（S、G）または（*、G）（SAPマルチキャストツリーに対応）などの対応するマルチキャストルーティングエントリの前にSAPアナウンスメッセージが確実に送信されるように、時間間隔を選択する必要があります。 s）タイムアウト。 （PIM仕様[RFC4601]によると、マルチキャストルーティングエントリのデフォルトのタイムアウト期間は210秒ですが、タイムアウト期間は、ルーターの実装で許可されている別の値に設定できます。）
A SAP implementation may also support the complex method for determining the SAP announcement time interval and provide the option to select it.
SAP実装は、SAPアナウンスの時間間隔を決定するための複雑な方法をサポートし、それを選択するオプションを提供する場合もあります。
The sender may choose to delete the announced FEC Framework Configuration Information, as defined in Section 4 of [RFC2974]. The explicit deletion is useful if the sender no longer desires to send any more FEC streams.
[RFC2974]のセクション4で定義されているように、送信者は発表されたFECフレームワーク構成情報を削除することを選択できます。明示的な削除は、送信者がFECストリームをこれ以上送信したくない場合に便利です。
If the sender needs to modify the announced FEC Framework Configuration Information for one or more FEC instances, then the sender must send a new announcement message with a different 'Message Identifier Hash' value as per the rules described in Section 5 of RFC 2974 [RFC2974]. Such an announcement message should be sent immediately (without having to wait for the time interval) to ensure that the modifications are received by the receiver as soon as possible. The sender must also send the SAP deletion message to delete the previous SAP announcement message (i.e., with the previous 'Message Identifier Hash' value).
送信者が1つ以上のFECインスタンスのアナウンスされたFECフレームワーク構成情報を変更する必要がある場合、送信者はRFC 2974 [RFC2974]のセクション5で説明されているルールに従って、異なる「メッセージIDハッシュ」値を持つ新しいアナウンスメッセージを送信する必要があります。 ]。このようなアナウンスメッセージは、すぐに（時間間隔を待たずに）送信して、変更が受信者にできるだけ早く受信されるようにする必要があります。また、送信者は、SAP削除メッセージを送信して、以前のSAPアナウンスメッセージを削除する必要があります（つまり、以前の「メッセージIDハッシュ」値を使用）。
The receiver must listen on UDP port 9875 for packets arriving with an IP destination address of either 224.2.127.254 (if an IPv4 global scope session is used for the FEC stream), ff0x:0:0:0:0:0:2:7ffe (if IPv6 is selected, where x is the 4-bit scope value), or the highest IP address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0- 239.255.255.255 is selected for the FEC stream). These IP addresses are mandated for SAP usage by RFC 2974 [RFC2974].
受信者は、UDPポート9875で224.2.127.254（FECストリームにIPv4グローバルスコープセッションが使用されている場合）、ff0x：0：0：0：0：0：0：2のいずれかのIP宛先アドレスで到着するパケットをリッスンする必要があります。 7ffe（IPv6が選択されている場合、xは4ビットのスコープ値です）、または関連する管理スコープゾーンの最大IPアドレス（239.255.255.255など）（IPv4管理スコープ239.0.0.0- 239.255.255.255がFECストリーム用に選択されています）。これらのIPアドレスは、RFC 2974 [RFC2974]によるSAPの使用に必須です。
The receiver, upon receiving a SAP announcement message, creates an entry, if it doesn't already exist, in a local database and passes the FEC Framework Configuration Information from the SAP Payload field to the 'FEC Framework' module. Each entry also maintains a timeout value, which is (re)set to five times the time interval value, which in turn is either the default of 60 seconds or the value signaled by the sender.
受信者は、SAPアナウンスメッセージを受信すると、ローカルデータベースにまだ存在しない場合はエントリを作成し、SAPペイロードフィールドからFECフレームワーク構成情報を「FECフレームワーク」モジュールに渡します。各エントリは、タイムアウト値も保持します。これは、時間間隔値の5倍に（再）設定されます。これは、デフォルトの60秒、または送信者から通知された値のいずれかです。
Note that SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the time interval should be included in the FEC Framework Configuration Information -- for example, the usage of the 'r=' (repeat time) field in SDP to convey the time interval value if the SDP encoding format is used.
SAPでは、時間間隔をSAPヘッダーで通知することはできません。したがって、時間間隔はFECフレームワーク構成情報に含める必要があります。たとえば、SDPエンコード形式が使用されている場合、時間間隔値を伝えるためにSDPの「r =」（繰り返し時間）フィールドを使用します。
The timeout value associated with each entry is reset when the corresponding announcement (please see Section 5 of [RFC2974]) is received. If the timeout value for any entry reaches zero, then that entry must be deleted from the database, as described in Section 4 of [RFC2974]. The receiver, upon receiving a SAP delete message, must delete the matching SAP entry in its database, as described in Section 4 of [RFC2974].
各エントリに関連付けられているタイムアウト値は、対応するアナウンス（[RFC2974]のセクション5を参照）を受信するとリセットされます。 [RFC2974]のセクション4で説明されているように、エントリのタイムアウト値がゼロに達した場合、そのエントリをデータベースから削除する必要があります。 [RFC2974]のセクション4で説明されているように、受信者はSAP削除メッセージを受信すると、データベース内の一致するSAPエントリを削除する必要があります。
The deletion of a SAP entry must result in the receiver no longer using the relevant FEC Framework Configuration Information for the corresponding instance and no longer subscribing to any related FEC streams.
SAPエントリを削除すると、受信者は対応するインスタンスの関連FECフレームワーク構成情報を使用しなくなり、関連するFECストリームにサブスクライブしなくなります。
This document describes leveraging any signaling protocol that is already used by the unicast application, for exchanging the FEC Framework Configuration Information between two nodes.
このドキュメントでは、2つのノード間でFECフレームワーク構成情報を交換するために、ユニキャストアプリケーションですでに使用されているシグナリングプロトコルを活用する方法について説明します。
For example, a multimedia (VoD) client may send a request via unicasting for a particular content to the multimedia (VoD) server, which may offer various options such as encodings, bitrates, transport, etc. for the content. The client selects the suitable options and answers the server, paving the way for the content to be unicast on the chosen transport from the server to the client. This offer/answer signaling, described in [RFC3264], is commonly utilized by many application protocols, such as SIP, RTSP, etc.
たとえば、マルチメディア（VoD）クライアントは、特定のコンテンツのユニキャストを介してマルチメディア（VoD）サーバーにリクエストを送信できます。マルチメディア（VoD）サーバーは、コンテンツのエンコーディング、ビットレート、トランスポートなどのさまざまなオプションを提供できます。クライアントは適切なオプションを選択してサーバーに応答し、コンテンツがサーバーからクライアントへの選択されたトランスポートでユニキャストされるようにします。 [RFC3264]で説明されているこのオファー/アンサーシグナリングは、SIP、RTSPなどの多くのアプリケーションプロトコルで一般的に利用されています。
The fact that two nodes desiring unicast communication almost always rely on an application to first exchange the application-related parameters via the signaling protocol makes it logical to enhance such signaling protocol(s) to (a) convey the desire for the FEC protection and (b) subsequently also exchange FEC parameters, i.e., the FEC Framework Configuration Information. This enables the node acting as the offerer to offer 'FEC Framework Configuration Information' for each available FEC instance and the node acting as the answerer to convey the chosen FEC Framework instance(s) to the offerer. The usage of the FEC Framework instance is explained in the FEC Framework document [RFC6363].
ユニキャスト通信を必要とする2つのノードがほとんど常にアプリケーションに依存して、最初にシグナリングプロトコルを介してアプリケーション関連のパラメータを交換するという事実により、そのようなシグナリングプロトコルを拡張して（a）FEC保護の要望を伝え、 b）その後、FECパラメータ、つまりFECフレームワーク構成情報も交換します。これにより、提供者として機能するノードは、利用可能な各FECインスタンスの「FECフレームワーク構成情報」を提供し、回答者として機能するノードは、選択したFECフレームワークインスタンスを提供者に伝達できます。 FECフレームワークインスタンスの使用法は、FECフレームワークドキュメント[RFC6363]で説明されています。
While enhancing an application's signaling protocol to exchange FEC parameters is one method (briefly explained above), an alternative method would be to have a unicast-based generic protocol that could be used by two nodes, independent of the application's signaling protocol. The latter is not covered by this document, of course.
アプリケーションのシグナリングプロトコルを拡張してFECパラメータを交換することは1つの方法です（上で簡単に説明しました）。代わりの方法は、アプリケーションのシグナリングプロトコルとは関係なく、2つのノードで使用できるユニキャストベースの汎用プロトコルを使用することです。もちろん、後者はこのドキュメントではカバーされていません。
The remainder of this section provides example signaling protocols and explains how they can be used to exchange the FEC Framework Configuration Information.
このセクションの残りの部分では、信号プロトコルの例を示し、それらを使用してFECフレームワーク構成情報を交換する方法を説明します。
SIP [RFC3261] is an application-level signaling protocol to create, modify, and terminate multimedia sessions with one or more participants. SIP also enables the participants to discover one another and to agree on a characterization of a multimedia session they would like to share. SIP runs on either TCP, UDP, or Stream Control Transmission Protocol (SCTP) transport and uses SDP as the encoding format to describe multimedia session attributes.
SIP [RFC3261]は、1人以上の参加者とのマルチメディアセッションを作成、変更、および終了するためのアプリケーションレベルのシグナリングプロトコルです。 SIPを使用すると、参加者はお互いを発見し、共有したいマルチメディアセッションの特性に同意することもできます。 SIPは、TCP、UDP、またはストリーム制御伝送プロトコル（SCTP）トランスポートのいずれかで実行され、マルチメディアセッション属性を記述するためのエンコード形式としてSDPを使用します。
SIP already uses an offer/answer model with SDP as described in [RFC3264] to exchange information between two nodes to establish unicast sessions between them. This document extends the usage of this model for exchanging the FEC Framework Configuration Information (described in Section 4). Any SDP-specific enhancements to accommodate the FEC Framework are covered in the SDP elements specification [RFC6364].
[RFC3264]で説明されているように、SIPはすでにSDPでオファー/アンサーモデルを使用して、2つのノード間で情報を交換し、それらのノード間のユニキャストセッションを確立しています。このドキュメントでは、FECフレームワーク構成情報を交換するためのこのモデルの使用法を拡張します（セクション4で説明）。 FECフレームワークに対応するためのSDP固有の拡張機能は、SDP要素仕様[RFC6364]でカバーされています。
RTSP [RFC2326] is an application-level signaling protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data such as audio and video. RTSP runs on either TCP or UDP transports.
RTSP [RFC2326]は、リアルタイムプロパティを持つデータの配信を制御するためのアプリケーションレベルのシグナリングプロトコルです。 RTSPは、オーディオやビデオなどのリアルタイムデータの制御されたオンデマンド配信を可能にする拡張可能なフレームワークを提供します。 RTSPはTCPまたはUDPトランスポートで実行されます。
RTSP already provides an ability to extend the existing method with new parameters. This specification defines the 'FEC-protection-needed' option tag (please see Section 7 for IANA Considerations) and prescribes including it in the Require (or Proxy-Require) header of SETUP (method) request messages, so as to request FEC protection for the data.
RTSPはすでに、既存のメソッドを新しいパラメーターで拡張する機能を提供しています。この仕様は、 'FEC-protection-needed'オプションタグを定義し（IANAの考慮事項についてはセクション7を参照してください）、FEC保護を要求するために、SETUP（メソッド）要求メッセージのRequire（またはProxy-Require）ヘッダーに含めることを規定していますデータ用。
The node receiving such a request either responds with a '200 OK' message that includes offers, i.e., available FEC options (e.g., FEC Framework Configuration Information for each instance) or a '551 Option not supported' message. A sample of a related message exchange is shown below.
このようなリクエストを受信したノードは、オファー、つまり使用可能なFECオプション（各インスタンスのFECフレームワーク構成情報など）を含む「200 OK」メッセージまたは「551 Option not supported」メッセージのいずれかで応答します。関連するメッセージ交換のサンプルを以下に示します。
Node1->Node2: SETUP < ... > RTSP/1.0
CSeq: 1
Transport: <omitted for simplicity>
Require: FEC-protection-needed
Node2->Node1: RTSP/1.0 200 OK
CSeq: 1
Transport: <omitted for simplicity>
The requesting node (Node1) may then send a new SETUP message to convey the selected FEC protection to Node2 and proceed with regular RTSP messaging.
要求側ノード（Node1）は新しいSETUPメッセージを送信して、選択されたFEC保護をNode2に伝え、通常のRTSPメッセージングを続行します。
Suffice it to say that if the requesting node (Node1) received a '551 Option not supported' response from Node2, then the requesting node (Node1) may send the SETUP message without using the Require header.
要求側ノード（Node1）がNode2から '551 Option not supported'応答を受け取った場合、要求側ノード（Node1）はRequireヘッダーを使用せずにSETUPメッセージを送信する可能性があると言うだけで十分です。
This document recommends that SAP message(s) be authenticated to ensure sender authentication, as described in Section 5.1.
このドキュメントでは、セクション5.1で説明されているように、送信者認証を確実にするためにSAPメッセージを認証することを推奨しています。
There are no additional security considerations other than those already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and [RFC3261] for SIP.
SAPについては[RFC2974]、RTSPについては[RFC2326]、SIPについては[RFC3261]で既にカバーされているもの以外に、セキュリティに関する追加の考慮事項はありません。
IANA has registered a new RTSP option tag (option-tag), listed below, in the RTSP/1.0 Option Tags table of the "Real Time Streaming Protocol (RTSP)/1.0 Parameters" registry available from http://www.iana.org/, and it provides the following information in compliance with Section 3.8.1 of [RFC2326]:
IANAは、http：//www.ianaから入手できる「リアルタイムストリーミングプロトコル（RTSP）/1.0パラメータ」レジストリのRTSP / 1.0オプションタグテーブルに、以下にリストする新しいRTSPオプションタグ（option-tag）を登録しました。 org /、および[RFC2326]のセクション3.8.1に準拠して次の情報を提供します。
o Name of option-tag: FEC-protection-needed
o オプションタグの名前：FEC保護が必要
o Description: See Section 5.2.2
o 説明：セクション5.2.2を参照
o Change Control: IETF
o 変更管理：IETF
Thanks to Colin Perkins for pointing out the issue with the time interval for the SAP messages. Additionally, thanks to Vincent Roca, Ali Begen, Mark Watson, Ulas Kozat, and David Harrington for greatly improving this document.
SAPメッセージの時間間隔に関する問題を指摘してくれたColin Perkinsに感謝します。さらに、このドキュメントを大幅に改善してくれたVincent Roca、Ali Begen、Mark Watson、Ulas Kozat、David Harringtonに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、2000年10月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364] Begen、A。、「Forward Error Correction（FEC）フレームワークのセッション記述プロトコル要素」、RFC 6364、2011年10月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
Author's Address
著者のアドレス
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. RTP, NC 27709-4987
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd。 RTP、NC 27709-4987
EMail: rajiva@cisco.com