[要約] RFC 5762は、RTPとDCCPの組み合わせに関するガイドラインであり、データグラムの輻輳制御に焦点を当てています。このRFCの目的は、RTPとDCCPの相互運用性を向上させ、高品質なリアルタイム通信を実現することです。
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)
RTPおよびデータグラムの混雑制御プロトコル（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ネットワーク上のリアルタイムマルチメディア用に広く使用されているトランスポートです。Datagram輻輳制御プロトコル（DCCP）は、リアルタイムアプリケーションに望ましいサービスを提供するトランスポートプロトコルです。このメモは、RTPのDCCPへのマッピングと関連するシグナリングを指定し、リアルタイムアプリケーションがDCCPが提供するサービスを利用できるようにします。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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を使用したアプリケーションのパフォーマンスは、低層輸送の選択に大きく影響されます。Datagramの混雑制御プロトコル（DCCP）[2]は、管理されていないベストエフォルトIPネットワークで実行されるリアルタイムアプリケーションに望ましいプロパティを提供するトランスポートプロトコルです。このメモは、DCCPを使用した輸送のためにRTPをどのようにフレーム化できるかを説明し、そのようなフレーミングの意味のいくつかについて説明します。また、セッション説明プロトコル（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.
このメモの残りの部分は、次のように構成されています。これは、セクション2の作業の理論的根拠から始まり、DCCPへのRTPのマッピングが必要な理由を説明します。セクション3のこのメモで使用されている規則の説明に従って、仕様はセクション4で始まり、RTPパケットがDCCP内でどのようにフレーム化されるかの定義が始まります。関連するシグナル伝達については、セクション5で説明します。セキュリティ上の考慮事項については、セクション6で説明し、IANAの考慮事項はセクション7で説明します。
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.
Best-Effortサービスが使用されている場合、RTP受信機はパケットの損失を監視して、パケットの損失率が許容可能なパラメーター内にあることを確認する必要があります。同じネットワークパスを横切るTCPフローが同じネットワーク条件を経験すると、合理的なタイムスケールで測定された平均スループットが得られる場合、パケット損失は許容可能と見なされます。この条件は、渋滞制御メカニズムを実装して伝送速度（または層状マルチキャストセッションにサブスクライブするレイヤー数）を適応させるか、損失率が容認できないほど高い場合にセッションを去るためにレシーバーを手配することによって満たすことができます。
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.
RTPの輻輳制御を提供するために2つのアプローチが使用されています。1）渋滞制御を組み込んだRTP拡張機能を開発します。2）混雑制御輸送プロトコルを介してRTPを実行するメカニズムを提供します。最初のアプローチの例は[16]に記載されており、RTPを拡張してフィードバック情報を組み込み、TCPフレンドリーレートコントロール（TFRC）[17]をアプリケーションレベルで実装できるようにします。これにより、オペレーティングシステムやネットワークサポートなしで既存のアプリケーションに混雑制御を追加できるようになり、開発中に新しい混雑制御アルゴリズムを実験する柔軟性が提供されます。残念ながら、それはまた、多くの人が避けることを好む負担であるアプリケーション著者に輻輳制御を実装する複雑さを渡します。
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を実行することです。1つの可能性は、[5]で定義されているようにTCPを介してRTPを実行することですが、TCPの信頼できる性質とその混雑制御アルゴリズムのダイナミクスにより、これをほとんどのインタラクティブなリアルタイムアプリケーション（Stream Control Transmission Protocol（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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プロファイルとペイロード形式に従って解釈する必要があります。ヘッダー処理はDCCPフレーミングの影響を受けません（特に、RTPシーケンス数と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.
ENDシステムがRTPセッションに参加すると、DCCP接続が開かれ、セッション中は開いたままです。NATバインディングを開いたままにするために、ENDシステムは、送信する他のデータがない期間中に15秒ごとに1回ゼロの長さのDCCP-DATAパケットを送信する必要があります。これにより、DCCPを介してRTPを使用する場合、RTP No-OPパケット[18]、および同様のアプリケーションレベルのキープライブの必要性が削除されます。このアプリケーションレベルのKeepAliveは、使用中のDCCP CCIDがトランスポートレベルのKeepaliveを提供することがわかっている場合、またはアプリケーションがパスに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.
アプリケーションレベルの混雑制御（[16]など）を提供するRTP拡張機能は、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レイヤーで部分的なチェックサムを有効にする場合があります。この場合、チェックサムは少なくともDCCPヘッダーとRTPヘッダーをカバーして、パケットが正しく配信されるようにする必要があります。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セッションの総トラフィックのごく一部のみを構成します。したがって、構成された名目上の「セッション帯域幅」（[1]のセクション6.2を参照）がDCCP接続で達成可能な帯域幅に沿っている場合、混雑制御による送信の遅延は一般的ではないと予想されます。ただし、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).
[2]のセクション17.1で述べたように、RTCPパケットで伝えられた情報とDCCPの謝辞オプションで伝えられる情報の間には重複の可能性があります。一般に、これは問題ではありません。RTCPパケットには、DCCP確認オプションに存在しないメディア固有のデータが含まれており、DCCPオプションにはRTCPに存在しないネットワークレベルのデータが含まれています。実際、RTP仕様[1]で定義されている5つのRTCPパケットタイプと標準のDCCPオプション[2]の間には重複はありません。ただし、オーバーラップが発生する場合があります。最も明確に、RTCP拡張レポート[23]の一部として定義された損失RLEレポートブロックとDCCP ACKベクターオプションの間で最も明確に。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).
DCCPへのRTPの明らかなマッピングは、RTPフローごとに2つのDCCP接続を作成します。1つはRTPデータパケットとRTP制御パケット用です。RTPに対する頻繁な批判は、大規模なテレフォニーゲートウェイがゲートウェイのペア間で32768以上のRTPフローをサポートしているため、UDPポートを使い果たすため、使用するポートの数に関連しています。さらに、複数のポートを使用すると、NATトラバーサルが複雑になります。これらの理由から、単一のRTPセッションのRTPおよびRTCPトラフィックを、[7]のガイドラインに従って単一のDCCP接続に多重化することをお勧めします（可能であれば、あらゆる状況では不可能かもしれません。競合する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.
ENDシステムは、DCCPフレーミングを使用しているため、単一のRTP同期ソース（SSRC）のみが観察されると想定してはなりません。RTPセッションは、任意の数の輸送接続にまたがる可能性があり、RTPミキサーまたは翻訳者を含めることができ、他の参加者をセッションに連れて行きます。ユニキャストDCCP接続の使用は、RTPセッションに2人の参加者のみがいることを意味するものではなく、RTP ENDシステムは、特に合図しない限り、DCCPを介して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.
複数のDCCP接続をブリッジするRTP翻訳者は、単一の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接続と他のタイプのトランスポート接続に及ぶこともあります。たとえば、RTPエンドシステムからRTP翻訳者へのDCCP接続を介したRTP接続があり、翻訳者の反対側にUDP/IPマルチキャストグループを介してRTPがあります。2番目の例は、パブリックスイッチの電話ネットワーク（PSTN）ゲートウェイをリンクするDCCP接続を介したRTPです。このようなRTP翻訳者の問題は、2つのDCCP接続をリンクする場合の問題に似ています。ただし、翻訳者の両側の混雑制御アルゴリズムが互換性がない場合があります。このような環境のための効果的な翻訳者の実装は自明ではありません。
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:
一般に、新しいRTPプロファイルとDCCPフレーミングの間に矛盾はなく、ほとんどのRTPプロファイルは、次の例外を除いてDCCPを介して使用するために交渉できます。
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の部分チェックサム機能と矛盾する可能性があります。この例は、RTP/SAVPプロファイルによって提供される整合性保護です。これは、DCCP部分チェックサムと併用できません。
o An RTP profile that mandates a particular non-DCCP lower-layer transport will conflict with DCCP.
o 特定の非DCCP低層輸送を義務付けるRTPプロファイルは、DCCPと矛盾します。
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).
現在定義されているプロファイルのうち、最小制御[4]を備えたオーディオおよびビデオ会議用のRTPプロファイル、安全なリアルタイムトランスポートプロトコル[8]、RTCPベースのフィードバック[9]の拡張RTPプロファイル、および拡張セキュアRTPRTCPベースのフィードバック[10]のプロファイルは、DCCPで使用できます（DCCP部分チェックサムと安全なRTPバリアントによって提供される整合性保護との間の潜在的な競合に注目してください - セクション6を参照）。
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:
Protoフィールドは、メディアに使用される輸送プロトコルを示し、ポートはメディアが送信される輸送ポートを示します。[5]および[12]に続いて、このメモは、DCCPを使用して輸送されたメディアを示すために、これらの5つの値のプロトフィールドの値を定義しています。
DCCP DCCP/RTP/AVP DCCP/RTP/SAVP DCCP/RTP/AVPF DCCP/RTP/SAVPF
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]を示しますが、上層層プロトコルではありません。「DCCP」プロトコルを指定するSDP「M =」行は、「FMT」識別子を使用してアプリケーション層プロトコルをさらに適格にする必要があります（「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」プロトコル識別子は、DCCPを介して実行されている最小制御[4]を使用して、オーディオおよびビデオ会議に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」プロトコル識別子は、DCCPを介して実行されている安全なリアルタイムトランスポートプロトコル[8]を使用してRTPを指します。
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」プロトコル識別子は、DCCPを介して実行されているRTCPベースのフィードバック[9]の拡張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を介して実行されているRTCPベースのフィードバック[10]の拡張セキュアー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」、「dccp/rtp/savp」、「dccp/rtp/avpf "、および「dccp/rtp/savpf」プロトコル識別子で使用されるRTPペイロード形式は" 価値。ペイロードタイプ番号が動的に割り当てられている場合、ペイロード形式のメディアタイプ登録で定義されている形式名とパラメーターを指定するには、追加の「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セッションがホストからアクティブである場合、ダイナミックレンジの偶数のポートを他のセッションに使用する必要があります。RTCPがRTPへの別のDCCP接続で送信される場合、RTCP接続は、「a = rtcp：」属性[13]を使用して代替DCCPポートが信号が表示されない限り、次の高い宛先ポート番号を使用する必要があります。相互運用性を向上させるには、「A = RTCP：」を使用する必要があります。
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-Service-Code"）は、次のABNF [14]に従ってDCCPサービスコードを通知するように定義されています。
dccp-service-attr = %x61 "=dccp-service-code:" service-code
service-code = hex-sc / decimal-sc / ascii-sc
hex-sc = %x53 %x43 "=" %x78 *HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT
ascii-sc = %x53 %x43 ":" *sc-char
sc-char = %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.
ここで、[14]で数字とhexdigが定義されています。サービスコードは、[2]のセクション8.1.2で定義されていると解釈され、16進数形式、小数、または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セッション（およびオプションの多重化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セッション（およびオプションの多重化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セッション（およびオプションの多重化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）：他のタイプのメディア（およびオプションの多重化された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）：対応するRTPとは別のRTCP接続
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セッションを特定する必要があります。サービスコードは、セッションに合図されたトップレベルのメディアタイプ（つまり、SDP "M ="行）と一致する必要があります。SC：RTCPを使用するRTCPパケットのみを輸送する接続。
The "a=dccp-service-code:" attribute is a media-level attribute that is not subject to the charset attribute.
「a = dccp-service-code：」属性は、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 = setup：」属性は、どのエンドポイントがDCCP接続確立を開始するかを示します（つまり、最初のDCCP-Requestパケットを送信します）。「a = setup：」属性は、[12]に匹敵する方法で使用する必要があります。ただし、DCCP接続がTCP接続ではなく開始されていることを除きます。
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 = connection：」属性は、[12]と互換性のある方法で使用して、その後のオファー/回答交換の結果として新しいDCCP接続を確立する必要があるか、既存の接続を使用する必要があるかどうかを決定する必要があります。
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ポートでRTCPデータを輸送するために別のDCCP接続を開く必要があります。
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のオファーは、サービスコード「RTPV」を使用してDCCPを使用してRTP/AVPを使用して、H.261ビデオセッションの可用性を示しています（SDPのサービスコードの16進コードを使用）。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]のセキュリティに関する考慮事項[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およびRTCPパケットのメッセージ認証を導入し、使用することを推奨するため、安全なRTPプロファイル（[8]、[10]）とDCCP部分チェックサムオプションの間には潜在的な競合があります。これらのプロファイルで使用されるタイプのメッセージ認証コードは、DCCPパケットペイロードの少しエラーが認証チェックを失敗させるため、部分的なチェックサムで使用することはできません。したがって、DCCP部分チェックサムは、安全なリアルタイムトランスポートプロトコル（SRTP）認証と組み合わせて使用しないでください。基本的なRTP仕様の機密性の機能は、ビットエラーが伝播するため、DCCP部分チェックサムでは使用できません。また、カウンターモードでAEを使用する場合、ビットエラーが伝播しないという事実にもかかわらず、プロファイルはセキュリティの認証を必要とし、認証は部分チェックサムと互換性がないため、安全なRTPプロファイルをDCCP部分チェックサムで使用すべきではありません。
The following SDP "proto" field identifiers have been registered (see Section 5.1):
次のSDP「Proto」フィールド識別子が登録されています（セクション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-field"）が登録されています。
Contact name: Colin Perkins <csp@csperkins.org>
Attribute name: dccp-service-code
属性名：DCCP-Service-Code
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
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-Profile-1 5004/DCCP RTPメディアデータ[RFC3551、RFC5762] AVT-Profile-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]
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.
この作業は、英国の工学および物理科学研究評議会によって部分的にサポートされていました。Philippe Gentric、Magnus Westerlund、Sally Floyd、Dan Wing、Gorry Fairhurst、Stephane Bortzmeyer、Arjuna Sathiaseelan、Tom Phelan、Lars Eggert、Eddie Kohler、Miguel Garcia、および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.、Frederick、R。、およびV. Jacobson、「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] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Lazzaro、J。、「リアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットを接続指向の輸送上のパケット」、RFC 4571、2006年7月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[7] Perkins、C。およびM. Westerlund、「単一のポートの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.、McGrew、D.、Naslund、M.、Carrara、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] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル」、RFC4585、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] Ott、J。およびE. Carrara、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/ SAVPF）の拡張セキュアーRTPプロファイル」、RFC 5124、2008年2月。
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[12] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[12] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、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。、「セッション説明プロトコル（SDP）のリアルタイムコントロールプロトコル（RTCP）属性」、RFC 3605、2003年10月。
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[14] Crocker、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] Floyd、S。およびJ. Kempf、「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] Floyd、S.、Handley、M.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（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] Andreasen、F.、Oran、D。、およびD. Wing、「RTPのNo-opペイロード形式」、2005年5月の作業。
[19] Phelan, T., "Strategies for Streaming Media Applications Using TCP-Friendly Rate Control", Work in Progress, July 2007.
[19] Phelan、T。、「TCPフレンドリーレートコントロールを使用したメディアアプリケーションをストリーミングするための戦略」、2007年7月、進行中の作業。
[20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User Guide", Work in Progress, April 2005.
[20] Phelan、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.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、 "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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[23] Friedman、T.、Caceres、R。、およびA. Clark、「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] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバックによるRTPオーディオビジュアルプロファイルのコーデックコントロールメッセージ（AVPF）」、2007年10月の作業。
Author's Address
著者の連絡先
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ UK
コリンパーキンスグラスゴー大学コンピューティング科学科
EMail: csp@csperkins.org