[要約] RFC 4571は、リアルタイムトランスポートプロトコル（RTP）とRTP制御プロトコル（RTCP）パケットを接続指向トランスポート上でフレーミングするための仕様です。このRFCの目的は、RTPとRTCPパケットの信頼性と効率性を向上させることです。
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
接続指向の輸送上のリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットをフレーミング
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).
Copyright（c）The Internet Society（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.
このメモは、リアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットを接続指向のトランスポート（TCPなど）にフレーミングする方法を定義します。メモは、セッションの説明がフレーミング方法を使用する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.
リアルタイムトランスポートプロトコル（RTP、[RFC3551]）のオーディオ/ビデオプロファイル（AVP、[RFC3550]）は、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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ビットの署名されていない整数整数フィールド（Big-Endian）がフレームを開始します。長さがゼロでない場合、RTPまたはRTCPパケットが長さフィールドに従います。長さフィールドでコード化された値は、RTPまたはRTCPパケットのオクテットの数に等しくなければなりません。ゼロは長さの有効な値であり、nullパケットをコードします。
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.
このフレーミング方法では、フレームマーカー（つまり、長さフィールドに先行する一定の値のオクテット）を使用しません。フレームマーカーは、長さフィールドのエラーを検出するのに役立ちます。フレームマーカーの代わりに、受信機は値が予測可能なRTPおよびRTCPヘッダーフィールド（たとえば、RTPバージョン番号）を監視する必要があります。追加のガイダンスについては、[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.
1つの点で、フレーミングプロトコルは、実際に単一のパケットのレベルを超えるプロパティを指定しています。接続の方向がRTPパケットを運ぶ場合、この方向に運ばれるストリームは、それらのRTPパケットで複数の同期ソース（SSRC）の使用をサポートする必要があります。接続の方向がRTCPパケットを運ぶ場合、この方向に運ばれるストリームは、それらのRTCPパケットで複数のSSRCの使用をサポートする必要があります。
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]と組み合わせて、[comedia]で説明されているメソッドを使用して、TCPでRTP/AVPストリームをセットアップする必要があります。この場合、[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 =" media sp port ["/" integer] sp proto 1*（sp fmt）crlf
Figure 2: Syntax for an SDP media (m=) line (from [SDP])
図2：SDPメディアの構文（m =）ライン（[SDP]から）
The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RFC3550] [RFC3551] stream that uses the framing method over TCP.
<proto>トークン値「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>トークンは、0〜127の範囲の一意の符号なし整数でなければなりません。<fmt>トークンは、ストリームに関連付けられたRTPペイロードタイプを指定します。
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を使用している場合、2番目の接続には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接続は、[コメディア]で定義されているセマンティクスに従って、双方向トラフィックを運ぶ場合があります。接続の両方の方向は、同じタイプのパケット（RTPまたはRTCP）を運ぶ必要があります。パケットは、接続に関連付けられたメディアラインで指定された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の使用は強く推奨されています。ただし、送信者がメディアセッションでRTCPパケットを送信したくない場合、送信者は「b = rs：0」および「b = rr：0」をメディアの説明（[RFC3556]から）に追加する必要があります。
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 = rs：0」と「b = rr：0」行が含まれている場合、メディアセッションのRTCP TCPフローは、セッションのどちらのエンドポイントでも作成してはなりません。他のすべてのケースでは、エンドポイントは、RTP/AVPストリームに2つのTCP接続を確立する必要があります。1つはRTPに、もう1つはRTCP用です。
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
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
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セッションに参加する2つのパーティを定義します。ファーストパーティ（図3）は、ステレオL16ストリーム（静的ペイロードタイプ11）を受信できます。
The second party (Figure 4) is capable of receiving mono (static payload type 10) or stereo L16 streams.
2番目のパーティ（図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の「セットアップ」属性は、第2のパーティが「パッシブ」であり、接続[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.
第一党は、第2党のネットワークアドレス（192.0.2.94）とポート（16112）に接続します。接続が確立されると、双方向に使用されます。1回目のパーティは、接続の一方向にフレーム付きRTPパケットを第2パーティに送信し、2番目のパーティは、接続の別の方向にフレーム付き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.
第一党はまた、第二党のポート16113（16112 1、[SDP]で定義されている）へのRTCP TCP接続を開始します。接続が確立されると、最初のパーティは、接続の一方向にフレーム付きRTCPパケットを第2パーティに送信し、2番目のパーティは、接続の別の方向のフレーム付きRTCPパケットを第1パーティに送信します。
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.
実装者は、これらのセクションで説明されている問題のほとんどがTCPに囲まれたRTPストリームに直接適用されるため、RTP [RFC3550]およびRTP/AVP [RFC3551]ドキュメントのセキュリティに関する考慮事項セクションを注意深く読み取る必要があります。
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]のセキュリティ上の考慮事項セクションでは、これらの問題について詳しく説明しています。
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バイトの配列をスタック変数として宣言し、フレーム付きパケットを配列に読み取るループ上のバインドとして長さを使用する場合があります。このコードは、EtherframeサイズのRTPパケットを使用するフレンドリーなアプリケーションでは正常に機能しますが、攻撃者が悪用することができます。したがって、実装は、nullパケット（長さ== 0）から64kオクテット（長さ= 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に、この定義を再現します。セクション4では、メディアラインの<proto>フィールド「TCP/RTP/AVP」の新しいトークン値を定義します。セクション4では、<proto>フィールドトークンに関連付けられたセマンティクスを指定し、セクション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.、Frederick、R。、およびV. Jacobson、「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.
[コメディア]ヨン、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] Handley、M.、Jacobson、V。、およびC. Perkins。「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605] Huitema、C。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。