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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
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]には少なくとも含有するソース記述（SDES）パケットに続く少なくともセンダレポート（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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の用語とその意味のリストです。また、詳細については、[RFC4585]の[RFC3550]でセクション6.1および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またはデータグラム輻輳制御プロトコル（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パケット：RTCPのRRまたはSRパケットと指定された順序でCNAMEアイテムと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.
（フル）化合物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パケットが必須SDES含む追加のパケットに続く最初の送信者レポート（SR）またはレシーバレポート（RR）、少なくとも二つの個々のRTCPパケットからなる複合RTCPパケットとして送信されなければならないことを指定します送信元識別子の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セッションの参加者の同期ソース（SSRC）識別子とRTPセッションの参加者を提供しています。すべての参加者が定期的にこれらのパケットを送信持つことは、誰もが参加者の現在の数を決定することができます。この情報は、送信スケジューリングアルゴリズムで使用されています。彼らはすぐにグループサイズの良好な推定値を確立することができるようにこのように、これは新しい参加者のために特に重要です。これを行うに失敗すると、あまりにも多くの帯域幅を消費する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パケットを送信した前に、それはまた、その送信前に見ているすべてのSSRCsと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）ごとにレポートが達成される、少なくともまで、より便利になります。したがって、すべての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.
前記送信者レポート（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を使用して、すなわち、二つの異なるのCNAMEをSSRC衝突を検出しなくてもよいです。また、同じSSRC及びCNAMEは、複数の下位層の送信元アドレスから到着その結果、RTPレベルのルーティングのループを検出することができません。
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）はプッシュ・ツー・トークセルラー（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のためのもう一つの興味深い使用は、例です。
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.
ステータスレポート：一つの提案アイデアは縮小RTCPの小さな測定やステータスレポートを送信するために、最小限の化合物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は、SRが52バイト、32バイトです。彼らは複数のソースのレポートブロックが含まれている場合の両方が大きくなることがあります。 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を使用する場合は、1が約一回RTTあたり以下、多くの場合に定期的な報告の間隔を制限するために、「TRR-INT」パラメータを使用することができます。ほとんどの場合のように、これよりも高い密度の定期的なレポートを提供する理由はほとんどありません。任意の追加の帯域幅は、フィードバックメッセージのために使用することができます。この場合、縮小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-FRIEND]のためのTCPフレンドリーレート制御のための開発（TFRC）の下でプロファイルとして、必要な場合には、化合物のRTCPsのサイズが非常に高い帯域幅の要件につながることができます。この特定のアプリケーションでは、縮小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を破棄してもよいです。例えば、ペイロードタイプ番号は、未知として処理することができる、207の代わりに、200または201である場合。この効果は、例えば、縮小サイズの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:
縮小RTCPパケットは、[RFC3550]の付録Aにパケット検証コードによって廃棄されるであろう。これにはいくつかの影響があります。
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に影響を与えます。この変更の一つの潜在的影響は、実際にいくつかの他のタイプの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を、破棄します。この効果は、フィードバックメッセージと受信機の役割の種類に依存します。たとえば、これは[によって定義された再送方式を使用して、セッション内の非更新されたメディアの送信者に（[RFC4585]のセクション6.2.1を参照）縮小サイズのNACKメッセージを送信しようとした場合の完全な機能喪失を引き起こす可能性がありRFC4588]。廃棄のこのタイプは、AVPFで定義されているフィードバック抑制に影響を与えます。結果は、複合RTCPフィードバックメッセージを見て、古い受信機との両方を見て新しいものとのセッション内の受信機のパーティショニング、だろう。この場合、古い受信機はすでに縮小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は、化合物のものよりも小さいと仮定すると、この計算に縮小RTCPを除外RTP受信機よりも大きくなることに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の計算：時間の経過とともに大きく変化avg_rtcp_sizeの値の計算につながる可能性の間に多くの縮小RTCPを有する化合物RTCP間の長い間隔。調査は、それが変化するが、これは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.
RTPとRTCPは、同じポート上にある多重化する用途では、[MULTI-RTP]で定義されるように、ケアは、逆多重化は、RTCPパケットのサイズを縮小されていても適切に行われるように注意しなければなりません。縮小RTCPの欠点は、RTCPパケットを表す複数の値が使用可能なRTPペイロードタイプスペースを低減する、存在することです。しかし、[MULTI-RTP]セクション4は既にこの多重化を行う際に使用されていない対応するRTPペイロードタイプの範囲を必要とします。
Two issues are related to header compression. Possible changes are left for future work:
二つの問題は、ヘッダ圧縮に関連しています。可能性のある変更は、将来の仕事のために残されています。
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.
RTCPのO圧縮：いいえ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まず第一に、化合物のRTCPsがフィードバック・レポート、仕事のように、化合物パケットによってメカニズムが維持されていることを確認するために定期的な間隔で送信されることが重要です。再び言及する参加者のワラントのセッションサイズと数の追跡、これは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).
複合RTCPパケットは、メディア間の同期を確立し、維持するために使用されるO第二、セッションに新しく加入者は、メディア送信元（S）から化合物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
縮小サイズRTCPの使用はAVPF [RFC4585]またはSAVPF [RFC5124]早期RTCPまたは即時フィードバックモードで動作するRTPセッションで行われるものとします。縮小RTCPは、少なくとも1つの化合物のRTCPが送信されるまで送信されないものとします。即時フィードバックモードでは、すべてのフィードバックメッセージが縮小RTCPとして送信されてもよいです。初期RTCPモードでは、フィードバック・メッセージは、AS送信のためにスケジュール
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、すなわち、ではない通常のRTCPは、縮小RTCPとして送信されてもよいです。 AVPF [RFC4585]によって示されるように正規RTCPとして送信のためにスケジュールされたすべてのRTCPは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ミドルボックスの問題がより困難であり、ここでは1は縮小サイズの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.
*送信者レポート（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]です。別の例では、一時的な最大メディアストリームビットレート要求（TMMBR）[RFC5104]に起因する一時的な最大メディアストリームビットレート通知（TMMBN）メッセージです。第三の例では、送信されたフルイントラ要求から得られる映像メディアストリームデコーダ・リフレッシュ・ポイント[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.
検証が失敗した場合、強くのみ化合物RTCPは、RFC 3550に概説されたルールに従って、送信することをお勧めします。
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を使用するアプリケーションのために縮小サイズの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オファー内の属性「= 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）としてSDPの宣言用法、[RFC2326]とセッションアナウンスメントプロトコル（SAP）[RFC2974]では、属性の存在は、セッション参加者は、その中に縮小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としてスプリアスデータの受け入れのより高い程度をもたらすことができます。この脆弱性は、主に認証を提供する任意のセキュリティメカニズムの使用によって対処することができます。そのような機構は、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
RFC 5506の作者：連絡先の名前、電子メールアドレス、電話番号O：[RFC4566]のガイドラインに続いて、IANAは新しいSDP属性を登録しています
o Attribute-name: rtcp-rsize
O属性名：RTCP-RSIZE
o Long-form attribute name: Reduced-Size RTCP
Oロング・フォームの属性名：縮小サイズRTCP
o Type of attribute: media-level
属性のOタイプ：メディアレベル
o Subject to charset: no
文字セットにO件名：なし
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.
この属性は、縮小RTCP、即ち、それは値をとらないプロパティ属性であり、RFC 3550で定義された化合物RTCPの規則に適合しないRTCPを送信する可能性のサポートを定義します。
The authors would like to thank all the people who gave feedback on this document. Special thanks go to 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[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]オット、J.およびE.カララ、RFC 5124、2008年2月 "リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / SAVPF）にSecure RTPプロファイル拡張"。
[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]パーキンス、C.とM.ウェスター、「シングルポートの多重化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/ Permanent_documents / OMA-TS-PoC_UserPlane-V2_0-20080507-C。ジップ」、2006年11月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（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.、マグリュー、D.、Naslund、M.、カララ、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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]レイ、J.、レオン、D.、宮崎、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]ウェンガー、S.、チャンドラ、U.、ウェスター、M.、およびB.ビルマ、RFC 5104、2008年2月 "フィードバック付きRTPオーディオビジュアルプロファイル（AVPF）におけるコーデック制御メッセージ"。
[TCP-FRIEND] Gharai, L., "RTP with TCP Friendly Rate Control", Work in Progress, July 2007.
[TCP-FRIEND] Gharai、L.、 "TCPフレンドリーレート制御とRTP"、進歩、2007年7月の作業。
Authors' Addresses
著者のアドレス
Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN
インゲマル・ヨハンソン、エリクソンAB研究所グランド11 SE-971 28ルーレオSWEDEN
Phone: +46 73 0783289 EMail: ingemar.s.johansson@ericsson.com
電話：+46 73 0783289 Eメール：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
電話：+46 10 7148287 Eメール：magnus.westerlund@ericsson.com