Network Working Group J. Lazzaro
Request for Comments: 4571 UC Berkeley
Category: Standards Track July 2006
Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets
over Connection-Oriented Transport
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method.
このメモは、（TCPのような）接続指向の輸送にリアルタイムトランスポートプロトコル（RTP）とRTP制御プロトコル（RTCP）パケットをフレーミングするための方法を定義します。メモは、セッション記述は、フレーミング方式を使用するRTPストリームを指定することができる方法を定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................2
2. The Framing Method ..............................................2
3. Packet Stream Properties ........................................3
4. Session Descriptions for RTP/AVP over TCP .......................3
5. Example .........................................................5
6. Congestion Control ..............................................6
7. Acknowledgements ................................................6
8. Security Considerations .........................................6
9. IANA Considerations .............................................7
10. Normative References ...........................................7
The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport Protocol (RTP, [RFC3551]) does not define a method for framing RTP and RTP Control Protocol (RTCP) packets onto connection-oriented transport protocols (such as TCP). However, earlier versions of RTP/AVP did define a framing method, and this method is in use in several implementations.
オーディオ/ビデオプロファイル（AVP、[RFC3550]）リアルタイムトランスポートプロトコル（RTP、[RFC3551]）は接続指向のトランスポートプロトコルにRTPとRTP制御プロトコル（RTCP）パケットをフレーミングするための方法を定義していないため（例えば）TCPのように。しかし、RTP / AVPの以前のバージョンは、フレーミング方法を定義したが、この方法は、いくつかの実装で使用されています。
In this memo, we document the framing method that was defined by earlier versions of RTP/AVP. In addition, we introduce a mechanism for a session description [SDP] to signal the use of the framing method. Note that session description signalling for the framing method is new and was not defined in earlier versions of RTP/AVP.
このメモでは、RTP / AVPの以前のバージョンで定義されたフレーミング方法を文書化します。加えて、我々は、フレーミング方法の使用をシグナリングするセッション記述[SDP]のためのメカニズムを導入します。フレーミング方法のためのシグナリングそのセッション記述は新規であり、RTP / AVPの以前のバージョンで定義されていない注意してください。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Figure 1 defines the framing method.
図1は、フレーミング方法を定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
---------------------------------------------------------------
| LENGTH | RTP or RTCP packet ... |
---------------------------------------------------------------
Figure 1: The bit field definition of the framing method
図1：フレーミング方式のビットフィールド定義
A 16-bit unsigned integer LENGTH field, coded in network byte order (big-endian), begins the frame. If LENGTH is non-zero, an RTP or RTCP packet follows the LENGTH field. The value coded in the LENGTH field MUST equal the number of octets in the RTP or RTCP packet. Zero is a valid value for LENGTH, and it codes the null packet.
ネットワークバイト順（ビッグエンディアン）でコード化された16ビット符号なし整数LENGTHフィールドは、フレームを開始します。長さがゼロでない場合、RTPまたはRTCPパケットは、LENGTHフィールドの後に続きます。 LENGTHフィールドに符号化された値は、RTPまたはRTCPパケットのオクテットの数が等しくなければなりません。ゼロはLENGTHに有効な値であり、そのコードヌルパケット。
This framing method does not use frame markers (i.e., an octet of constant value that would precede the LENGTH field). Frame markers are useful for detecting errors in the LENGTH field. In lieu of a frame marker, receivers SHOULD monitor the RTP and RTCP header fields whose values are predictable (for example, the RTP version number). See Appendix A.1 of [RFC3550] for additional guidance.
このフレーミング方法は、フレーム・マーカーを使用していない（即ち、長さフィールドに先行することになる一定値のオクテット）。フレームマーカーは、LENGTHフィールドにエラーを検出するのに有用です。フレームマーカーの代わりに、受信機は、その値（例えば、RTPバージョン番号）予測可能でRTPとRTCPヘッダフィールドを監視する必要があります。追加のガイダンスのために[RFC3550]の付録A.1を参照してください。
In most respects, the framing method does not specify properties above the level of a single packet. In particular, Section 2 does not specify the following:
多くの点で、フレーミング方法は、単一パケットのレベル以上のプロパティを指定しません。具体的には、第2章では、次のように指定していません。
Bi-directional issues
双方向の問題
Section 2 defines a framing method for use in one direction on a connection. The relationship between framed packets flowing in a defined direction and in the reverse direction is not specified.
セクション2は、接続上の一方向における使用のためのフレーミング方法を定義します。定義された方向と逆方向に流れるフレームパケットとの関係が指定されていません。
Packet loss and reordering
パケット損失や並べ替え
The reliable nature of a connection does not imply that a framed RTP stream has a contiguous sequence number ordering. For example, if the connection is used to tunnel a UDP stream through a network middlebox that only passes TCP, the sequence numbers in the framed stream reflect any packet loss or reordering on the UDP portion of the end-to-end flow.
接続の信頼性の性質は、フレームRTPストリームが連続したシーケンス番号の順序付けを持っていることを意味するものではありません。接続はTCPのみを通過させるネットワークを介してミドルUDPストリームトンネルに使用される場合、例えば、フレームのストリームにおけるシーケンス番号は、エンドツーエンドのフローのUDP部上の任意のパケット損失または再順序付けを反映しています。
Out-of-band semantics
アウトオブバンドのセマンティクス
Section 2 does not define the RTP or RTCP semantics for closing a TCP socket, or of any other "out of band" signal for the connection.
第2節では、TCPソケットを閉じるため、または接続のために、他の「帯域外」信号のRTPまたはRTCPのセマンティクスを定義していません。
Memos that normatively include the framing method MAY specify these properties. For example, Section 4 of this memo specifies these properties for RTP/AVP sessions specified in session descriptions.
規範的にフレーミング法などが挙げられるメモは、これらのプロパティを指定するかもしれません。たとえば、このメモのセクション4は、セッション記述で指定されたRTP / AVPのセッションのためにこれらのプロパティを指定します。
In one respect, the framing protocol does indeed specify a property above the level of a single packet. If a direction of a connection carries RTP packets, the streams carried in this direction MUST support the use of multiple synchronization sources (SSRCs) in those RTP packets. If a direction of a connection carries RTCP packets, the streams carried in this direction MUST support the use of multiple SSRCs in those RTCP packets.
一つの点において、フレーミングプロトコルは、実際、単一パケットのレベル以上のプロパティを指定しません。接続の方向がRTPパケットを搬送する場合、この方向に搬送ストリームは、これらのRTPパケット内の複数の同期ソース（SSRCs）の使用をサポートしなければなりません。接続の方向がRTCPパケットを搬送する場合、この方向に搬送ストリームは、これらのRTCPパケット内の複数のSSRCsの使用をサポートしなければなりません。
Session management protocols that use the Session Description Protocol [SDP] in conjunction with the Offer/Answer Protocol [RFC3264] MUST use the methods described in [COMEDIA] to set up RTP/AVP streams over TCP. In this case, the use of Offer/Answer is REQUIRED, as the setup methods described in [COMEDIA] rely on Offer/Answer.
セッション記述プロトコルを使用するセッション管理プロトコル[SDP]オファーと一緒に/プロトコル[RFC3264]を答えがTCP上RTP / AVPストリームを設定する[COMEDIA]に記載された方法を使用しなければなりません。 【COMEDIA]に記載の設定方法は、オファー/アンサーに依存しているように、この場合には、オファー/アンサーの使用は、必要とされます。
In principle, [COMEDIA] is capable of setting up RTP sessions for any RTP profile. In practice, each profile has unique issues that must be considered when applying [COMEDIA] to set up streams for the profile.
原則的には、[COMEDIA]任意のRTPプロファイル用のRTPセッションを設定することができます。実際には、各プロファイルは、プロファイルのストリームを設定するには、[COMEDIA]適用する際に考慮しなければならない独特の問題があります。
In this memo, we restrict our focus to the Audio/Video Profile (AVP, [RFC3551]). Below, we define a token value ("TCP/RTP/AVP") that signals the use of RTP/AVP in a TCP session. We also define the operational procedures that a TCP/RTP/AVP stream MUST follow.
このメモでは、私たちは、オーディオ/ビデオプロファイル（AVP、[RFC3551]）への注力を制限します。以下では、TCPセッションにおけるRTP / AVPの使用を知らせるトークン値（「TCP / RTP / AVP」）を定義します。また、TCP / RTP / AVPストリームが従わなければならない操作手順を定義します。
We expect that other standards-track memos will appear to support the use of the framing method with other RTP profiles. The support memo for a new profile MUST define a token value for the profile, using the style we used for AVP. Thus, for profile xyz, the token value MUST be "TCP/RTP/xyz". The memo SHOULD adopt the operational procedures we define below for AVP, unless these procedures are in some way incompatible with the profile.
私たちは、他の標準トラックのメモは、他のRTPプロファイルを持つフレーミング方法の使用をサポートするように見えることを期待しています。新しいプロファイルのサポートメモは、我々がAVPのために使用されるスタイルを使用して、プロファイルのトークン値を定義しなければなりません。このように、プロファイルXYZのために、トークン値は、 "TCP / RTP / XYZ" でなければなりません。メモは、これらの手順は、プロファイルと互換性のないいくつかの方法でない限り、我々は、AVPのために以下の定義操作手順を採用すべきです。
The remainder of this section describes how to setup and use an AVP stream in a TCP session. Figure 2 shows the syntax of a media (m=) line [SDP] of a session description:
このセクションの残りの部分は、どのようにセットアップする方法について説明し、TCPセッションでAVPストリームを使用しています。図2は、セッション記述の媒体（M =）ライン[SDP]のシンタクスを示す図です。
"m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF
"M =" メディアSPポート[ "/" は整数] SPプロト1 *（SP FMT）CRLF
Figure 2: Syntax for an SDP media (m=) line (from [SDP])
図2：（[SDP]から）SDPメディアの構文（M =）ライン
The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RFC3550] [RFC3551] stream that uses the framing method over TCP.
<プロト>トークン値 "TCP / RTP / AVPは、" TCP上フレーミング方式を使用するRTP / AVP [RFC3550]、[RFC3551]のストリームを指定します。
The <fmt> tokens that follow <proto> MUST be unique unsigned integers in the range 0 to 127. The <fmt> tokens specify an RTP payload type associated with the stream.
<プロトを>従う<FMT>トークンは<FMT>は、ストリームに関連付けられたRTPペイロードタイプを指定するトークンを0〜127の範囲の一意の符号なし整数でなければなりません。
In all other respects, the session description syntax for the framing method is identical to [COMEDIA].
他の全ての点で、フレーミング方法のためのセッション記述の構文は[COMEDIA]と同一です。
The TCP <port> on the media line carries RTP packets. If a media stream uses RTCP, a second connection carries RTCP packets. The port for the RTCP connection is chosen using the algorithms defined in [SDP] or by the mechanism defined in [RFC3605].
メディアライン上のTCP <port>は、RTPパケットを運びます。メディアストリームがRTCPを使用している場合は、第二の接続は、RTCPパケットを運びます。 RTCP接続用のポートは、[SDP]または[RFC3605]で定義された機構によって定義されたアルゴリズムを使用して選択されます。
The TCP connections MAY carry bi-directional traffic, following the semantics defined in [COMEDIA]. Both directions of a connection MUST carry the same type of packets (RTP or RTCP). The packets MUST exclusively code the RTP or RTCP streams specified on the media line(s) associated with the connection.
TCP接続は、[COMEDIA]で定義された意味論以下、双方向のトラフィックを運ぶことができます。接続の両方の方向は、パケット（RTPまたはRTCP）の同じタイプを運ばなければなりません。パケットは、排他的接続に関連付けられたメディアライン（S）で指定RTPまたはRTCPストリームをコーディングしなければなりません。
As noted in [RFC3550], the use of RTP without RTCP is strongly discouraged. However, if a sender does not wish to send RTCP packets in a media session, the sender MUST add the lines "b=RS:0" AND "b=RR:0" to the media description (from [RFC3556]).
[RFC3550]で述べたように、RTCPずにRTPを使用することが強く推奨されます。 「B = RR：0」（[RFC3556]からの）メディアの説明に：送信者がメディアセッションにRTCPパケットを送信したくない場合は、送信者が行「0、B = RS」を追加しなければなりません。
If the session descriptions of the offer AND the answer both contain the "b=RS:0" AND "b=RR:0" lines, an RTCP TCP flow for the media session MUST NOT be created by either endpoint in the session. In all other cases, endpoints MUST establish two TCP connections for an RTP/AVP stream, one for RTP and one for RTCP.
「B = RR：0」：提供し、両方の回答のセッション記述が「0、B = RS」含まれている場合はライン、メディアセッションのためのRTCP TCPフローをセッション中にいずれかのエンドポイントによって作成されてはなりません。他のすべてのケースでは、エンドポイントは、RTP / AVPストリーム、RTP用とRTCPのための1のための2つのTCP接続を確立する必要があります。
As described in [RFC3264], the use of the "sendonly" or "sendrecv" attribute in an offer (or answer) indicates that the offerer (or answerer) intends to send RTP packets on the RTP TCP connection. The use of the "recvonly" or "sendrecv" attributes in an offer (or answer) indicates that the offerer (or answerer) wishes to receive RTP packets on the RTP TCP connection.
[RFC3264]で説明したように、申し出（または回答）で、「sendonlyで」または「SENDRECV」属性の使用は、オファー側（または回答）はRTP TCP接続でRTPパケットを送信しようとしていることを示しています。 「recvonlyで」または「のsendrecv」の使用は、申し出（または回答）に属性オファー側（または回答）はRTP TCP接続でRTPパケットを受信したいことを示しています。
The session descriptions in Figures 3 and 4 define a TCP RTP/AVP session.
図3および図4におけるセッション記述は、TCP RTP / AVPセッションを定義します。
v=0 o=first 2520644554 2838152170 IN IP4 first.example.net s=Example t=0 0 c=IN IP4 192.0.2.105 m=audio 9 TCP/RTP/AVP 11 a=setup:active a=connection:new
IP4 IN V = 0 0 =第2520644554 2838152170 IP4 192.0.2.105 M =オーディオ9 TCP / RTP / AVP 11 =セットアップIN first.example.net S =例、T = 0のC =：アクティブA =接続：新しいです
Figure 3: TCP session description for the first participant
図3：最初の参加者のためのTCPセッション記述
v=0 o=second 2520644554 2838152170 IN IP4 second.example.net s=Example t=0 0 c=IN IP4 192.0.2.94 m=audio 16112 TCP/RTP/AVP 10 11 a=setup:passive a=connection:new
受動A =接続：新しいIP4 second.example.net IP4 192.0.2.94 M =オーディオ16112 TCP / RTP / AVP 10 11 =セットアップ中のS =例、T = 0のC = IN V = 0 0 =第2520644554 2838152170
Figure 4: TCP session description for the second participant
図4：2番目の参加のためのTCPセッション記述
The session descriptions define two parties that participate in a connection-oriented RTP/AVP session. The first party (Figure 3) is capable of receiving stereo L16 streams (static payload type 11).
セッション記述は、接続指向のRTP / AVPセッションに参加する二者を定義します。最初のパーティ（図3）は、ステレオL16ストリーム（静的ペイロードタイプ11）を受信することが可能です。
The second party (Figure 4) is capable of receiving mono (static payload type 10) or stereo L16 streams.
第二の当事者（図4）モノ（静的ペイロードタイプ10）またはステレオL16ストリームを受信することができます。
The "setup" attribute in Figure 3 specifies that the first party is "active" and initiates connections, and the "setup" attribute in Figure 4 specifies that the second party is "passive" and accepts connections [COMEDIA].
図3の「設定」属性は、最初のパーティが「アクティブ」であり、接続を開始し、図4の「セットアップ」属性は、第二者が「受動的」であり、接続[COMEDIA]を受け入れるように指定することを指定します。
The first party connects to the network address (192.0.2.94) and port (16112) of the second party. Once the connection is established, it is used bi-directionally: the first party sends framed RTP packets to the second party in one direction of the connection, and the second party sends framed RTP packets to the first party in the other direction of the connection.
第一当事者は、第二者のネットワークアドレス（192.0.2.94）とポート（16112）に接続されています。接続が確立されると、それは双方向に使用されている：第一当事者は、接続の一方の方向に第二者に入りRTPパケットを送信し、第二当事者は、接続の他の方向における第1の当事者に入りRTPパケットを送信します。 。
The first party also initiates an RTCP TCP connection to port 16113 (16112 + 1, as defined in [SDP]) of the second party. Once the connection is established, the first party sends framed RTCP packets to the second party in one direction of the connection, and the second party sends framed RTCP packets to the first party in the other direction of the connection.
第一当事者は、第二当事者の（[SDP]で定義されるように16112 + 1）ポート16113にRTCP TCP接続を開始します。接続が確立されると、第一当事者は、接続の一方の方向に第二者に入りRTCPパケットを送信し、第二当事者は、接続の他の方向における第1の当事者に入りRTCPパケットを送信します。
The RTP congestion control requirements are defined in [RFC3550]. As noted in [RFC3550], all transport protocols used on the Internet need to address congestion control in some way, and RTP is not an exception.
RTP輻輳制御要件は[RFC3550]で定義されています。 [RFC3550]で述べたように、インターネット上で使用されるすべてのトランスポートプロトコルは、何らかの方法で輻輳制御に対処する必要があり、RTPは例外ではありません。
In addition, the congestion control requirements for the Audio/Video Profile are defined in [RFC3551]. The basic congestion control requirement defined in [RFC3551] is that RTP sessions should compete fairly with TCP flows that share the network. As the framing method uses TCP, it competes fairly with other TCP flows by definition.
また、オーディオ/ビデオのプロファイルのための輻輳制御要件は[RFC3551]で定義されています。 [RFC3551]で定義された基本的な輻輳制御要件は、RTPセッションがネットワークを共有するTCPフローとの公正な競争すべきであるということです。フレーミング方法は、TCPを使用すると、それは他のTCPと公平に競合する定義によって流れています。
This memo, in part, documents discussions on the AVT mailing list about TCP and RTP. Thanks to all of the participants in these discussions.
このメモは、部分的に、TCPおよびRTPについてAVTメーリングリスト上のドキュメントの議論。これらの議論の参加者のすべてに感謝します。
Implementors should carefully read the Security Considerations sections of the RTP [RFC3550] and RTP/AVP [RFC3551] documents, as most of the issues discussed in these sections directly apply to RTP streams framed over TCP.
これらのセクションで説明した問題のほとんどは、直接RTPに適用される実装者は慎重に、RTP [RFC3550]のセキュリティの考慮事項のセクションおよびRTP / AVP [RFC3551]の文書をお読みくださいTCP上枠ストリーム。
Session descriptions that specify connection-oriented media sessions (such as the example session shown in Figures 3 and 4 of Section 5) raise unique security concerns for streaming media. The Security Considerations section of [COMEDIA] describes these issues in detail.
（例えば、第5の図3及び図4に示す例セッションなど）の接続指向のメディアセッションは、ストリーミングメディアのためのユニークなセキュリティ上の懸念を提起指定セッション記述。 [COMEDIA]のSecurity Considerations部は詳細にこれらの問題について説明します。
Below, we discuss security issues that are unique to the framing method defined in Section 2.
以下では、第2節で定義されたフレーミング方法にユニークなセキュリティ上の問題を議論します。
Attackers may send framed packets with large LENGTH values to exploit security holes in applications. For example, a C implementation may declare a 1500-byte array as a stack variable, and use LENGTH as the bound on the loop that reads the framed packet into the array. This code would work fine for friendly applications that use Etherframe-sized RTP packets, but may be open to exploit by an attacker. Thus, an implementation needs to handle packets of any length, from a NULL packet (LENGTH == 0) to the maximum-length packet holding 64K octets (LENGTH = 0xFFFF).
攻撃者は、アプリケーションのセキュリティホールを悪用するために大規模な長さの値で囲まパケットを送信することができます。例えば、Cの実装では、スタック変数として1500バイトの配列を宣言し、配列にフレームパケットを読み出しループに結合されるよう長さを使用することができます。このコードは、イーサフレーム-ULEサイズのRTPパケットを使用するフレンドリーなアプリケーションのために正常に動作しますが、攻撃者が悪用する開くことがあります。したがって、実装はNULLパケット（長さ== 0）から64Kオクテット（LENGTH = 0xFFFFの）を保持する最大長のパケットに、任意の長さのパケットを処理する必要があります。
[SDP] defines the syntax of session description media lines. We reproduce this definition in Figure 2 of Section 4 of this memo. In Section 4, we define a new token value for the <proto> field of media lines: "TCP/RTP/AVP". Section 4 specifies the semantics associated with the <proto> field token, and Section 5 shows an example of its use in a session description.
[SDP]セッション記述メディア・ラインの構文を定義します。私たちは、このメモのセクション4の図2にこの定義を再現します。 「TCP / RTP / AVP」：第4章では、我々はメディアラインの<プロト>フィールドに新しいトークン値を定義します。セクション4は、<プロト>フィールドトークンに関連付けられたセマンティクスを指定し、第5節では、セッション記述におけるその使用の例を示す図です。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[COMEDIA]ヨン、D.とG.キャマリロ、 "セッション記述プロトコル（SDP）におけるTCPベースのメディア交通"、RFC 4145、2005年9月。
[SDP] Handley, M., Jacobson, V., and C. Perkins. "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP]ハンドレー、M.、ヤコブソン、V.、およびC.パーキンス。 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]のHuitema、C.、 "リアルタイム制御プロトコル（RTCP）セッション記述プロトコル（SDP）内の属性"、RFC 3605、2003年10月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月。
Author's Address
著者のアドレス
John Lazzaro UC Berkeley CS Division 315 Soda Hall Berkeley CA 94720-1776
ジョン・ラザロUCバークレーCS課315ソーダホールバークレーCA 94720から1776
EMail: lazzaro@cs.berkeley.edu
メールアドレス：lazzaro@cs.berkeley.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。