[要約] RFC 8108は、1つのRTPセッションで複数のRTPストリームを送信するための方法を提案しています。このRFCの目的は、効率的なメディアストリーミングを実現するために、複数のメディアストリームを単一のRTPセッションで送信する方法を定義することです。
Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 8108 Vidyo
Updates: 3550, 4585 M. Westerlund
Category: Standards Track Ericsson
ISSN: 2070-1721 Q. Wu
Huawei
C. Perkins
University of Glasgow
March 2017
Sending Multiple RTP Streams in a Single RTP Session
単一のRTPセッションで複数のRTPストリームを送信する
Abstract
概要
This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.
このメモは、複数の同期ソース（SSRC）を使用するリアルタイムトランスポートプロトコル（RTP）エンドポイントの動作を拡張して明確にします。これは、たとえば、エンドポイントが単一のRTPセッションで複数のRTPストリームを送信するときに発生します。このメモは、RTPセッションのエンドポイントごとの複数のSSRCの処理に関してRFC 3550を更新し、特にRTP制御プロトコル（RTCP）の動作に焦点を当てています。また、RFC 4585を更新して、SSRCのタイムアウトの計算とフィードバックメッセージを含めることを変更および明確化します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8108.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8108で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Use Cases for Multi-Stream Endpoints ............................4
3.1. Endpoints with Multiple Capture Devices ....................4
3.2. Multiple Media Types in a Single RTP Session ...............5
3.3. Multiple Stream Mixers .....................................5
3.4. Multiple SSRCs for a Single Media Source ...................5
4. Use of RTP by Endpoints That Send Multiple Media Streams ........6
5. Use of RTCP by Endpoints That Send Multiple Media Streams .......6
5.1. RTCP Reporting Requirement .................................7
5.2. Initial Reporting Interval .................................7
5.3. Aggregation of Reports into Compound RTCP Packets ..........8
5.3.1. Maintaining AVG_RTCP_SIZE ...........................9
5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ....10
5.4. Use of RTP/AVPF or RTP/SAVPF Feedback .....................13
5.4.1. Choice of SSRC for Feedback Packets ................13
5.4.2. Scheduling an RTCP Feedback Packet .................14
6. Adding and Removing SSRCs ......................................15
6.1. Adding RTP Streams ........................................16
6.2. Removing RTP Streams ......................................16
7. RTCP Considerations for Streams with Disparate Rates ...........17
7.1. Timing Out SSRCs ..........................................19
7.1.1. Problems with the RTP/AVPF T_rr_interval
Parameter ..........................................19
7.1.2. Avoiding Premature Timeout .........................20
7.1.3. Interoperability between RTP/AVP and RTP/AVPF ......21
7.1.4. Updated SSRC Timeout Rules .........................22
7.2. Tuning RTCP Transmissions .................................22
7.2.1. RTP/AVP and RTP/SAVP ...............................22
7.2.2. RTP/AVPF and RTP/SAVPF .............................24
8. Security Considerations ........................................25
9. References .....................................................26
9.1. Normative References ......................................26
9.2. Informative References ....................................26
Acknowledgments ...................................................29
Authors' Addresses ................................................29
At the time the Real-Time Transport Protocol (RTP) [RFC3550] was originally designed, and for quite some time after, endpoints in RTP sessions typically only transmitted a single media source and, thus, used a single RTP stream and synchronization source (SSRC) per RTP session, where separate RTP sessions were typically used for each distinct media type. Recently, however, a number of scenarios have emerged in which endpoints wish to send multiple RTP streams, distinguished by distinct RTP synchronization source (SSRC) identifiers, in a single RTP session. These are outlined in Section 3. Although the initial design of RTP did consider such scenarios, the specification was not consistently written with such use cases in mind; thus, the specification is somewhat unclear in places.
当時、リアルタイムトランスポートプロトコル（RTP）[RFC3550]は最初に設計され、その後しばらくの間、RTPセッションのエンドポイントは通常、単一のメディアソースのみを送信し、したがって単一のRTPストリームと同期ソース（ SSRC）RTPセッションごと。通常、個別のメディアタイプごとに個別のRTPセッションが使用されました。ただし、最近、エンドポイントが単一のRTPセッションで個別のRTP同期ソース（SSRC）識別子で区別された複数のRTPストリームを送信したいというシナリオがいくつか登場しました。これらはセクション3で概説されています。RTPの初期の設計ではそのようなシナリオを考慮しましたが、仕様はそのようなユースケースを念頭に置いて一貫して書かれていませんでした。そのため、仕様は場所によって多少不明確です。
This memo updates [RFC3550] to clarify behavior in use cases where endpoints use multiple SSRCs. It also updates [RFC4585] to resolve problems with regard to timeout of inactive SSRCs and to clarify behavior around inclusion of feedback messages.
このメモは[RFC3550]を更新して、エンドポイントが複数のSSRCを使用するユースケースでの動作を明確にします。また、[RFC4585]を更新して、非アクティブなSSRCのタイムアウトに関する問題を解決し、フィードバックメッセージの包含に関する動作を明確にしました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL "このドキュメントのRFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。
This section discusses several use cases that have motivated the development of endpoints that sends RTP data using multiple SSRCs in a single RTP session.
このセクションでは、単一のRTPセッションで複数のSSRCを使用してRTPデータを送信するエンドポイントの開発の動機となったいくつかの使用例について説明します。
The most straightforward motivation for an endpoint to send multiple simultaneous RTP streams in a single RTP session is when an endpoint has multiple capture devices and, hence, can generate multiple media sources, of the same media type and characteristics. For example, telepresence systems of the type described by the CLUE Telepresence Framework [CLUE-FRAME] often have multiple cameras or microphones covering various areas of a room and, hence, send several RTP streams of each type within a single RTP session.
エンドポイントが単一のRTPセッションで複数の同時RTPストリームを送信する最も簡単な動機は、エンドポイントに複数のキャプチャデバイスがあるため、同じメディアタイプと特性の複数のメディアソースを生成できる場合です。たとえば、CLUE Telepresence Framework [CLUE-FRAME]で説明されているタイプのテレプレゼンスシステムは、部屋のさまざまな領域をカバーする複数のカメラまたはマイクを備えていることが多いため、1つのRTPセッション内で各タイプの複数のRTPストリームを送信します。
Recent work has updated RTP [MULTI-RTP] and Session Description Protocol (SDP) [SDP-BUNDLE] to remove the historical assumption in RTP that media sources of different media types would always be sent on different RTP sessions. In this work, a single endpoint's audio and video RTP streams (for example) are instead sent in a single RTP session to reduce the number of transport-layer flows used.
最近の作業により、RTP [MULTI-RTP]およびセッション記述プロトコル（SDP）[SDP-BUNDLE]が更新され、異なるメディアタイプのメディアソースは常に異なるRTPセッションで送信されるというRTPの歴史的な前提が取り除かれました。この作業では、単一のエンドポイントのオーディオとビデオのRTPストリーム（たとえば）が単一のRTPセッションで送信され、使用されるトランスポート層フローの数を減らします。
There are several RTP topologies that can involve a central device that itself generates multiple RTP streams in a session. An example is a mixer providing centralized compositing for a multi-capture scenario like that described in Section 3.1. In this case, the centralized node is behaving much like a multi-capturer endpoint, generating several similar and related sources.
それ自体がセッションで複数のRTPストリームを生成する中央デバイスを含む可能性のあるRTPトポロジがいくつかあります。例は、セクション3.1で説明されているようなマルチキャプチャシナリオの集中型合成を提供するミキサーです。この場合、集中型ノードはマルチキャプチャーエンドポイントのように動作し、いくつかの類似した関連するソースを生成します。
A more complex example is the selective forwarding middlebox, described in Section 3.7 of [RFC7667]. This is a middlebox that receives RTP streams from several endpoints and then selectively forwards modified versions of some RTP streams toward the other endpoints to which it is connected. For each connected endpoint, a separate media source appears in the session for every other source connected to the middlebox, "projected" from the original streams, but at any given time many of them can appear to be inactive (and thus are receivers, not senders, in RTP). This sort of device is closer to being an RTP mixer than an RTP translator: it terminates RTCP reporting about the mixed streams; it can rewrite SSRCs, timestamps, and sequence numbers, as well as the contents of the RTP payloads; and it can turn sources on and off at will without appearing to generate packet loss. Each projected stream will typically preserve its original RTCP source description (SDES) information.
より複雑な例は、[RFC7667]のセクション3.7で説明されている選択転送ミドルボックスです。これは、複数のエンドポイントからRTPストリームを受信し、接続されている他のエンドポイントに向けて一部のRTPストリームの変更バージョンを選択的に転送するミドルボックスです。接続されたエンドポイントごとに、ミドルボックスに接続された他のすべてのソースのセッションに個別のメディアソースが表示され、元のストリームから「投影」されますが、それらの多くは常に非アクティブに見える可能性があります（したがって、レシーバーではなく、送信者、RTP）。この種のデバイスは、RTPトランスレータよりもRTPミキサーに近いものです。混合ストリームに関するRTCPレポートを終了します。 SSRC、タイムスタンプ、シーケンス番号、およびRTPペイロードの内容を書き換えることができます。また、パケット損失を発生させているように見えることなく、ソースを自由にオン/オフできます。投影された各ストリームは、通常、元のRTCPソース記述（SDES）情報を保持します。
There are also several cases where multiple SSRCs can be used to send data from a single media source within a single RTP session. These include, but are not limited to, transport robustness tools, such as the RTP retransmission payload format [RFC4588], that require one SSRC to be used for the media data and another SSRC for the repair data. Similarly, some layered media encoding schemes, for example, H.264 Scalable Video Coding (SVC) [RFC6190], can be used in a configuration where each layer is sent using a different SSRC within a single RTP session.
また、複数のSSRCを使用して、1つのRTPセッション内で1つのメディアソースからデータを送信できるケースもいくつかあります。これらには、RTP再送信ペイロード形式[RFC4588]など、メディアデータ用に1つのSSRCを使用し、修復データ用に別のSSRCを必要とするトランスポートロバストネスツールが含まれますが、これらに限定されません。同様に、一部の階層化メディアエンコーディングスキーム、たとえばH.264スケーラブルビデオコーディング（SVC）[RFC6190]は、各レイヤーが単一のRTPセッション内で異なるSSRCを使用して送信される構成で使用できます。
RTP is inherently a group communication protocol. Each endpoint in an RTP session will use one or more SSRCs, as will some types of RTP-level middlebox. Accordingly, unless restrictions on the number of SSRCs have been signaled, RTP endpoints can expect to receive RTP data packets sent using a number of different SSRCs, within a single RTP session. This can occur irrespective of whether the RTP session is running over a point-to-point connection or a multicast group, since middleboxes can be used to connect multiple transport connections together into a single RTP session (the RTP session is defined by the shared SSRC space, not by the transport connections). Furthermore, if RTP mixers are used, some SSRCs might only be visible in the contributing source (CSRC) list of an RTP packet and in RTCP, and might not appear directly as the SSRC of an RTP data packet.
RTPは本質的にグループ通信プロトコルです。 RTPセッションの各エンドポイントは、RTPレベルのミドルボックスのタイプと同様に、1つ以上のSSRCを使用します。したがって、SSRC数の制限が通知されていない限り、RTPエンドポイントは、単一のRTPセッション内で、複数の異なるSSRCを使用して送信されたRTPデータパケットを受信することを期待できます。これは、ミドルボックスを使用して複数のトランスポート接続を1つのRTPセッションに接続することができるため、RTPセッションがポイントツーポイント接続またはマルチキャストグループのどちらで実行されているかに関係なく発生します（RTPセッションは共有SSRCによって定義されます）トランスポート接続ではなくスペース）。さらに、RTPミキサーが使用されている場合、一部のSSRCは、RTPパケットの提供元（CSRC）リストとRTCPでのみ表示され、RTPデータパケットのSSRCとして直接表示されない場合があります。
Every RTP endpoint will have an allocated share of the available session bandwidth, as determined by signaling and congestion control. The endpoint needs to keep its total media sending rate within this share. However, endpoints that send multiple RTP streams do not necessarily need to subdivide their share of the available bandwidth independently or uniformly to each RTP stream and its SSRCs. In particular, an endpoint can vary the bandwidth allocation to different streams depending on their needs, and it can dynamically change the bandwidth allocated to different SSRCs (for example, by using a variable-rate codec), provided the total sending rate does not exceed its allocated share. This includes enabling or disabling RTP streams, or their redundancy streams, as more or less bandwidth becomes available.
すべてのRTPエンドポイントには、使用可能なセッション帯域幅の割り当てが割り当てられます。これは、シグナリングと輻輳制御によって決定されます。エンドポイントは、メディア共有の合計レートをこの共有内に維持する必要があります。ただし、複数のRTPストリームを送信するエンドポイントは、使用可能な帯域幅のシェアを必ずしも各RTPストリームとそのSSRCに個別にまたは均一に分割する必要はありません。特に、エンドポイントは、必要に応じてさまざまなストリームへの帯域幅割り当てを変えることができます。また、合計送信レートが超えないことを条件として、さまざまなSSRCに割り当てられる帯域幅を（たとえば、可変レートコーデックを使用して）動的に変更できます。割り当てられたシェア。これには、使用可能な帯域幅の増減に応じて、RTPストリームまたはその冗長ストリームを有効または無効にすることが含まれます。
RTCP is defined in Section 6 of [RFC3550]. The description of the protocol is phrased in terms of the behavior of "participants" in an RTP session, under the assumption that each endpoint is a participant with a single SSRC. However, for correct operation in cases where endpoints have multiple SSRC values, implementations MUST treat each SSRC as a separate participant in the RTP session, so that an endpoint that has multiple SSRCs counts as multiple participants.
RTCPは[RFC3550]のセクション6で定義されています。プロトコルの説明は、各エンドポイントが単一のSSRCを持つ参加者であるという前提の下で、RTPセッションでの「参加者」の動作に関して表現されています。ただし、エンドポイントに複数のSSRC値がある場合の正しい操作のために、実装は各SSRCをRTPセッションの個別の参加者として扱う必要があるため、複数のSSRCを持つエンドポイントは複数の参加者としてカウントされます。
An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a separate participant in the RTP session. Each SSRC will maintain its own RTCP-related state information and, hence, will have its own RTCP reporting interval that determines when it sends RTCP reports. If the mechanism in [MULTI-STREAM-OPT] is not used, then each SSRC will send RTCP reports for all other SSRCs, including those co-located at the same endpoint.
複数のSSRCを持つRTPエンドポイントは、各SSRCをRTPセッションの個別の参加者として扱う必要があります。各SSRCは独自のRTCP関連の状態情報を維持するため、RTCPレポートを送信するタイミングを決定する独自のRTCPレポート間隔があります。 [MULTI-STREAM-OPT]のメカニズムが使用されていない場合、各SSRCは、同じエンドポイントに同じ場所にあるものを含め、他のすべてのSSRCのRTCPレポートを送信します。
If the endpoint has some SSRCs that are sending data and some that are only receivers, then they will receive different shares of the RTCP bandwidth and calculate different base RTCP reporting intervals. Otherwise, all SSRCs at an endpoint will calculate the same base RTCP reporting interval. The actual reporting intervals for each SSRC are randomized in the usual way, but reports can be aggregated as described in Section 5.3.
エンドポイントに、データを送信しているSSRCと受信側のみのSSRCがある場合、それらはRTCP帯域幅の異なるシェアを受信し、異なるベースRTCPレポート間隔を計算します。そうでない場合、エンドポイントのすべてのSSRCが同じ基本RTCPレポート間隔を計算します。各SSRCの実際のレポート間隔は通常の方法でランダム化されますが、レポートはセクション5.3で説明されているように集約できます。
When a participant joins a unicast session, the following text from Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the delay before sending the initial compound RTCP packet MAY be zero." The basic assumption is that this also ought to apply in the case of multiple SSRCs. Caution has to be exercised, however, when an endpoint (or middlebox) with a large number of SSRCs joins a unicast session, since immediate transmission of many RTCP reports can create a significant burst of traffic, leading to transient congestion and packet loss due to queue overflows.
参加者がユニキャストセッションに参加する場合、[RFC3550]のセクション6.2の次のテキストが関連します。「ユニキャストセッションの場合...最初の複合RTCPパケットを送信する前の遅延はゼロになる場合があります。」基本的な仮定は、これは複数のSSRCの場合にも適用されるべきであるということです。ただし、多数のSSRCを持つエンドポイント（またはミドルボックス）がユニキャストセッションに参加する場合は注意が必要です。多くのRTCPレポートをすぐに送信すると、トラフィックのバーストが激しくなり、一時的な輻輳やパケット損失が発生する可能性があるためです。キューがオーバーフローしました。
To ensure that the initial burst of traffic generated by an RTP endpoint is no larger than would be generated by a TCP connection, an RTP endpoint MUST NOT send more than four compound RTCP packets with zero initial delay when it joins an RTP session, independent of the number of SSRCs used by the endpoint. Each of those initial compound RTCP packets MAY include aggregated reports from multiple SSRCs, provided the total compound RTCP packet size does not exceed the MTU, and the avg_rtcp_size is maintained as in Section 5.3.1. Aggregating reports from several SSRCs in the initial compound RTCP packets allows a substantial number of SSRCs to report immediately. Endpoints SHOULD prioritize reports on SSRCs that are likely to be most immediately useful, e.g., for SSRCs that are initially senders.
RTPエンドポイントによって生成されるトラフィックの初期バーストが、TCP接続によって生成されるトラフィックよりも大きくないことを保証するために、RTPエンドポイントは、RTPセッションに参加するときに、初期遅延がゼロの4つを超える複合RTCPパケットを送信してはなりませんエンドポイントによって使用されるSSRCの数。複合RTCPパケットの合計サイズがMTUを超えず、avg_rtcp_sizeがセクション5.3.1のように維持されている場合、これらの初期複合RTCPパケットのそれぞれに、複数のSSRCからの集約レポートが含まれる場合があります。最初の複合RTCPパケット内のいくつかのSSRCからのレポートを集約すると、相当数のSSRCがすぐにレポートできます。エンドポイントは、たとえば最初に送信者であるSSRCに対して、すぐに役立つ可能性が高いSSRCに関するレポートを優先する必要があります（SHOULD）。
An endpoint that needs to report on more SSRCs than will fit into the four compound RTCP reports that can be sent immediately MUST send the other reports later, following the usual RTCP timing rules including timer reconsideration. Those reports MAY be aggregated as described in Section 5.3.
すぐに送信できる4つの複合RTCPレポートに収まるよりも多くのSSRCでレポートする必要があるエンドポイントは、タイマーの再検討を含む通常のRTCPタイミングルールに従って、後で他のレポートを送信する必要があります。これらのレポートは、セクション5.3で説明されているように集約される場合があります。
Note: The above is chosen to match the TCP maximum initial window of four packets [RFC3390], not the larger TCP initial windows for which there is an ongoing experiment [RFC6928]. The reason for this is a desire to be conservative, since an RTP endpoint will also in many cases start sending RTP data packets at the same time as these initial RTCP packets are sent.
注：上記は、4つのパケットのTCP最大初期ウィンドウ[RFC3390]と一致するように選択されており、進行中の実験[RFC6928]があるより大きなTCP初期ウィンドウではありません。この理由は、RTPエンドポイントも多くの場合、これらの初期RTCPパケットが送信されると同時にRTPデータパケットの送信を開始するため、控えめにしたいという要望です。
As outlined in Section 5.1, an endpoint with multiple SSRCs has to treat each SSRC as a separate participant when it comes to sending RTCP reports. This will lead to each SSRC sending a compound RTCP packet in each reporting interval. Since these packets are coming from the same endpoint, it might reasonably be expected that they can be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] allows RTP translators and mixers to aggregate packets in similar circumstances:
セクション5.1で概説されているように、複数のSSRCを持つエンドポイントは、RTCPレポートの送信に関して、各SSRCを個別の参加者として扱う必要があります。これにより、各SSRCが各レポート間隔で複合RTCPパケットを送信します。これらのパケットは同じエンドポイントから送信されているため、オーバーヘッドを削減するためにそれらを集約できることが合理的に予想されます。実際、[RFC3550]のセクション6.1により、RTPトランスレータとミキサーは、同様の状況でパケットを集約できます。
It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.
トランスレータとミキサは、転送する複数のソースからの個々のRTCPパケットを、可能な場合は常に1つの複合パケットに結合して、パケットのオーバーヘッドを償却することをお勧めします（セクション7を参照）。ミキサーによって生成されるRTCP複合パケットの例を図1に示します。複合パケットの全長がネットワークパスのMTUを超える場合は、複数の短い複合パケットに分割して、個別に送信する必要があります（SHOULD）。基礎となるプロトコルのパケット。各複合パケットは少なくとも1つの異なる参加者を表すため、これはRTCP帯域幅の推定を損なうことはありません。複合パケットのそれぞれは、SRまたはRRパケットで始まる必要があることに注意してください。
This allows RTP translators and mixers to generate compound RTCP packets that contain multiple Sender Report (SR) or Receiver Report (RR) packets from different SSRCs, as well as any of the other packet types. There are no restrictions on the order in which the RTCP packets can occur within the compound packet, except the regular rule that the compound RTCP packet starts with an SR or RR packet. Due to this rule, correctly implemented RTP endpoints will be able to handle compound RTCP packets that contain RTCP packets relating to multiple SSRCs.
これにより、RTPトランスレーターおよびミキサーは、異なるSSRCからの複数の送信者レポート（SR）または受信者レポート（RR）パケット、およびその他のパケットタイプを含む複合RTCPパケットを生成できます。複合RTCPパケットがSRまたはRRパケットで始まるという通常の規則を除いて、複合パケット内でRTCPパケットが発生する順序には制限はありません。このルールにより、正しく実装されたRTPエンドポイントは、複数のSSRCに関連するRTCPパケットを含む複合RTCPパケットを処理できます。
Accordingly, endpoints that use multiple SSRCs can aggregate the RTCP packets sent by their different SSRCs into compound RTCP packets, provided 1) the resulting compound RTCP packets begin with an SR or RR packet, 2) they maintain the average RTCP packet size as described in Section 5.3.1, and 3) they schedule packet transmission and manage aggregation as described in Section 5.3.2.
したがって、複数のSSRCを使用するエンドポイントは、異なるSSRCによって送信されたRTCPパケットを複合RTCPパケットに集約できます。ただし、1）結果の複合RTCPパケットは、SRまたはRRパケットで始まります。2）説明されているように、平均RTCPパケットサイズを維持します。セクション5.3.1、および3）セクション5.3.2で説明されているように、パケット送信をスケジュールし、集約を管理します。
The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. Each SSRC sends a single compound RTCP packet in each RTCP reporting interval. When an endpoint uses multiple SSRCs, it is desirable to aggregate the compound RTCP packets sent by its SSRCs, reducing the overhead by forming a larger compound RTCP packet. This aggregation can be done as described in Section 5.3.2, provided the average RTCP packet size calculation is updated as follows.
[RFC3550]のRTCPスケジューリングアルゴリズムは、SSRCごとに機能します。各SSRCは、各RTCPレポート間隔で単一の複合RTCPパケットを送信します。エンドポイントが複数のSSRCを使用する場合、SSRCによって送信された複合RTCPパケットを集約し、より大きな複合RTCPパケットを形成することでオーバーヘッドを削減することが望ましいです。この集約は、セクション5.3.2で説明されているように実行できます。ただし、平均RTCPパケットサイズの計算が次のように更新されます。
Participants in an RTP session update their estimate of the average RTCP packet size (avg_rtcp_size) each time they send or receive an RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP packet that contains RTCP packets from several SSRCs is sent or received, the avg_rtcp_size estimate for each SSRC that is reported upon is updated using div_packet_size rather than the actual packet size:
RTPセッションの参加者は、RTCPパケットを送受信するたびに、平均RTCPパケットサイズ（avg_rtcp_size）の推定値を更新します（[RFC3550]のセクション6.3.3を参照）。複数のSSRCからのRTCPパケットを含む複合RTCPパケットが送信または受信されると、報告される各SSRCのavg_rtcp_size見積もりは、実際のパケットサイズではなくdiv_packet_sizeを使用して更新されます。
avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size
where div_packet_size is packet_size divided by the number of SSRCs reporting in that compound packet. The number of SSRCs reporting in a compound packet is determined by counting the number of different SSRCs that are the source of SR or RR RTCP packets within the compound RTCP packet. Non-compound RTCP packets (i.e., RTCP packets that do not contain an SR or RR packet [RFC5506]) are considered to report on a single SSRC.
ここで、div_packet_sizeは、packet_sizeをその複合パケットで報告するSSRCの数で割ったものです。複合パケットで報告するSSRCの数は、複合RTCPパケット内のSRまたはRR RTCPパケットのソースである異なるSSRCの数をカウントすることによって決定されます。非複合RTCPパケット（つまり、SRまたはRRパケットを含まないRTCPパケット[RFC5506]）は、単一のSSRCで報告すると見なされます。
A participant that doesn't follow the above rule, and instead uses the full RTCP compound packet size to calculate avg_rtcp_size, will derive an RTCP reporting interval that is overly large by a factor that is proportional to the number of SSRCs aggregated into compound RTCP packets and the size of set of SSRCs being aggregated relative to the total number of participants. This increased RTCP reporting interval can cause premature timeouts if it is more than five times the interval chosen by the SSRCs that understand compound RTCP that aggregate reports from many SSRCs. A 1500-octet MTU can fit five typical-size reports into a compound RTCP packet, so this is a real concern if endpoints aggregate RTCP reports from multiple SSRCs.
上記のルールに従わず、代わりに完全なRTCP複合パケットサイズを使用してavg_rtcp_sizeを計算する参加者は、複合RTCPパケットに集約されたSSRCの数に比例する係数によって過度に大きいRTCPレポート間隔を導出します参加者の総数に関連して集約されるSSRCのセットのサイズ。この増加したRTCPレポート間隔は、多くのSSRCからのレポートを集約する複合RTCPを理解するSSRCによって選択された間隔の5倍を超えると、早期のタイムアウトを引き起こす可能性があります。 1500オクテットのMTUは、5つの標準サイズのレポートを複合RTCPパケットに収めることができるため、エンドポイントが複数のSSRCからのRTCPレポートを集約する場合、これは実際の懸念事項です。
The issue raised in the previous paragraph is mitigated by the modification in timeout behavior specified in Section 7.1.2 of this memo. This mitigation is in place in those cases where the RTCP bandwidth is sufficiently high that an endpoint, using avg_rtcp_size calculated without taking into account the number of reporting SSRCs, can transmit more frequently than approximately every 5 seconds. Note, however, that the non-updated endpoint's RTCP reporting is still negatively impacted even if the premature timeouts of its SSRCs are avoided. If compatibility with non-updated endpoints is a concern, the number of reports from different SSRCs aggregated into a single compound RTCP packet SHOULD either be limited to two reports or aggregation ought not be used at all. This will limit the non-updated endpoint's RTCP reporting interval to be no larger than twice the RTCP reporting interval that would be chosen by an endpoint following this specification.
前の段落で提起された問題は、このメモのセクション7.1.2で指定されているタイムアウト動作の変更によって緩和されています。この緩和策は、RTCP帯域幅が十分に高く、レポートSSRCの数を考慮せずに計算されたavg_rtcp_sizeを使用して、エンドポイントが約5秒ごとよりも頻繁に送信できるほど高い場合に適用されます。ただし、SSRCの早期タイムアウトが回避された場合でも、更新されていないエンドポイントのRTCPレポートは依然として悪影響を受けることに注意してください。更新されていないエンドポイントとの互換性が懸念される場合、単一の複合RTCPパケットに集約されたさまざまなSSRCからのレポートの数は、2つのレポートに制限するか、集約をまったく使用しないでください。これにより、更新されていないエンドポイントのRTCPレポート間隔は、この仕様に従ってエンドポイントによって選択されるRTCPレポート間隔の2倍以下に制限されます。
This section revises and extends the behavior defined in Section 6.3 of [RFC3550], and in Section 3.5.3 of [RFC4585] if the RTP/AVPF profile or the RTP/SAVPF profile is used, regarding actions to take when scheduling and sending RTCP packets where multiple reporting SSRCs are aggregating their RTCP packets into the same compound RTCP packet. These changes to the RTCP scheduling rules are needed to maintain important RTCP timing properties, including the inter-packet distribution, and the behavior during flash joins and other changes in session membership.
このセクションは、[RFC3550]のセクション6.3、および[RFC4585]のセクション3.5.3で定義されている動作を改訂および拡張し、RTP / AVPFプロファイルまたはRTP / SAVPFプロファイルが使用されている場合、RTCPのスケジュールおよび送信時に実行するアクションに関して複数のレポートSSRCがRTCPパケットを同じ複合RTCPパケットに集約しているパケット。 RTCPスケジューリングルールに対するこれらの変更は、パケット間の分散、フラッシュ結合中の動作、およびセッションメンバーシップの他の変更を含む、重要なRTCPタイミングプロパティを維持するために必要です。
The variables tn, tp, tc, T, and Td used in the following are defined in Section 6.3 of [RFC3550]. The variables T_rr_interval and T_rr_last are defined in [RFC4585].
以下で使用される変数tn、tp、tc、T、およびTdは、[RFC3550]のセクション6.3で定義されています。変数T_rr_intervalとT_rr_lastは[RFC4585]で定義されています。
Each endpoint MUST schedule RTCP transmission independently for each of its SSRCs using the regular calculation of tn for the RTP profile being used. Each time the timer tn expires for an SSRC, the endpoint MUST perform RTCP timer reconsideration and, if applicable, suppression based on T_rr_interval. If the result indicates that a compound RTCP packet is to be sent by that SSRC, and the transmission is not an early RTCP packet [RFC4585], then the endpoint SHOULD try to aggregate RTCP packets of additional SSRCs that are scheduled in the future into the compound RTCP packet before it is sent. The reason to limit or not aggregate due to backwards compatibility reasons is discussed in Section 5.3.1.
各エンドポイントは、使用されているRTPプロファイルのtnの通常の計算を使用して、そのSSRCごとに独立してRTCP送信をスケジュールする必要があります。 SSRCのタイマーtnが期限切れになるたびに、エンドポイントはRTCPタイマーの再検討と、該当する場合はT_rr_intervalに基づく抑制を実行する必要があります。結果がそのRSCパケットがそのSSRCによって送信されることを示し、送信が初期のRTCPパケットではない[RFC4585]場合、エンドポイントは、将来スケジュールされる追加のSSRCのRTCPパケットをに集約しようとする必要があります（SHOULD）。送信前の複合RTCPパケット。下位互換性のために制限するか、または集計しない理由については、セクション5.3.1で説明します。
Aggregation proceeds as follows. The endpoint selects the SSRC that has the smallest tn value after the current time, tc, and prepares the RTCP packets that SSRC would send if its timer tn expired at tc. If those RTCP packets will fit into the compound RTCP packet that is being generated, taking into account the path MTU and the previously added RTCP packets, then they are added to the compound RTCP packet; otherwise, they are discarded. This process is repeated for each SSRC, in order of increasing tn, until the compound RTCP packet is full or all SSRCs have been aggregated. At that point, the compound RTCP packet is sent.
集計は次のように行われます。エンドポイントは、現在の時刻tcの後にtn値が最小のSSRCを選択し、タイマーtnがtcで期限切れになった場合にSSRCが送信するRTCPパケットを準備します。それらのRTCPパケットが、パスMTUと以前に追加されたRTCPパケットを考慮して、生成される複合RTCPパケットに収まる場合、それらは複合RTCPパケットに追加されます。それ以外の場合は破棄されます。このプロセスは、複合RTCPパケットがいっぱいになるか、すべてのSSRCが集約されるまで、tnの増加順に各SSRCに対して繰り返されます。その時点で、複合RTCPパケットが送信されます。
When the compound RTCP packet is sent, the endpoint MUST update tp, tn, and T_rr_last (if applicable) for each SSRC that was included. These variables are updated as follows:
複合RTCPパケットが送信されると、エンドポイントは、含まれていた各SSRCのtp、tn、およびT_rr_last（該当する場合）を更新する必要があります。これらの変数は次のように更新されます。
a. For the first SSRC that reported in the compound RTCP packet, set the effective transmission time, tt, of that SSRC to tc.
a. 複合RTCPパケットで報告された最初のSSRCについて、そのSSRCの実効送信時間ttをtcに設定します。
b. For each additional SSRC that reported in the compound RTCP packet, calculate the transmission time that SSRC would have had if it had not been aggregated into the compound RTCP packet. This is derived by taking tn for that SSRC, then performing reconsideration and updating tn until tp + T <= tn. Once this is done, set the effective transmission time, tt, for that SSRC to the calculated value of tn. If the RTP/AVPF profile or the RTP/ SAVPF profile is being used, then suppression based on T_rr_interval MUST NOT be used in this calculation.
b. 複合RTCPパケットで報告された追加の各SSRCについて、複合RTCPパケットに集約されなかった場合のSSRCの送信時間を計算します。これは、そのSSRCのtnを取得し、再検討を実行して、tp + T <= tnになるまでtnを更新することで得られます。これが完了したら、そのSSRCの有効伝送時間ttを計算されたtnの値に設定します。 RTP / AVPFプロファイルまたはRTP / SAVPFプロファイルが使用されている場合、T_rr_intervalに基づく抑制をこの計算で使用してはなりません（MUST NOT）。
c. Calculate average effective transmission time, tt_avg, for the compound RTCP packet based on the tt values for all SSRCs sent in the compound RTCP packet. Set tp for each of the SSRCs sent in the compound RTCP packet to tt_avg. If the RTP/AVPF profile or the RTP/SAVPF profile is being used, set T_tt_last for each SSRC sent in the compound RTCP packet to tt_avg.
c. 複合RTCPパケットで送信されたすべてのSSRCのtt値に基づいて、複合RTCPパケットの平均有効伝送時間tt_avgを計算します。複合RTCPパケットで送信された各SSRCのtpをtt_avgに設定します。 RTP / AVPFプロファイルまたはRTP / SAVPFプロファイルが使用されている場合は、複合RTCPパケットで送信される各SSRCのT_tt_lastをtt_avgに設定します。
d. For each of the SSRCs sent in the compound RTCP packet, calculate new tn values based on the updated parameters and the usual RTCP timing rules and reschedule the timers.
d. 複合RTCPパケットで送信される各SSRCについて、更新されたパラメーターと通常のRTCPタイミング規則に基づいて新しいtn値を計算し、タイマーを再スケジュールします。
When using the RTP/AVPF profile or the RTP/SAVPF profile, the above mechanism only attempts to aggregate RTCP packets when the compound RTCP packet to be sent is not an early RTCP packet, and hence the algorithm in Section 3.5.3 of [RFC4585] will control RTCP scheduling. If T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or 2b of the algorithm are chosen, then the above mechanism updates the necessary variables. However, if the transmission is suppressed per option 2c of the algorithm, then tp is updated to tc as aggregation has not taken place.
RTP / AVPFプロファイルまたはRTP / SAVPFプロファイルを使用する場合、上記のメカニズムは、送信される複合RTCPパケットが初期のRTCPパケットでない場合にのみRTCPパケットを集約しようとするため、[RFC4585のセクション3.5.3のアルゴリズム] RTCPスケジューリングを制御します。 T_rr_interval == 0、またはT_rr_interval！= 0で、アルゴリズムのオプション1、2a、または2bが選択されている場合、上記のメカニズムは必要な変数を更新します。ただし、アルゴリズムのオプション2cに従って送信が抑制された場合、集約は行われていないため、tpはtcに更新されます。
Reverse reconsideration MUST be performed following Section 6.3.4 of [RFC3550]. In some cases, this can lead to the value of tp after reverse reconsideration being larger than tc. This is not a problem, and has the desired effect of proportionally pulling the tp value towards tc (as well as tn) as the reporting interval shrinks in direct proportion the reduced group size.
[RFC3550]のセクション6.3.4に従って、逆の再検討を行う必要があります。場合によっては、これにより、逆再検討後のtpの値がtcよりも大きくなることがあります。これは問題ではなく、レポート間隔が縮小されたグループサイズに正比例して縮小するときに、tp値をtc（およびtn）に比例して引き寄せるという望ましい効果があります。
The above algorithm has been shown in simulations [Sim88] [Sim92] to maintain the inter-RTCP packet transmission time distribution for each SSRC and to consume the same amount of bandwidth as non-aggregated RTCP packets. With this algorithm, the actual transmission interval for an SSRC triggering an RTCP compound packet transmission is following the regular transmission rules. The value tp is set to somewhere in the interval [0, 1.5/1.21828*Td] ahead of tc. The actual value is the average of one instance of tc and the randomized transmission times of the additional SSRCs; thus, the lower range of the interval is more probable. This compensates for the bias that is otherwise introduced by picking the shortest tn value out of the N SSRCs included in aggregate.
上記のアルゴリズムは、シミュレーション[Sim88] [Sim92]で示され、各SSRCのRTCP間パケット送信時間分布を維持し、非集約RTCPパケットと同じ量の帯域幅を消費します。このアルゴリズムでは、RTCP複合パケット送信をトリガーするSSRCの実際の送信間隔は、通常の送信ルールに従います。値tpは、tcの前の間隔[0、1.5 / 1.21828 * Td]のどこかに設定されます。実際の値は、tcの1つのインスタンスの平均と、追加のSSRCのランダム化された送信時間です。したがって、間隔の範囲が低いほど、確率が高くなります。これにより、集計に含まれるN個のSSRCから最短のtn値を選択することで、導入されるバイアスが補正されます。
The algorithm also handles the cases where the number of SSRCs that can be included in an aggregated packet varies. An SSRC that previously was aggregated and fails to fit in a packet still has its own transmission scheduled according to normal rules. Thus, it will trigger a transmission in due time, or the SSRC will be included in another aggregate. The algorithm's behavior under SSRC group size changes is as follows:
このアルゴリズムは、集約されたパケットに含めることができるSSRCの数が異なる場合も処理します。以前に集約され、パケットに収まらなかったSSRCには、通常のルールに従って独自の送信がスケジュールされています。したがって、それはやがて送信をトリガーするか、SSRCは別の集合体に含まれます。 SSRCグループサイズの変更におけるアルゴリズムの動作は次のとおりです。
RTP sessions where the number of SSRCs is growing: When the group size is growing, Td grows in proportion to the number of new SSRCs in the group. When reconsideration is performed due to expiry of the tn timer, that SSRC will reconsider the transmission and with a certain probability reschedule the tn timer. This part of the reconsideration algorithm is only impacted by the above algorithm having tp values that were in the future instead of set to the time of the actual last transmission at the time of updating tp.
SSRCの数が増加しているRTPセッション：グループサイズが増加すると、Tdはグループ内の新しいSSRCの数に比例して増加します。 tnタイマーの期限切れのために再検討が実行されると、そのSSRCは送信を再検討し、一定の確率でtnタイマーを再スケジュールします。再検討アルゴリズムのこの部分は、tpの更新時に実際の最後の送信時刻に設定されるのではなく、将来のtp値を持つ上記のアルゴリズムによってのみ影響を受けます。
RTP sessions where the number of SSRCs is shrinking: When the group shrinks, reverse reconsideration moves the tp and tn values towards tc proportionally to the number of SSRCs that leave the session compared to the total number of participants when they left. The setting of the tp value forward in time related to the tc could be believed to have negative effect. However, the reason for this setting is to compensate for bias caused by picking the shortest tn out of the N aggregated. This bias remains over a reduction in the number of SSRCs. The reverse reconsideration compensates the reduction independently of whether or not aggregation is being used. The negative effect that can occur on removing an SSRC is that the most favorable tn belonged to the removed SSRC. The impact of this is limited to delaying the transmission, in the worst case, one reporting interval.
SSRCの数が減少しているRTPセッション：グループが減少すると、逆再検討により、参加者の去ったときの総数と比較してセッションを離れたSSRCの数に比例して、tpとtnの値がtcに向かって移動します。 tcに関連する時間的に進んだtp値の設定は、悪影響があると考えられます。ただし、この設定の理由は、集計されたNから最短のtnを選択することによって引き起こされるバイアスを補償するためです。このバイアスは、SSRCの数の減少を超えて残っています。逆再検討は、集約が使用されているかどうかに関係なく、削減を補正します。 SSRCの削除時に発生する可能性のあるマイナスの影響は、最も有利なtnが削除されたSSRCに属していたことです。この影響は、最悪の場合、1つのレポート間隔で送信を遅らせることに限定されます。
In conclusion, the investigations performed have found no significant negative impact on the scheduling algorithm.
結論として、実施された調査では、スケジューリングアルゴリズムに重大な悪影響はありませんでした。
This section discusses the transmission of RTP/AVPF feedback packets when the transmitting endpoint has multiple SSRCs. The guidelines in this section also apply to endpoints using the RTP/SAVPF profile.
このセクションでは、送信エンドポイントに複数のSSRCがある場合のRTP / AVPFフィードバックパケットの送信について説明します。このセクションのガイドラインは、RTP / SAVPFプロファイルを使用するエンドポイントにも適用されます。
When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC to use as the source for the RTCP feedback packets it sends. Several factors can affect that choice:
RTP / AVPFエンドポイントに複数のSSRCがある場合、エンドポイントは、送信するRTCPフィードバックパケットのソースとして使用するSSRCを選択できます。いくつかの要因がその選択に影響を与える可能性があります。
o RTCP feedback packets relating to a particular media type SHOULD be sent by an SSRC that receives that media type. For example, when audio and video are multiplexed onto a single RTP session, endpoints will use their audio SSRC to send feedback on the audio received from other participants.
o 特定のメディアタイプに関連するRTCPフィードバックパケットは、そのメディアタイプを受信するSSRCによって送信される必要があります（SHOULD）。たとえば、オーディオとビデオが単一のRTPセッションに多重化されている場合、エンドポイントはオーディオSSRCを使用して、他の参加者から受信したオーディオに関するフィードバックを送信します。
o RTCP feedback packets and RTCP codec control messages that are notifications or indications regarding RTP data processed by an endpoint MUST be sent from the SSRC used for that RTP data. This includes notifications that relate to a previously received request or command [RFC4585][RFC5104].
o エンドポイントによって処理されたRTPデータに関する通知または表示であるRTCPフィードバックパケットおよびRTCPコーデック制御メッセージは、そのRTPデータに使用されるSSRCから送信される必要があります。これには、以前に受信した要求またはコマンド[RFC4585] [RFC5104]に関連する通知が含まれます。
o If separate SSRCs are used to send and receive media, then the corresponding SSRC SHOULD be used for feedback, since they have differing RTCP bandwidth fractions. This can also affect the consideration of whether or not the SSRC can be used in immediate mode.
o メディアの送受信に別のSSRCを使用する場合、対応するSSRCはフィードバックに使用する必要があります。RRC帯域幅の割合が異なるためです。これは、SSRCを即時モードで使用できるかどうかの検討にも影響を与える可能性があります。
o Some RTCP feedback packet types require consistency in the SSRC used. For example, if a Temporary Maximum Media Stream Bit Rate Request (TMMBR) limitation [RFC5104] is set by an SSRC, the same SSRC needs to be used to remove the limitation.
o 一部のRTCPフィードバックパケットタイプでは、使用するSSRCの一貫性が必要です。たとえば、一時最大メディアストリームビットレート要求（TMMBR）制限[RFC5104]がSSRCによって設定されている場合、同じSSRCを使用して制限を削除する必要があります。
o If several SSRCs are suitable for sending feedback, it might be desirable to use an SSRC that allows the sending of feedback as an early RTCP packet.
o 複数のSSRCがフィードバックの送信に適している場合は、初期のRTCPパケットとしてフィードバックを送信できるSSRCを使用することが望ましい場合があります。
When an RTCP feedback packet is sent as part of a compound RTCP packet that aggregates reports from multiple SSRCs, there is no requirement that the compound packet contain an SR or RR packet generated by the sender of the RTCP feedback packet. For reduced-size RTCP packets, aggregation of RTCP feedback packets from multiple sources is not limited further than Section 4.2.2 of [RFC5506].
複数のSSRCからのレポートを集約する複合RTCPパケットの一部としてRTCPフィードバックパケットが送信される場合、複合パケットにRTCPフィードバックパケットの送信者が生成したSRまたはRRパケットが含まれている必要はありません。縮小サイズのRTCPパケットの場合、複数のソースからのRTCPフィードバックパケットの集約は、[RFC5506]のセクション4.2.2よりも制限されません。
When an SSRC has a need to transmit a feedback packet in early mode, it MUST schedule that packet following the algorithm in Section 3.5 of [RFC4585] modified as follows:
SSRCがフィードバックパケットをアーリーモードで送信する必要がある場合、[RFC4585]のセクション3.5のアルゴリズムに従って、そのパケットを次のように変更してスケジュールする必要があります。
o To determine whether an RTP session is considered to be a point-to-point session or a multiparty session, an endpoint MUST count the number of distinct RTCP SDES CNAME values used by the SSRCs listed in the SSRC field of RTP data packets it receives and in the "SSRC of sender" field of RTCP SR, RR, RTPFB, or PSFB packets it receives. An RTP session is considered to be a multiparty session if more than one CNAME is used by those SSRCs, unless signaling indicates that the session is to be handled as point to point or RTCP reporting groups [MULTI-STREAM-OPT] are used. If RTCP reporting groups are used, an RTP session is considered to be a point-to-point session if the endpoint receives only a single reporting group and is considered to be a multiparty session if multiple reporting groups are received or a combination of reporting groups and SSRCs that are not part of a reporting group are received. Endpoints MUST NOT determine whether an RTP session is multiparty or point to point based on the type of connection (unicast or multicast) used, or on the number of SSRCs received.
o RTPセッションがポイントツーポイントセッションとマルチパーティセッションのどちらであると見なされるかを判断するには、エンドポイントは、受信するRTPデータパケットのSSRCフィールドにリストされているSSRCによって使用される個別のRTCP SDES CNAME値の数をカウントする必要があります。受信するRTCP SR、RR、RTPFB、またはPSFBパケットの「送信者のSSRC」フィールド。 RTPセッションは、複数のCNAMEがそれらのSSRCによって使用されている場合、マルチセッションであると見なされます。ただし、セッションがポイントツーポイントとして処理されることを示しているか、RTCPレポートグループ[MULTI-STREAM-OPT]が使用されている場合を除きます。 RTCPレポートグループが使用されている場合、RTPセッションは、エンドポイントが単一のレポートグループのみを受信する場合はポイントツーポイントセッションと見なされ、複数のレポートグループまたはレポートグループの組み合わせを受信する場合はマルチパーティセッションと見なされます。および報告グループの一部ではないSSRCが受信されます。エンドポイントは、使用される接続のタイプ（ユニキャストまたはマルチキャスト）、または受信したSSRCの数に基づいて、RTPセッションがマルチパーティであるかポイントツーポイントであるかを決定してはなりません（MUST NOT）。
o When checking if there is already a scheduled compound RTCP packet containing feedback messages (Step 2 in Section 3.5.2 of [RFC4585]), that check MUST be done considering all local SSRCs.
o フィードバックメッセージを含むスケジュールされた複合RTCPパケットがすでにあるかどうかを確認する場合（[RFC4585]のセクション3.5.2のステップ2）、その確認はすべてのローカルSSRCを考慮して行う必要があります。
o If an SSRC is not allowed to send an early RTCP packet, then the feedback message MAY be queued for transmission as part of any early or regular scheduled transmission that can occur within the maximum useful lifetime of the feedback message (T_max_fb_delay). This modifies the behavior in item 4a in Section 3.5.2 of [RFC4585].
o SSRCが早期RTCPパケットの送信を許可されていない場合、フィードバックメッセージは、フィードバックメッセージの最大有効期間（T_max_fb_delay）内で発生する可能性のある早期または定期的な送信の一部として、送信のためにキューに入れられます（MAY）。これにより、[RFC4585]のセクション3.5.2の項目4aの動作が変更されます。
The first bullet point above specifies a rule to determine if an RTP session is to be considered a point-to-point session or a multiparty session. This rule is straightforward to implement, but is known to incorrectly classify some sessions as multiparty sessions. The known problems are as follows:
上記の最初の箇条書きは、RTPセッションをポイントツーポイントセッションとマルチパーティセッションのどちらと見なすかを決定するルールを指定しています。このルールは簡単に実装できますが、一部のセッションをマルチパーティセッションとして誤って分類することがわかっています。既知の問題は次のとおりです。
Endpoint with multiple synchronization contexts: An endpoint that is part of a point-to-point session can have multiple synchronization contexts, for example, due to forwarding an external media source into an interactive real-time conversation. In this case, the classification will consider the peer as two endpoints, while the actual RTP/RTCP transmission will be under the control of one endpoint.
複数の同期コンテキストを持つエンドポイント：ポイントツーポイントセッションの一部であるエンドポイントは、たとえば、外部メディアソースをインタラクティブなリアルタイム会話に転送するため、複数の同期コンテキストを持つことができます。この場合、分類ではピアを2つのエンドポイントと見なしますが、実際のRTP / RTCP送信は1つのエンドポイントの制御下にあります。
Selective Forwarding Middlebox: The Selective Forwarding Middlebox (SFM) as defined in Section 3.7 of [RFC7667] has control over the transmission and configurations between itself and each peer endpoint individually. It also fully controls the RTCP packets being forwarded between the individual legs. Thus, this type of middlebox can be compared to the RTP mixer, which uses its own SSRCs to mix or select the media it forwards, that will be classified as a point-to-point RTP session by the above rule.
セレクティブフォワーディングミドルボックス：[RFC7667]のセクション3.7で定義されているセレクティブフォワーディングミドルボックス（SFM）は、それ自体と各ピアエンドポイント間の伝送と構成を個別に制御します。また、個々のレッグ間で転送されるRTCPパケットを完全に制御します。したがって、このタイプのミドルボックスは、独自のSSRCを使用して転送するメディアを混合または選択するRTPミキサーと比較できます。これは、上記のルールによってポイントツーポイントRTPセッションとして分類されます。
In the above cases, it is very reasonable to use RTCP reporting groups [MULTI-STREAM-OPT]. If that extension is used, an endpoint can indicate that the multitude of CNAMEs are in fact under a single endpoint or middlebox control by using only a single reporting group.
上記の場合、RTCPレポートグループ[MULTI-STREAM-OPT]を使用することは非常に合理的です。その拡張が使用されている場合、エンドポイントは、単一のレポートグループのみを使用することにより、多数のCNAMEが実際には単一のエンドポイントまたはミドルボックスコントロールの下にあることを示すことができます。
The above rules will also classify some sessions where the endpoint is connected to an RTP mixer as being point to point. For example, the mixer could act as gateway to an RTP session based on Any Source Multicast for the discussed endpoint. However, this will, in most cases, be okay, as the RTP mixer provides separation between the two parts of the session. The responsibility falls on the mixer to act accordingly in each domain.
上記のルールは、エンドポイントがRTPミキサーに接続されている一部のセッションもポイントツーポイントとして分類します。たとえば、ミキサーは、議論されたエンドポイントの任意のソースマルチキャストに基づいて、RTPセッションへのゲートウェイとして機能できます。ただし、RTPミキサーはセッションの2つの部分を分離するため、ほとんどの場合これで問題ありません。各ドメインで適切に機能する責任はミキサーにあります。
Finally, we note that signaling mechanisms could be defined to override the rules when they would result in the wrong classification.
最後に、シグナルメカニズムを定義して、ルールが誤った分類になる場合にルールを上書きできることに注意してください。
The set of SSRCs present in a single RTP session can vary over time due to changes in the number of endpoints in the session or due to changes in the number or type of RTP streams being sent.
単一のRTPセッションに存在するSSRCのセットは、セッション内のエンドポイントの数の変化、または送信されるRTPストリームの数またはタイプの変化により、時間とともに変化する可能性があります。
Every endpoint in an RTP session will have at least one SSRC that it uses for RTCP reporting, and for sending media if desired. It can also have additional SSRCs, for sending extra media sources or for additional RTCP reporting. If the set of media sources being sent changes, then the set of SSRCs being sent will change. Changes in the media format or clock rate might also require changes in the set of SSRCs used. An endpoint can also have more SSRCs than it has active RTP streams, and send RTCP relating to SSRCs that are not currently sending RTP data packets so that its peers are aware of the SSRCs, and have the associated context (e.g., clock synchronization and an SDES CNAME) in place to be able to play out media as soon as they becomes active.
RTPセッションのすべてのエンドポイントには、RTCPレポート、および必要に応じてメディアを送信するために使用する少なくとも1つのSSRCがあります。追加のメディアソースを送信したり、追加のRTCPレポートを作成したりするために、追加のSSRCを含めることもできます。送信されるメディアソースのセットが変更されると、送信されるSSRCのセットも変更されます。メディアフォーマットまたはクロックレートを変更すると、使用するSSRCセットの変更も必要になる場合があります。エンドポイントは、アクティブなRTPストリームよりも多くのSSRCを持つことができ、現在RTPデータパケットを送信していないSSRCに関連するRTCPを送信して、ピアがSSRCを認識し、関連するコンテキスト（たとえば、クロック同期とSDES CNAME）メディアがアクティブになるとすぐにメディアを再生できるように配置されます。
In the following, we describe some considerations around adding and removing RTP streams and their associated SSRCs.
以下では、RTPストリームとそれに関連するSSRCの追加と削除に関するいくつかの考慮事項について説明します。
When an endpoint joins an RTP session, it can have zero, one, or more RTP streams it will send, or that it is prepared to send. If it has no RTP stream it plans to send, it still needs an SSRC that will be used to send RTCP feedback. If it will send one or more RTP streams, it will need the corresponding number of SSRC values. The SSRCs used by an endpoint are made known to other endpoints in the RTP session by sending RTP and RTCP packets. SSRCs can also be signaled using non-RTP means (e.g., [RFC5576]). Unless restricted by signaling, an endpoint can, at any time, send an additional RTP stream, identified by a new SSRC (this might be associated with a signaling event, but that is outside the scope of this memo). This makes the new SSRC visible to the other endpoints in the session, since they share the single SSRC space inherent in the definition of an RTP session.
エンドポイントがRTPセッションに参加するとき、エンドポイントは、送信するRTPストリームが0個、1個、またはそれ以上あるか、送信する準備ができている可能性があります。送信する予定のRTPストリームがない場合でも、RTCPフィードバックの送信に使用されるSSRCが必要です。 1つ以上のRTPストリームを送信する場合は、対応する数のSSRC値が必要です。エンドポイントで使用されるSSRCは、RTPおよびRTCPパケットを送信することにより、RTPセッションの他のエンドポイントに認識されます。 SSRCは、RTP以外の手段（[RFC5576]など）を使用して通知することもできます。シグナリングによって制限されない限り、エンドポイントはいつでも、新しいSSRCによって識別される追加のRTPストリームを送信できます（これはシグナリングイベントに関連付けられている可能性がありますが、このメモの範囲外です）。これにより、新しいSSRCはRTPセッションの定義に固有の単一のSSRCスペースを共有するため、セッション内の他のエンドポイントから見えるようになります。
An endpoint that has never sent an RTP stream will have an SSRC that it uses for RTCP reporting. If that endpoint wants to start sending an RTP stream, it is RECOMMENDED that it use its existing SSRC for that stream, since otherwise the participant count in the RTP session will be unnecessarily increased, leading to a longer RTCP reporting interval and larger RTCP reports due to cross reporting. If the endpoint wants to start sending more than one RTP stream, it will need to generate a new SSRC for the second and any subsequent RTP streams.
RTPストリームを送信したことがないエンドポイントには、RTCPレポートに使用するSSRCがあります。そのエンドポイントがRTPストリームの送信を開始したい場合は、そのストリームに既存のSSRCを使用することをお勧めします。そうしないと、RTPセッションの参加者数が不必要に増加し、RTCPレポート間隔が長くなり、RTCPレポートが大きくなるためです。クロスレポートする。エンドポイントが複数のRTPストリームの送信を開始する場合、2番目以降のRTPストリーム用に新しいSSRCを生成する必要があります。
An endpoint that has previously stopped sending an RTP stream, and that wants to start sending a new RTP stream, cannot generally reuse the existing SSRC, and often needs to generate a new SSRC, because an SSRC cannot change media type (e.g., audio to video) or RTP timestamp clock rate [RFC7160] and because the SSRC might be associated with a particular semantic by the application (note: an RTP stream can pause and restart using the same SSRC, provided RTCP is sent for that SSRC during the pause; these rules only apply to new RTP streams reusing an existing SSRC).
以前にRTPストリームの送信を停止し、新しいRTPストリームの送信を開始したいエンドポイントは、SSRCがメディアタイプ（オーディオなど）を変更できないため、通常は既存のSSRCを再利用できず、新しいSSRCを生成する必要がありますビデオ）またはRTPタイムスタンプクロックレート[RFC7160]およびSSRCがアプリケーションによって特定のセマンティクスに関連付けられている可能性があるため（注：RTPストリームは、休止中にそのSSRCに対してRTCPが送信される場合、同じSSRCを使用して休止および再開できます。これらのルールは、既存のSSRCを再利用する新しいRTPストリームにのみ適用されます。
An SSRC is removed from an RTP session in one of two ways. When an endpoint stops sending RTP and RTCP packets using an SSRC, then that SSRC will eventually time out as described in Section 6.3.5 of [RFC3550]. Alternatively, an SSRC can be explicitly removed from use by sending an RTCP BYE packet as described in Section 6.3.7 of [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by sending an RTCP BYE packet. Note that [RFC3550] requires that the RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session for an SSRC. If an endpoint needs to restart an RTP stream after sending an RTCP BYE for its SSRC, it needs to generate a new SSRC value for that stream.
SSRCは、2つの方法のいずれかでRTPセッションから削除されます。エンドポイントがSSRCを使用したRTPおよびRTCPパケットの送信を停止すると、[RFC3550]のセクション6.3.5で説明されているように、SSRCは最終的にタイムアウトします。または、[RFC3550]のセクション6.3.7で説明されているように、RTCP BYEパケットを送信することで、SSRCを明示的に使用から除外できます。 RTCP BYEパケットを送信して、SSRCを使用しないようにすることをお勧めします。 [RFC3550]では、RTCP BYEがSSRCのRTPセッションで送信された最後のRTP / RTCPパケットである必要があることに注意してください。エンドポイントがSSRCのRTCP BYEを送信した後にRTPストリームを再起動する必要がある場合、そのエンドポイントはそのストリームの新しいSSRC値を生成する必要があります。
The finality of sending RTCP BYE means that endpoints need to consider if the ceasing of transmission of an RTP stream is temporary or permanent. Temporary suspension of media transmission using a particular RTP stream (SSRC) needs to maintain that SSRC as an active participant, by continuing RTCP transmission for it. That way the media sending can be resumed immediately, knowing that the context is in place. When permanently halting transmission, a participant needs to send an RTCP BYE to allow the other participants to use the RTCP bandwidth resources and clean up their state databases.
RTCP BYEの送信の最終性は、RTPストリームの送信の停止が一時的か永続的かをエンドポイントが考慮する必要があることを意味します。特定のRTPストリーム（SSRC）を使用したメディア送信を一時的に停止するには、RTCP送信を継続することにより、そのSSRCをアクティブな参加者として維持する必要があります。これにより、コンテキストが適切であることを認識して、メディア送信をすぐに再開できます。送信を永続的に停止する場合、参加者はRTCP BYEを送信して、他の参加者がRTCP帯域幅リソースを使用し、状態データベースをクリーンアップできるようにする必要があります。
An endpoint that ceases transmission of all its RTP streams but remains in the RTP session MUST maintain at least one SSRC that is to be used for RTCP reporting and feedback (i.e., it cannot send a BYE for all SSRCs, but needs to retain at least one active SSRC). As some Feedback packets can be bound to media type, there might be a need to maintain one SSRC per media type within an RTP session. An alternative can be to create a new SSRC to use for RTCP reporting and feedback. However, to avoid the perception that an endpoint drops completely out of an RTP session, such a new SSRC ought to be established first -- before terminating all the existing SSRCs.
すべてのRTPストリームの送信を停止するが、RTPセッションに残っているエンドポイントは、RTCPレポートとフィードバックに使用される少なくとも1つのSSRCを維持する必要があります（つまり、すべてのSSRCにBYEを送信できませんが、少なくとも保持する必要があります1つのアクティブなSSRC）。一部のフィードバックパケットはメディアタイプにバインドできるため、RTPセッション内でメディアタイプごとに1つのSSRCを維持する必要がある場合があります。別の方法として、RTCPレポートとフィードバックに使用する新しいSSRCを作成することもできます。ただし、エンドポイントがRTPセッションから完全にドロップするという認識を回避するには、既存のすべてのSSRCを終了する前に、そのような新しいSSRCを最初に確立する必要があります。
An RTP session has a single set of parameters that configure the session bandwidth. These are the RTCP sender and receiver fractions (e.g., the SDP "b=RR:" and "b=RS:" lines [RFC3556]) and the parameters of the RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence, the base RTCP reporting interval, before randomization, will be the same for every sending SSRC in an RTP session. Similarly, every receiving SSRC in an RTP session will have the same base reporting interval, although this can differ from the reporting interval chosen by sending SSRCs. This uniform RTCP reporting interval for all SSRCs can result in RTCP reports being sent more often, or too seldom, than is considered desirable for an RTP stream.
RTPセッションには、セッション帯域幅を構成するパラメータの単一のセットがあります。これらは、RTCPの送信側と受信側の比率（例：SDP "b = RR："および "b = RS："行[RFC3556]）とRTP / AVPFプロファイルのパラメーター[RFC4585]（例：trr-int）です。そのプロファイル（またはそのセキュア拡張、RTP / SAVPF [RFC5124]）が使用されている場合。結果として、ランダム化前の基本RTCPレポート間隔は、RTPセッションで送信するすべてのSSRCで同じになります。同様に、RTPセッションで受信するすべてのSSRCには同じベースレポート間隔がありますが、これはSSRCを送信することによって選択されたレポート間隔とは異なる場合があります。すべてのSSRCのこの均一なRTCPレポート間隔により、RTPストリームに望ましいと見なされるよりも頻繁に、またはめったに送信されないRTCPレポートが発生する可能性があります。
For example, consider a scenario in which an audio flow sending at tens of kilobits per second is multiplexed into an RTP session with a multi-megabit high-quality video flow. If the session bandwidth is configured based on the video sending rate, and the default RTCP bandwidth fraction of 5% of the session bandwidth is used, it is likely that the RTCP bandwidth will exceed the audio sending rate. If the reduced minimum RTCP interval described in Section 6.2 of [RFC3550] is then used in the session, as appropriate for video where rapid feedback on damaged I-frames is wanted, the uniform reporting interval for all senders could mean that audio sources are expected to send RTCP packets more often than they send audio data packets. This bandwidth mismatch can be reduced by careful tuning of the RTCP parameters, especially trr_int when the RTP/AVPF profile is used, but cannot be avoided entirely as it is inherent in the design of the RTCP timing rules, and affects all RTP sessions that contain flows with greatly mismatched bandwidth.
たとえば、毎秒数十キロビットで送信するオーディオフローが、マルチメガビットの高品質ビデオフローを使用してRTPセッションに多重化されるシナリオを考えてみます。セッションの帯域幅がビデオ送信レートに基づいて構成され、セッション帯域幅の5％のデフォルトのRTCP帯域幅の割合が使用されている場合、RTCP帯域幅がオーディオの送信レートを超える可能性があります。 [RFC3550]のセクション6.2で説明されている短縮された最小RTCP間隔がセッションで使用される場合、破損したIフレームに関する迅速なフィードバックが必要なビデオに適切である場合、すべての送信者の均一なレポート間隔は、オーディオソースが期待されることを意味します。オーディオデータパケットを送信するよりも頻繁にRTCPパケットを送信する。この帯域幅の不一致は、RTCPパラメータ、特にRTP / AVPFプロファイルを使用する場合のtrr_intを注意深く調整することで減らすことができますが、RTCPタイミングルールの設計に固有であり、これを含むすべてのRTPセッションに影響するため、完全に回避することはできません。帯域幅が大きく一致しないフロー。
Different media rates or desired RTCP behaviors can also occur with SSRCs carrying the same media type. A common case in multiparty conferencing is when a small number of video streams are shown in high resolution, while the others are shown as low-resolution thumbnails, with the choice of which is shown in high resolution being voice-activity controlled. Here the differences are both in actual media rate and in choices for what feedback messages might be needed. Other examples of differences that can exist are due to the intended usage of a media source. A media source carrying the video of the speaker in a conference is different from a document camera. Basic parameters that can differ in this case are frame-rate, acceptable end-to-end delay, and the Signal-to-Noise Ratio (SNR) fidelity of the image. These differences affect not only the needed bitrates, but also possible transmission behaviors, usable repair mechanisms, what feedback messages the control and repair requires, the transmission requirements on those feedback messages, and monitoring of the RTP stream delivery. Other similar scenarios can also exist.
同じメディアタイプを伝送するSSRCでも、異なるメディアレートやRTCPの望ましい動作が発生する可能性があります。マルチパーティ会議の一般的なケースは、少数のビデオストリームが高解像度で表示され、その他は低解像度のサムネイルとして表示され、音声アクティビティで制御される高解像度で表示が選択される場合です。ここでの違いは、実際のメディアレートと、必要なフィードバックメッセージの選択肢の両方です。存在する可能性のあるその他の違いの例は、メディアソースの使用目的によるものです。会議で話し手のビデオを運ぶメディアソースは、書画カメラとは異なります。この場合に異なる可能性がある基本的なパラメーターは、フレームレート、許容可能なエンドツーエンドの遅延、および画像の信号対ノイズ比（SNR）の忠実度です。これらの違いは、必要なビットレートだけでなく、可能な伝送動作、使用可能な修復メカニズム、制御と修復に必要なフィードバックメッセージ、それらのフィードバックメッセージの伝送要件、RTPストリーム配信の監視にも影響します。他の同様のシナリオも存在する可能性があります。
Sending multiple media types in a single RTP session causes that session to contain more SSRCs than if each media type was sent in a separate RTP session. For example, if two participants each send an audio and a video RTP stream in a single RTP session, that session will comprise four SSRCs; but if separate RTP sessions had been used for audio and video, each of those two RTP sessions would comprise only two SSRCs. Hence, sending multiple RTP streams in an RTP session increases the amount of cross reporting between the SSRCs, as each SSRC reports on all other SSRCs in the session. This increases the size of the RTCP reports, causing them to be sent less often than would be the case if separate RTP sessions where used for a given RTCP bandwidth.
単一のRTPセッションで複数のメディアタイプを送信すると、そのセッションには、各メディアタイプが個別のRTPセッションで送信された場合よりも多くのSSRCが含まれます。たとえば、2人の参加者がそれぞれ単一のRTPセッションでオーディオとビデオのRTPストリームを送信する場合、そのセッションは4つのSSRCで構成されます。ただし、オーディオとビデオに別々のRTPセッションが使用された場合、これらの2つのRTPセッションはそれぞれ2つのSSRCのみで構成されます。したがって、RTPセッションで複数のRTPストリームを送信すると、各SSRCがセッション内の他のすべてのSSRCについてレポートするため、SSRC間のクロスレポートの量が増加します。これにより、RTCPレポートのサイズが大きくなり、特定のRTCP帯域幅で個別のRTPセッションを使用する場合よりも、送信頻度が少なくなります。
Finally, when an RTP session contains multiple media types, it is important to note that the RTCP reception quality reports, feedback messages, and extended report blocks used might not be applicable to all media types. Endpoints will need to consider the media type of each SSRC, and only send or process reports and feedback that apply to that particular SSRC and its media type. Signaling solutions might have shortcomings when it comes to indicating that a particular set of RTCP reports or feedback messages only apply to a particular media type within an RTP session.
最後に、RTPセッションに複数のメディアタイプが含まれている場合、使用されるRTCP受信品質レポート、フィードバックメッセージ、および拡張レポートブロックがすべてのメディアタイプに適用できるとは限らないことに注意することが重要です。エンドポイントは、各SSRCのメディアタイプを考慮し、その特定のSSRCとそのメディアタイプに適用されるレポートとフィードバックのみを送信または処理する必要があります。 RTCPレポートまたはフィードバックメッセージの特定のセットがRTPセッション内の特定のメディアタイプにのみ適用されることを示す場合、シグナリングソリューションには欠点がある場合があります。
From an RTCP perspective, therefore, it can be seen that there are advantages to using separate RTP sessions for each media source, rather than sending multiple media sources in a single RTP session. However, these are frequently offset by the need to reduce port use, to ease NAT/firewall traversal, achieved by combining media sources into a single RTP session. The following sections consider some of the issues with using RTCP in sessions with multiple media sources in more detail.
したがって、RTCPの観点からは、単一のRTPセッションで複数のメディアソースを送信するよりも、メディアソースごとに個別のRTPセッションを使用する方が有利であることがわかります。ただし、これらは、メディアソースを単一のRTPセッションに結合することによって達成される、NAT /ファイアウォールトラバーサルを容易にするために、ポートの使用を減らす必要性によってしばしば相殺されます。以下のセクションでは、複数のメディアソースとのセッションでRTCPを使用する場合のいくつかの問題について詳しく説明します。
Various issues have been identified with timing out SSRC values when sending multiple RTP streams in an RTP session.
RTPセッションで複数のRTPストリームを送信するときのSSRC値のタイムアウトに関するさまざまな問題が確認されています。
The RTP/AVPF profile includes a method to prevent regular RTCP reports from being sent too often. This mechanism is described in Section 3.5.3 of [RFC4585]; it is controlled by the T_rr_interval parameter. It works as follows. When a regular RTCP report is sent, a new random value, T_rr_current_interval, is generated, drawn evenly in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is to be sent earlier than T_rr_current_interval seconds after the previous regular RTCP packet, and there are no feedback messages to be sent, then that regular RTCP packet is suppressed and the next regular RTCP packet is scheduled. The T_rr_current_interval is recalculated each time a regular RTCP packet is sent. The benefit of suppression is that it avoids wasting bandwidth when there is nothing requiring frequent RTCP transmissions, but still allows utilization of the configured bandwidth when feedback is needed.
RTP / AVPFプロファイルには、通常のRTCPレポートが頻繁に送信されないようにする方法が含まれています。このメカニズムは、[RFC4585]のセクション3.5.3で説明されています。 T_rr_intervalパラメータによって制御されます。次のように動作します。通常のRTCPレポートが送信されると、新しいランダムな値T_rr_current_intervalが生成され、T_rr_intervalの0.5〜1.5倍の範囲で均等に描画されます。通常のRTCPパケットが前の通常のRTCPパケットのT_rr_current_interval秒より前に送信され、フィードバックメッセージが送信されない場合、その通常のRTCPパケットは抑制され、次の通常のRTCPパケットがスケジュールされます。 T_rr_current_intervalは、通常のRTCPパケットが送信されるたびに再計算されます。抑制の利点は、頻繁なRTCP送信を必要とするものが何もない場合に帯域幅を浪費することを回避しながら、フィードバックが必要なときに構成された帯域幅を利用できることです。
Unfortunately, this suppression mechanism skews the distribution of the RTCP sending intervals compared to the regular RTCP reporting intervals. The standard RTCP timing rules, including reconsideration and the compensation factor, result in the intervals between sending RTCP packets having a distribution that is skewed towards the upper end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the deterministic calculated RTCP reporting interval. With Td = 5 s, this distribution covers the range [2.052 s, 6.156 s]. In comparison, the RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5 times T_rr_interval; for T_rr_interval = 5s, this is [2.5 s, 7.5 s].
残念ながら、この抑制メカニズムは、通常のRTCPレポート間隔と比較して、RTCP送信間隔の分布を歪めます。再検討と補正係数を含む標準のRTCPタイミングルールにより、範囲[0.5 / 1.21828、1.5 / 1.21828] * Tdに向かって歪んだ分布を持つRTCPパケットの送信間隔は、Tdであり、決定論的に計算されたRTCPレポート間隔。 Td = 5秒の場合、この分布は[2.052秒、6.156秒]の範囲をカバーします。これに対して、RTP / AVPF抑制ルールはT_rr_intervalの0.5〜1.5倍の間隔で機能します。 T_rr_interval = 5秒の場合、これは[2.5秒、7.5秒]です。
The effect of this is that the time between consecutive RTCP packets when using T_rr_interval suppression can become large. The maximum time interval between sending one regular RTCP packet and the next, when T_rr_interval is being used, occurs when T_rr_current_interval takes its maximum value and a regular RTCP packet is suppressed at the end of the suppression period, then the next regular RTCP packet is scheduled after its largest possible reporting interval. Taking the worst case of the two intervals gives a maximum time between two RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td.
この影響は、T_rr_interval抑制を使用する場合、連続するRTCPパケット間の時間が長くなる可能性があることです。 T_rr_current_intervalが最大値をとり、抑制期間の最後に通常のRTCPパケットが抑制されたときに、T_rr_intervalが使用されているときに、1つの通常のRTCPパケットと次のRTCPパケットが送信されるまでの最大時間間隔は、次の通常のRTCPパケットがスケジュールされます。可能な最大のレポート間隔の後。 2つの間隔の最悪の場合、2つのRTCPレポート間の最大時間は1.5 * T_rr_interval + 1.5 / 1.21828 * Tdになります。
This behavior can be surprising when Td and T_rr_interval have the same value. That is, when T_rr_interval is configured to match the regular RTCP reporting interval. In this case, one might expect that regular RTCP packets are sent according to their usual schedule, but feedback packets can be sent early. However, the above-mentioned issue results in the RTCP packets actually being sent in the range [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but is not a problem in itself. However, when coupled with packet loss, it raises the issue of premature timeout.
TdとT_rr_intervalの値が同じである場合、この動作は驚くべきことです。つまり、T_rr_intervalが通常のRTCPレポート間隔と一致するように構成されている場合。この場合、通常のRTCPパケットは通常のスケジュールに従って送信されますが、フィードバックパケットは早く送信される可能性があります。ただし、上記の問題により、RTCPパケットは実際には[0.41 * Td、1.23 * Td]の範囲ではなく、非常に不均一な分布で[0.5 * Td、2.731 * Td]の範囲で送信されます。これはおそらく予想外ですが、それ自体は問題ではありません。ただし、パケット損失と組み合わせると、時期尚早のタイムアウトの問題が発生します。
In RTP/AVP [RFC3550] the timeout behavior is simple; it is 5 times Td, where Td is calculated with a Tmin value of 5 seconds. In other words, if the configured RTCP bandwidth allows for an average RTCP reporting interval shorter than 5 seconds, the timeout is 25 seconds of no activity from the SSRC (RTP or RTCP); otherwise, the timeout is 5 average reporting intervals.
RTP / AVP [RFC3550]では、タイムアウトの動作は単純です。これはTdの5倍です。Tdは5秒のTmin値で計算されます。つまり、設定されたRTCP帯域幅が5秒未満の平均RTCPレポート間隔を許容する場合、タイムアウトはSSRC（RTPまたはRTCP）からのアクティビティがない場合の25秒です。それ以外の場合、タイムアウトは5つの平均レポート間隔です。
RTP/AVPF [RFC4585] introduces different timeout behaviors depending on the value of T_rr_interval. When T_rr_interval is 0, it uses the same timeout calculation as RTP/AVP. However, when T_rr_interval is non-zero, it replaces Tmin in the timeout calculation, most likely to speed up detection of timed out SSRCs. However, using a non-zero T_rr_interval has two consequences for RTP behavior.
RTP / AVPF [RFC4585]は、T_rr_intervalの値に応じて異なるタイムアウト動作を導入します。 T_rr_intervalが0の場合、RTP / AVPと同じタイムアウト計算を使用します。ただし、T_rr_intervalがゼロ以外の場合、タイムアウト計算のTminに置き換わり、タイムアウトしたSSRCの検出を高速化する可能性が最も高くなります。ただし、ゼロ以外のT_rr_intervalを使用すると、RTPの動作に2つの影響があります。
First, due to suppression, the number of RTP and RTCP packets sent by an SSRC that is not an active RTP sender can become very low, because of the issue discussed in Section 7.1.1. As the RTCP packet interval can be as long as 2.73*Td, during a 5*Td time period, an endpoint might in fact transmit only a single RTCP packet. The long intervals result in fewer RTCP packets, to a point where a single RTCP packet loss can sometimes result in timing out an SSRC.
まず、抑制により、アクティブなRTP送信者ではないSSRCによって送信されるRTPおよびRTCPパケットの数は、セクション7.1.1で説明されている問題のために非常に少なくなる可能性があります。 RTCPパケットの間隔は2.73 * Tdと長くなる可能性があるため、5 * Tdの期間中、エンドポイントは実際には単一のRTCPパケットのみを送信する可能性があります。間隔が長いとRTCPパケットが少なくなり、1つのRTCPパケットが失われるとSSRCがタイムアウトすることがあります。
Second, the RTP/AVPF changes to the timeout rules reduce robustness to misconfiguration. It is common to use RTP/AVPF configured such that RTCP packets can be sent frequently to allow rapid feedback;
次に、タイムアウトルールに対するRTP / AVPFの変更により、設定ミスに対する堅牢性が低下します。迅速なフィードバックを可能にするためにRTCPパケットを頻繁に送信できるように構成されたRTP / AVPFを使用するのが一般的です。
however, this makes timeouts very sensitive to T_rr_interval. For example, if two SSRCs are configured, one with T_rr_interval = 0.1 s and the other with T_rr_interval = 0.6 s, then this small difference will result in the SSRC with the shorter T_rr_interval timing out the other if it stops sending RTP packets, since the other RTCP reporting interval is more than five times its own. When RTP/AVP is used, or RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout period will be 25 s, and differences between configured RTCP bandwidth can only cause premature timeouts when the reporting intervals are greater than 5 s and differ by a factor of five. To limit the scope for such problematic misconfiguration, we define an update to the RTP/AVPF timeout rules in Section 7.1.4.
ただし、これにより、タイムアウトはT_rr_intervalに非常に敏感になります。たとえば、2つのSSRCが構成されている場合、1つはT_rr_interval = 0.1秒、もう1つはT_rr_interval = 0.6秒であり、この小さな違いにより、SSRCはRTPパケットの送信を停止すると、RTPパケットの送信を停止すると、もう一方のタイムアウトが短くなります。他のRTCPレポート間隔は、それ自体の5倍以上です。 RTP / AVP、またはT_rr_interval = 0のRTP / AVPFが使用されている場合、タイムアウト期間は25秒であり、設定されたRTCP帯域幅の違いは、レポート間隔が次の値よりも大きい場合にのみ、早期タイムアウトを引き起こす可能性があるため、問題ではありません。 5秒で、5倍異なります。このような問題のある誤設定の範囲を制限するために、セクション7.1.4でRTP / AVPFタイムアウトルールの更新を定義します。
If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their secure variants) are combined within a single RTP session, and the RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly below 5 seconds, there is a risk that the RTP/AVPF endpoints will prematurely time out the SSRCs of the RTP/AVP endpoints, due to their different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints use a T_rr_interval that is significantly larger than 5 seconds, there is a risk that the RTP/AVP endpoints will time out the SSRCs of the RTP/AVPF endpoints.
RTP / AVPおよびRTP / AVPFプロファイル（またはそれらの安全なバリアント）を実装するエンドポイントが単一のRTPセッション内で結合され、RTP / AVPFエンドポイントが5秒を大幅に下回るゼロ以外のT_rr_intervalを使用する場合、次のようなリスクがあります。 RTP / AVPFエンドポイントは、RTPタイムアウトルールが異なるため、RTP / AVPエンドポイントのSSRCが時期尚早にタイムアウトします。逆に、RTP / AVPFエンドポイントが5秒を大幅に超えるT_rr_intervalを使用する場合、RTP / AVPエンドポイントがRTP / AVPFエンドポイントのSSRCをタイムアウトにするリスクがあります。
Mixing endpoints using two different RTP profiles within a single RTP session is NOT RECOMMENDED. However, if mixed RTP profiles are used, and the RTP/AVPF endpoints are not updated to follow Section 7.1.4 of this memo, then the RTP/AVPF session SHOULD be configured to use T_rr_interval = 4 seconds to avoid premature timeouts.
1つのRTPセッション内で2つの異なるRTPプロファイルを使用してエンドポイントを混在させることはお勧めしません。ただし、混合RTPプロファイルが使用されており、RTP / AVPFエンドポイントがこのメモのセクション7.1.4に従って更新されていない場合、RTP / AVPFセッションは、早期タイムアウトを回避するためにT_rr_interval = 4秒を使用するように構成する必要があります。
The choice of T_rr_interval = 4 seconds for interoperability might appear strange. Intuitively, this value ought to be 5 seconds, to make both the RTP/AVP and RTP/AVPF use the same timeout period. However, the behavior outlined in Section 7.1.1 shows that actual RTP/AVPF reporting intervals can be longer than expected. Setting T_rr_interval = 4 seconds gives actual RTCP intervals near to those expected by RTP/AVP, ensuring interoperability.
相互運用性のためのT_rr_interval = 4秒の選択は奇妙に見えるかもしれません。直感的には、RTP / AVPとRTP / AVPFの両方が同じタイムアウト期間を使用するようにするには、この値を5秒にする必要があります。ただし、セクション7.1.1で概説されている動作は、実際のRTP / AVPFレポート間隔が予想よりも長くなる可能性があることを示しています。 T_rr_interval = 4秒に設定すると、RTP / AVPが期待する間隔に近い実際のRTCP間隔が提供され、相互運用性が保証されます。
To ensure interoperability and avoid premature timeouts, all SSRCs in an RTP session MUST use the same timeout behavior. However, previous specifications are inconsistent in this regard. To avoid interoperability issues, this memo updates the timeout rules as follows:
相互運用性を確保し、早期タイムアウトを回避するには、RTPセッションのすべてのSSRCが同じタイムアウト動作を使用する必要があります。ただし、以前の仕様はこの点で一貫していません。相互運用性の問題を回避するために、このメモはタイムアウト規則を次のように更新します。
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the timeout interval SHALL be calculated using a multiplier of five times the deterministic RTCP reporting interval. That is, the timeout interval SHALL be 5*Td.
o RTP / AVP、RTP / SAVP、RTP / AVPF、およびRTP / SAVPFプロファイルの場合、タイムアウト間隔は、確定的RTCPレポート間隔の5倍の乗数を使用して計算する必要があります（SHALL）。つまり、タイムアウト間隔は5 * Tdである必要があります。
o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, calculation of Td, for the purpose of calculating the participant timeout only, SHALL be done using a Tmin value of 5 seconds and not the reduced minimal interval, even if the reduced minimum interval is used to calculate RTCP packet transmission intervals.
o RTP / AVP、RTP / SAVP、RTP / AVPF、およびRTP / SAVPFプロファイルの場合、Tdの計算は、参加者のタイムアウトのみを計算する目的で、5秒のTmin値を使用して行われ、短縮された最小間隔は使用されません。減少した最小間隔を使用してRTCPパケット送信間隔を計算する場合でも。
This changes the behavior for the RTP/AVPF or RTP/SAVPF profiles when T_rr_interval != 0. Specifically, the first paragraph of Section 3.5.4 of [RFC4585] is updated to use Tmin instead of T_rr_interval in the timeout calculation for RTP/AVPF entities.
これにより、T_rr_interval！= 0の場合のRTP / AVPFまたはRTP / SAVPFプロファイルの動作が変更されます。具体的には、[RFC4585]のセクション3.5.4の最初の段落が更新され、RTP / AVPFのタイムアウト計算でT_rr_intervalではなくTminが使用されますエンティティ。
This subsection discusses what tuning can be done to reduce the downsides of the shared RTCP packet intervals. First, what possibilities exist for the RTP/AVP [RFC3551] profile are listed followed by what additional tools are provided by RTP/AVPF [RFC4585].
このサブセクションでは、共有RTCPパケット間隔のマイナス面を減らすために実行できるチューニングについて説明します。最初に、RTP / AVP [RFC3551]プロファイルに存在する可能性があるものをリストし、次にRTP / AVPF [RFC4585]によって提供される追加のツールをリストします。
When using the RTP/AVP or RTP/SAVP profiles, the options for tuning the RTCP reporting intervals are limited to the RTCP sender and receiver bandwidth, and whether the minimum RTCP interval is scaled according to the bandwidth. As the scheduling algorithm includes both randomization and reconsideration, one cannot simply calculate the expected average transmission interval using the formula for Td given in Section 6.3.1 of [RFC3550]. However, by considering the inputs to that expression, and the randomization and reconsideration rules, we can begin to understand the behavior of the RTCP transmission interval.
RTP / AVPまたはRTP / SAVPプロファイルを使用する場合、RTCPレポート間隔を調整するためのオプションは、RTCP送信側と受信側の帯域幅、および最小RTCP間隔が帯域幅に従ってスケーリングされるかどうかに制限されます。スケジューリングアルゴリズムにはランダム化と再検討の両方が含まれているため、[RFC3550]のセクション6.3.1に示されているTdの式を使用して予想平均送信間隔を単純に計算することはできません。ただし、その式への入力、およびランダム化と再検討のルールを考慮することにより、RTCP送信間隔の動作を理解し始めることができます。
Let's start with some basic observations:
いくつかの基本的な観察から始めましょう：
a. Unless the scaled minimum RTCP interval is used, Td prior to randomization and reconsideration can never be less than Tmin. The default value of Tmin is 5 seconds.
a. スケーリングされた最小RTCP間隔が使用されない限り、ランダム化と再検討の前のTdがTminよりも小さくなることはありません。 Tminのデフォルト値は5秒です。
b. If the scaled minimum RTCP interval is used, Td can become as low as 360 divided by RTP Session bandwidth in kilobits per second. In SDP, the RTP session bandwidth is signaled using a "b=AS" line. An RTP Session bandwidth of 72 kbps results in Tmin being 5 seconds. An RTP session bandwidth of 360 kbps of course gives a Tmin of 1 second, and to achieve a Tmin equal to once every frame for a 25 frame-per-second video stream requires an RTP session bandwidth of 9 Mbps. Use of the RTP/AVPF or RTP/SAVPF profile allows more frequent RTCP reports for the same bandwidth, as discussed below.
b. スケーリングされた最小RTCP間隔が使用される場合、Tdは、毎秒キロビット単位のRTPセッション帯域幅で割った360まで低くなる可能性があります。 SDPでは、RTPセッション帯域幅は「b = AS」ラインを使用して通知されます。 72 kbpsのRTPセッション帯域幅により、Tminは5秒になります。もちろん、360 kbpsのRTPセッション帯域幅では1秒のTminが与えられ、25フレーム/秒のビデオストリームでフレームごとに1回のTminを達成するには、9 MbpsのRTPセッション帯域幅が必要です。以下で説明するように、RTP / AVPFまたはRTP / SAVPFプロファイルを使用すると、同じ帯域幅についてより頻繁なRTCPレポートが可能になります。
c. The value of Td scales with the number of SSRCs and the average size of the RTCP reports to keep the overall RTCP bandwidth constant.
c. Tdの値は、全体的なRTCP帯域幅を一定に保つために、SSRCの数とRTCPレポートの平均サイズに比例します。
d. The actual transmission interval for a Td value is in the range [0.5*Td/1.21828, 1.5*Td/1.21828], and the distribution is skewed, due to reconsideration, with the majority of the probability mass being above Td. This means, for example, that for Td = 5 s, the actual transmission interval will be distributed in the range [2.052 s, 6.156 s], and tending towards the upper half of the interval. Note that Tmin parameter limits the value of Td before randomization and reconsideration are applied, so the actual transmission interval will cover a range extending below Tmin.
d. Td値の実際の送信間隔は[0.5 * Td / 1.21828、1.5 * Td / 1.21828]の範囲内にあり、再考により分布が歪んでおり、確率質量の大部分がTdを上回っています。これは、たとえば、Td = 5秒の場合、実際の送信間隔は[2.052秒、6.156秒]の範囲で分散され、間隔の上半分に向かう傾向があることを意味します。 Tminパラメータは、ランダム化と再検討が適用される前にTdの値を制限するため、実際の送信間隔はTminより下の範囲をカバーすることに注意してください。
Given the above, we can calculate the number of SSRCs, n, that an RTP session with 5% of the session bandwidth assigned to RTCP can support while maintaining Td equal to Tmin. This will tell us how many RTP streams we can report on, keeping the RTCP overhead within acceptable bounds. We make two assumptions that simplify the calculation: that all SSRCs are senders, and that they all send compound RTCP packets comprising an SR packet with n-1 report blocks, followed by an SDES packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets will vary in size between 54 and 798 octets depending on n, up to the maximum of 31 report blocks that can be included in an SR packet). If we put this packet size, and a 5% RTCP bandwidth fraction into the RTCP interval calculation in Section 6.3.1 of [RFC3550], and calculate the value of n needed to give Td = Tmin for the scaled minimum interval, we find n=9 SSRCs can be supported (irrespective of the interval, due to the way the reporting interval scales with the session bandwidth). We see that to support more SSRCs without changing the scaled minimum interval, we need to increase the RTCP bandwidth fraction from 5%; changing the session bandwidth to a higher value would reduce the Tmin. However, if using the default 5% allocation of RTCP bandwidth, an increase will result in more SSRCs being supported given a fixed Td target.
上記のことから、RTCPに割り当てられたセッション帯域幅の5％のRTPセッションがTdをTminに維持しながらサポートできるSSRCの数nを計算できます。これにより、レポートできるRTPストリームの数がわかり、RTCPオーバーヘッドを許容範囲内に保ちます。計算を簡略化する2つの仮定を行います。すべてのSSRCは送信者であり、n-1レポートブロックを含むSRパケットを含む複合RTCPパケットを送信し、その後に16オクテットのCNAME値[RFC7022]を含むSDESパケットを送信します（このようなRTCPパケットのサイズは、nに応じて54〜798オクテットで異なり、SRパケットに含めることができる最大31のレポートブロックまでです。このパケットサイズと5％のRTCP帯域幅の割合を[RFC3550]のセクション6.3.1のRTCP間隔計算に入れ、スケーリングされた最小間隔のTd = Tminを与えるために必要なnの値を計算すると、nがわかります= 9のSSRCをサポートできます（間隔に関係なく、レポート間隔がセッション帯域幅に応じて変化するため）。スケーリングされた最小間隔を変更せずにより多くのSSRCをサポートするには、RTCP帯域幅の割合を5％から増やす必要があることがわかります。セッション帯域幅を高い値に変更すると、Tminが減少します。ただし、RTCP帯域幅のデフォルトの5％割り当てを使用している場合、増加すると、固定Tdターゲットを指定した場合にサポートされるSSRCが増えます。
Based on the above, when using the RTP/AVP profile or the RTP/SAVP profile, the key limitation for rapid RTCP reporting in small unicast sessions is going to be the Tmin value. The RTP session bandwidth configured in RTCP has to be sufficiently high to reach the reporting goals the application has following the rules for the scaled minimal RTCP interval.
上記に基づいて、RTP / AVPプロファイルまたはRTP / SAVPプロファイルを使用する場合、小さなユニキャストセッションでの高速RTCPレポートの主な制限はTmin値になります。 RTCPで構成されたRTPセッション帯域幅は、アプリケーションがスケーリングされた最小RTCP間隔のルールに従っているレポート目標に到達するのに十分な高さである必要があります。
When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool for tuning RTCP transmissions: the T_rr_interval parameter. Use of this parameter allows short RTCP reporting intervals; alternatively it gives the ability to sent frequent RTCP feedback without sending frequent regular RTCP reports.
RTP / AVPFまたはRTP / SAVPFを使用する場合、RTCP送信を調整するための強力な追加ツール、T_rr_intervalパラメーターがあります。このパラメーターを使用すると、RTCPレポート間隔を短くできます。あるいは、頻繁な定期的なRTCPレポートを送信せずに、頻繁なRTCPフィードバックを送信する機能を提供します。
The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set to a value greater than zero but smaller than Tmin allows more frequent RTCP feedback than the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This happens because Tmin is set to zero after the transmission of the initial RTCP report, causing the reporting interval for later packet to be determined by the usual RTCP bandwidth-based calculation, with Tmin=0, and the T_rr_interval. This has the effect that we are no longer restricted by the minimal interval (whether the default 5-second minimum or the reduced minimum interval). Rather, the RTCP bandwidth and the T_rr_interval are the governing factors, allowing faster feedback. Applications that care about rapid regular RTCP feedback ought to consider using the RTP/ AVPF or RTP/SAVPF profile, even if they don't use the feedback features of that profile.
T_rr_intervalを0より大きくTminよりも小さい値に設定してRTP / AVPFまたはRTP / SAVPFプロファイルを使用すると、特定のRTCP帯域幅について、RTP / AVPまたはRTP / SAVPプロファイルよりも頻繁にRTCPフィードバックを行うことができます。これは、初期RTCPレポートの送信後にTminがゼロに設定され、その後のパケットのレポート間隔が、Tmin = 0およびT_rr_intervalを使用した通常のRTCP帯域幅ベースの計算によって決定されるために発生します。これにより、最小間隔（デフォルトの5秒の最小間隔または短縮された最小間隔）による制限がなくなります。むしろ、RTCP帯域幅とT_rr_intervalが支配的な要素であり、より高速なフィードバックを可能にします。急速な定期的なRTCPフィードバックを重視するアプリケーションは、RTP / AVPFまたはRTP / SAVPFプロファイルを使用することを検討する必要があります。そのプロファイルのフィードバック機能を使用しない場合でも同様です。
The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback packets to be sent frequently, without also requiring regular RTCP reports to be sent frequently, since T_rr_interval limits the rate at which regular RTCP packets can be sent, while still permitting RTCP feedback packets to be sent. Applications that can use feedback packets for some RTP streams, e.g., video streams, but don't want frequent regular reporting for other RTP streams, can configure the T_rr_interval to a value so that the regular reporting for both audio and video is at a level that is considered acceptable for the audio. They could then use feedback packets, which will include RTCP SR/RR packets unless reduced size RTCP feedback packets [RFC5506] are used, for the video reporting. This allows the available RTCP bandwidth to be devoted on the feedback that provides the most utility for the application.
RTP / AVPFまたはRTP / SAVPFプロファイルを使用すると、RTCPを許可しながら、通常のRTCPパケットを送信できるレートがT_rr_intervalによって制限されるため、RTCPフィードバックパケットを頻繁に送信できます。送信されるフィードバックパケット。一部のRTPストリーム（ビデオストリームなど）にフィードバックパケットを使用できるが、他のRTPストリームの頻繁な定期レポートを望まないアプリケーションは、オーディオとビデオの両方の定期レポートが一定のレベルになるようにT_rr_intervalを値に設定できますそれはオーディオにとって許容できると見なされます。次に、ビデオレポートのために、縮小サイズのRTCPフィードバックパケット[RFC5506]が使用されない限り、RTCP SR / RRパケットを含むフィードバックパケットを使用できます。これにより、アプリケーションに最も有用なフィードバックを提供するために、利用可能なRTCP帯域幅を割り当てることができます。
Using T_rr_interval still requires one to determine suitable values for the RTCP bandwidth value. Indeed, it might make this choice even more important, as this is more likely to affect the RTCP behavior and performance than when using the RTP/AVP or RTP/SAVP profile, as there are fewer limitations affecting the RTCP transmission.
T_rr_intervalを使用する場合でも、RTCP帯域幅値の適切な値を決定する必要があります。実際、RTCP送信に影響する制限が少ないため、RTP / AVPまたはRTP / SAVPプロファイルを使用する場合よりもRTCPの動作とパフォーマンスに影響を与える可能性が高いため、この選択がさらに重要になる可能性があります。
When T_rr_interval is non-zero, there are configurations that need to be avoided. If the RTCP bandwidth chosen is such that the Td value is smaller than, but close to, T_rr_interval, then the actual regular RTCP packet transmission interval can become very large, as discussed in Section 7.1.1. Therefore, for configuration where one intends to have Td smaller than T_rr_interval, then Td is RECOMMENDED to be targeted at values less than 1/4th of T_rr_interval, which results in the range becoming [0.5*T_rr_interval, 1.81*T_rr_interval].
T_rr_intervalがゼロ以外の場合、回避する必要がある構成があります。選択されたRTCP帯域幅が、Td値がT_rr_intervalよりも小さい（T_rr_intervalに近い）場合、セクション7.1.1で説明したように、実際の通常のRTCPパケット送信間隔は非常に大きくなる可能性があります。したがって、TdをT_rr_intervalよりも小さくしようとする構成の場合、TdはT_rr_intervalの1/4未満の値をターゲットにすることをお勧めします。その結果、範囲は[0.5 * T_rr_interval、1.81 * T_rr_interval]になります。
With the RTP/AVPF or RTP/SAVPF profiles, using T_rr_interval = 0 has utility and results in a behavior where the RTCP transmission is only limited by the bandwidth, i.e., no Tmin limitations at all. This allows more frequent regular RTCP reporting than can be achieved using the RTP/AVP profile. Many configurations of RTCP will not consume all the bandwidth that they have been configured to use, but this configuration will consume what it has been given. Note that the same behavior will be achieved as long as T_rr_interval is smaller than 1/3 of Td as that prevents T_rr_interval from affecting the transmission.
RTP / AVPFまたはRTP / SAVPFプロファイルの場合、T_rr_interval = 0を使用すると実用性があり、RTCP送信が帯域幅によってのみ制限される、つまりTmin制限がまったくないという動作になります。これにより、RTP / AVPプロファイルを使用して達成できるよりも、より頻繁な定期的なRTCPレポートが可能になります。 RTCPの多くの構成は、それらが使用するように構成されているすべての帯域幅を消費するわけではありませんが、この構成は与えられたものを消費します。 T_rr_intervalが送信に影響を与えないようにするため、T_rr_intervalがTdの1/3より小さい限り、同じ動作が実現されることに注意してください。
There exists no method for using different regular RTCP reporting intervals depending on the media type or individual RTP stream, other than using a separate RTP session for each type or stream.
タイプまたはストリームごとに個別のRTPセッションを使用する以外に、メディアタイプまたは個々のRTPストリームに応じて異なる通常のRTCPレポート間隔を使用する方法はありません。
When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the cryptographic context of a compound secure RTCP packet is the SSRC of the sender of the first RTCP (sub-)packet. This could matter in some cases, especially for keying mechanisms such as MIKEY [RFC3830] that allow use of per-SSRC keying.
セキュアRTPプロトコル（RTP / SAVP）[RFC3711]、またはフィードバックプロファイルのセキュアバリアント（RTP / SAVPF）[RFC5124]を使用する場合、複合セキュアRTCPパケットの暗号化コンテキストは、最初の送信者のSSRCです。 RTCP（サブ）パケット。これは、SSRCごとのキーイングの使用を許可するMIKEY [RFC3830]などのキーイングメカニズムの場合に特に問題になることがあります。
Otherwise, the standard security considerations of RTP apply; sending multiple RTP streams from a single endpoint in a single RTP session does not appear to have different security consequences than sending the same number of RTP streams spread across different RTP sessions.
それ以外の場合は、RTPの標準的なセキュリティの考慮事項が適用されます。単一のRTPセッションで単一のエンドポイントから複数のRTPストリームを送信しても、異なるRTPセッションにまたがって同じ数のRTPストリームを送信する場合とは異なるセキュリティ上の影響があるようには見えません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。
[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, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5506] Johansson、I。およびM. Westerlund、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<http：// www .rfc-editor.org / info / rfc5506>。
[CLUE-FRAME] Duckworth, M., Ed., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", Work in Progress, draft-ietf-clue-framework-25, January 2016.
[CLUE-FRAME] Duckworth、M.、Ed。、Pepperell、A。、およびS. Wenger、「テレプレゼンスマルチストリームのフレームワーク」、作業中、draft-ietf-clue-framework-25、2016年1月。
[MULTI-RTP] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", Work in Progress, draft-ietf-avtcore-multi-media-rtp-session-13, December 2015.
[MULTI-RTP] Westerlund、M.、Perkins、C。、およびJ. Lennox、「単一のRTPセッションでの複数のタイプのメディアの送信」、作業中、draft-ietf-avtcore-multi-media-rtp-session 2015年12月13日。
[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream-optimisation-12, March 2016.
[MULTI-STREAM-OPT] Lennox、J.、Westerlund、M.、Wu、Q。、およびC. Perkins、「単一のRTPセッションでの複数のメディアストリームの送信：RTCP受信統計とその他のフィードバックのグループ化」、進行中の作業、draft-ietf-avtcore-rtp-multi-stream-optimization-12、2016年3月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, DOI 10.17487/RFC3390, October 2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「Increeasing TCP's Initial Window」、RFC 3390、DOI 10.17487 / RFC3390、2002年10月、<http://www.rfc-editor.org/info / rfc3390>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <http://www.rfc-editor.org/info/rfc3556>.
[RFC3556] Casner、S。、「RTP制御プロトコル（RTCP）帯域幅のセッション記述プロトコル（SDP）帯域幅修飾子」、RFC 3556、DOI 10.17487 / RFC3556、2003年7月、<http://www.rfc-editor.org / info / rfc3556>。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M.、and K. Norrman、 "MIKEY：Multimedia Internet KEYing"、RFC 3830、DOI 10.17487 / RFC3830、August 2004、<http： //www.rfc-editor.org/info/rfc3830>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /www.rfc-editor.org/info/rfc4588>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きのRTPオーディオビジュアルプロファイルのコーデック制御メッセージ（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008、<http://www.rfc-editor.org/info/rfc5104>。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、Ott、J。、およびT. Schierl、「Session Description Protocol（SDP）のソース固有のメディア属性」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<http：// www.rfc-editor.org/info/rfc5576>。
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190] Wenger、S.、Wang、Y.、Schierl、T。、およびA. Eleftheriadis、「RTP Payload Format for Scalable Video Coding」、RFC 6190、DOI 10.17487 / RFC6190、2011年5月、<http：// www .rfc-editor.org / info / rfc6190>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <http://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y。、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<http：//www.rfc- editor.org/info/rfc6928>。
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022] Begen、A.、Perkins、C.、Wing、D。、およびE. Rescorla、「RTP制御プロトコル（RTCP）正規名（CNAME）の選択に関するガイドライン」、RFC 7022、DOI 10.17487 / RFC7022、2013年9月、<http://www.rfc-editor.org/info/rfc7022>。
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <http://www.rfc-editor.org/info/rfc7160>.
[RFC7160] Petit-Huguenin、M。およびG. Zorn、編、「RTPセッションでの複数のクロックレートのサポート」、RFC 7160、DOI 10.17487 / RFC7160、2014年4月、<http：//www.rfc-editor .org / info / rfc7160>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<http://www.rfc-editor.org/info/rfc7667>。
[SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-36, October 2016.
[SDP-BUNDLE] Holmberg、C.、Alvestrand、H。、およびC. Jennings、「Session Description Protocol（SDP）を使用したメディア多重化のネゴシエーション」、進行中の作業、draft-ietf-mmusic-sdp-bundle-negotiation- 2016年10月36日。
[Sim88] Westerlund, M., "SIMULATION RESULTS FOR MULTI-STREAM", IETF 88 Proceedings, November 2013, <https://www.ietf.org/proceedings/88/slides/ slides-88-avtcore-0.pdf>.
[Sim88] Westerlund、M。、「マルチストリームのシミュレーション結果」、IETF 88 Proceedings、2013年11月、<https://www.ietf.org/proceedings/88/slides/ slides-88-avtcore-0.pdf >。
[Sim92] Westerlund, M., Lennox, J., Perkins, C., and Q. Wu, "Changes in RTP Multi-stream", IETF 92 Proceedings, March 2015, <https://www.ietf.org/proceedings/92/slides/ slides-92-avtcore-0.pdf>.
[Sim92] Westerlund、M.、Lennox、J.、Perkins、C.、Q。Wu、「Changes in RTP Multi-stream」、IETF 92 Proceedings、2015年3月、<https://www.ietf.org/議事録/92/slides/slides-92-avtcore-0.pdf>。
Acknowledgments
謝辞
The authors like to thank Harald Alvestrand and everyone else who has been involved in the development of this document.
著者は、Harald Alvestrandおよびこのドキュメントの開発に携わったすべての人に感謝します。
Authors' Addresses
著者のアドレス
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 United States of America
Jonathan Lennox Vidyo、Inc. 433 Hackensack Avenue Seventh Floor Hackensack、NJ 07601アメリカ合衆国
Email: jonathan@vidyo.com
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kistaスウェーデン
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQは101ソフトウェアアベニューで、Y Uは地区210012中国江蘇省NaN京を描画します
Email: bill.wu@huawei.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
コリン・パーキンスグラスゴー大学コンピューティングサイエンススクールグラスゴーG12 8QQイギリス
Email: csp@csperkins.org