Internet Engineering Task Force (IETF) J. Ott
Request for Comments: 5968 Aalto University
Category: Informational C. Perkins
ISSN: 2070-1721 University of Glasgow
September 2010
Guidelines for Extending the RTP Control Protocol (RTCP)
Abstract
抽象
The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.
RTP制御プロトコル（RTCP）は、メディア送信側と受信側との間の制御チャネルを提供するために、リアルタイムトランスポートプロトコル（RTP）と共に使用されます。これは、他の用途のうち、アプリケーションの適応および監視を可能にするためにフィードバックループを構成することができます。 RTCPが提供する基本的な報告メカニズムは、一般的な、まだ非常に強力であり、用途の範囲をカバーするのに十分。これらの基本的なメカニズムが不十分であることが判明した場合、この文書では、RTCPを拡張するためのガイドラインを提供します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5968.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5968で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. RTP and RTCP Operation Overview .................................4
3.1. RTCP Capabilities ..........................................5
3.2. RTCP Limitations ...........................................7
3.3. Interactions with Network- and Transport-Layer Mechanisms ..8
4. Issues with RTCP Extensions .....................................9
5. Guidelines .....................................................10
6. Security Considerations ........................................14
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
The Real-time Transport Protocol (RTP) [RFC3550] is used to carry time-dependent (often continuous) media such as audio or video across a packet network in an RTP session. RTP usually runs on top of an unreliable transport such as UDP, Datagram Transport Layer Security (DTLS), or the Datagram Congestion Control Protocol (DCCP), so that RTP packets are susceptible to loss, re-ordering, or duplication. Associated with RTP is the RTP Control Protocol (RTCP), which provides a control channel for each session: media senders provide information about their current sending activities ("feed forward"), and media receivers report on their reception statistics ("feedback") in terms of received packets, losses, and jitter. Senders and receivers provide self-descriptions allowing them to disambiguate all entities in an RTP session and correlate synchronisation source (SSRC) identifiers with specific application instances. RTCP is carried over the same transport as RTP and is inherently best-effort; hence the RTCP reports are designed for such an unreliable environment, e.g., by making them "for information only".
リアルタイムトランスポートプロトコル（RTP）[RFC3550]の時間依存（しばしば連続）などのRTPセッションのパケットネットワークを介して音声やビデオなどのメディアを運ぶために使用されています。 RTPは通常、UDPのような信頼性の低いトランスポート上で動作し、データグラムトランスポート層セキュリティ（DTLS）、またはデータグラム輻輳制御プロトコル（DCCP）、RTPパケットが損失の影響を受けやすいように、再発注、または重複。 RTPに関連付けられていることは、各セッションのための制御チャネルを提供RTP制御プロトコル（RTCP）、次のとおりです。メディアの送信者は、（「フィードフォワード」）、現在の送信の活動に関する情報を提供し、その受信統計上のメディアレシーバレポート（「フィードバック」）受信したパケット、損失、およびジッタの観点インチ送信側と受信側は、彼らがRTPセッション内のすべてのエンティティを明確にし、特定のアプリケーションインスタンスと同期ソース（SSRC）識別子を相関させることができ、自己記述を提供しています。 RTCPはRTPと同じトランスポート上で実施し、本質的にベストエフォートです。したがって、RTCPレポートは、「情報のみのために、」それらを作ることで、例えば、そのような信頼性のない環境向けに設計されています。
The RTCP control channel provides coarse-grained information about the session in two respects: 1) the RTCP sender report (SR) and receiver report (RR) packets contain only cumulative information or means over a certain period of time and 2) the time period is in the order of seconds and thus neither has a high resolution nor does the feedback come back instantaneously. Both these restrictions have their origin in RTP being scalable and generic. Even these basic mechanisms (which are still not implemented everywhere despite their simplicity and very precise specification, including sample code) offer substantial information for designing adaptive applications and for monitoring purposes, among others.
RTCP制御チャネルが2つの点でセッションに関する粗い情報を提供する：1）RTCP送信者レポート（SR）とレシーバレポート（RR）パケットは、累積情報を含むか、一定期間にわたって手段と、2）時間秒のオーダーであるため、高解像度を持っていませんどちらもフィードバックが瞬時に戻ってくるん。どちらもこれらの制限は、RTPは、スケーラブルかつ汎用的であることにその起源を持っています。 （サンプルコードを含む依然としてその単純かつ非常に正確な仕様にもかかわらず、どこにでも実装されていない）も、これらの基本的なメカニズムは、とりわけ、適応型アプリケーションを設計するための監視目的のために実質的な情報を提供します。
Recently, numerous extensions have been proposed in different contexts to RTCP that significantly increase the complexity of the protocol and the reported values, mutate it toward a command channel, and/or attempt turning it into a reliable messaging protocol. While the reasons for such extensions may be legitimate, many of the resulting designs appear ill-advised in the light of the RTP architecture. Moreover, extensions are often badly motivated and thus appear unnecessary given what can be achieved with the RTCP mechanisms in place today.
最近では、多数の拡張機能が著しく、プロトコルの複雑さと報告された値を上げるコマンドチャネルに向かって、それを変異させ、および/または信頼性の高いメッセージングプロトコルにそれを回す試みRTCPに異なるコンテキストで提案されています。そのような拡張の理由が正当なものであるかもしれないが、結果の設計の多くは、RTPアーキテクチャの光で無分別表示されます。また、拡張子は、多くの場合、ひどく動機づけられているので、今日の場所にRTCPメカニズムで達成することができるものを与え、不必要な表示されます。
This document is intended to provide some guidelines for designing RTCP extensions. It is particularly intended to avoid an extension creep for corner cases that can only harm interoperability and future evolution of the protocol at large. We first outline the basic operation of RTCP and constructing feedback loops using the basic RTCP mechanisms. Subsequently, we outline categories of extensions proposed (and partly already accepted) for RTCP and discuss issues and alternative ways of thinking by example. Finally, we provide some guidelines and highlight a number of questions to ask (and answer!) before writing up an RTCP extension.
この文書は、RTCP拡張を設計するためのいくつかのガイドラインを提供することを意図しています。特に大きいだけで、相互運用性およびプロトコルの将来の発展を害することができ、コーナーケースの拡張クリープを回避するためです。我々は最初のRTCPの基本的な操作の概要を説明し、フィードバックの基本的なRTCPメカニズムを使用してループを構築します。その後、我々はRTCPのために提案されている（と一部がすでに受け入れられた）拡張子のカテゴリの概要を説明し、問題や例で思考する別の方法を議論します。最後に、我々はいくつかのガイドラインを提供して依頼する質問の数を強調（と答える！）RTCP拡張子を書き込む前に。
The terminology defined in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550], "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551], and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] apply.
リアルタイムトランスポート制御プロトコルのための[RFC3550]、「最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール」[RFC3551]、および「拡張RTPプロファイル（RTCP：「リアルタイムアプリケーションのためのトランスポートプロトコルRTP」で定義された用語）ベースのフィードバック（RTP / AVPF）」[RFC4585]適用します。
One of the twelve networking truths in [RFC1925] states: "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away". Despite (or because of) this being an April 1st RFC, this specific truth is very valid, and it applies to RTCP as well.
[RFC1925]で12のネットワーキングの真理の一つは述べて：「を追加し、左、しかし何も存在しない場合に奪うように左に何もないとき、プロトコルの設計では、完璧ではないに達しました」。これは4月1日のRFCであるにもかかわらず（またはのため）、この具体的な真実は非常に有効であり、そしてそれは同様に、RTCPに適用されます。
In this section, we will briefly review what is available from the basic RTP/RTCP specifications. As specifications, we include those that are generic, i.e., do not have dependencies on particular media types. This includes the RTP base specification [RFC3550] and profile [RFC3551], the RTCP bandwidth modifiers for session descriptions [RFC3556], the timely feedback extensions (RFC 4585), and the extensions to run RTCP over source-specific multicast (SSM) networks [RFC5760]. RTCP extended reports (XRs) [RFC3611] provide extended reporting mechanisms that are partly generic in nature, and partly specific to a certain media stream.
このセクションでは、我々は簡単に基本的なRTP / RTCP仕様から利用できるもの見直します。仕様として、我々はすなわち、特定のメディアタイプへの依存関係を持っていない、一般的なものが含まれます。このことは、RTPベースの仕様[RFC3550]およびプロファイル[RFC3551]、セッション記述[RFC3556]のためのRTCP帯域幅調整剤、タイムリーなフィードバックの拡張（RFC 4585）、およびソース固有マルチキャスト（SSM）ネットワークを介してRTCPを実行するための拡張機能を含みます[RFC5760]。 RTCP拡張レポート（XRS）[RFC3611]自然の中で、一部の一般的な、および特定のメディアストリームに一部が特定されている拡張された報告メカニズムを提供します。
We do not discuss RTP-related documents that are orthogonal to RTCP. The Secure RTP Profile [RFC3711] can be used to secure RTCP in much the same way it secures RTP data, but otherwise does not affect the behaviour of RTCP. The transport protocol used also has little impact, since RTCP remains a group communication protocol even when running over a unicast transport (such as TCP [RFC4571] or DCCP [RFC5762]), and is little affected by congestion control due to its low rate relative to the media. The description of RTP topologies [RFC5117] is useful knowledge, but is functionally not relevant here. The various RTP error correction mechanisms (e.g., [RFC2198], [RFC4588], [RFC5109]) are useful for protecting RTP media streams, and may be enabled as a result of RTCP feedback, but do not directly affect RTCP behaviour. Finally, RTP and RTCP may be multiplexed inside the same transport connection or using the same port number [RFC5761], but this does not affect the operation of RTCP itself; distinguishing RTP and RTCP packets is achieved because the code points for RTCP and the payload types for RTP use disjoint number spaces.
私たちは、RTCPに直交しているRTP関連の書類については説明しません。セキュアRTPプロフィール[RFC3711]は、それがRTPデータを確保ほぼ同じ方法で、RTCPを確保するために使用することができますが、そうでない場合はRTCPの動作には影響しません。トランスポートプロトコル（例えばTCP [RFC4571]またはDCCP [RFC5762]のような）ユニキャストトランスポート上に実行するときRTCPもグループ通信プロトコルのままであるので、また、ほとんど影響を有し、そしてほとんどその低いレート相対に輻輳制御に影響される使用しましたメディアへ。 RTPトポロジの記述[RFC5117]は有用な知識であるが、ここでは機能的に関連はありません。様々なRTP誤り訂正機構（例えば、[RFC2198]、[RFC4588]、[RFC5109]）はRTPメディアストリームを保護するために有用であり、RTCPフィードバックの結果として可能にすることができるが、直接RTCPの動作に影響を及ぼしません。最後に、RTPおよびRTCPは、同じトランスポート接続、または同じポート番号[RFC5761]を使用して内部で多重化されてもよいが、これはRTCP自体の動作に影響を及ぼしません。 RTCPとRTPのペイロードタイプのコードポイントがばらばら数のスペースを使用するため、RTP及びRTCPパケットを区別することは達成されます。
The RTP/RTCP specifications quoted above provide feedback mechanisms with the following properties, which can be considered as "building blocks" for adaptive real-time applications for IP networks.
上記引用されたRTP / RTCP仕様は、IPネットワークのための適応リアルタイムアプリケーションのための「ビルディング・ブロック」として考えることができる次のプロパティを持つフィードバックメカニズムを提供します。
o Sender reports (SRs) indicate to the receivers the total number of packets and octets that have been sent (since the beginning of the session or the last change of the sender's SSRC). These values allow deducing the mean data rate and mean packet size for both the entire session and, if continuously monitored, for every transmission interval. They also allow a receiver to distinguish between breaks in reception caused by network problems, and those due to pauses in transmission.
O送信者レポート（SRS）は、受信器に（セッションの開始または送信者のSSRCの最後の変更以降）が送信されたパケットとオクテットの総数を示しています。これらの値は、すべての送信間隔のために、継続的に監視た場合、平均データレートを推定できるようにし、セッション全体の両方のパケットサイズを意味します。彼らはまた、受信機は、ネットワークの問題によって引き起こされる受信の中断、および送信に休止に起因するものとを区別することを可能にします。
o Receiver reports (RRs) and SRs indicate reception statistics from each receiver for every sender. These statistics include:
Oレシーバ（RRS）を報告し、SRSは、すべての送信者のために、各受信機からの受信統計を示しています。これらの統計は、次のとおりです。
* The packet loss rate since the last SR or RR was sent.
*最後のSRやRRが送られたため、パケット損失率。
* The total number of packets lost since the beginning of the session, which may again be broken down to each reporting period.
*再び各報告期間に分解することができるセッションの初め以来、失われたパケットの合計数。
* The highest sequence number received so far -- which allows a sender to roughly estimate how much data is in flight when used together with the SR and RR timestamps (and also allows observing whether the path still works and at which rate packets are delivered to the receiver).
*最高のシーケンス番号は、これまでに受信 - 送信者は大体SRとRRのタイムスタンプと一緒に使用する場合、飛行中にあるどのくらいのデータを推定することができます（また、パスがまだ動作とする速度パケットがに配信されているかどうかを観察することができました受信機）。
* The moving average of the inter-arrival jitter of media packets. This gives the sender an indirect view of the size of any adaptive playout buffer used at the receiver ([RFC3611] gives precise figures for Voice over IP (VoIP) sessions).
*メディアパケットの到着間ジッタの移動平均。これは、送信側に受信機で使用される任意の適応プレイアウトバッファ（[RFC3611]は、ボイスオーバーIP（VoIP）のセッションのための正確な数値を与える）の大きさの間接的な表示を与えます。
o Sender reports also contain NTP and RTP format timestamps. These allow receivers to synchronise multiple RTP streams, and (when used in conjunction with receiver reports) allow the sender to calculate the current round-trip time (RTT) to each receiver. This value can be monitored over time and thus may be used to infer trends at coarse granularity. A similar mechanism is provided by [RFC3611] to allow receivers to calculate the RTT to senders.
O送信者レポートはまた、NTPおよびRTP形式のタイムスタンプが含まれています。これらは、受信機が、複数のRTPストリームを同期させ、そして（レシーバレポートと併せて使用される場合）、送信者は、各受信機に現在のラウンドトリップ時間（RTT）を計算することを可能にすることを可能にします。この値は、経時的にモニターすることができ、したがって、粗い粒度での傾向を推測するために使用することができます。同様のメカニズムは、受信機が送信者にRTTを計算することを可能にする[RFC3611]によって与えられます。
RTCP sender reports and receiver reports are sent, and the statistics are sampled, at random intervals chosen uniformly in the range from 0.5 to 1.5 times the deterministic calculated interval, T. The interval T is calculated based on the media bitrate, the mean RTCP packet size, whether the sampling node is a sender or a receiver, and the number of participants in the session, and will remain constant while the number of participants in the session remains constant. The lower bound on the base inter-report interval, T, is five seconds, or 360 seconds divided by the session bandwidth in kilobits/ second (giving an interval smaller than 5 seconds for bandwidths greater than 72 kbits/s) [RFC3550].
RTCP送信者レポートおよび受信レポートが送信され、統計は0.5〜1.5倍決定的算出し間隔の範囲内に一様に選択されたランダムな間隔で、サンプリングされ、Tは、間隔Tは、メディアビットレート、平均RTCPパケットに基づいて算出されますサイズ、サンプリングノードは送信側または受信側、およびセッションの参加者の数であり、セッションの参加者数は一定のままで一定のままであるかどうか。ベース間レポート間隔に下限、Tは、5秒、またはキロビット/秒（72人のキロビット/秒を超える帯域幅のために5秒よりも小さい間隔を与える）のセッション帯域幅[RFC3550]で割った360秒です。
This lower limit can be eliminated, allowing more frequent feedback, when using the early feedback profile for RTCP [RFC4585]. In this case, the RTCP frequency is only limited by the available bitrate (usually 5% of the media stream bitrate is allocated for RTCP). If this fraction is insufficient, the RTCP bitrate may be increased in the session description to enable more frequent feedback [RFC3556]. The considerations in [RFC5506] may be used to reduce the mean RTCP packet size, further increasing feedback frequency.
RTCP [RFC4585]の早期フィードバックプロファイルを使用するとき、この下限は、より頻繁なフィードバックを可能にする、排除することができます。この場合、RTCP周波数のみ（通常、メディアストリームのビットレートの5％RTCPに割り当てられる）利用可能なビットレートによって制限されます。この画分が不足している場合、RTCPビットレートは、より頻繁なフィードバック[RFC3556]を有効にするセッション記述に増加させることができます。 [RFC5506]での考察は、さらに、フィードバック周波数を高く、平均RTCPパケットサイズを減少させるために使用されてもよいです。
The mechanisms defined in [RFC4585] even allow -- statistically -- a receiver to provide close-to-instant feedback to a sender about observed events in the media stream (e.g., picture or slice loss).
[RFC4585]で定義されたメカニズムも可能 - 統計 - メディアストリーム（例えば、ピクチャまたはスライスの損失）で観察されたイベントについての送信者に近いツー即座にフィードバックを提供するために受信機。
RTCP is suitable for unicast and multicast communications. All basic functions are designed with group communications in mind. While traditional (any-source) multicast (ASM) is clearly not available in the Internet at large, source-specific multicast (SSM) and overlay multicast are -- and both are commercially relevant. RTCP extensions have been defined to operate over SSM, and complex topologies may be created by interconnecting RTP mixers and translators. The group communication nature of RTP and RTCP is also essential for the operation of Multipoint Control Units.
RTCPは、ユニキャストとマルチキャスト通信に適しています。すべての基本的な機能は、心の中でグループ通信を使用して設計されています。伝統的な（任意のソース）マルチキャスト（ASM）が大きく、ソース固有マルチキャスト（SSM）で明らかにインターネットで利用可能ではなく、マルチキャストオーバーレイしつつある - との両方は、商業的に関連しています。 RTCPの拡張は、SSM上で動作するように定義されており、かつ複雑なトポロジは、RTPミキサーと翻訳者を相互接続することによって作成することができます。 RTPとRTCPのグループ通信性質もマルチポイントコントロールユニットの動作のために不可欠です。
These mechanisms can be used to implement a quite flexible feedback loop and enable short-term reaction to observed events as well as long-term adaptation to changes in the networking environment. Adaptation mechanisms available on the sender side include (but are not limited to) choosing different codecs, different parameters for codecs (spatial or temporal resolution for video, audible quality for audio and voice), and different packet sizes to adjust the bitrate. Furthermore, various forward error correction (FEC) mechanisms and, if RTTs are short and the application permits extra delays, even reactive error control such as retransmissions can be used. Long-term feedback can be provided in regular RTCP reports at configurable intervals, whereas (close-to-)instant feedback is available by means of the early feedback profile. Figure 1 below outlines this idea graphically.
これらのメカニズムは、非常に柔軟なフィードバックループを実装し、ネットワーク環境の変化が観察されたイベントへの短期反応ならびに長期適応を可能にするために使用することができます。送信側で利用可能な適応メカニズムは、（限定されるものではないが）異なるコーデック、ビットレートを調整するためのコーデック（ビデオ、オーディオおよび音声のための可聴品質のための空間や時間分解能）、および異なるパケットサイズの異なるパラメータを選択します。さらに、様々な前方誤り訂正（FEC）メカニズムと、のRTTが短いと、アプリケーションが余分な遅延を許可する場合、そのような再送信なども反応性エラー制御を使用することができます。即座にフィードバックを早期にフィードバックプロファイルによって提供されています（クローズ・トゥ・）に対し、フィードバックは、通常のRTCPで提供することができる長期的には、設定可能な間隔で報告します。下の図1は、グラフィカルにこのアイデアを概説します。
Long-term adaptation: RTCP sender reports Media processing:
- Codec+parameter choice - Data rate, pkt count - De-jittering
- Packet size - Timing and sync info - Synchronisation
- FEC, interleaving - Traffic characteristics - Error concealment
--------------------------------> - Playout
+---------------+/ \+---------------+
| | RTP media stream (codec, repair) | |
| Media sender |=================================>| Media receiver |
| | | |
+---------------+\ RTCP receiver reports /+---------------+
<--------------------------------
Short-term reaction: - long-term statistics Control functions:
- Retransmissions - event information - RTP monitoring
- Retroactive FEC - media-specific info and reporting
- Adaptive source coding - "congestion info"(*) - Instant event
- Congestion control(*) notifications
(*) RTCP feedback is insufficient for the purposes of TCP-friendly congestion control due to the infrequent nature of reporting (which should be in the order of once per RTT), but can still be used to adapt to the available bandwidth on slower time-scales.
（*）RTCPフィードバックが原因（一度RTTあたりの順であるべき）報告のまれな性質のためにTCPフレンドリーな輻輳制御の目的のためには不十分であるが、それでも低速の時に利用可能な帯域幅に適合させるために使用することができます-scales。
Figure 1: Outline of an RTCP Feedback Loop
図1：RTCPフィードバックループの概要
It is important to note that not all information needs to be signalled explicitly -- ever, or upon every RTCP packet -- but can be derived locally from other pieces of information and from the evolution of the information over time.
これまで、またはすべてのRTCPパケット時 - - ないすべての情報が明示的にシグナリングする必要があることに注意することが重要であるが、他の情報から、時間にわたる情報の進化からローカルに導くことができます。
The design of RTP limits what can meaningfully be done (and hence should be done) with RTCP. In particular, the design favours scalability and loose coupling over tightly controlled feedback loops. Some of these limitations are listed below (they need to be taken into account when designing extensions):
RTPの設計は、RTCPで有意義に行うことができる（したがって、行われるべき）ものを制限します。具体的には、設計は、厳密に制御フィードバックループ上スケーラビリティと疎結合を好みます。これらの制限の一部は、（彼らは拡張を設計する際に考慮される必要がある）次のとおりです。
o RTCP is designed to provide occasional feedback, which is unlike, e.g., TCP ACKs, which can be sent in response to every (other) packet. It does not offer per-packet feedback (even when using [RFC4585] with increased RTCP bandwidth fraction, the feedback guarantees are only statistical in nature).
O RTCPは、とは違って、時折フィードバック、すべての（他の）パケットに応答して送信することができ、例えば、TCP ACKを、提供するように設計されています。これは、パケットごとのフィードバックを提供していません（増加したRTCP帯域幅の割合で、[RFC4585]を使用する場合でも、フィードバックの保証は、自然の中での統計のみです）。
o RTCP is not capable of providing truly instant feedback.
O RTCPは本当に即座にフィードバックを提供することが可能ではありません。
o RTCP is inherently unreliable and does not guarantee any consistency between the observed state at multiple members of a group.
O RTCPは、本質的に信頼できないとグループの複数のメンバーで観測された状態との間の一貫性を保証するものではありません。
It is important to note that these features of RTCP are intentional design choices, and are essential for it to scale to large groups.
RTCPのこれらの機能は、意図的な設計上の選択であり、それは大規模なグループに拡張するために不可欠であることに注意することが重要です。
As discussed above, RTCP flows are used to measure, infer, and convey information about the performance of an RTP media stream.
上述したように、RTCPフローは、測定推論、およびRTPメディアストリームのパフォーマンスに関する情報を伝えるために使用されます。
Inference in baseline RTCP is mainly limited to determining the path RTT from pairs of RTCP SR and RR packets. This inference makes the implicit assumption that RTP and RTCP are treated equally: they are routed along the same path, mapped to the same (DiffServ) traffic classes, and treated as part of the same fair queuing classification. This is true in many cases; however, since RTP and RTCP are generally sent using different ports, any flow classification based upon the 5-tuple (of source and destination IP addresses, source and destination port numbers, and the transport protocol) could lead to a differentiation between RTP and RTCP flows, disrupting the statistics.
ベースラインRTCPにおける推論は、RTCP SRのペアとRRパケットから経路RTTを決定することに主に制限されます。彼らは、同じパスに沿ってルーティングされた同じ（DiffServの）トラフィッククラスにマッピングされ、そして同じ公平キューイング分類の一部として扱われます。この推論は、RTPとRTCPが平等に扱われる暗黙の前提になります。これは、多くの場合においても同様です。 RTPとRTCPは、一般に、異なるポートを使用して送信されるので、任意のフロー分類は、（ソースおよび宛先IPアドレス、送信元および宛先ポート番号、トランスポートプロトコルの）5タプルに基づいてRTPとRTCPの間の区別につながる可能性統計を破壊し、流れています。
While some networks may wish to intentionally prioritise RTCP over RTP (to provide quicker feedback) or RTP over RTCP (since the media is considered more important than control), we recommend that they be treated identically where possible, to enable this inference of network performance, and hence support application adaptation.
いくつかのネットワークは、意図的にRTP（迅速なフィードバックを提供するために）またはRTCPオーバーRTP（メディアがコントロールよりも重要と考えられているため）の上にRTCPを優先させたい場合がありますが、私たちは、ネットワークパフォーマンスのこの推論を可能にするために、それらが同一の場所を可能に処理することをお勧めします、したがって、アプリケーションの適応をサポートしています。
When using reliable transport connections for (RTP and) RTCP [RFC2326] [RFC4571], retransmissions and head-of-line blocking may similarly lead to inaccurate RTT estimates derived by RTCP. (These may, nevertheless, properly reflect the mean RTT for a media packet, including retransmissions.)
（RTPなど）RTCP [RFC2326]、[RFC4571]のための信頼できるトランスポート接続を使用する場合、再送信およびヘッドオブラインブロッキングは同様に、RTCPによって導出不正確なRTT推定値につながる可能性があります。 （これらは、それにもかかわらず、適切に再送信を含むメディアパケット、の平均RTTを反映してもよいです。）
The conveyance of information in RTCP is affected by the above only as soon as the prioritisation leads to a disproportionately high number of RTCP packets being dropped.
RTCPの情報の搬送のみとすぐに優先順位がドロップされるRTCPパケットの不釣り合いに高い数をもたらすように、上記の影響を受けています。
All of this emphasises the unreliable nature of RTCP. Multiplexing on the same port number [RFC5761] or inside the same transport connection might help mitigate some of these effects, but this is limited to speculation at this point and should not be relied upon.
このすべては、RTCPの信頼性のない性格を強調しています。同じポート番号[RFC5761]上または同じトランスポート接続内の多重化は、これらの効果の一部を緩和に役立つかもしれないが、これは、この時点での憶測に限定されており、依拠すべきではありません。
Issues that have come up in the past with extensions to RTP and RTCP include (but are probably not limited to) the following:
（おそらく、これらに限定されない）RTPとRTCPの拡張で、過去に出ている問題以下：
o Defining RTP or RTCP extensions only or primarily for unicast two-party sessions. RTP is inherently a group communication protocol, even when operating on a unicast connection. Extensions may become useful in the future well outside their originally intended area of application, and should consider this. Stating that something works for unicast only is not acceptable, particularly since various flavours of multicast have become relevant again, and as middleboxes such as repair servers, mixers, and RTCP-supporting Multipoint Control Units (MCUs) [RFC5117] become more widely used.
Oの定義RTPまたはRTCPの拡張のみ、または主にユニキャストの二者セッションのために。 RTPは、ユニキャスト接続で動作する場合であっても、本質的に、グループ通信プロトコルです。拡張機能は、アプリケーションの彼らの本来の領域の外側だけでなく、将来的に便利になることがあり、これを考慮すべきです。何かがユニキャストのみのために働くことを伝えることは、マルチキャストの様々な味が再び関連となっている、そのような修理・サーバ、ミキサー、およびRTCP支持マルチポイントコントロールユニット（MCUの）としてミドルボックスと[RFC5117]は、より広く使用されるようになって、特に以来、受け入れられません。
o Assuming reliable (instant) state synchronisation. RTCP reports are sent irregularly and may be lost. Hence, there may be a significant time lag (several seconds) between intending to send a state update to the RTP peer(s) and the packet being received; in some cases, the packet may not be received at all.
信頼性の高い（インスタント）状態の同期を想定すると、O。 RTCPレポートは不定期に送信され、失われることがあります。したがって、RTPピア（複数可）、受信されたパケットの状態の更新を送信することを意図との間に有意な時間遅れ（数秒）が存在してもよいです。いくつかのケースでは、パケットは一切お受けできない場合があります。
o Requiring reliable delivery of RTCP reports. While reliability can be implemented on top of RTCP using acknowledgements, this will come at the cost of significant additional delay, which may defeat the purpose of providing the feedback in the first place. Moreover, for scalability reasons due to the group-based nature of RTCP, these ACKs need to be adaptively rate limited or targeted to a subgroup or individual entity to avoid implosion as group sizes increase. RTCP is not intended or suitable for use as a reliable control channel.
RTCP報告の信頼性の高い配信を要求O。信頼性が確認応答を使用してRTCPの上に実装することができますが、これは最初の場所でのフィードバックを提供する目的を倒すことが重要な追加の遅延のコストで来ます。また、RTCPのグループベースの性質のため、スケーラビリティの理由から、これらのACKは適応基が増加してサイズなど爆縮を避けるために制限されたレートまたはサブグループまたは個々のエンティティに標的化される必要があります。 RTCPは、意図や信頼性の高い制御チャネルとして使用するのに適していません。
o Issuing commands, rather than giving hints. RTCP is about reporting observations -- in a best-effort manner -- between RTP entities. Causing actions on the remote side requires some form of reliability (see above), and adherence cannot be verified.
コマンドを発行するのではなく、ヒントを与えて、O。ベストエフォート方式で - - RTPエンティティ間RTCPは、観測の報告についてです。リモート側でアクションを引き起こすことは、信頼性のいくつかのフォームを必要とする（上記参照）、及び密着性が検証できません。
o Expanding RTCP reporting, to use it as a network management tool. RTCP is sensitive to the size of RTCP reports as the latter determines the mean reporting interval given a certain bitrate share for RTCP (yet, RTCP may also be used to report information that has fine-grained temporal characteristics, if summarisation or data reduction by the endpoint would lose essential resolution). The information going into RTCP reports should primarily target the peer(s) (and thus include information that can be meaningfully reacted upon); nevertheless, such reports may provide useful information to augment other network management tools. Gathering and reporting statistics beyond this is not an RTCP task and should be addressed by out-of-band protocols.
ネットワーク管理ツールとしてそれを使用するために、RTCPレポートを拡大O。後者は間隔RTCPのための一定のビットレートシェアを与え（まだによってsummarisationまたはデータ削減場合、RTCPも、きめの細かい時間的特性を有する情報を報告するために使用され得る報告の平均を決定するようにRTCPはRTCPのサイズに敏感であることを報告しエンドポイントは）基本的な解像度を失うことになります。 RTCPレポートに入る情報は、主に、ピア（複数可）を標的とする（したがって、意味の上に反応することができる情報を含む）べきです。それにもかかわらず、そのような報告書は、他のネットワーク管理ツールを強化するために有用な情報を提供することができます。収集し、これ以上の統計を報告することはRTCPタスクではなく、アウトオブバンドのプロトコルによって対処されなければなりません。
o Creating serious complexity. Related to the previous item, RTCP reports that convey all kinds of data need to gather and calculate/infer this information to begin with (which requires very precise specifications). Given that it already seems to be difficult to even implement baseline RTCP, any added complexity can only discourage implementers, may lead to buggy implementations (in which case the reports do not serve their intended purpose), and hinder interoperability.
O深刻な複雑さを作成します。前の項目に関連して、すべての種類のデータを伝えるRTCPレポートは、（これは非常に正確な仕様が必要です）を開始するために、この情報を収集し、計算/推論する必要があります。すでにさえベースラインRTCPを実装することは困難であると思われることを考えると、のみ、実装を阻止することができます任意の追加の複雑さは、バグだらけの実装（この場合、レポートには、その意図する目的に使うことはありません）につながる、との相互運用性を妨げることがあります。
o Introducing architectural issues. Extensions are written without considering the architectural concepts of RTP. For example, point-to-point communication is assumed, yet third-party monitors are expected to listen in. Besides being a bad idea to rely on eavesdropping entities on the path, this is obviously not possible if Secure RTP (SRTP) is being used with encrypted SRTCP packets.
Oアーキテクチャの問題をご紹介します。拡張機能は、RTPの建築の概念を考慮せずに書かれています。例えば、セキュアRTP（SRTP）がされている場合、経路上の盗聴エンティティに依存することは悪い考えであることに加えて、これは明らかに不可能である。ポイント・ツー・ポイント通信が想定され、さらに第3のパーティのモニタはで聞くことが期待されます暗号化されたSRTCPパケットで使用されます。
This list is surely not exhaustive. Also, the authors do not claim that the suggested extensions (even if using acknowledgements) would not serve a legitimate purpose. We rather want to draw attention to the fact that the same results may be achievable in a way that is architecturally cleaner and conceptually more RTP/RTCP-compliant. The following section contains a first attempt to provide some guidelines on what to consider when thinking about extensions to RTP and RTCP.
このリストは、確かに網羅しているわけではありません。また、著者は提案拡張子が（でも確認応答を使用している場合）、正当な目的を果たしていないだろうと主張しません。私たちは、むしろ同じ結果はアーキテクチャクリーナーと概念的よりRTP / RTCPに準拠した方法で達成できるかもしれないという事実に注意を引きたいです。次のセクションでは、RTPとRTCPの拡張を考える際に考慮すべきかについて、いくつかのガイドラインを提供する最初の試みが含まれています。
Designing RTCP extensions requires consideration of a number of issues, as well as in-depth understanding of the operation of RTP mechanisms. While it is expected that there are many aspects not yet covered by RTCP reporting and operation, quite a bit of functionality is readily available for use. Other mechanisms should probably never become part of the RTP family of specifications, despite the existence of their equivalents in other environments. In the following, we provide some guidance to consider when (and before!) developing an extension to RTCP.
RTCPの拡張を設計することは、多くの問題を考慮し、だけでなく、RTPメカニズムの動作の深い理解が必要です。それはまだRTCP報告および操作でカバーされていない多くの側面があることが予想されるが、機能のかなりのビットは、使用のために容易に利用可能です。他のメカニズムは、おそらく他の環境におけるそれらの等価物が存在するにもかかわらず、仕様のRTPファミリーの一部になることはありません。以下では、RTCPの拡張機能を開発（と前に！）考慮すべきいくつかの指針を提供します。
We begin with a short checklist concerning the applicability of RTCP in the first place:
我々は最初の場所でRTCPの適用性に関する短いチェックリストで始まります。
o Check what can be done with the existing mechanisms, exploiting the information that is already available in RTCP. Is the need for an extension only perceived (e.g., due to lazy implementers, or artificial constraints in endpoints), or is the function or data really not available (or derivable from existing reports)? It is worthwhile remembering that redundant information supplied by a protocol runs the risk of being inconsistent at some point, and various implementations may handle such situations differently (e.g., give precedence to different values). Similarly, there should be exactly one (well-specified) way of performing every function and operation of the protocol.
O RTCPですでに利用可能な情報を利用し、既存のメカニズムで何ができるか確認してください。 （起因するエンドポイントで怠惰な実装、または人工的な制約など、）のみの知覚の拡張の必要性がある、または関数やデータは、（既存のレポートから、または導き出せる）が利用でき、本当にないのですか？これは、（例えば、異なる値に優先権を与える）プロトコルによって供給された冗長情報は、いくつかの点で矛盾しているのリスクを実行し、様々な実装が異なるような状況を処理することができることは価値が覚えています。同様に、プロトコルのすべての機能及び動作を行うの正確に一つ（ウェル指定）方法があるべきです。
o Is the extension applicable to RTP entities running anywhere in the Internet, or is it a link- or environment-specific extension? In the latter cases, local extensions (e.g., header compression, or non-RTP protocols) may be preferable. RTCP should not be used to carry information specific to a particular (access) link.
Oの拡張は、インターネットのどこでも実行されているRTPエンティティに適用可能であり、あるいはそれはリンク - または環境固有の拡張機能ですか？後者の場合には、ローカル拡張（例えば、ヘッダ圧縮、または非RTPプロトコル）が好ましいかもしれません。 RTCPは、特定の（アクセス）リンクに固有の情報を運ぶために使用すべきではありません。
o Is the extension applicable in a group communication environment, or is it specific to point-to-point communications? RTP and RTCP are inherently group communication protocols, and extensions must scale gracefully with increasing group sizes.
oはグループ通信環境において適用可能な拡張機能である、またはそれは、ポイントツーポイント通信に特有のでしょうか？ RTPとRTCPは、本質的にグループ通信プロトコルであり、拡張機能は、グループサイズの増加に伴って優雅に拡張しなければなりません。
From a conceptual viewpoint, the designer of every RTCP extension should ask -- and answer(!) -- at least the following questions:
答える - 概念的な観点から、すべてのRTCP拡張の設計者は、依頼する必要があります - 少なくとも、次の質問を（！）：
o How will this new building block complement and work with the other components of RTCP? Are all interactions fully specified?
Oどのようにこの新しいビルディングブロックの補数とは、RTCPの他のコンポーネントで動作しますか？すべての相互作用は完全に指定されていますか？
o Will this extension work with all different profiles (e.g., the Secure RTP profile [RFC3711], and the extended RTP profile for RTCP-based feedback [RFC4585])? Are any feature interactions expected?
Oするすべての異なるプロファイルを持つこの拡張作業（例えば、セキュアRTPプロファイル[RFC3711]、およびRTCPベースのフィードバックのための拡張RTPプロファイル[RFC4585]）？任意の機能の相互作用が期待されていますか？
o Should this extension be kept in-line with baseline RTP and its existing profiles, or does it deviate so much from the base RTP operation that an incompatible new profile must be defined? Use and definition of incompatible profiles are strongly discouraged, but if they prove necessary, how do nodes using the different profiles interact? What are the failure modes, and how is it ensured that the system fails in a safe manner?
Oこの拡張機能は、ベースラインのRTPとその既存のプロファイルとインライン保つ必要があり、またはそれは互換性のない新しいプロファイルが定義されなければならないことを基本RTP操作からあまり逸脱しませんか？使用して、互換性のないプロファイルの定義が強く推奨されているが、彼らが必要であることが判明した場合、どのノードが異なるプロファイルが相互作用使用していますか？どのような故障モードがあり、それはどのようにシステムが安全な方法で失敗することが保証されますか？
o How does this extension interoperate with other nodes when the extension is not understood by the peer(s)?
拡張がピア（複数可）によって理解されていないときにOどのようにこの拡張は、他のノードと相互運用しますか？
o How will the extension deal with different networking conditions (e.g., how does performance degrade with increases in losses and latency, possibly across orders of magnitude)?
Oどのように異なるネットワーク条件（例えば、どのようにパフォーマンスはおそらく桁違いに渡って、損失と遅延の増加に劣化しない）との延長契約だろうか？
o How will this extension work with group communication scenarios, such as multicast? Will the extensions degrade gracefully with increasing group sizes? What will be the impact on the RTCP report frequency and bitrate allocation?
Oにどのようなマルチキャストなどのグループ通信のシナリオ、この拡張工事？拡張子は、グループの大きさが増加すると正常に低下でしょうか？ RTCPレポート周波数とビットレート配分への影響は何でしょうか？
For the specific design, the following considerations should be taken into account (they're a mixture of common protocol design guidelines, and specifics for RTCP):
特定の設計のために、次の考慮事項は、（彼らは一般的なプロトコルの設計ガイドラインの混合物だし、RTCPのための仕様）を考慮すべきです。
o First of all, if there is (and for RTCP this applies quite often) a mechanism from a different networking environment, don't try to directly recreate this mechanism in RTP/RTCP. The Internet environment is extremely heterogeneous, and will often have drastically different properties and behaviour to other network environments. Instead, ask what the actual semantics and the result required to be perceived by the application or the user are. Then, design a mechanism that achieves this result in a way that is compatible with RTP/RTCP. (And do not forget that every mechanism will break when no packets get through -- the Internet does not guarantee connectivity or performance.)
あればOまず第一に、直接RTP / RTCPでこのメカニズムを再作成しようとしない、異なるネットワーク環境からメカニズム（およびRTCPのために、これはかなり頻繁に適用されます）。インターネット環境は非常に不均一であり、そして多くの場合、他のネットワーク環境に劇的に異なる性質や振る舞いを持つことになります。代わりに、実際の意味と用途によって知覚するために必要な結果やユーザーが何であるかを尋ねます。その後、RTP / RTCPと互換性のある方法でこの結果を達成する機構を設計します。 （そして、パケットが通らないときに、すべてのメカニズムが壊れることを忘れてはいけない - インターネット接続やパフォーマンスを保証するものではありません。）
o Target re-usability of the specification. That is, think broader than a specific use case, and try to solve the general problem in cases where it makes sense to do so. Point solutions need a very good motivation to be dealt with in the IETF in the first place. This essentially suggests developing building blocks whenever possible, allowing them to be combined in different environments than initially considered. Where possible, avoid mechanisms that are specific to particular payload formats, media types, link or network types, etc.
Oターゲットは、仕様書の利用性を再。これは、特定のユースケースよりも広いと思うし、それは感覚がそうすることができます場合は一般的な問題を解決しようとしています。ポイント・ソリューションは、最初の場所でIETFで対処することは非常に良いモチベーションを必要としています。これは本質的に、彼らが最初に考慮さよりも、異なる環境で組み合わせることができるように、できる限りのビルディング・ブロックの開発を示唆しています。可能な場合、など、特定のペイロード・フォーマット、メディアタイプ、リンクまたはネットワークタイプに固有のメカニズムを避けます
o For everything (packet format, value, procedure, timer, etc.) being defined, make sure that it is defined properly, so that independent interoperable implementation can be built. It is not sufficient that you can implement the feature: it has to be implemented in several years by someone unfamiliar with the working group discussion and industry context. Remember that fields need to be both generated and reacted upon, that mechanisms need to be implemented, etc., and that all of this increases the complexity of an implementation. Features that are too complex won't get implemented (correctly) in the first place.
O定義されているすべてのもの（パケットフォーマット、値、手順、タイマーなど）のために、独立した相互運用可能な実装を構築することができるように、それは、適切に定義されていることを確認してください。あなたが機能を実装できることは十分ではない：それはワーキンググループの議論や業界の状況に慣れていない誰かによって、数年後に実装する必要があります。フィールドは機構等、実装する必要があること、の両方が生成され、時に反応させる必要があること、そしてこのすべては実装の複雑さを増加させることを覚えています。複雑すぎる特長は、最初の場所で（正確に）実装されません。
o Extensions defining new metrics and parameters should reference existing standards whenever possible, rather than try to invent something new and/or proprietary.
O新しいメトリックおよびパラメータを定義する拡張機能は、可能な限り既存の標準を参照するのではなく、新しいおよび/または独自の何かを発明しようとする必要があります。
o Remember that not every bit or every action must be represented or signalled explicitly. It may be possible to infer the necessary pieces of information from other values or their evolution (a very prominent example is TCP congestion control). As a result, it may be possible to de-couple bits on the wire from local actions and reduce the overhead.
Oすべてのビットまたはすべてのアクションを表現または明示的にシグナリングされなければならないことに注意してください。それは他の値またはそれらの進化からの情報の必要な部分を推測することも可能である（非常に顕著な例は、TCP輻輳制御です）。その結果、ローカルアクションからワイヤ上のビット・カップルド及びオーバーヘッドを低減することが可能であってもよいです。
o Particularly with media streams, reliability can often be "soft". Rather than implementing explicit acknowledgements, receipt of a hint may also be observed from the altered behaviour (e.g., the reception of a requested intra-frame, or changing the reference frame for video, changing the codec, etc.). The semantics of messages should be idempotent so that the respective message may be sent repeatedly. Requiring hard reliability does not scale with increasing group sizes, and does not degrade gracefully as network performance reduces.
O特にメディアストリームで、信頼性は、多くの場合、「ソフト」することができます。むしろ明示的な肯定応答を実現するよりも、ヒントの受信はまた、変化した動作から観察することができる（例えば、要求されたイントラフレーム、又はコーデックを変更、ビデオのための参照フレームを変更する、などの受信）。メッセージの意味は、それぞれのメッセージが繰り返し送信することができるように、冪等する必要があります。ハード信頼性を要求することは、グループのサイズの増加に伴って拡大しないと、ネットワークのパフォーマンスが低下すると正常に低下しません。
o Choose the appropriate extension point. Depending on the type of RTCP extension being developed, new data items can be transported in several different ways:
O適切な拡張ポイントを選択してください。開発中のRTCP拡張子の種類に応じて、新しいデータ項目は、いくつかの異なる方法で輸送することができます。
* A new RTCP Source Description (SDES) item is appropriate for transporting data that describes the source, or the user represented by the source, rather than the ongoing media transmission. New SDES items may be registered to transport source description information of general interest (see [RFC3550], Section 15), or the PRIV item ([RFC3550], Section 6.5.8) may be used for proprietary extensions.
*新しいRTCPソース記述（SDES）アイテムは、ソース、またはソースで表されるユーザではなく、継続的なメディア伝送を記述するデータを搬送するために適切です。新しいSDESアイテムは（[RFC3550]、セクション15を参照）一般的な関心のソース記述情報を搬送するために登録されていてもよい、またはPRIV項目（[RFC3550]、セクション6.5.8）は、独自の拡張のために使用することができます。
* A new RTCP XR block type is appropriate for transporting new metrics regarding media transmission or reception quality (see [RFC3611], Section 6.2).
*新しいRTCP XRブロックタイプ（[RFC3611]、セクション6.2を参照）メディア送信又は受信品質に関する新たな指標を搬送するのに適しています。
* New RTP profiles may define a profile-specific extension to RTCP SR and/or RR packets, to give additional feedback (see [RFC3550], Section 6.4.3). It is important to note that while extensions using this mechanism have low overhead, they are not backwards compatible with other profiles. Where compatibility is needed, it's generally more appropriate to define a new RTCP XR block or a new RTCP packet type instead.
*新しいRTPプロファイルが追加のフィードバックを与えるために、SRおよび/またはRRパケットをRTCPするプロファイル固有の拡張を定義することができる（[RFC3550]セクション6.4.3を参照）。このメカニズムを使用して拡張子が低いオーバーヘッドを持っていながら、彼らは他のプロファイルとの後方互換性がないことに注意することが重要です。互換性が必要とされている場合、それは新しいRTCP XRブロックまたは代わりに新しいRTCPパケットタイプを定義するために、一般的に、より適切です。
* New RTCP AVPF (Audio-Visual Profile with Feedback) transport-layer feedback messages should be used to transmit general-purpose feedback information that will be generated and processed by the RTP transport. Examples include (negative) acknowledgements for particular packets, or requests to limit the transmission rate. This information is intended to be independent of the codec or application in use (see [RFC4585], Sections 6.2 and 9).
*新しいRTCP AVPF（フィードバック付きオーディオビジュアルプロファイル）トランスポート層フィードバックメッセージはRTP輸送によって生成され、処理される汎用的なフィードバック情報を送信するために使用する必要があります。例としては、（負の）特定のパケットに対する肯定応答、又は伝送レートを制限するための要求を含みます。この情報は、使用中のコーデックやアプリケーションに依存しないように意図されている（[RFC4585]を参照して、セクション6.2および9）。
* New RTCP AVPF payload-specific feedback messages should be used to convey feedback information that is specific to a particular media codec, RTP payload format, or category of RTP payload formats. Examples include video picture loss indication or reference picture selection, which are useful for many video codecs (see [RFC4585], Sections 6.3 and 9).
*新しいRTCP AVPFペイロード特有のフィードバックメッセージは、特定のメディアコーデック、RTPペイロードフォーマット、またはRTPペイロード形式のカテゴリに固有のフィードバック情報を伝えるために使用する必要があります。例としては、多くのビデオコーデックのために有用であるビデオピクチャロス表示又は参照ピクチャ選択を、（セクション6.3および9、[RFC4585]を参照のこと）が挙げられます。
* New RTCP AVPF application layer feedback messages should be used to convey higher-level feedback, from one application to another, above the level of codecs or transport (see [RFC4585], Sections 6.4 and 9).
*新しいRTCP AVPFアプリケーション層フィードバックメッセージは、コーデックまたは輸送のレベル（セクション6.4および9、[RFC4585]を参照）上に、一つのアプリケーションから別のものに、より高いレベルのフィードバックを伝えるために使用されるべきです。
* A new RTCP application-defined, or APP, packet is appropriate for private use by applications that don't need to interoperate with others, or for experimentation before registering a new RTCP packet type ([RFC3550], Section 6.7). It is not appropriate to define a new RTCP APP packet in a standards document: use one of the other extension points, or define a new RTCP packet type instead.
*新しいRTCPアプリケーション定義、またはAPP、パケットは、新しいRTCPパケットタイプ（[RFC3550]、セクション6.7）を登録する前に他の人と、または実験のために相互運用する必要はありませんアプリケーションによって私的使用のために適切です。他の拡張ポイントのいずれかを使用するか、代わりに新しいRTCPパケットタイプを定義します。標準文書に新しいRTCP APPパケットを定義することは適切ではありません。
* Finally, new RTCP packet types may be registered with IANA if none of the other RTCP extension points are appropriate (see [RFC3550], Section 15).
他のRTCP拡張ポイントのどれが適切でない場合*最後に、新しいRTCPパケットタイプは、IANAに登録されてもよい（[RFC3550]、セクション15を参照）。
The RTP framework was designed following the principle of application level framing with integrated layer processing, proposed by Clark and Tennenhouse [ALF]. Effective use of RTP requires that extensions and implementations be designed and built following the same philosophy. That philosophy differs markedly from many previous systems in this space, and making effective use of RTP requires an understanding of those differences.
RTPフレームワークは、クラークとTennenhouse [ALF]によって提案された統合されたレイヤ処理とアプリケーションレベルフレーミングの原理は、以下のように設計しました。 RTPの有効活用は、拡張機能や実装が同じ哲学に従って設計および構築されている必要があります。その哲学は、このスペースでは、多くの従来のシステムとは著しく異なり、RTPを有効活用することは、それらの違いを理解する必要があります。
This memo does not specify any new protocol mechanisms or procedures, and so raises no explicit security considerations. When designing RTCP extensions, it is important to consider the following points: o Privacy: RTCP extensions, in particular new Source Description (SDES) items, can potentially reveal information considered to be sensitive by end users. Extensions should carefully consider the uses to which information they release could be put, and should be designed to reveal the minimum amount of additional information needed for their correct operation.
このメモはどんな新しいプロトコルメカニズムや手順を指定して、その明示的なセキュリティ上の考慮事項を提起しません。プライバシー：O：RTCPの拡張子は、特定の新しいソース説明（SDES）項目では、潜在的にエンドユーザーが敏感であると考えられた情報を明らかにすることができますRTCP拡張を設計するとき、次の点を考慮することが重要です。拡張機能は慎重に、彼らはリリース情報を置くことができ、そしてその正しい操作のために必要な追加情報の最小量を明らかにするように設計すべきな使用を検討すべきです。
o Congestion control: RTCP transmission timers have been carefully designed such that the total amount of traffic generated by RTCP is a small fraction of the media data rate. One consequence of this is that the individual RTCP reporting interval scales with both the media data rate and the group size. The RTCP timing algorithms have been shown to scale from two-party unicast sessions to groups with tens of thousands of participants, and to gracefully handle flash crowds and sudden departures [TimerRecon]. Proposals that modify the RTCP timer algorithms must be careful to avoid congestion, potentially leading to denial of service, across the full range of environments where RTCP is used.
O輻輳制御：RTCP送信タイマーを注意深くRTCPによって生成されたトラフィックの総量は、メディア・データ・レートのごく一部であるように設計されています。このことの1つの結果は、個々のRTCPは、メディア・データ・レートとグループサイズの両方との間隔尺度を報告することです。 RTCPタイミングアルゴリズムは、数十、参加者の何千ものとグループへの2つのパーティのユニキャストセッションから拡張し、そして優雅にフラッシュ群衆と突然の出発[TimerRecon]を処理することが示されています。 RTCPタイマーアルゴリズムを変更する提案は、潜在的にRTCPが使用されている環境の完全な範囲を越え、サービス拒否につながる、混雑を避けるために注意しなければなりません。
o Denial of service: RTCP extensions that change the location where feedback is sent must be carefully designed to prevent denial of service attacks against third-party nodes. When such extensions are signalled, for example in the Session Description Protocol (SDP), this typically requires some form of authentication of the signalling messages (e.g., see the security considerations of [RFC5760]).
Oサービス拒否：フィードバックが送信される場所を変更するRTCPの拡張は慎重に、サードパーティのノードに対するサービス拒否攻撃を防ぐように設計されなければなりません。そのような拡張は、セッション記述プロトコル（SDP）は、例えば、シグナリングされる場合、これは、典型的には、（例えば、[RFC5760]のセキュリティ問題を参照）シグナリングメッセージの認証のいくつかのフォームを必要とします。
The security considerations of the RTP specification [RFC3550] apply, along with any applicable profile (e.g., [RFC3551]).
RTP仕様[RFC3550]のセキュリティ問題は、該当のプロファイル（例えば、[RFC3551]）と一緒に適用されます。
This document has been motivated by many discussions in the AVT WG. The authors would like to acknowledge the active members in the group for providing the inspiration.
この文書では、AVT WGでの多くの議論が動機とされてきました。著者は、インスピレーションを提供するために、グループ内のアクティブなメンバーを承認したいと思います。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[RFC2198]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[RFC3556] Casner、S.、 "セッション記述プロトコル（SDP）RTP制御プロトコル（RTCP）帯域の帯域幅修飾子"、RFC 3556、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T.、カセレス、R.、およびA.クラーク、 "RTP制御プロトコル拡張レポート（RTCP XR）"、RFC 3611、2003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571]ラザロ、J.、RFC 4571、2006年7月 "リアルタイム転送プロトコル（RTP）およびRTP制御プロトコルコネクション型トランスポート・オーバー（RTCP）パケットをフレーミング"。
[RFC4585] 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.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]レイ、J.、レオン、D.、宮崎、A.、Varsa、V.、およびR. Hakenberg、 "RTP再送信ペイロードフォーマット"、RFC 4588、2006年7月。
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.
[RFC5109]李、A.、 "一般的なフォワードエラー訂正のためのRTPペイロードフォーマット"、RFC 5109、2007年12月。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009.
[RFC5506]ヨハンソン、I.およびM.ウェスター、「縮小リアルタイムトランスポート制御プロトコル（RTCP）のサポート：機会と帰結」、RFC 5506、2009年4月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925] Callon、R.、 "十二・ネットワーキング真実"、RFC 1925、1996年4月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5760]オット、J.、チェスターフィールド、J.、およびE.学生、 "ユニキャストフィードバックを有する単一ソースマルチキャストセッションのためにRTP制御プロトコル（RTCP）拡張"、RFC 5760、2010年2月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]パーキンス、C.とM.ウェスター、 "シングルポートの多重化RTPデータおよび制御パケット"、RFC 5761、2010年4月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762]パーキンス、C.、 "RTPデータグラム輻輳制御プロトコル（DCCP）"、RFC 5762、2010年4月。
[ALF] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Proceedings of ACM SIGCOMM 1990, September 1990.
[ALF]クラーク、D.とD. Tennenhouse、 "プロトコルの新世代のための建築に関する注意事項"、ACMのSIGCOMM 1990の議事録、1990年9月。
[TimerRecon] Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration for Enhanced RTP Scalability", Proceedings of IEEE Infocom 1998, March 1998.
[TimerRecon] Schulzrinneと、H.とJ.ローゼンバーグ、 "強化されたRTPスケーラビリティのためのタイマー再考"、IEEEインフォコム1998年、1998年3月の議事。
Authors' Addresses
著者のアドレス
Joerg Ott Aalto University School of Science and Technology Otakaari 5 A Espoo, FIN 02150 Finland
科学技術Otakaari 5のイェルクオットアアルト大学エスポー、FIN 02150フィンランド
EMail: jo@netlab.tkk.fi
メールアドレス：jo@netlab.tkk.fi
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ United Kingdom
コンピューティング科学グラスゴーG12 8QQイギリスのグラスゴー学部のコリンパーキンス大学
EMail: csp@csperkins.org
メールアドレス：csp@csperkins.org