[要約] RFC 5968は、RTP制御プロトコル（RTCP）の拡張に関するガイドラインです。その目的は、RTCPの機能を拡張し、新しい機能や要件をサポートするための指針を提供することです。
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)
RTP制御プロトコル（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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ライセンステキストを含める必要があります。
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、Datagram Transport Layer Security（DTLS）、またはDatagram混雑制御プロトコル（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.
「RTP：リアルタイムアプリケーションのためのトランスポートプロトコル」[RFC3550]、「最小制御を備えたオーディオおよびビデオ会議のRTPプロファイル」[RFC3551]、および「RTCPの拡張RTPプロファイル（RTCP）で定義されている用語） - ベースのフィードバック（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のネットワーキングの真実の1つは、「プロトコルの設計では、追加するものが残っていないときではなく、奪うものが残っていないときに完璧に達しました」と述べています。これは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]、セッション説明のRTCP帯域幅修飾子[RFC3556]、タイムリーなフィードバック拡張（RFC 4585）、およびソース特有のマルチカスト（SSM）ネットワークの供給源（SSM）を超えるRTCPを超える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の動作に影響しません。RTCPは、ユニキャスト輸送（TCP [RFC4571]やDCCP [RFC5762]など）を実行してもグループ通信プロトコルのままであり、その低価格の相対的な相対的なコントロールの影響をほとんど受けないため、使用されている輸送プロトコルもほとんど影響を与えません。メディアに。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オーバー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）を計算できます。この値は時間の経過とともに監視できるため、粗粒性の傾向を推測するために使用できます。[RFC3611]によって同様のメカニズムが提供され、受信機がRTTを送信者に計算できるようにします。
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、Tは5秒、または360秒をキロビット/秒のセッション帯域幅で割った360秒（72 kbits/ sを超える帯域幅で5秒以下の間隔を与えます）[RFC3550]。
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ごとに1回の順になるはずです）のためにTCPに優しい混雑制御の目的では不十分ですが、それでも時間の遅い時間の帯域幅に適応するために使用できます。 - スケール。
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 Acksとは異なり、すべての（他の）パケットに応じて送信できる場合、時折フィードバックを提供するように設計されています。パケットごとのフィードバックは提供されません（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を決定することに限定されています。この推論は、RTPとRTCPが等しく扱われるという暗黙の仮定を作成します。それらは同じパスに沿ってルーティングされ、同じ（diffserv）トラフィッククラスにマッピングされ、同じ公正なキューイング分類の一部として扱われます。これは多くの場合に当てはまります。ただし、RTPとRTCPは通常、異なるポートを使用して送信されるため、5タプル（ソースおよび宛先IPアドレス、ソースおよび宛先ポート番号、および輸送プロトコルの）に基づくフロー分類は、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またはRTPよりもRTPを使用することをお勧めしますが、ネットワークパフォーマンスのこの推論を可能にするために、可能な場合は同一に扱うことをお勧めします。、したがって、アプリケーションの適応をサポートします。
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拡張機能のみを定義するか、主にユニキャスト2パーティセッションのために。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.
o RTCPレポートの信頼できる配信が必要です。謝辞を使用して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 ヒントを与えるのではなく、コマンドを発行します。RTCPは、RTPエンティティ間で観察結果を報告することです。リモート側にアクションを引き起こすには、何らかの形の信頼性が必要であり（上記参照）、アドヒアランスを検証することはできません。
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.
o RTCPレポートを拡大して、ネットワーク管理ツールとして使用します。RTCPは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）がある場合、これは明らかに不可能です暗号化された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ですでに利用可能な情報を利用してください。拡張機能のみが認識されているのは（例えば、怠zyな実装者、またはエンドポイントの人為的制約による）、または関数またはデータが実際には利用できない（または既存のレポートから派生可能）か？プロトコルによって提供される冗長な情報は、ある時点で一貫性がないというリスクがあることを覚えておく価値があり、さまざまな実装がそのような状況を異なる方法で処理する可能性があります（例えば、異なる値に優先される）。同様に、プロトコルのすべての機能と動作を実行する（適切に指定された）方法が1つある必要があります。
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 まず第一に、別のネットワーキング環境からのメカニズムがある場合（およびRTCPが非常に頻繁に適用される場合）、RTP/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プロファイルは、RTCP SRおよび/またはRRパケットのプロファイル固有の拡張機能を定義して、追加のフィードバックを提供する場合があります（[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ペイロード形式のカテゴリに固有のフィードバック情報を伝えるために使用する必要があります。例には、多くのビデオコーデックに役立つビデオ画像の損失表示または参照画像の選択が含まれます（[RFC4585]、セクション6.3および9を参照）。
* 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アプリケーションレイヤーフィードバックメッセージは、コーデックまたはトランスポートのレベルを超える高レベルのフィードバックを別のアプリケーションから別のアプリケーションに伝えるために使用する必要があります（[RFC4585]、セクション6.4および9を参照）。
* 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パケットタイプを定義します。
* 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フレームワークは、Clarkと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.
このメモは、新しいプロトコルメカニズムや手順を指定していないため、明示的なセキュリティ上の考慮事項を提起しません。RTCP拡張機能を設計する場合、次のポイントを検討することが重要です。Oプライバシー：RTCP拡張機能、特に新しいソース説明（SDES）アイテムは、エンドユーザーが敏感であると考えられる情報を明らかにする可能性があります。拡張機能は、リリースされる情報を配置できる使用法を慎重に検討し、正しい操作に必要な追加情報を最小限に供給するように設計する必要があります。
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] Perkins、C.、Kouvelas、I.、Hodson、O.、Hardman、V.、Handley、M.、Bolot、J.、Vega-Garcia、A。、およびS. Fosse-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.、Rao、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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[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] Friedman、T.、Caceres、R。、およびA. Clark、「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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] Lazzaro、J。、「接続指向の輸送上のリアルタイム輸送プロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットのフレーミング」、RFC 4571、2006年7月。
[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] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張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] Rey、J.、Leon、D.、Miyazaki、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] Li、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] Johansson、I。およびM. Westerlund、「低サイズのリアルタイム輸送制御プロトコル（RTCP）のサポート：機会と結果」、RFC 5506、2009年4月。
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996.
[RFC1925] Callon、R。、「Twelve Networking Truths」、RFC 1925、1996年4月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、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] Ott、J.、Chesterfield、J。、およびE. Schooler、「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] Perkins、C。およびM. Westerlund、「単一のポートのRTPデータと制御パケットを多重化」、RFC 5761、2010年4月。
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, April 2010.
[RFC5762] Perkins、C。、「RTPおよびThe Datagram輻輳制御プロトコル（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] Clark、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. Rosenberg、「RTPスケーラビリティの強化のためのタイマーの再考」、IEEE Infocom 1998の議事録、1998年3月。
Authors' Addresses
著者のアドレス
Joerg Ott Aalto University School of Science and Technology Otakaari 5 A Espoo, FIN 02150 Finland
Joerg Ott Aalto University School of Science and Technology Otakaari 5 A Espoo、Fin 02150フィンランド
EMail: jo@netlab.tkk.fi
Colin Perkins University of Glasgow Department of Computing Science Glasgow G12 8QQ United Kingdom
コリンパーキンスグラスゴー大学コンピューティング科学科学科学G12 8QQイギリス
EMail: csp@csperkins.org