[要約] 要約：RFC 5506は、リアルタイムトランスポート制御プロトコル（RTCP）のサポートに関するものであり、小規模なRTCPパケットの利点と影響について説明しています。目的：このRFCの目的は、小規模なRTCPパケットの使用によるネットワークリソースの節約と、リアルタイム通信の品質向上を実現することです。
Network Working Group I. Johansson
Request for Comments: 5506 M. Westerlund
Updates: 3550, 3711, 4585 Ericsson AB
Category: Standards Track April 2009
Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences
減少するリアルタイム輸送制御プロトコル（RTCP）のサポート：機会と結果
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585.
このメモは、リアルタイムトランスポートプロトコル（RTCP）パケットを縮小サイズで送信できる場合に発生する利点と問題について説明します。RFC 3550で概説されている化合物パケットを作成する方法に関するルールが削除または変更されると、サイズを縮小できます。その分析に基づいて、このメモはルールの特定の変更を定義して、RTP / AVPF（フィードバックを使用してリアルタイムトランスポートプロトコル /オーディオビジュアルプロファイル）プロファイルを使用する場合、特定の条件下で縮小サイズのRTCPパケットとしてフィードバックメッセージを送信することを許可します。（RFC 4585）。このドキュメントは、RFC 3550、RFC 3711、およびRFC 4585を更新します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Use Cases and Design Rationale ..................................4
3.1. RTCP Compound Packets (Background) .........................4
3.2. Use Cases for Reduced-Size RTCP ............................6
3.3. Benefits of Reduced-Size RTCP ..............................7
3.4. Issues with Reduced-Size RTCP ..............................8
3.4.1. Middle Boxes ........................................9
3.4.2. Packet Validation ...................................9
3.4.3. Encryption/Authentication ..........................10
3.4.4. RTP and RTCP Multiplex on the Same Port ............10
3.4.5. Header Compression .................................11
4. Use of Reduced-Size RTCP with AVPF .............................11
4.1. Definition of Reduced-Size RTCP ...........................12
4.2. Algorithm Considerations ..................................12
4.2.1. Verification of Delivery ...........................12
4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13
4.2.3. Enforcing Compound RTCP ............................13
4.2.4. Immediate Feedback Mode ............................14
5. Signaling ......................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgements ...............................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
In RTP [RFC3550] it is currently mandatory to send RTP Control Protocol (RTCP) packets as compound packets containing at least a sender report (SR) or receiver report (RR), followed by a source description (SDES) packet containing at least the CNAME item. There are good reasons for this, as discussed below (see Section 3.1); however, it does result in the minimal RTCP packets being quite large.
RTP [RFC3550]では、少なくとも送信者レポート（SR）またはレシーバーレポート（RR）を含む複合パケットとしてRTPコントロールプロトコル（RTCP）パケットを送信することが現在必須です。cnameアイテム。以下で説明するように、これには正当な理由があります（セクション3.1を参照）。ただし、最小限のRTCPパケットは非常に大きくなります。
The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for feedback messages. Some of these feedback messages would benefit from being transmitted with minimal delay. AVPF provides some mechanisms to support this; however, for environments with low-bitrate links, these messages can still consume a large amount of resources and can introduce extra delay in the time it takes to completely send the compound packet in the network. It is therefore desirable to send just the feedback, without the other parts of a compound RTCP packet. This memo proposes such a mechanism for this and other use cases, as discussed in Section 3.2.
RTP/AVPFプロファイル[RFC4585]は、フィードバックメッセージの新しいRTCPパケットタイプを指定します。これらのフィードバックメッセージの一部は、最小限の遅延で送信されることから恩恵を受けるでしょう。AVPFは、これをサポートするためのいくつかのメカニズムを提供します。ただし、低ビトレートリンクを持つ環境の場合、これらのメッセージは依然として大量のリソースを消費することができ、ネットワーク内のコンパウンドパケットを完全に送信するのにかかる時間に余分な遅延を導入できます。したがって、化合物RTCPパケットの他の部分なしでは、フィードバックのみを送信することが望ましいです。このメモは、セクション3.2で説明したように、このようなメカニズムおよびその他のユースケースを提案しています。
There are a number of benefits with Reduced-Size RTCP; these are discussed in Section 3.3.
縮小されたRTCPには多くの利点があります。これらについては、セクション3.3で説明します。
The use of Reduced-Size RTCP is not without issues. This is discussed in Section 3.4. These issues need to be considered and are part of the motivation for this document.
縮小サイズのRTCPの使用には問題がないわけではありません。これについては、セクション3.4で説明します。これらの問題を考慮する必要があり、このドキュメントの動機の一部です。
Finally, this document defines how AVPF is updated to allow for the transmission of Reduced-Size RTCP in a way that would not substantially affect the mechanisms that compound packets provide; see Section 4 for more details. The connection to AVPF (or SAVPF [RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly beneficial for event-driven feedback purposes and that the AVPF Early RTCP and Immediate Feedback modes make this possible.
最後に、このドキュメントでは、AVPFが更新されて、複合パケットが提供するメカニズムに実質的に影響を与えない方法で、縮小サイズのRTCPの送信を可能にする方法を定義しています。詳細については、セクション4を参照してください。AVPF（またはSAVPF [RFC5124]）への接続は、低サイズのRTCPがイベント駆動型のフィードバック目的で主に有益であり、AVPFの初期RTCPおよび即時フィードバックモードがこれを可能にするという事実によって動機付けられています。
This document updates [RFC3550], [RFC3711], and [RFC4585].
このドキュメントは、[RFC3550]、[RFC3711]、および[RFC4585]を更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The naming convention for RTCP is often confusing. Below is a list of RTCP terms and what they mean. See also Section 6.1 in [RFC3550] and Section 3.1 in [RFC4585] for details.
RTCPの命名規則はしばしば混乱しています。以下は、RTCP用語のリストとその意味です。詳細については、[RFC3550]のセクション6.1および[RFC4585]のセクション3.1も参照してください。
RTCP packet: Can be of different types, contains a fixed header part followed by structured elements depending on RTCP packet type.
RTCPパケット：さまざまなタイプで、固定ヘッダーパーツが含まれていて、RTCPパケットタイプに応じて構造化された要素が続きます。
Lower layer datagram: Can be interpreted as the UDP payload. It may however, depending on the transport, be a TCP or Datagram Congestion Control Protocol (DCCP) payload or something else. Synonymous to the "underlying protocol" defined in Section 3 in [RFC3550].
下層データグラム：UDPペイロードとして解釈できます。ただし、輸送に応じて、TCPまたはDatagramの混雑制御プロトコル（DCCP）ペイロードなどである場合があります。[RFC3550]のセクション3で定義されている「基礎となるプロトコル」と同義。
Compound RTCP packet: A collection of two or more RTCP packets. A compound RTCP packet is transmitted in a lower-layer datagram. It must contain at least an RTCP RR or SR packet and an SDES packet with the CNAME item. Often "compound" is left out, the interpretation of RTCP packet is therefore dependent on the context.
化合物RTCPパケット：2つ以上のRTCPパケットのコレクション。化合物RTCPパケットは、低層データグラムに送信されます。少なくともRTCP RRまたはSRパケットと、CNAMEアイテムを備えたSDESパケットを含める必要があります。多くの場合、「化合物」が除外されているため、RTCPパケットの解釈はコンテキストに依存します。
Minimal compound RTCP packet: A compound RTCP packet that contains the RTCP RR or SR packet and the SDES packet with the CNAME item with a specified ordering.
最小化合物RTCPパケット：指定された注文を備えたCNAMEアイテムを備えたRTCP RRまたはSRパケットとSDESパケットを含む化合物RTCPパケット。
(Full) compound RTCP packet: A compound RTCP packet that conforms to the requirements on minimal compound RTCP packets and contains more RTCP packets.
（FULL）化合物RTCPパケット：最小化合物RTCPパケットの要件に適合し、より多くのRTCPパケットを含む複合RTCPパケット。
Reduced-Size RTCP packet: May contain one or more RTCP packets but does not follow the compound RTCP rules defined in Section 6.1 in [RFC3550] and is thus neither a minimal nor a full compound RTCP. See Section 4.1 for a full definition.
縮小サイズのRTCPパケット：1つ以上のRTCPパケットを含めることができますが、[RFC3550]のセクション6.1で定義されている化合物RTCPルールには従わないため、最小化または完全な化合物RTCPでもありません。完全な定義については、セクション4.1を参照してください。
Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent as a compound RTCP packet consisting of at least two individual RTCP packets, first a sender report (SR) or receiver report (RR), followed by additional packets including a mandatory SDES packet containing a CNAME item for the transmitting source identifier. Below is a short description of what these RTCP packet types are used for.
[RFC3550]のセクション6.1は、RTCPパケットを少なくとも2つの個別のRTCPパケット、最初に送信者レポート（SR）または受信者レポート（RR）で構成される複合RTCPパケットとして送信する必要があることを指定し、その後、必須のSDESを含む追加パケットが続きます。送信ソース識別子のCNAMEアイテムを含むパケット。以下は、これらのRTCPパケットタイプが使用されるものの簡単な説明です。
1. The sender and receiver reports (see Section 6.4 of [RFC3550]) provide the RTP session participant with the synchronization source (SSRC) identifier of all RTP session participants. Having all participants send these packets periodically allows everyone to determine the current number of participants. This information is used in the transmission scheduling algorithm. Thus, this is particularly important for new participants so that they can quickly establish a good estimate of the group size. Failure to do this would result in RTCP senders consuming too much bandwidth.
1. 送信者と受信者レポート（[RFC3550]のセクション6.4を参照）は、RTPセッション参加者にすべてのRTPセッション参加者の同期ソース（SSRC）識別子を提供します。すべての参加者にこれらのパケットを定期的に送信させることで、全員が参加者の現在の数を決定できます。この情報は、送信スケジューリングアルゴリズムで使用されます。したがって、これは新しい参加者にとって特に重要であるため、グループサイズの適切な推定値を迅速に確立できるようにします。これを行わないと、RTCP送信者が帯域幅を消費しすぎるようになります。
2. Before a new session participant has sent any RTP or RTCP packet, it can also avoid SSRC collisions with all the SSRCs it sees prior to that transmission. So the possibility to see a substantial proportion of the participating sources minimizes the risk of any collision when selecting SSRC.
2. 新しいセッションがRTPまたはRTCPパケットを送信する前に、その送信前に見られるすべてのSSRCとのSSRC衝突を回避することもできます。そのため、参加しているソースのかなりの割合を見る可能性は、SSRCを選択する際の衝突のリスクを最小限に抑えます。
3. The sender and receiver reports contain some basic statistics usable for monitoring of the transport and thus enable adaptation. These reports become more useful if sent regularly, as the receiver of a report can perform analyses to find trends between the individual reports. When used for media transmission adaptation, the information becomes more useful the more frequently it is received, at least until one report per round-trip time (RTT) is achieved. Therefore, there is, in most cases, no reason not to include the sender or receiver report in all RTCP packets.
3. 送信者と受信機のレポートには、輸送の監視に使用できる基本的な統計が含まれているため、適応が可能になります。レポートの受信者は分析を実行して個々のレポート間の傾向を見つけることができるため、これらのレポートは定期的に送信された場合、より有用になります。メディア送信の適応に使用されると、少なくとも往復時間（RTT）ごとに1回のレポートが達成されるまで、情報がより頻繁に受信されるほど有用になります。したがって、ほとんどの場合、すべてのRTCPパケットに送信者またはレシーバーレポートを含めない理由はありません。
4. The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists to allow receivers to determine which media flows should be synchronized with each other, both within an RTP session and between different RTP sessions carrying different media types. Thus, it is important to quickly receive this for each media sender in the session when joining an RTP session.
4. CNAME SDES項目（[RFC3550]のセクション6.5.1を参照）は、RTPセッション内とさまざまなメディアタイプを搭載した異なるRTPセッションの両方で、どのメディアフローを相互に同期するかを受信者が決定できるようにするために存在します。したがって、RTPセッションに参加する際に、セッションの各メディア送信者に対してこれをすばやく受信することが重要です。
5. Sender reports (SR) are used in combination with the above SDES CNAME mechanism to synchronize multiple RTP streams, such as audio and video. After having determined which media streams should be synchronized using the CNAME field, the receiver uses the sender report's NTP and RTP timestamp fields to establish synchronization.
5. Sender Reports（SR）は、オーディオやビデオなどの複数のRTPストリームを同期するために、上記のSDES CNAMEメカニズムと組み合わせて使用されます。CNAMEフィールドを使用してどのメディアストリームを同期するかを決定した後、受信者は送信者レポートのNTPおよびRTPタイムスタンプフィールドを使用して同期を確立します。
6. The CNAME SDES item also allows a session participant to detect SSRC collisions and separate them from routing loops. The 32- bit, randomly selected SSRC has some probability of collision. The CNAME is used as the longer canonical identifier of a particular endpoint instance that is bound to an SSRC. If that binding isn't received and kept current, the receiver may not detect an SSRC collision, i.e., two different CNAMEs using the same SSRC. It also can't detect an RTP-level routing loop, with the result that the same SSRC and CNAME arrive from multiple lower-layer source addresses.
6. CNAME SDESアイテムでは、セッション参加者がSSRC衝突を検出し、ルーティングループから分離することもできます。ランダムに選択された32ビットのSSRCには、衝突の確率があります。CNAMEは、SSRCにバインドされている特定のエンドポイントインスタンスの長い標準識別子として使用されます。そのバインディングが受信されず、最新の状態に保たれている場合、受信機はSSRCの衝突、つまり同じSSRCを使用して2つの異なるCNAMEを検出しない場合があります。また、RTPレベルのルーティングループを検出することはできず、その結果、同じSSRCとCNAMEが複数の低層ソースアドレスから到着します。
Reviewing the above, it is obvious that both SR/RR and the CNAME are very important in order for new session participants to be able to utilize any received media and to avoid flooding the network with RTCP reports. In addition, the dynamic nature of the information provided would make it less useful if not sent regularly.
上記のレビューでは、SR/RRとCNAMEの両方が、新しいセッションの参加者が受け入れたメディアを利用し、RTCPレポートでネットワークをあふれさせないようにするために非常に重要であることは明らかです。さらに、提供される情報の動的な性質により、定期的に送信されないと有用性が低くなります。
The following sections will describe the cases when Reduced-Size RTCP is beneficial and will also show the possible issues that must be considered.
次のセクションでは、減少サイズのRTCPが有益であり、考慮しなければならない可能性のある問題も示します。
Below are listed a few use cases for Reduced-Size RTCP.
以下に、縮小サイズのRTCPのいくつかのユースケースがリストされています。
Control Plane Signaling: The Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when transmitting certain events. The OMA PoC service is primarily used over cellular links capable of IP transport, such as the Global System for Mobile Connections (GSM) General Packet Radio Service (GPRS).
コントロールプレーンシグナル伝達：オープンモバイルアライアンス（OMA）Cellular（POC）[OMA-POC]上のプッシュトークトーク[OMA-POC]は、特定のイベントを送信する際に縮小サイズのRTCPを使用します。OMA POCサービスは、主に、モバイル接続用のグローバルシステム（GSM）一般パケットラジオサービス（GPRS）など、IPトランスポートが可能なセルラーリンクで使用されます。
Codec Control Signaling: An example that can be used with Reduced-Size RTCP is, e.g., Temporary Maximum Media Stream Bitrate Request (TMMBR) messages as specified in [RFC5104], which signal a request for a change in codec bitrate. These messages benefit from the usage of Reduced-Size RTCP in bad channel conditions, as Reduced-Size RTCP are much more likely to be successfully transmitted than larger compound RTCP. This is critical, as these messages are likely to occur when channel conditions are poor. Other examples of codec control usage for Reduced-Size RTCP are found in [MTSI-3GPP].
コーデック制御シグナル伝達：縮小サイズのRTCPで使用できる例は、たとえば、[RFC5104]で指定されている一時的な最大メディアストリームビットレートリクエスト（TMMBR）メッセージであり、コーデックビットレートの変更の要求を示しています。低サイズのRTCPは、大きな化合物RTCPよりも正常に送信される可能性がはるかに高いため、これらのメッセージは、低いチャネル条件での減少サイズのRTCPの使用の恩恵を受けます。チャネル条件が悪い場合にこれらのメッセージが発生する可能性が高いため、これは重要です。縮小サイズのRTCPのコーデック制御使用の他の例は、[MTSI-3GPP]に記載されています。
Feedback: An example of a feedback scenario that would benefit from Reduced-Size RTCP is Video streams with generic NACK. In cases where the RTT is shorter than the receiver buffer depth, generic NACK can be used to request retransmission of missing packets, thus improving playout quality considerably. If the generic NACK packets are transmitted as Reduced-Size RTCP, the bandwidth requirement for RTCP will be minimal, enabling more frequent feedback. As in the codec control case, it is important that these packets can be transmitted with as little delay as possible. Another interesting use for Reduced-Size RTCP is in cases when regular feedback is needed, as described in Section 3.3.
フィードバック：減少サイズのRTCPの恩恵を受けるフィードバックシナリオの例は、一般的なNACKを備えたビデオストリームです。RTTが受信機バッファの深さよりも短い場合、ジェネリックNACKを使用して、欠落したパケットの再送信を要求することができ、プレイアウトの品質が大幅に向上します。一般的なNACKパケットが縮小サイズのRTCPとして送信される場合、RTCPの帯域幅要件は最小限になり、より頻繁なフィードバックが可能になります。コーデックコントロールの場合と同様に、これらのパケットをできるだけ遅延させて送信できることが重要です。セクション3.3で説明されているように、縮小サイズのRTCPのもう1つの興味深い用途は、定期的なフィードバックが必要な場合です。
Status Reports: One proposed idea is to transmit small measurement or status reports in Reduced-Size RTCP, and to split the minimal compound RTCP and transmit the individual RTCP separately. The status reports can be used either by the endpoints or by other network monitoring boxes in the network. The benefit is that, with some radio access technologies, small packets are more robust to poor radio conditions than large packets. Additionally, with small (report) packets, there is a smaller risk that the report packets will affect the channel upon which they report. Another benefit is that it is possible, with Reduced-Size RTCP, to allow, for example, anonymous status reporting to be transmitted unencrypted. This is something that may be beneficial, for instance, for network monitoring purposes.
ステータスレポート：提案されているアイデアの1つは、小型のRTCPで小さな測定またはステータスレポートを送信し、最小化合物RTCPを分割し、個々のRTCPを個別に送信することです。ステータスレポートは、エンドポイントまたはネットワーク内の他のネットワーク監視ボックスのいずれかによって使用できます。利点は、一部のラジオアクセステクノロジーでは、小さなパケットが大きなパケットよりも貧弱な無線条件により堅牢であることです。さらに、小さな（レポート）パケットを使用すると、レポートパケットが報告するチャネルに影響を与えるというリスクが小さくなります。別の利点は、たとえば、匿名のステータスレポートを暗号化せずに送信できるようにすることができることです。これは、たとえば、ネットワーク監視の目的で有益なものです。
As mentioned in the introduction, most advantages of using Reduced-Size RTCP packets exist in cases when the available RTCP bitrate is limited. This is because they can become substantially smaller than compound packets. A compound packet is forced to contain both an RR or an SR and the CNAME SDES item. The RR containing a report block for a single source is 32 bytes, an SR is 52 bytes. Both may be larger if they contain report blocks for multiple sources. The SDES packet containing a CNAME item will be 10 bytes plus the CNAME string length. Here, it is reasonable that the CNAME string is at least 10 bytes to get a decent collision resistance. If the recommended form of user@host is used, then most strings will be longer than 20 characters. Thus, a Reduced-Size RTCP can become at least 70-80 bytes smaller than the compound packet.
導入部で述べたように、利用可能なRTCPビットレートが制限されている場合には、縮小サイズのRTCPパケットを使用することのほとんどの利点があります。これは、それらが複合パケットよりもかなり小さくなる可能性があるためです。複合パケットには、RRまたはSRとCNAME SDESアイテムの両方を含めることを余儀なくされます。単一のソースのレポートブロックを含むRRは32バイトで、SRは52バイトです。複数のソースのレポートブロックが含まれている場合、どちらも大きくなる場合があります。CNAMEアイテムを含むSDESパケットは、10バイトとCNAME文字列の長さになります。ここでは、CName文字列が少なくとも10バイトであるため、まともな衝突抵抗を得ることが合理的です。ユーザー@ホストの推奨フォームを使用すると、ほとんどの文字列は20文字より長くなります。したがって、縮小サイズのRTCPは、複合パケットよりも少なくとも70〜80バイトが小さくなる可能性があります。
For low bitrate links, the benefits of this reduction in size are as follows:
低ビットレートリンクの場合、このサイズの削減の利点は次のとおりです。
o For links where the packet-loss rate grows with the packet size, smaller packets are less likely to be dropped. Radio links are an example of such links. In the cellular world, there exist links that are optimized to handle RTP packets sized for carrying compressed speech. This increases the capacity and coverage for voice services in a given wireless network. Minimal compound RTCP packets are commonly 2-3 times the size of an RTP packet carrying compressed speech. If the speech packet over such a bearer has a packet-loss probability of p, then the RTCP packet will experience a loss probability of 1-(1-p)^x, where x is the number of fragments the compound packet will be split into on the link layer, i.e., commonly into 2 or 3 fragments.
o パケットがパケットサイズで成長するリンクの場合、小さなパケットがドロップされる可能性が低くなります。ラジオリンクは、そのようなリンクの例です。セルラーの世界には、圧縮された音声を運ぶためにサイズのRTPパケットを処理するために最適化されたリンクが存在します。これにより、特定のワイヤレスネットワークでの音声サービスの容量とカバレッジが増加します。最小化合物のRTCPパケットは、通常、圧縮音声を運ぶRTPパケットのサイズの2〜3倍です。そのようなベアラー上の音声パケットにPのパケット損失確率がある場合、RTCPパケットには1-（1-p）^xの損失確率が発生します。ここで、xは化合物パケットが分割されるフラグメントの数です。リンク層の上、つまり、一般に2つまたは3つのフラグメントに。
o There is a shorter serialization time, i.e., the time it takes the link to transmit the packet. For slower links, this time can be substantial. For example, transmitting 120 bytes over a link interface capable of 30 kbps takes 32 milliseconds (ms), assuming uniform transmission rate.
o より短いシリアル化時間、つまり、パケットを送信するためにリンクがかかる時間です。遅いリンクの場合、今回はかなりのものになる可能性があります。たとえば、30 kbpsが可能なリンクインターフェイスで120バイトを送信するには、均一な伝送速度を想定して32ミリ秒（MS）がかかります。
In cases when Reduced-Size RTCP carries important and time-sensitive feedback, both shorter serialization time and the lower loss probability are important to enable the best possible functionality. Having a packet-loss rate that is much higher for the feedback packets than the media packets hurts when trying to perform media adaptation to, for example, handle the changed performance present at the cell border in a cellular system.
縮小サイズのRTCPが重要かつ時間依存のフィードバックをもたらす場合、シリアル化時間の短縮と低い損失確率の両方が、可能な限り最良の機能を可能にするために重要です。メディアの適応を実行しようとすると、メディアパケットが痛い場合よりも、フィードバックパケットの方がはるかに高くなるパケットロスレートを持つたとえば、セルラーシステムのセル境界に存在する変化したパフォーマンスを処理しようとすると、痛いです。
For high-bitrate applications, there is usually no problem to supply RTCP with sufficient bitrates. When using AVPF, one can use the "trr-int" parameter to restrict the regular reporting interval to approximately once per RTT or less often. As in most cases, there is little reason to provide regular reports of higher density than this; any additional bandwidth can then be used for feedback messages. The benefit of Reduced-Size RTCP in this case is limited, but exists. One typical example is video using generic NACK in cases where the RTT is low. Using Reduced-Size RTCP would reduce the total amount of bits used for RTCP. This is primarily applicable if the number of reports is large. This would also result in lower processing delay and less complexity for the feedback packets, as they do not need to query the RTCP database to construct the right messages.
高双性アプリケーションの場合、通常、RTCPに十分なビットレートを提供することに問題はありません。AVPFを使用する場合、「TRR-INT」パラメーターを使用して、通常のレポート間隔をRTTごとに約1回以下に制限できます。ほとんどの場合と同様に、これよりも高い密度の定期的なレポートを提供する理由はほとんどありません。その後、追加の帯域幅をフィードバックメッセージに使用できます。この場合の減少サイズのRTCPの利点は限られていますが、存在します。典型的な例の1つは、RTTが低い場合の一般的なNACKを使用したビデオです。縮小サイズのRTCPを使用すると、RTCPに使用されるビットの総量が減少します。これは、レポートの数が多い場合に主に適用されます。また、適切なメッセージを作成するためにRTCPデータベースを照会する必要がないため、フィードバックパケットの処理遅延が低くなり、複雑さが少なくなります。
As message size is generally a smaller issue at higher bitrates, it is also possible to transmit multiple RTCP in each lower-layer datagram in these cases. The motivation behind Reduced-Size RTCP in this case is not size, rather it is to avoid the extra overhead caused by inclusion of the SR/RR and SDES CNAME items in each transmitted RTCP.
メッセージサイズは一般に、より高いビットレートではより小さな問題であるため、これらの場合、各低層データグラムで複数のRTCPを送信することもできます。この場合の減少サイズのRTCPの背後にある動機はサイズではなく、送信された各RTCPにSR/RRおよびSDES CNAMEアイテムを含めることによって引き起こされる追加のオーバーヘッドを避けるためです。
Independently of the link type, there are additional benefits with sending feedback in small Reduced-Size RTCP. Applications that use RTCP AVPF in Early RTCP or Immediate Feedback mode need to send frequent event-driven feedback. Under these circumstances, the risk is reduced that the RTCP bandwidth becomes too high during periods of heavy feedback signaling.
リンクの種類とは無関係に、小規模なRTCPでフィードバックを送信することには追加の利点があります。初期のRTCPまたは即時フィードバックモードでRTCP AVPFを使用するアプリケーションは、頻繁にイベント駆動型のフィードバックを送信する必要があります。これらの状況下では、激しいフィードバックシグナル伝達の期間中にRTCP帯域幅が高すぎるというリスクが低下します。
In cases when regular feedback is needed, such as the profile under development for TCP friendly rate control (TFRC) for RTP [TCP-FRIEND], the size of compound RTCPs can result in very high bandwidth requirements if the round-trip time is short. For this particular application, Reduced-Size RTCP gives a very substantial improvement.
RTP [TCPフレンド]のTCPフレンドリーレート制御（TFRC）の開発中のプロファイルなど、定期的なフィードバックが必要な場合、複合RTCPのサイズは、往復時間が短い場合、非常に高い帯域幅要件をもたらす可能性があります。。この特定のアプリケーションでは、縮小サイズのRTCPが非常に大幅に改善されます。
This section describes the known issues with Reduced-Size RTCP and also provides a brief analysis of their effects and mitigation.
このセクションでは、減少したRTCPの既知の問題について説明し、それらの効果と緩和の簡単な分析についても説明します。
Middle boxes in the network may discard RTCP that do not follow the rules outlined in Section 6.1 of RFC 3550. Newer report types may be interpreted as unknown by the middle box. For instance, if the payload type number is 207 instead of 200 or 201, it may be treated as unknown. The effect of this might, for instance, be that compound RTCP would get through while the Reduced-Size RTCP would be lost.
ネットワーク内の中間ボックスは、RFC 3550のセクション6.1で概説されているルールに従わないRTCPを破棄する場合があります。新しいレポートタイプは、中央のボックスでは不明であると解釈される場合があります。たとえば、ペイロードタイプ数が200または201ではなく207の場合、不明として扱われる場合があります。たとえば、この効果は、化合物のRTCPが通過している間、減少サイズのRTCPが失われる可能性があります。
Verification of the delivery of Reduced-Size RTCP is discussed in Section 4.2.1.
縮小サイズのRTCPの配信の検証については、セクション4.2.1で説明します。
A Reduced-Size RTCP packet will be discarded by the packet validation code in Appendix A of [RFC3550]. This has several impacts:
[RFC3550]の付録Aのパケット検証コードによって、縮小サイズのRTCPパケットが破棄されます。これにはいくつかの影響があります：
Weakened Packet Validation: The packet validation code needs to be rewritten to accept Reduced-Size RTCP. In particular, this affects Section 9.1 in [RFC3550] in the sense that the header verification must take into account that the payload type numbers for the (first) RTCP in the lower-layer datagram may differ from 200 or 201 (SR or RR). One potential effect of this change is much weaker validation that received packets actually are RTCP and not packets of some other type being wrongly delivered. Thus, some consideration should be given to ensure the best possible validation is available, for example, restricting Reduced-Size RTCP to contain only some specific RTCP packet types that are preferably signalled on a per-session basis. However, the application of a security mechanism for source authentication on the packets will provide much stronger protection.
パケット検証の弱体化：パケット検証コードを書き直して、縮小サイズのRTCPを受け入れる必要があります。特に、これはヘッダーの検証が下層データグラムの（最初の）RTCPのペイロードタイプ数が200または201（SRまたはRR）と異なる場合があるという意味で、[RFC3550]のセクション9.1に影響します。。この変更の潜在的な効果の1つは、実際に受信したパケットがRTCPであり、他のタイプのパケットが誤って配信されることではなく、はるかに弱い検証です。したがって、たとえば、可能な限り最良の検証が利用可能であることを保証するためにいくつかの考慮事項を与えられるべきです。たとえば、縮小サイズのRTCPが、セッションごとにシグナルとされる特定のRTCPパケットタイプのみを含むように制限する必要があります。ただし、パケットにソース認証にセキュリティメカニズムを適用すると、はるかに強力な保護が提供されます。
Old RTP Receivers: Any RTCP receiver without an updated packet validation code will discard the Reduced-Size RTCP, which means that the receiver will not see e.g., the contained feedback messages. The effect of this depends on the type of feedback message and the role of the receiver. For example, this may cause complete function loss in the case of attempting to send a Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a non-updated media sender in a session using the retransmission scheme defined by [RFC4588]. This type of discarding would also affect the feedback suppression defined in AVPF. The result would be a partitioning of the receivers within the session, with the old receivers only seeing the compound RTCP feedback messages and the newer ones seeing both. In this case, the old receivers may send feedback messages for events already reported on in Reduced-Size RTCP.
古いRTP受信機：更新されたパケット検証コードのないRTCPレシーバーは、縮小サイズのRTCPを破棄します。つまり、レシーバーには、含まれるフィードバックメッセージが表示されません。この効果は、フィードバックメッセージのタイプと受信機の役割に依存します。たとえば、これは、[REDIZE NACKメッセージ（[RFC4585]のセクション6.2.1を参照）を送信しようとする場合に完全な関数損失を引き起こす可能性があります。RFC4588]。このタイプの破棄は、AVPFで定義されたフィードバック抑制にも影響します。その結果、セッション内の受信機のパーティション化が行われ、古いレシーバーは化合物のRTCPフィードバックメッセージのみが表示され、新しいレシーバーが両方を表示します。この場合、古い受信機は、redicizeのRTCPで既に報告されているイベントのフィードバックメッセージを送信する場合があります。
Bandwidth Considerations: The discarding of Reduced-Size RTCP would affect the RTCP transmission calculation in that the avg_rtcp_size value would become larger than for RTP receivers that exclude the Reduced-Size RTCP in this calculation (assuming that Reduced-Size RTCP are smaller than compound ones). Therefore, these senders would under-utilize the available bitrate and send with a longer interval than updated receivers. For most sessions, this should not be an issue. However, for sessions with a large portion of Reduced-Size RTCP, the updated receivers may time out non-updated senders prematurely. This is, however, not likely to occur, as the time between compound RTCP transmissions needs to become 5 times that used by the Reduced-Size RTCP senders for it to happen.
帯域幅の考慮事項：減少したRTCPの破棄は、AVG_RTCP_SIZE値が、この計算で減少サイズのRTCPを除外するRTP受信機の方が大きくなるという点で、RTCP伝送計算に影響します（減少サイズのRTCPが複合型よりも小さいと仮定すると）。したがって、これらの送信者は、利用可能なビットレートを過小評価し、更新されたレシーバーよりも長い間隔で送信します。ほとんどのセッションでは、これは問題ではありません。ただし、縮小サイズのRTCPの大部分を持つセッションでは、更新されたレシーバーは、更新されていない送信者を早期にタイムアウトする場合があります。ただし、これは発生する可能性は低いです。化合物RTCP送信の間の時間は、それが発生するために縮小サイズのRTCP送信者が使用する5倍になる必要があるためです。
Computation of avg_rtcp_size: Long intervals between compound RTCP with many Reduced-Size RTCP in between may lead to a computation of a value for avg_rtcp_size that varies greatly over time. Investigation shows that although it varies, this is not enough of a problem to warrant further changes or complexities to the RTCP scheduling algorithm.
AVG_RTCP_SIZEの計算：複合RTCPの間の長い間隔では、多くの縮小サイズのRTCPが間にある可能性があります。AVG_RTCP_SIZEの値は、時間とともに大きく異なります。調査によると、それは異なりますが、これはRTCPスケジューリングアルゴリズムのさらなる変更または複雑さを保証するのに十分ではないことを示しています。
The Secure Real-time Transport Protocol (SRTP) presents a problem for Reduced-Size RTCP. Section 3.4 of [RFC3711] states, "SRTCP MUST be given packets according to that requirement in the sense that the first part MUST be a sender report or a receiver report".
安全なリアルタイムトランスポートプロトコル（SRTP）は、縮小サイズのRTCPの問題を提示します。[RFC3711]のセクション3.4は、「最初の部分が送信者レポートまたは受信者レポートでなければならないという意味で、その要件に従ってSRTCPにパケットを与えなければならない」と述べています。
Upon examination of how SRTP processes packets, it becomes obvious that SRTP has no real dependency on whether the first packet is an SR or an RR packet. What is needed is the common RTCP packet header, which is present in all the packet types, with a source SSRC. The conclusion is therefore that it is possible to use Reduced-Size RTCP with SRTP. Nevertheless, as this implies a change to the rules in [RFC3711], changes in SRTP implementations MAY become necessary.
SRTPがパケットをどのように処理するかを調べると、SRTPが最初のパケットがSRパケットかRRパケットであるかに実際の依存性がないことが明らかになります。必要なのは、ソースSSRCを備えたすべてのパケットタイプに存在する一般的なRTCPパケットヘッダーです。したがって、結論は、SRTPを使用して減少サイズのRTCPを使用することが可能であるということです。それにもかかわらず、これは[RFC3711]のルールの変更を意味するため、SRTP実装の変更が必要になる場合があります。
In applications in which multiplex RTP and RTCP are on the same port, as defined in [MULTI-RTP], care must be taken to ensure that de-multiplexing is done properly even though the RTCP packets are reduced size. The downside of Reduced-Size RTCP is that more values representing RTCP packets exist, reducing the available RTP payload type space. However, Section 4 in [MULTI-RTP] already requires the corresponding RTP payload type range not be used when performing this multiplexing.
[Multi-RTP]で定義されているように、Multiplex RTPとRTCPが同じポートにあるアプリケーションでは、RTCPパケットのサイズが縮小されていても、脱マルグレックスが適切に行われるように注意する必要があります。縮小サイズのRTCPのマイナス面は、RTCPパケットを表す値が多いため、利用可能なRTPペイロードタイプのスペースが減少することです。ただし、[Multi-RTP]のセクション4では、この多重化を実行するときに使用されない対応するRTPペイロードタイプの範囲を既に要求しています。
Two issues are related to header compression. Possible changes are left for future work:
2つの問題は、ヘッダー圧縮に関連しています。将来の作業のために可能な変更が残されています：
o Payload type number identification: The Robust Header Compression (RoHC) algorithm [RFC3095] needs to create different compression contexts for RTP and RTCP for optimum performance. If RTP and RTCP are multiplexed on the same port, the classification may be based on payload type numbers. The classification algorithm must here acknowledge the fact that the payload type number for (the first) RTCP may differ from 200 or 201.
o ペイロードタイプ番号識別：ロバストヘッダー圧縮（ROHC）アルゴリズム[RFC3095]は、最適なパフォーマンスのためにRTPとRTCPの異なる圧縮コンテキストを作成する必要があります。RTPとRTCPが同じポートで多重化されている場合、分類はペイロードタイプ番号に基づいている場合があります。分類アルゴリズムは、（最初の）RTCPのペイロードタイプ数が200または201と異なる可能性があるという事実をここで認める必要があります。
o Compression of RTCP: No IETF-defined header compression method compress RTCP; however, if such methods are developed in the future, these methods must take Reduced-Size RTCP in account.
o RTCPの圧縮：IETF定義のヘッダー圧縮法は、RTCPを圧縮しません。ただし、そのような方法が将来開発されている場合、これらの方法は縮小サイズのRTCPを考慮する必要があります。
Based on the above analysis, it seems feasible to allow transmission of Reduced-Size RTCP under some restrictions:
上記の分析に基づいて、いくつかの制限の下で縮小サイズのRTCPの送信を許可することが可能であると思われます。
o First of all, it is important that compound RTCPs are transmitted at regular intervals to ensure that the mechanisms maintained by the compound packets, like feedback reporting, work. The tracking of session size and number of participants warrants mentioning again, as this ensures that the RTCP bandwidth remains bounded independent of the number of session participants.
o まず第一に、化合物RTCPを定期的に送信して、フィードバックレポートなどの化合物パケットによって維持されるメカニズムを確保することが重要です。セッションサイズと参加者の数の追跡は、RTCP帯域幅がセッション参加者の数とは無関係に境界を獲得したままであることを保証するため、再び言及する必要があります。
o Second, as the compound RTCP packets are also used to establish and maintain synchronization between media, any newly joining participant in a session would need to receive compound RTCP from the media sender(s).
o 第二に、化合物RTCPパケットもメディア間の同期を確立および維持するために使用されるため、セッションに新たに参加する参加者は、メディア送信者から複合RTCPを受信する必要があります。
This implies that the regular transmission of compound RTCP MUST be maintained throughout an RTP session. Reduced-Size RTCP SHOULD be restricted to be used as extra RTCP (e.g., feedback), sent in cases when a regular compound RTCP packet would not otherwise have been sent.
これは、化合物RTCPの定期的な伝送をRTPセッション全体で維持する必要があることを意味します。縮小サイズのRTCPは、通常の化合物RTCPパケットが送信されなかった場合に送信される追加のRTCP（フィードバックなど）として使用するように制限する必要があります。
The usage of Reduced-Size RTCP SHALL only be done in RTP sessions operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or Immediate Feedback mode. Reduced-Size RTCP SHALL NOT be sent until at least one compound RTCP has been sent. In Immediate Feedback mode, all feedback messages MAY be sent as Reduced-Size RTCP. In Early RTCP mode, a feedback message scheduled for transmission as an Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size RTCP. All RTCP that are scheduled for transmission as Regular RTCP SHALL be sent as compound RTCP as indicated by AVPF [RFC4585].
縮小サイズのRTCPの使用は、AVPF [RFC4585]またはSAVPF [RFC5124]の初期RTCPまたは即時フィードバックモードで動作するRTPセッションでのみ行われます。縮小サイズのRTCPは、少なくとも1つの化合物RTCPが送信されるまで送信してはなりません。即時フィードバックモードでは、すべてのフィードバックメッセージが減少したRTCPとして送信される場合があります。初期のRTCPモードでは、初期のRTCPとして送信が予定されているフィードバックメッセージ、つまり通常のRTCPではなく、縮小サイズのRTCPとして送信できます。通常のRTCPとして伝送が予定されているすべてのRTCPは、AVPF [RFC4585]で示されるように、化合物RTCPとして送信されます。
A Reduced-Size RTCP packet is an RTCP packet with the following properties that make it deviate from the compound RTCP packet definition given in Section 6.1 in [RFC3550]:
縮小サイズのRTCPパケットは、[RFC3550]のセクション6.1に与えられた化合物RTCPパケット定義から逸脱する次のプロパティを備えたRTCPパケットです。
o contains one or more RTCP packet(s)
o 1つ以上のRTCPパケットが含まれています
o allows any RTCP packet type; however, see Section 4.2.1
o RTCPパケットタイプを許可します。ただし、セクション4.2.1を参照してください
o MUST NOT be used for Regular (scheduled) RTCP report purposes
o 定期的な（スケジュールされた）RTCPレポートの目的に使用しないでください
o MUST NOT be used with the RTP/AVP profile [RFC3551] or the RTP/SAVP profile [RFC3711]
o RTP/AVPプロファイル[RFC3551]またはRTP/SAVPプロファイル[RFC3711]で使用しないでください
If an application is to use Reduced-Size RTCP, it is important to verify that the Reduced-Size RTCP packets actually reach the session participants. As outlined above in Section 3.4.1 and Section 3.4.2, packets may be discarded along the path or in the endpoint.
アプリケーションが縮小サイズのRTCPを使用する場合、縮小サイズのRTCPパケットが実際にセッション参加者に到達することを確認することが重要です。上記のセクション3.4.1およびセクション3.4.2で概説したように、パケットまたはエンドポイントにパケットが破棄される場合があります。
A few verification rules are RECOMMENDED to ensure robust RTCP transmission and reception and to solve the identified issues when Reduced-Size RTCP is used:
堅牢なRTCPの送信と受信を確保し、縮小サイズのRTCPを使用した場合に特定された問題を解決するために、いくつかの検証ルールが推奨されます。
o The endpoint issue can be solved by introducing signaling that informs if all session participants are capable of Reduced-Size RTCP. See Section 5.
o エンドポイントの問題は、すべてのセッション参加者が縮小されたRTCPが可能かどうかを通知するシグナルを導入することで解決できます。セクション5を参照してください。
o The middle box issue is more difficult, and here one will be required to use heuristics to determine whether or not the Reduced-Size RTCP packets are delivered. The method used to detect successful delivery of Reduced-Size RTCP packets depends on the packet type. The RTCP packet types for which successful delivery can be detected are:
o ミドルボックスの問題はより困難であり、ここでは、ヒューリスティックを使用して、減少サイズのRTCPパケットが配信されるかどうかを判断する必要があります。縮小サイズのRTCPパケットの配信の成功を検出するために使用される方法は、パケットタイプに依存します。配信が成功することができるRTCPパケットタイプは次のとおりです。
* Sender reports (SR): Successful transmission of a sender report can be verified by inspection of the echoed timestamp in the received receiver report (RR). This can also be used as a method to verify if Reduced-Size RTCP can be used at all.
* Sender Reports（SR）：送信者レポートの成功した送信は、受信したレシーバーレポート（RR）のエコーされたタイムスタンプの検査により検証できます。これは、縮小サイズのRTCPをまったく使用できるかどうかを検証する方法としても使用できます。
* Feedback RTCP packets: In many cases, the feedback messages sent using Reduced-Size RTCP will result in either explicit or implicit indications that they have been received. An example of this is the RTP retransmission [RFC4588] that results from a NACK message [RFC4585]. Another example is the Temporary Maximum Media Stream Bitrate Notification (TMMBN) message resulting from a Temporary Maximum Media Stream Bitrate Request (TMMBR) [RFC5104]. A third example is the presence of a decoder refresh point [RFC5104] in the video media stream resulting from the Full Intra Request that was sent.
* フィードバックRTCPパケット：多くの場合、縮小サイズのRTCPを使用して送信されたフィードバックメッセージは、それらが受信されたという明示的または暗黙的な兆候のいずれかをもたらします。この例は、NACKメッセージ[RFC4585]に起因するRTP再送信[RFC4588]です。もう1つの例は、一時的な最大メディアストリームビットレートリクエスト（TMMBR）[RFC5104]に起因する一時的な最大メディアストリームビットレート通知（TMMBN）メッセージです。3番目の例は、送信された完全なリクエストに起因するビデオメディアストリームにデコーダーリフレッシュポイント[RFC5104]の存在です。
RTCP packet types for which it is not possible to detect successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP packets unless they are transmitted in the same lower-layer datagram as another RTCP packet type for which successful delivery can be detected.
成功した配信を検出できないRTCPパケットタイプは、成功した配信を検出できる別のRTCPパケットタイプと同じ低層データグラムで送信されない限り、縮小サイズのRTCPパケットとして送信すべきではありません。
o An algorithm to detect consistent failure of delivery of Reduced-Size RTCP MUST be used by any application using Reduced-Size RTCP. The details of this algorithm are application dependent and therefore outside the scope of this document.
o 縮小されたRTCPを使用して、任意のアプリケーションで、縮小サイズのRTCPの一貫した障害を検出するアルゴリズムを使用する必要があります。このアルゴリズムの詳細は、アプリケーションに依存するため、このドキュメントの範囲外です。
If the verification fails, it is strongly RECOMMENDED that only compound RTCP, according to the rules outlined in RFC 3550, is transmitted.
検証が失敗した場合、RFC 3550で概説されているルールに従って、複合RTCPのみが送信されることを強くお勧めします。
The result of the definition in Section 4.1 may be that the resulting size of Reduced-Size RTCP can become larger than a regularly scheduled compound RTCP packet. For applications that use access types that are sensitive to packet size (see Paragraph 2 in Section 3.3), it is strongly RECOMMENDED that the use of Reduced-Size RTCP is limited to the transmission of a single RTCP packet in each lower-layer datagram. The method to determine the need for this is outside the scope of this document.
セクション4.1の定義の結果は、結果として得られる縮小サイズのRTCPのサイズが、定期的にスケジュールされた化合物RTCPパケットよりも大きくなる可能性がある可能性があります。パケットサイズに敏感なアクセスタイプを使用するアプリケーション（セクション3.3のパラグラフ2を参照）の場合、縮小サイズのRTCPの使用は、各低層データグラムの単一のRTCPパケットの送信に限定されることを強くお勧めします。これの必要性を判断する方法は、このドキュメントの範囲外です。
In general, as the benefit with large Reduced-Size RTCP packets is very limited, it is strongly RECOMMENDED to transmit large Reduced-Size RTCP packets as compound RTCP packets instead.
一般に、大規模な縮小サイズのRTCPパケットを使用する利点は非常に限られているため、代わりに大規模な縮小サイズのRTCPパケットをコンパウンドRTCPパケットとして送信することを強くお勧めします。
As discussed earlier, it is important that the transmission of compound RTCP occurs at regular intervals. However, this will occur as long as the RTCP senders follow the AVPF scheduling algorithm defined in Section 3.5 of [RFC4585]. This follows as all Regular RTCP MUST be full compound RTCP. Note that there is also a requirement on sending Regular RTCP in Immediate Feedback mode.
前述のように、化合物RTCPの伝達を定期的に発生することが重要です。ただし、これは、RTCP送信者が[RFC4585]のセクション3.5で定義されているAVPFスケジューリングアルゴリズムに従う限り発生します。これは、すべての通常のRTCPが完全な化合物RTCPでなければならないため、続きます。通常のRTCPを即時フィードバックモードで送信することにも要件があることに注意してください。
Section 3.3 of [RFC4585] gives the option to use AVPF Immediate Feedback mode as long as the group size is below a certain limit. As transmissions using Reduced-Size RTCP may reduce the bandwidth demand, such transmissions also open up the possibility of a more liberal use of Immediate Feedback mode.
[RFC4585]のセクション3.3は、グループサイズが特定の制限を下回っている限り、AVPF即時フィードバックモードを使用するオプションを提供します。縮小サイズのRTCPを使用したトランスミッションは帯域幅の需要を減らす可能性があるため、このような送信は、即時フィードバックモードのよりリベラルな使用の可能性も開かれます。
This document defines the "a=rtcp-rsize" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the session participant is capable of supporting Reduced-Size RTCP for applications that use SDP for configuration of RTP sessions. It is REQUIRED that a participant that proposes the use of Reduced-Size RTCP shall itself support the reception of Reduced-Size RTCP.
このドキュメントでは、「a = rtcp-rsize」セッション説明プロトコル（SDP）[RFC4566]属性を定義して、セッション参加者がRTPセッションの構成にSDPを使用するアプリケーションにdeden-size RTCPをサポートできるかどうかを示します。縮小サイズのRTCPの使用を提案する参加者自体が、縮小サイズのRTCPの受信をサポートすることが必要です。
An offering client that wishes to use Reduced-Size RTCP MUST include the attribute "a=rtcp-rsize" in the SDP offer. If "a=rtcp-rsize" is present in the offer SDP, the answerer that supports Reduced-Size RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute in the answer.
縮小サイズのRTCPの使用を希望するオファリングクライアントには、SDPオファーに属性「a = rtcp-rsize」を含める必要があります。「a = rtcp-rsize」がオファーSDPに存在する場合、減少サイズのRTCPをサポートし、それを使用することを希望する回答者には、回答に「a = rtcp-rsize」属性が含まれます。
In declarative usage of SDP, such as the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) [RFC2974], the presence of the attribute indicates that the session participant MAY use Reduced-Size RTCP packets in its RTCP transmissions.
リアルタイムストリーミングプロトコル（RTSP）[RFC2326]やセッションアナウンスプロトコル（SAP）[RFC2974]などのSDPの宣言的使用法では、属性の存在は、セッション参加者がその削減されたサイズのRTCPパケットを使用する可能性があることを示しています。RTCP送信。
The security considerations of RTP [RFC3550] and AVPF [RFC4585] will apply also to Reduced-Size RTCP. The reduction in validation strength for received packets on the RTCP port may result in a higher degree of acceptance of spurious data as real RTCP. This vulnerability can mostly be addressed by usage of any security mechanism that provides authentication; one such mechanism is SRTP [RFC3711].
RTP [RFC3550]およびAVPF [RFC4585]のセキュリティ上の考慮事項は、縮小サイズのRTCPにも適用されます。RTCPポートの受信パケットの検証強度の低下により、実際のRTCPとして偽のデータがより高い程度の受け入れが生じる可能性があります。この脆弱性は、認証を提供するセキュリティメカニズムの使用によって主に対処できます。そのようなメカニズムの1つはSRTP [RFC3711]です。
Following the guidelines in [RFC4566], the IANA has registered a new SDP attribute: o Contact name, email address, and telephone number: Authors of RFC 5506
[RFC4566]のガイドラインに従って、IANAは新しいSDP属性を登録しました：o連絡先名、メールアドレス、電話番号：RFC 5506の著者
o Attribute-name: rtcp-rsize
o 属性名：rtcp-rsize
o Long-form attribute name: Reduced-Size RTCP
o ロングフォーム属性名：redced-size RTCP
o Type of attribute: media-level
o 属性のタイプ：メディアレベル
o Subject to charset: no
o charsetの対象：いいえ
This attribute defines the support for Reduced-Size RTCP, i.e., the possibility to transmit RTCP that does not conform to the rules for compound RTCP defined in RFC 3550. It is a property attribute, which does not take a value.
この属性は、RFC 3550で定義されている化合物RTCPのルールに準拠していないRTCPを送信する可能性を減少したRTCPのサポートを定義します。これは、値をとらないプロパティ属性です。
The authors would like to thank all the people who gave feedback on this document. Special thanks go to Colin Perkins.
著者は、この文書についてフィードバックをしたすべての人々に感謝したいと思います。Colin Perkinsに感謝します。
This document also contains some text copied from [RFC3550], [RFC4585], and [RFC3711]. We take this opportunity to thank the authors of said documents.
このドキュメントには、[RFC3550]、[RFC4585]、および[RFC3711]からコピーされたテキストも含まれています。この機会を利用して、上記の文書の著者に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124] OTT、J。およびE. Carrara、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック（RTP/SAVPF）のセキュアRTPプロファイル拡張」、RFC 5124、2008年2月。
[MTSI-3GPP] 3GPP, "Specification : 3GPP TS 26.114 (v8.2.0 or later), http://www.3gpp.org/ftp/Specs/html-info/ 26-series.htm", March 2007.
[MTSI-3GPP] 3GPP、 "仕様：3GPP TS 26.114（v8.2.0以降）、http：//www.3gpp.org/ftp/specs/html-info/ 26-series.htm"、2007年3月。
[MULTI-RTP] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", Work in Progress, August 2007.
[Multi-RTP] Perkins、C。およびM. Westerlund、「単一のポートのRTPデータと制御パケットを多重化」、2007年8月の作業。
[OMA-PoC] Open Mobile Alliance, "Specification : Push to talk Over Cellular User Plane, http:// member.openmobilealliance.org/ftp/public_documents/poc/ Permanent_documents/ OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip", November 2006.
[OMA-POC]オープンモバイルアライアンス、「仕様：携帯電話のユーザープレーン、http：// member.openmobilealliance.org/ftp/public_documents/poc/ permanage_documents/oma-ts-poc_userplane-v2_0-20080507-c。zip "、2006年11月。
[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月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[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、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、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月。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）のコーデックコントロールメッセージ」、2008年2月。
[TCP-FRIEND] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007.
[TCPフレンド] Gharai、L。、「TCPフレンドリーレートコントロールを備えたRTP」、2007年7月の作業。
Authors' Addresses
著者のアドレス
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN
Ingemar Johansson Ericsson AB LaboratorieGrand 11 SE-971 28 Lulea Sweden
Phone: +46 73 0783289
EMail: ingemar.s.johansson@ericsson.com
Magnus Westerlund Ericsson AB Faeroegatan 6 SE-164 80 Stockholm SWEDEN
マグナスウェスターランドエリクソンab faeroegatan 6 Se-164 80ストックホルムスウェーデン
Phone: +46 10 7148287
EMail: magnus.westerlund@ericsson.com