Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 5762 University of Glasgow
Category: Standards Track April 2010
ISSN: 2070-1721
RTP and the Datagram Congestion Control Protocol (DCCP)
Abstract
抽象
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP.
リアルタイムトランスポートプロトコル（RTP）は、IPネットワーク上のリアルタイムマルチメディアのために広く使用されるトランスポートです。データグラム輻輳制御プロトコル（DCCP）は、リアルタイム・アプリケーションのために望ましいサービスを提供するトランスポート・プロトコルです。このメモはリアルタイムアプリケーションがDCCPが提供するサービスを利用することができるように、関連シグナリング、と一緒に、DCCPにRTPのマッピングを指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc5762.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5762で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Conventions Used in This Memo ...................................4
4. RTP over DCCP: Framing ..........................................4
4.1. RTP Data Packets ...........................................4
4.2. RTP Control Packets ........................................5
4.3. Multiplexing Data and Control ..............................7
4.4. RTP Sessions and DCCP Connections ..........................7
4.5. RTP Profiles ...............................................8
5. RTP over DCCP: Signalling using SDP .............................8
5.1. Protocol Identification ....................................8
5.2. Service Codes .............................................10
5.3. Connection Management .....................................11
5.4. Multiplexing Data and Control .............................11
5.5. Example ...................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
The Real-time Transport Protocol (RTP) [1] is widely used in video streaming, telephony, and other real-time networked applications. RTP can run over a range of lower-layer transport protocols, and the performance of an application using RTP is heavily influenced by the choice of lower-layer transport. The Datagram Congestion Control Protocol (DCCP) [2] is a transport protocol that provides desirable properties for real-time applications running on unmanaged best-effort IP networks. This memo describes how RTP can be framed for transport using DCCP, and discusses some of the implications of such a framing. It also describes how the Session Description Protocol (SDP) [3] can be used to signal such sessions.
リアルタイム転送プロトコル（RTP）[1]広くビデオストリーミング、テレフォニー、および他のリアルタイムネットワーク・アプリケーションで使用されています。 RTPは、下位層のトランスポートプロトコルの範囲で実行することができ、およびRTPを使用してアプリケーションのパフォーマンスが大きく下層輸送の選択によって影響されます。データグラム輻輳制御プロトコル（DCCP）[2]アンマネージベストエフォートIPネットワーク上で実行されているリアルタイムアプリケーションのための望ましい特性を提供するトランスポート・プロトコルです。このメモはRTPがDCCPを使用して輸送するためにフレーム化する方法について説明し、そのようなフレーミングの意味のいくつかを説明します。また、セッション記述プロトコル（SDP）は、[3]そのようなセッションを通知するために使用することができる方法について説明します。
The remainder of this memo is structured as follows: it begins with a rationale for the work in Section 2, describing why a mapping of RTP onto DCCP is needed. Following a description of the conventions used in this memo in Section 3, the specification begins in Section 4 with the definition of how RTP packets are framed within DCCP. Associated signalling is described in Section 5. Security considerations are discussed in Section 6, and IANA considerations in Section 7.
次のように、このメモの残りは構成されている：それはDCCPへのRTPのマッピングが必要とされる理由を説明すると、第2の作業の根拠で始まります。第3節ではこのメモで使用されている表記規則の説明に続いて、仕様はRTPパケットはDCCP内枠れる方法の定義とセクション4で開始されます。関連するシグナリングは、前記セキュリティ問題はセクション7でセクション6、およびIANAの考慮事項に記載されているセクションに記載されています。
With the widespread adoption of RTP have come concerns that many real-time applications do not implement congestion control, leading to the potential for congestion collapse of the network [15]. The designers of RTP recognised this issue, stating in RFC 3551 that [4]:
RTPの普及によって、多くのリアルタイムアプリケーションがネットワーク[15]の輻輳崩壊の潜在的につながる、輻輳制御を実装していないことを懸念してきました。 RTPの設計者は、RFC 3551に述べ、この問題を認識している[4]：
If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
ベストエフォート型のサービスが使用されている場合は、RTP受信機は、パケット損失率が許容パラメータの範囲内であることを保証するために、パケット損失を監視する必要があります。 TCPの同じネットワーク・パスを横切る流れと同じネットワーク条件を経験するが、合理的なタイムスケールで測定した平均スループットを達成する場合は、パケット損失が許容されると考えられる、すなわち、RTPフローが達成さ以上です。この条件は、伝送速度（又は層状マルチキャストセッションのために加入層数）を適合させるために、輻輳制御メカニズムを実装することで、または損失率が許容できないほど高い場合にセッションを終了するための受信機のために配置することによって満たすことができます。
While the goals are clear, the development of TCP friendly congestion control that can be used with RTP and real-time media applications is an open research question with many proposals for new algorithms, but little deployment experience.
目標は明確ですが、RTPとリアルタイムメディアアプリケーションで使用することができますTCPフレンドリー輻輳制御の開発は、新しいアルゴリズムのための多くの提案が、少し展開の経験を持つ、オープン研究課題です。
Two approaches have been used to provide congestion control for RTP: 1) develop RTP extensions that incorporate congestion control; and 2) provide mechanisms for running RTP over congestion-controlled transport protocols. An example of the first approach can be found in [16], extending RTP to incorporate feedback information such that TCP Friendly Rate Control (TFRC) [17] can be implemented at the application level. This will allow congestion control to be added to existing applications without operating system or network support, and it offers the flexibility to experiment with new congestion control algorithms as they are developed. Unfortunately, it also passes the complexity of implementing congestion control onto application authors, a burden which many would prefer to avoid.
2つのアプローチがRTPのための輻輳制御を提供するために使用されています：1）輻輳制御を組み込んだRTPの拡張機能を開発します。 2）輻輳制御トランスポートプロトコルの上にRTPを実行するためのメカニズムを提供します。最初のアプローチの例は、TCPフレンドリーレート制御（TFRC）[17]は、アプリケーション・レベルで実装することができるようにフィードバック情報を組み込むためにRTPを拡張する、[16]に見出すことができます。これは、輻輳制御は、オペレーティングシステムやネットワークをサポートしていない既存のアプリケーションに追加できるようになります、そしてそれは、彼らが開発される新しい輻輳制御アルゴリズムを実験するための柔軟性を提供しています。残念ながら、それはまた、アプリケーションの作者に輻輳制御を実装の複雑さ、多くは避けることを好むだろう負担を渡します。
The second approach is to run RTP on a lower-layer transport protocol that provides congestion control. One possibility is to run RTP over TCP, as defined in [5], but the reliable nature of TCP and the dynamics of its congestion control algorithm make this inappropriate for most interactive real-time applications (the Stream Control Transmission Protocol (SCTP) is inappropriate for similar reasons). A better fit for such applications may be to run RTP over DCCP, since DCCP offers unreliable packet delivery and a choice of congestion control. This gives applications the ability to tailor the transport to their needs, taking advantage of better congestion control algorithms as they come available, while passing the complexity of implementation to the operating system. If DCCP should come to be widely available, it is believed these will be compelling advantages. Accordingly, this memo defines a mapping of RTP onto DCCP.
第2のアプローチは、輻輳制御を提供する下位層トランスポートプロトコルでRTPを実行することです。一つの可能性は、[5]で定義されるように、TCP上のRTPを実行することですが、TCPおよびその輻輳制御アルゴリズムのダイナミクスの信頼性の性質は、ほとんどのインタラクティブなリアルタイム・アプリケーションのために、これは不適切作る（ストリーム制御伝送プロトコル（SCTP）であります）同様の理由には不適切。このようなアプリケーションのためのより良いフィット感はDCCPは信頼性の低いパケット配信と輻輳制御の選択肢を提供していますから、DCCPの上にRTPを実行することであってもよいです。これは、オペレーティングシステムへの実装の複雑さを通過する間、彼らは、利用可能来るよう、より良い輻輳制御アルゴリズムを利用して、アプリケーションが自分のニーズに輸送を調整する能力を提供します。 DCCPが広く利用できるように来るべき場合には、これらの魅力的な利点になると考えられています。したがって、このメモはDCCPにRTPのマッピングを定義します。
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 [6].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[6]。
The following section defines how RTP and RTP Control Protocol (RTCP) packets can be framed for transport using DCCP. It also describes the differences between RTP sessions and DCCP connections, and the impact these have on the design of applications.
次のセクションでは、RTP及びRTP制御プロトコル（RTCP）パケットがDCCPを用いて輸送するためのフレームすることができる方法を定義します。また、RTPセッションとDCCP接続、およびアプリケーションの設計上、これらが与える影響の違いについて説明します。
Each RTP data packet MUST be conveyed in a single DCCP datagram. Fields in the RTP header MUST be interpreted according to the RTP specification, and any applicable RTP Profile and Payload Format. Header processing is not affected by DCCP framing (in particular, note that the semantics of the RTP sequence number and the DCCP sequence number are not compatible, and the value of one cannot be inferred from the other).
各RTPデータパケットは、単一のDCCPデータグラムに搬送しなければなりません。 RTPヘッダ内のフィールドは、RTP仕様、及び該当RTPプロファイルとペイロードフォーマットに従って解釈されなければなりません。ヘッダ処理は、（特に、RTPシーケンス番号とDCCPシーケンス番号のセマンティクスは互換性がないと、1つの値が他から推測することができないことに留意されたい）DCCPフレーミングによって影響されません。
A DCCP connection is opened when an end system joins an RTP session, and it remains open for the duration of the session. To ensure NAT bindings are kept open, an end system SHOULD send a zero-length DCCP-Data packet once every 15 seconds during periods when it has no other data to send. This removes the need for RTP no-op packets [18], and similar application-level keepalives, when using RTP over DCCP. This application-level keepalive does not need to be sent if it is known that the DCCP CCID in use provides a transport-level keepalive, or if the application can determine that there are no NAT devices on the path.
DCCP接続は、エンドシステムがRTPセッションに参加したときに開かれ、そしてそれは、セッションの間、開いたままにされます。それが送信する他のデータを持っていないときにNATバインディングが開いたままにしていることを確認するには、エンド・システムは、期間中に一度だけ、15秒ごとに長さゼロのDCCP - データパケットを送るべきです。 DCCPの上にRTPを使用する場合は、RTPノーオペレーションパケット[18]、および同様のアプリケーションレベルのキープアライブの必要性を除去します。使用中のDCCP CCIDは、トランスポートレベルのキープアライブを提供し、またはアプリケーションが、パスにはNATデバイスがないと判断できる場合ことが知られている場合は、このアプリケーション・レベルのキープアライブを送信する必要はありません。
RTP data packets MUST obey the dictates of DCCP congestion control. In some cases, the congestion control will require a sender to send at a rate below that which the payload format would otherwise use. To support this, an application could use either a rate-adaptive payload format, or a range of payload formats (allowing it to switch to a lower rate format if necessary). Details of the rate adaptation policy for particular payload formats are outside the scope of this memo (but see [19] and [20] for guidance).
RTPデータパケットは、DCCPの輻輳制御のおもむくままに従わなければなりません。いくつかのケースでは、輻輳制御は、ペイロードフォーマットがそうでなければ使用するもの以下のレートで送信するために、送信者が必要になります。これをサポートするために、アプリケーションがレート適応型ペイロードフォーマット、またはペイロードフォーマット（必要であれば、それはより低いレートフォーマットに切り替えることを可能にする）の範囲のいずれかを使用することができます。特定のペイロード・フォーマットのためのレート適応ポリシーの詳細は、このメモの範囲外である（ただし、ガイダンスのために[19]及び[20]参照）。
RTP extensions that provide application-level congestion control (e.g., [16]) will conflict with DCCP congestion control, and MUST NOT be used.
アプリケーション・レベルの輻輳制御を提供するRTPの拡張（例えば、[16]）DCCP輻輳制御と競合し、使用してはいけません。
DCCP allows an application to choose the checksum coverage, using a partial checksum to allow an application to receive packets with corrupt payloads. Some RTP Payload Formats (e.g., [21]) can make use of this feature in conjunction with payload-specific mechanisms to improve performance when operating in environments with frequent non-congestive packet corruption. If such a payload format is used, an RTP end system MAY enable partial checksums at the DCCP layer, in which case the checksum MUST cover at least the DCCP and RTP headers to ensure packets are correctly delivered. Partial checksums MUST NOT be used unless supported by mechanisms in the RTP payload format.
DCCPは、アプリケーションが破損しているペイロードを持つパケットを受信するためのアプリケーションを許可するために、部分的チェックサムを使用して、チェックサム適用範囲を選択することができます。いくつかのRTPペイロードフォーマット（例えば、[21]）は、頻繁な非うっ血パケットが破損して環境で動作するときのパフォーマンスを改善するために、ペイロード固有のメカニズムに関連してこの機能を利用することができます。そのようなペイロードフォーマットが使用される場合、RTPエンドシステムは、チェックサムは、パケットが正しく配信されることを保証するために、少なくともDCCP及びRTPヘッダをカバーしなければならない場合にDCCP層で部分的チェックサムを、可能にすることができます。 RTPペイロード形式のメカニズムによってサポートされない限り、部分的なチェックサムを使用してはいけません。
The RTP Control Protocol (RTCP) is used in the standard manner with DCCP. RTCP packets are grouped into compound packets, as described in Section 6.1 of [1], and each compound RTCP packet is transported in a single DCCP datagram.
RTP制御プロトコル（RTCP）はDCCPとの標準的な方法で使用されています。 [1]のセクション6.1で説明したように、RTCPパケットは、化合物パケットにグループ化され、そして各化合物RTCPパケットは、単一のDCCPデータグラムに搬送されます。
The usual RTCP timing rules apply, with the additional constraint that RTCP packets MUST obey the DCCP congestion control algorithm negotiated for the connection. This can prevent a participant from sending an RTCP packet at the expiration of the RTCP transmission timer if there is insufficient network capacity available. In such cases the RTCP packet is delayed and sent at the earliest possible instant when capacity becomes available. The actual time the RTCP packet was sent is then used as the basis for calculating the next RTCP transmission time.
通常RTCPタイミング規則は、RTCPパケットが接続のために交渉DCCP輻輳制御アルゴリズムに従わなければならない追加の制約と、適用されます。これは、利用可能な十分なネットワーク容量がある場合にRTCP送信タイマの満了時にRTCPパケットを送信することから、参加者を防ぐことができます。このような場合、RTCPパケットが遅延していると容量が利用可能になったときに可能な限り早い瞬間に送られます。 RTCPパケットが送信された実際の時間は、次のRTCP送信時間を計算するための基礎として使用されます。
RTCP packets comprise only a small fraction of the total traffic in an RTP session. Accordingly, it is expected that delays in their transmission due to congestion control will not be common, provided the configured nominal "session bandwidth" (see Section 6.2 of [1]) is in line with the bandwidth achievable on the DCCP connection. If, however, the capacity of the DCCP connection is significantly below the nominal session bandwidth, RTCP packets may be delayed enough for participants to time out due to apparent inactivity. In such cases, the session parameters SHOULD be re-negotiated to more closely match the available capacity, for example by performing a re-invite with an updated "b=" line when using the Session Initiation Protocol [22] for signalling.
RTCPパケットは、RTPセッションにおける総トラフィックのごく一部を構成します。したがって、輻輳制御への伝送における遅延は一般的ではないと予想される、DCCP接続で達成可能な帯域幅に沿ったものである（[1]のセクション6.2参照）を構成公称「セッション帯域幅」を提供しました。しかし、DCCPコネクションの容量が大きく、公称セッション帯域幅を下回っている場合は、参加者が原因見かけ非アクティブにタイムアウトするため、RTCPパケットが十分に遅れることがあります。このような場合に、セッションパラメータは、より密接にシグナリングのためにセッション開始プロトコル[22]を使用する場合、更新「B =」行で再招待行うことにより、例えば、利用可能な容量と一致するように再交渉されるべきです。
Note: Since the nominal session bandwidth is chosen based on media codec capabilities, a session where the nominal bandwidth is much larger than the available bandwidth will likely become unusable due to constraints on the media channel, and so require negotiation of a lower bandwidth codec, before it becomes unusable due to constraints on the RTCP channel.
、名目上のセッション帯域幅がメディアコーデック能力に基づいて選択されているので、公称帯域幅が利用可能な帯域幅よりもはるかに大きいセッションの可能性が高いため、メディアチャネル上の制約に使用できなくなるだろう、とその低帯域幅コーデックの交渉が必要になります。注意してくださいそれが原因RTCPチャネル上の制約のために使用できなくなる前に。
As noted in Section 17.1 of [2], there is the potential for overlap between information conveyed in RTCP packets and that conveyed in DCCP acknowledgement options. In general this is not an issue since RTCP packets contain media-specific data that is not present in DCCP acknowledgement options, and DCCP options contain network-level data that is not present in RTCP. Indeed, there is no overlap between the five RTCP packet types defined in the RTP specification [1] and the standard DCCP options [2]. There are, however, cases where overlap does occur: most clearly between the Loss RLE Report Blocks defined as part of the RTCP Extended Reports [23] and the DCCP Ack Vector option. If there is overlap between RTCP report packets and DCCP acknowledgements, an application SHOULD use either RTCP feedback or DCCP acknowledgements, but not both (use of both types of feedback will waste available network capacity, but is not otherwise harmful).
セクション17.1で述べたように、[2]、RTCPパケットで搬送される情報とDCCP確認オプションで搬送それとの間の重複の可能性があります。 RTCPパケットはDCCP確認オプションに存在しないメディア固有のデータを含み、DCCPオプションがRTCPに存在しないネットワークレベルのデータを含んでいるので、一般的に、これは問題ではありません。実際には、RTP仕様で定義された5つのRTCPパケットタイプとの間の重複がない[1]と標準DCCPオプション[2]。最も明確にRTCP拡張レポート[23]とDCCPのAckベクトルオプションの一部として定義されて消失RLEレポートブロックの間：オーバーラップが発生した場合は、しかし、があります。 RTCPレポートパケットとDCCP肯定応答間のオーバーラップがある場合、アプリケーションがRTCPフィードバックまたはDCCP肯定応答のいずれかを使用する必要がありますが、両方の（フィードバックの両方のタイプを使用することは、利用可能なネットワーク容量を浪費するであろうが、そうでなければ有害ではない）ではありません。
The obvious mapping of RTP onto DCCP creates two DCCP connections for each RTP flow: one for RTP data packets and one for RTP control packets. A frequent criticism of RTP relates to the number of ports it uses, since large telephony gateways can support more than 32768 RTP flows between pairs of gateways, and so run out of UDP ports. In addition, use of multiple ports complicates NAT traversal. For these reasons, it is RECOMMENDED that the RTP and RTCP traffic for a single RTP session is multiplexed onto a single DCCP connection following the guidelines in [7], where possible (it may not be possible in all circumstances, for example when translating from an RTP stream over a non-DCCP transport that uses conflicting RTP payload types and RTCP packet types).
RTPデータパケットのための1つおよびRTP制御パケットのための1つ：DCCP上RTPの明白なマッピングは、各RTPフローのための2つのDCCP接続を作成します。 RTPの頻繁な批判は、大きなテレフォニーゲートウェイ以上32768 RTPは、ゲートウェイのペア間で流れ、従ってUDPポートの不足サポートすることができるので、それは、使用するポートの数に関する。また、複数のポートを使用すると、NATトラバーサルを複雑にします。これらの理由から、単一のRTPセッションのRTPおよびRTCPトラフィックのガイドライン以下の単一DCCP接続に多重化することが推奨される[7]から変換するとき、それは、例えば、すべての状況で可能ではないかもしれない場合（可能競合RTPペイロードタイプ及びRTCPパケットタイプ）を使用して、非DCCP輸送オーバーRTPストリーム。
An end system SHOULD NOT assume that it will observe only a single RTP synchronisation source (SSRC) because it is using DCCP framing. An RTP session can span any number of transport connections, and can include RTP mixers or translators bringing other participants into the session. The use of a unicast DCCP connection does not imply that the RTP session will have only two participants, and RTP end systems SHOULD assume that multiple synchronisation sources may be observed when using RTP over DCCP, unless otherwise signalled.
エンドシステムは、それがDCCPフレーミングを使用しているので、それが唯一のRTP同期ソース（SSRC）を観察することを仮定するべきではありません。 RTPセッションは、交通機関の接続、任意の数にまたがることができ、およびセッションに他の参加者をもたらすRTPミキサーやトランスレータを含めることができます。ユニキャストDCCP接続の使用は、RTPセッションが2つだけの参加者を有するであろうことを意味するものではない、そうでなければ合図しない限り、DCCP上にRTPを使用する場合のRTPエンドシステムは、複数の同期ソースを観察することができると仮定すべきです。
An RTP translator bridging multiple DCCP connections to form a single RTP session needs to be aware of the congestion state of each DCCP connection, and must adapt the media to the available capacity of each. The Codec Control Messages defined in [24] may be used to signal congestion state to the media senders, allowing them to adapt their transmission. Alternatively, media transcoding may be used to perform adaptation: this is computationally expensive, induces delay, and generally gives poor-quality results. Depending on the payload, it might also be possible to use some form of scalable coding.
シングルRTPセッションを形成するために、複数のDCCP接続をブリッジするRTPトランスレータは、各DCCPコネクションの輻輳状態を認識する必要があり、それぞれの使用可能容量にメディアを適応しなければなりません。 [24]で定義されたコーデック制御メッセージは、彼らの送信を適応することを可能にする、メディア送信者に輻輳状態を通知するために使用されてもよいです。あるいは、メディアトランスコーディングは、適応を実行するために使用することができる：これは計算的に高価であり、遅延を誘導し、そして一般的に低品質の結果を与えます。ペイロードによっては、また、スケーラブル符号化のいくつかのフォームを使用することも可能かもしれません。
A single RTP session may also span a DCCP connection and some other type of transport connection. An example might be an RTP over DCCP connection from an RTP end system to an RTP translator, with an RTP over UDP/IP multicast group on the other side of the translator. A second example might be an RTP over DCCP connection that links Public Switched Telephone Network (PSTN) gateways. The issues for such an RTP translator are similar to those when linking two DCCP connections, except that the congestion control algorithms on either side of the translator may not be compatible. Implementation of effective translators for such an environment is non-trivial.
シングルRTPセッションはまた、DCCP接続とトランスポート接続のいくつかの他のタイプにまたがってもよいです。例では、トランスレータの反対側にUDP / IPマルチキャストグループオーバーRTPのRTPトランスレータにRTPエンドシステムからRTP DCCPを介した接続、であるかもしれません。第二の例は、公衆交換電話網（PSTN）ゲートウェイを交換リンクRTP DCCPを介した接続であるかもしれません。 2つのDCCP接続をリンクするとき、このようなRTPトランスレータの課題は、翻訳者のいずれかの側の輻輳制御アルゴリズムは互換性がないかもしれないことを除いて、同様です。このような環境のための効果的な翻訳の実装は非自明です。
In general, there is no conflict between new RTP profiles and DCCP framing, and most RTP profiles can be negotiated for use over DCCP with the following exceptions:
一般的には、以下の例外を除いて、DCCPにわたる使用のために交渉することができ、新たなRTPプロファイルとDCCPフレーミング、および最もRTPプロファイル間の競合はありません。
o An RTP profile that is intolerant of packet corruption may conflict with the DCCP partial checksum feature. An example of this is the integrity protection provided by the RTP/SAVP profile, which cannot be used in conjunction with DCCP partial checksums.
Oパケットの破損の不耐性であるRTPプロファイルがDCCP部分チェックサム機能と競合することができます。この例は、DCCP部分的チェックサムと一緒に使用することができないRTP / SAVPプロファイルによって提供される完全性保護です。
o An RTP profile that mandates a particular non-DCCP lower-layer transport will conflict with DCCP.
DCCPと競合する特定の非DCCP下層輸送を義務付けRTPプロファイルO。
RTP profiles that fall under these exceptions SHOULD NOT be used with DCCP unless the conflicting features can be disabled.
相反する機能を無効にすることができない限り、これらの例外に該当RTPプロファイルがDCCPには使用しないでください。
Of the profiles currently defined, the RTP Profile for Audio and Video Conferences with Minimal Control [4], the Secure Real-time Transport Protocol [8], the Extended RTP Profile for RTCP-based Feedback [9], and the Extended Secure RTP Profile for RTCP-based Feedback [10] MAY be used with DCCP (noting the potential conflict between DCCP partial checksums and the integrity protection provided by the secure RTP variants -- see Section 6).
現在、セキュアリアルタイムトランスポートプロトコルが[9]、[8]、[4]、RTCPベースのフィードバックのための拡張RTPプロファイルをオーディオと最小量のコントロールがビデオ会議用RTPプロファイルを定義したプロファイル、および拡張セキュアRTPのRTCPベースのフィードバック[10]のプロファイル（ - セクション6を参照DCCP部分的チェックサムと変異体セキュアRTPによって提供される完全性保護の間の潜在的な競合を指摘）DCCPと共に使用することができます。
The Session Description Protocol (SDP) [3] and the offer/answer model [11] are widely used to negotiate RTP sessions (for example, using the Session Initiation Protocol [22]). This section describes how SDP is used to signal RTP sessions running over DCCP.
セッション記述プロトコル（SDP）[3]及びオファー/アンサーモデル[11]が広くRTPセッションをネゴシエートするために使用される（セッション開始プロトコルを使用して、例えば[22]）。このセクションでは、SDPは、DCCP上で実行されているRTPセッションを通知するために使用される方法について説明します。
SDP uses a media ("m=") line to convey details of the media format and transport protocol used. The ABNF syntax of a media line is as follows (from [3]):
SDPは、使用されるメディアフォーマット及びトランスポートプロトコルの詳細を伝えるためにメディア（「M =」）線を使用します。メディアラインのABNF構文は以下の通りである（から[3]）。
media-field = %x6d "=" media SP port ["/" integer] SP proto
1*(SP fmt) CRLF
The proto field denotes the transport protocol used for the media, while the port indicates the transport port to which the media is sent. Following [5] and [12], this memo defines these five values of the proto field to indicate media transported using DCCP:
ポートは、メディアが送信されるトランスポート・ポートを示しているプロト・フィールドは、媒体に使用されるトランスポートプロトコルを示します。 [5]及び[12]以下、このメモがprotoフィールドのこれらの5つの値は、DCCPを用いて搬送媒体を示すために定義されています。
DCCP
DCCP/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
The "DCCP" protocol identifier is similar to the "UDP" and "TCP" protocol identifiers and denotes the DCCP transport protocol [2], but not its upper-layer protocol. An SDP "m=" line that specifies the "DCCP" protocol MUST further qualify the application-layer protocol using a "fmt" identifier (the "fmt" namespace is managed in the same manner as for the "UDP" protocol identifier). A single DCCP port is used, as denoted by the port field in the media line. The "DCCP" protocol identifier MUST NOT be used to signal RTP sessions running over DCCP; those sessions MUST use a protocol identifier of the form "DCCP/RTP/..." as described below.
「DCCP」プロトコル識別子は、上位層プロトコル「UDP」および「TCP」プロトコル識別子と同様であり、DCCPトランスポートプロトコル[2]である、ではありません。さらに、「FMT」識別子を使用して、アプリケーション層のプロトコルを修飾する必要があり、「DCCP」プロトコルを指定SDP「M =」行が（「FMT」名前空間は、「UDP」プロトコル識別子と同様に管理されています）。メディア行のポートフィールドで示すようにシングルDCCPポートは、使用されます。 「DCCP」プロトコル識別子はDCCP上で動作するRTPセッションを知らせるために使用してはいけません。以下に説明するように、これらのセッションは、「/ ... DCCP / RTP」形のプロトコル識別子を使用しなければなりません。
The "DCCP/RTP/AVP" protocol identifier refers to RTP using the RTP Profile for Audio and Video Conferences with Minimal Control [4] running over DCCP.
「DCCP / RTP / AVP」プロトコル識別子は、[4] DCCP上で動作する最小量のコントロールがあるオーディオとビデオ会議のためのRTPプロファイルを使用して、RTPを指します。
The "DCCP/RTP/SAVP" protocol identifier refers to RTP using the Secure Real-time Transport Protocol [8] running over DCCP.
「DCCP / RTP / SAVP」プロトコル識別子は、セキュアリアルタイムトランスポートプロトコルを使用して、RTPを指す[8] DCCP上で動作します。
The "DCCP/RTP/AVPF" protocol identifier refers to RTP using the Extended RTP Profile for RTCP-based Feedback [9] running over DCCP.
「DCCP / RTP / AVPF」プロトコル識別子は、[9] DCCP上で動作RTCPベースのフィードバックのための拡張RTPプロファイルを使用して、RTPを指します。
The "DCCP/RTP/SAVPF" protocol identifier refers to RTP using the Extended Secure RTP Profile for RTCP-based Feedback [10] running over DCCP.
「DCCP / RTP / SAVPF」プロトコル識別子はDCCP上で動作する[10] RTCPベースのフィードバックのための拡張セキュアRTPプロファイルを使用してRTPを指します。
RTP payload formats used with the "DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF", and "DCCP/RTP/SAVPF" protocol identifiers MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format.
"DCCP / RTP / AVP" と共に使用RTPペイロードフォーマット、 "DCCP / RTP / SAVP"、 "DCCP / RTP / AVPF"、及び "DCCP / RTP / SAVPF" プロトコル識別子は、それらの「FMTとしてペイロードタイプ番号を使用する必要があります「値。ペイロードタイプ番号が動的に割り当てられている場合、ペイロード形式のメディアタイプ登録によって定義されるように、追加の「rtpmap」属性は、フォーマット名とパラメータを指定するために含まれなければなりません。
DCCP port 5004 is registered for use by the RTP profiles listed above, and SHOULD be the default port chosen by applications using those profiles. If multiple RTP sessions are active from a host, even-numbered ports in the dynamic range SHOULD be used for the other sessions. If RTCP is to be sent on a separate DCCP connection to RTP, the RTCP connection SHOULD use the next higher destination port number, unless an alternative DCCP port is signalled using the "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp:" SHOULD be used whenever an alternate DCCP port is used.
DCCPポート5004は、上記RTPプロファイルで使用するために登録され、それらのプロファイルを使用してアプリケーションによって選択されたデフォルトのポートである必要があります。複数のRTPセッションがホストからアクティブな場合、ダイナミックレンジの偶数番号のポートが他のセッションのために使用されるべきです。属性[13]：RTCPは、RTPに別DCCP接続上で送信される場合、RTCP接続は別のDCCPポートは「A = RTCP」を使用して通知されない限り、次の上位の宛先ポート番号を使用すべきです。改良された相互運用性のために、「= RTCPは、」代替DCCPポートが使用されるときはいつでも使用されるべきです。
In addition to the port number, specified on the SDP "m=" line, a DCCP connection has an associated service code. A single new SDP attribute ("dccp-service-code") is defined to signal the DCCP service code according to the following ABNF [14]:
SDP「M =」行に指定されたポート番号に加えて、DCCP接続は、関連するサービスコードを有しています。単一の新しいSDP属性（「DCCPサービスコード」）は、以下のABNFに従ってDCCPサービスコードを通知するために定義されている[14]。
dccp-service-attr = %x61 "=dccp-service-code:" service-code
DCCP-サービスのattr =％X61 "= DCCP-サービスコード：" サービスコード
service-code = hex-sc / decimal-sc / ascii-sc
サービスコード=ヘキサSC /小数-SC / ASCII-SC
hex-sc = %x53 %x43 "=" %x78 *HEXDIG
六角-SC =％X53％X43 "=" ％のx78 * HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT
小数-SC =％X53％X43 "=" * DIGIT
ascii-sc = %x53 %x43 ":" *sc-char
アスキー-SC =％X53％X43 "：" * SC-CHAR
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122
SC-チャー=％d42-43 /％d45-47 /％d63-90 /％D95 /％d97-122
where DIGIT and HEXDIG are as defined in [14]. The service code is interpreted as defined in Section 8.1.2 of [2] and may be specified using either the hexadecimal, decimal, or ASCII formats. A parser MUST interpret service codes according to their numeric value, independent of the format used to represent them in SDP.
DIGITとHEXDIGは[14]で定義した通りです。 [2]のセクション8.1.2で定義され、16進数、10進数、またはASCIIフォーマットのいずれかを使用して指定することができるように、サービスコードが解釈されます。パーサーは、SDPでそれらを表すために使用されるフォーマットとは無関係に、その数値に応じたサービスコードを解釈しなければなりません。
The following DCCP service codes are registered for use with RTP:
次DCCPサービスコードは、RTPを使用するために登録されています。
o SC:RTPA (equivalently SC=1381257281 or SC=x52545041): an RTP session conveying audio data (and OPTIONAL multiplexed RTCP)
O SC：RTPA（等価SC = 1381257281またはSC = x52545041）：RTPオーディオデータを搬送するセッション（およびOPTIONAL多重RTCP）
o SC:RTPV (equivalently SC=1381257302 or SC=x52545056): an RTP session conveying video data (and OPTIONAL multiplexed RTCP)
O SC：RTPV（等価SC = 1381257302またはSC = x52545056）：RTPビデオデータを搬送するセッション（およびOPTIONAL多重RTCP）
o SC:RTPT (equivalently SC=1381257300 or SC=x52545054): an RTP session conveying text media (and OPTIONAL multiplexed RTCP)
O SC：RTPT（等価SC = 1381257300またはSC = x52545054）：RTPセッション搬送テキストメディア（及びOPTIONAL多重RTCP）
o SC:RTPO (equivalently SC=1381257295 or SC=x5254504f): an RTP session conveying any other type of media (and OPTIONAL multiplexed RTCP)
O SC：RTPO（等価SC = 1381257295またはSC = x5254504f）：メディア（及びOPTIONAL多重RTCP）の任意の他のタイプを運ぶRTPセッション
o SC:RTCP (equivalently SC=1381253968 or SC=x52544350): an RTCP connection, separate from the corresponding RTP
O SC：RTCP（等価SC = 1381253968またはSC = x52544350）：RTCP接続、対応するRTPとは別に
To ease the job of middleboxes, applications SHOULD use these service codes to identify RTP sessions running within DCCP. The service code SHOULD match the top-level media type signalled for the session (i.e., the SDP "m=" line), with the exception connections using media types other than audio, video, or text, which use SC:RTPO, and connections that transport only RTCP packets, which use SC:RTCP.
ミドルボックスの仕事を容易にするために、アプリケーションはDCCP内で実行されているRTPセッションを識別するために、これらのサービスコードを使用すべきです。トップレベルのメディアタイプと一致している必要があり、サービスコードは、例外接続はSC使用オーディオ、ビデオ、またはテキスト以外のメディアタイプ、使用して、セッション（すなわち、SDP「M =」行）の合図：RTPO、および接続SCを使用して、トランスポートのみRTCPパケット、：RTCP。
The "a=dccp-service-code:" attribute is a media-level attribute that is not subject to the charset attribute.
「A = DCCP-サービスコード：」属性は、charset属性の対象ではありませんメディアレベル属性です。
The "a=setup:" attribute indicates which of the endpoints should initiate the DCCP connection establishment (i.e., send the initial DCCP-Request packet). The "a=setup:" attribute MUST be used in a manner comparable with [12], except that DCCP connections are being initiated rather than TCP connections.
「=セットアップA：」属性（すなわち、初期のDCCP-Requestパケットを送信する）DCCP接続確立を開始すべきエンドポイントのかを示します。 「A =セットアップは：」そのDCCP接続はTCP接続ではなく、開始されている以外の属性は、[12]と同等の方法で使用されなければなりません。
After the initial offer/answer exchange, the endpoints may decide to re-negotiate various parameters. The "a=connection:" attribute MUST be used in a manner compatible with [12] to decide whether a new DCCP connection needs to be established as a result of subsequent offer/ answer exchanges, or if the existing connection should still be used.
最初のオファー/アンサー交換した後、エンドポイントは、様々なパラメータを再交渉するように決定することができます。 「=接続A：」属性は、既存の接続がまだ使用されなければならない場合は、新しいDCCP接続は、後続のオファー/アンサー交換の結果として確立する必要がある、またはかどうかを決定するために、[12]と互換性のある方法で使用しなければなりません。
A single DCCP connection can be used to transport multiplexed RTP and RTCP packets. Such multiplexing MUST be signalled using an "a=rtcp-mux" attribute according to [7]. If multiplexed RTP and RTCP are not to be used, then the "a=rtcp-mux" attribute MUST NOT be present in the SDP offer, and a separate DCCP connection MUST be opened to transport the RTCP data on a different DCCP port.
単一DCCP接続が多重RTP及びRTCPパケットを伝送するために使用することができます。そのような多重化は、[7]に記載の「A = RTCP-MUX」属性を使用してシグナリングされなければなりません。多重RTPとRTCPを使用すべきでない場合は、「A = RTCP-MUX」属性は、SDPオファー中に存在してはならない、と別のDCCP接続は異なるDCCPポートにRTCPデータを転送するために開く必要があります。
An offerer at 192.0.2.47 signals its availability for an H.261 video session, using RTP/AVP over DCCP with service code "RTPV" (using the hexadecimal encoding of the service code in the SDP). RTP and RTCP packets are multiplexed onto a single DCCP connection:
192.0.2.47にオファーは、サービスコード（SDP内のサービス・コードの16進数のエンコーディングを使用して）「RTPV」とDCCP上RTP / AVPを使用して、H.261ビデオセッションのためにその状況を知らせます。 RTPとRTCPパケットは、単一のDCCP接続に多重化されています。
v=0
o=alice 1129377363 1 IN IP4 192.0.2.47
s=-
c=IN IP4 192.0.2.47
t=0 0
m=video 5004 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC=x52545056
a=setup:passive
a=connection:new
An answerer at 192.0.2.128 receives this offer and responds with the following answer:
192.0.2.128の回答は、このオファーを受けて、次の答えを応答します。
v=0
o=bob 1129377364 1 IN IP4 192.0.2.128
s=-
c=IN IP4 192.0.2.128
t=0 0
m=video 9 DCCP/RTP/AVP 99
a=rtcp-mux
a=rtpmap:99 h261/90000
a=dccp-service-code:SC:RTPV
a=setup:active
a=connection:new
The end point at 192.0.2.128 then initiates a DCCP connection to port 5004 at 192.0.2.47. DCCP port 5004 is used for both the RTP and RTCP data, and port 5005 is unused. The textual encoding of the service code is used in the answer, and represents the same service code as in the offer.
192.0.2.128のエンドポイントは、192.0.2.47でポート5004へのDCCP接続を開始します。 DCCPポート5004は、RTPとRTCPデータの両方に使用され、5005ポートが未使用です。サービスコードのテキスト符号化は、回答で使用され、オファーと同じサービスコードを表しています。
The security considerations in the RTP specification [1] and any applicable RTP profile (e.g., [4], [8], [9], or [10]) or payload format apply when transporting RTP over DCCP.
RTP仕様のセキュリティ上の考慮事項[1]と該当RTPプロファイル（例えば、[4]、[8]、[9]又は[10]）またはDCCP上RTPを輸送する際のペイロードフォーマットが適用されます。
The security considerations in the DCCP specification [2] apply.
DCCP仕様におけるセキュリティの考慮事項は、[2]適用されます。
The SDP signalling described in Section 5 is subject to the security considerations of [3], [11], [12], [5], and [7].
セクション5で説明SDPシグナリングがセキュリティの考慮の対象となる[3]、[11]、[12]、[5]、及び[7]。
The provision of effective congestion control for RTP through use of DCCP is expected to help reduce the potential for denial of service present when RTP flows ignore the advice in [1] to monitor packet loss and reduce their sending rate in the face of persistent congestion.
DCCPを使用してRTPのための効果的な輻輳制御の提供は、RTPは、[1]パケット損失を監視し、持続的な輻輳の顔に自分の送信速度を低下させるにアドバイスを無視流れたときにサービスの存在拒否の可能性を減らすのに役立つことが期待されます。
There is a potential conflict between the Secure RTP profiles ([8], [10]) and the DCCP partial checksum option, since these profiles introduce, and recommend the use of, message authentication for RTP and RTCP packets. Message authentication codes of the type used by these profiles cannot be used with partial checksums, since any bit error in the DCCP packet payload will cause the authentication check to fail. Accordingly, DCCP partial checksums SHOULD NOT be used in conjunction with Secure Real-time Transport Protocol (SRTP) authentication. The confidentiality features of the basic RTP specification cannot be used with DCCP partial checksums, since bit errors propagate. Also, despite the fact that bit errors do not propagate when using AES in counter mode, the Secure RTP profiles SHOULD NOT be used with DCCP partial checksums, since the profiles require authentication for security, and authentication is incompatible with partial checksums.
セキュアRTPプロファイルとの間の潜在的な衝突がある（[8]、[10]）とDCCP部分チェックサムオプションは、これらのプロファイルは、導入以来、及びRTP及びRTCPパケットのメッセージ認証の使用をお勧めします。 DCCPパケットのペイロードにおける任意のビット誤りが認証チェックが失敗する原因になりますので、これらのプロファイルによって使用されるタイプのメッセージ認証コードは、部分的なチェックサムで使用することはできません。したがって、DCCP部分的なチェックサムは、セキュアリアルタイム転送プロトコル（SRTP）認証と組み合わせて使用されるべきではありません。ビットエラーが伝播するため、基本的なRTP仕様の機密性の機能は、DCCP部分的なチェックサムで使用することはできません。プロファイルは、セキュリティのために認証を必要とし、認証は、部分的なチェックサムと互換性がないため、また、カウンタモードでAESを使用した場合のビットエラーが伝播しないという事実にもかかわらず、セキュアRTPプロファイルは、DCCP部分的なチェックサムと一緒に使用しないでください。
The following SDP "proto" field identifiers have been registered (see Section 5.1):
以下SDP「プロト」フィールド識別子は、（セクション5.1を参照）に登録されています：
Type SDP Name Reference
---- -------- ---------
proto DCCP [RFC5762]
DCCP/RTP/AVP [RFC5762]
DCCP/RTP/SAVP [RFC5762]
DCCP/RTP/AVPF [RFC5762]
DCCP/RTP/SAVPF [RFC5762]
The following new SDP attribute ("att-field") has been registered:
次の新しいSDP属性（「ATT-フィールド」）が登録されています：
Contact name: Colin Perkins <csp@csperkins.org>
担当者名：コリン・パーキンス<csp@csperkins.org>
Attribute name: dccp-service-code
属性名：DCCP-サービスコード
Long-form attribute name in English: DCCP service code
英語での長い形式の属性名：DCCPサービスコード
Type of attribute: Media level.
属性の種類：メディアレベル。
Subject to the charset attribute? No.
charset属性の対象？番号。
Purpose of the attribute: see RFC 5762, Section 5.2
属性の目的：RFC 5762を参照してください、セクション5.2
Allowed attribute values: see RFC 5762, Section 5.2
許可された属性値：RFC 5762を参照してください、セクション5.2
The following DCCP service code values have been registered (see Section 5.2):
次DCCPサービスコード値は（5.2節を参照）に登録されています：
1381257281 RTPA RTP session conveying audio [RFC5762] data (and associated RTCP) 1381257302 RTPV RTP session conveying video [RFC5762] data (and associated RTCP) 1381257300 RTPT RTP session conveying text [RFC5762] media (and associated RTCP) 1381257295 RTPO RTP session conveying other [RFC5762] media (and associated RTCP) 1381253968 RTCP RTCP connection, separate from [RFC5762] the corresponding RTP
テキスト[RFC5762]メディア（および関連するRTCP）1381257295 RTPO RTPセッション搬送を搬送1381257281 RTPA RTPビデオを搬送するオーディオ[RFC5762]データ（および関連するRTCP）1381257302 RTPV RTPセッションを搬送するセッション[RFC5762]はデータ（および関連するRTCP）1381257300 RTPT RTPセッション他の[RFC5762]、[RFC5762]対応するRTPから別のメディア（および関連するRTCP）1381253968 RTCP RTCP接続、
The following DCCP ports have been registered (see Section 5.1):
次DCCPポートは（セクション5.1を参照）に登録されています：
avt-profile-1 5004/dccp RTP media data [RFC3551, RFC5762] avt-profile-2 5005/dccp RTP control protocol [RFC3551, RFC5762]
AVTプロファイル-1 5004 / DCCP RTPメディアデータ[RFC3551、RFC5762] AVTプロファイル-2 5005 / DCCP RTP制御プロトコル[RFC3551、RFC5762]
Note: ports 5004/tcp, 5004/udp, 5005/tcp, and 5005/udp have existing registrations, but incorrect descriptions and references. The IANA has updated the existing registrations as follows:
注：ポート5004 / TCP、5004 / UDP、5005 / TCP、および5005 / udpのは、既存の登録を持っていますが、不正確な記述や参照。次のようにIANAは既存の登録を更新しました：
avt-profile-1 5004/tcp RTP media data [RFC3551, RFC4571] avt-profile-1 5004/udp RTP media data [RFC3551] avt-profile-2 5005/tcp RTP control protocol [RFC3551, RFC4571] avt-profile-2 5005/udp RTP control protocol [RFC3551]
AVTプロファイル-1 5004 TCP / RTPメディアデータ[RFC3551、RFC4571] AVTプロファイル-1 5004 / UDP RTPメディアデータ[RFC3551] AVTプロファイル-2 5005 TCP / RTP制御プロトコル[RFC3551、RFC4571] AVT-プロフィール - 2 5005 / UDP RTP制御プロトコル[RFC3551]
This work was supported in part by the UK Engineering and Physical Sciences Research Council. Thanks are due to Philippe Gentric, Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, Eddie Kohler, Miguel Garcia, and the other members of the DCCP working group for their comments.
この作品は、英国工学・物理科学研究評議会によって部分的にサポートされていました。おかげでフィリップGentric、マグヌスウェスター、サリー・フロイド、ダン・ウィング、Gorry Fairhurst、ステファンBortzmeyer、アルジュナSathiaseelan、トム・フェラン、ラースEggertの、エディコーラー、ミゲル・ガルシア、そして彼らのコメントのためにDCCPワーキンググループの他のメンバーによるものです。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[2]コーラー、E.、ハンドレー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[5] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[5]ラザロ、J.、RFC 4571、2006年7月、 "接続指向のトランスポート上でリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットをフレーミング"。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[7]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[8] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[9] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[9]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、「リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル-Basedフィードバック（RTP / AVPF） 」、RFC 4585、2006年7月。
[10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)", RFC 5124, February 2008.
[10]オット、J.及びE.カララ、RFC 5124、2008年2月 "リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / SAVPF）にSecure RTPプロファイルの拡張"。
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[11]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[12]ヨン、D.とG.キャマリロ、 "セッション記述プロトコルでTCPベースのメディアトランスポート（SDP）"、RFC 4145、2005年9月。
[13] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[13]のHuitema、C.、RFC 3605、2003年10月 "セッション記述プロトコル（SDP）でのリアルタイム制御プロトコル（RTCP）属性"。
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[14]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[15] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[15]フロイド、S.とJ.ケンプ、「インターネットでの音声トラフィックのための輻輳制御に関するIAB心配」、RFC 3714、2004年3月。
[16] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007.
[16] Gharai、L.、 "TCPフレンドリーレート制御とRTP"、進歩、2007年7月の作業。
[17] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[17]フロイド、S.、ハンドレー、M.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 5348、2008年9月。
[18] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format for RTP", Work in Progress, May 2005.
[18]アンドレア、F.、オラン、D.、およびD.翼、 "RTPのための無オペアンプペイロードフォーマット"、進歩、2005年5月での作業。
[19] Phelan, T., "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Work in Progress, July 2007.
[19]フェラン、T.、進歩、2007年7月の作業「TCPフレンドリーレート制御を使用したストリーミングメディアアプリケーションのための戦略」。
[20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User Guide", Work in Progress, April 2005.
[20]フェラン、T.、 "データグラム混雑制御プロトコル（DCCP）ユーザガイド"、進歩、2005年4月の作業。
[21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[21] Sjoberg、J.、ウェスター、M.、Lakaniemi、A.、およびQ.謝、「RTPペイロード形式と適応マルチレート（AMR）と適応マルチレート広帯域（AMR-WBのためのストレージ・ファイル形式）オーディオコーデック」、RFC 4867、2007年4月。
[22] 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.
[22]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[23]フリードマン、T.、カセレス、R.、およびA.クラーク、 "RTP制御プロトコルの拡張レポート（RTCP XR）"、RFC 3611、2003年11月。
[24] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Work in Progress, October 2007.
[24]ウェンガー、S.、チャンドラ、U.、進歩、2007年10月に、仕事ウェスター、M.、およびB.ビルマ、 "フィードバック（AVPF）とRTPオーディオビジュアルプロファイルにおけるコーデック制御メッセージ"。
Author's Address
著者のアドレス
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
コンピューティング科学グラスゴーG12 8QQ英国のグラスゴー学部のコリンパーキンス大学
EMail: csp@csperkins.org
メールアドレス：csp@csperkins.org