7. レートが大きく異なるストリームに対する RTCP の考慮事項

RTP セッションは、セッション帯域幅を設定する単一のパラメータ集合を持つ。これらは、RTCP の送信者および受信者の割合（例えば、SDP の "b=RR:" 行および "b=RS:" 行 [RFC3556]）と、そのプロファイル（またはそのセキュア拡張である RTP/SAVPF [RFC5124]）が使用される場合の RTP/AVPF プロファイル [RFC4585] のパラメータ（例えば trr-int）である。結果として、ランダム化前の基本 RTCP 報告間隔は、RTP セッション内のすべての送信 SSRC について同じになる。同様に、RTP セッション内のすべての受信 SSRC は同じ基本報告間隔を持つが、これは送信 SSRC が選択する報告間隔とは異なることがある。すべての SSRC に対するこの均一な RTCP 報告間隔は、RTCP レポートが、ある RTP ストリームにとって望ましいと考えられるよりも頻繁に、またはあまりにまれに送信される結果となりうる。

例えば、毎秒数十キロビットで送信する音声フローが、数メガビットの高品質映像フローとともに単一の RTP セッションに多重化されるシナリオを考える。セッション帯域幅が映像の送信レートに基づいて設定され、セッション帯域幅の 5% という既定の RTCP 帯域幅割合が使用される場合、RTCP 帯域幅が音声の送信レートを超える可能性が高い。その後、[RFC3550] のセクション 6.2 で記述されている縮小最小 RTCP 間隔が、損傷した I フレームに対する迅速なフィードバックが望まれる映像に適するものとしてセッションで使用される場合、すべての送信者に対する均一な報告間隔は、音声ソースが音声データパケットを送信するよりも頻繁に RTCP パケットを送信することが期待されることを意味しうる。この帯域幅の不一致は、RTCP パラメータ、特に RTP/AVPF プロファイルが使用される場合の trr_int を注意深く調整することによって軽減できるが、RTCP タイミング規則の設計に固有のものであり、帯域幅が大きく不一致なフローを含むすべての RTP セッションに影響するため、完全に回避することはできない。

異なるメディアレートや望ましい RTCP 動作は、同じメディアタイプを運ぶ SSRC でも発生しうる。多者間会議における一般的なケースは、少数の映像ストリームが高解像度で表示され、その他が低解像度のサムネイルとして表示され、どれを高解像度で表示するかが音声アクティビティによって制御される場合である。ここでは、違いは実際のメディアレートと、どのようなフィードバックメッセージが必要とされうるかの選択の両方にある。存在しうる違いの他の例は、メディアソースの意図された用途によるものである。会議における話者の映像を運ぶメディアソースは、書画カメラとは異なる。この場合に異なりうる基本的なパラメータは、フレームレート、許容可能なエンドツーエンド遅延、および画像の信号対雑音比 (SNR) 忠実度である。これらの違いは、必要なビットレートだけでなく、可能な送信動作、使用可能な修復メカニズム、制御と修復が必要とするフィードバックメッセージ、それらのフィードバックメッセージに対する送信要件、および RTP ストリーム配信の監視にも影響する。他にも同様のシナリオが存在しうる。

単一の RTP セッションで複数のメディアタイプを送信すると、各メディアタイプを別々の RTP セッションで送信する場合よりも、そのセッションに含まれる SSRC が多くなる。例えば、2 人の参加者がそれぞれ音声と映像の RTP ストリームを単一の RTP セッションで送信する場合、そのセッションは 4 つの SSRC で構成される。しかし、音声と映像に別々の RTP セッションが使用されていた場合、それら 2 つの RTP セッションはそれぞれ 2 つの SSRC のみで構成される。したがって、RTP セッションで複数の RTP ストリームを送信すると、各 SSRC がセッション内の他のすべての SSRC について報告するため、SSRC 間の相互報告の量が増加する。これは RTCP レポートのサイズを増大させ、所与の RTCP 帯域幅に対して別々の RTP セッションが使用された場合よりもレポートが送信される頻度を低くする。

最後に、RTP セッションが複数のメディアタイプを含む場合、使用される RTCP 受信品質レポート、フィードバックメッセージ、および拡張レポートブロックがすべてのメディアタイプに適用できるとは限らないことに注意することが重要である。エンドポイントは、各 SSRC のメディアタイプを考慮し、その特定の SSRC とそのメディアタイプに適用されるレポートおよびフィードバックのみを送信または処理する必要がある。シグナリングソリューションは、特定の RTCP レポートまたはフィードバックメッセージの集合が RTP セッション内の特定のメディアタイプにのみ適用されることを示すことに関して、欠点を持つ可能性がある。

したがって、RTCP の観点からは、複数のメディアソースを単一の RTP セッションで送信するよりも、各メディアソースに別々の RTP セッションを使用することに利点があることがわかる。しかし、これらはしばしば、ポート使用量を削減し、NAT/ファイアウォール通過を容易にする必要性によって相殺される。これは、メディアソースを単一の RTP セッションに統合することによって達成される。以降の節では、複数のメディアソースを持つセッションで RTCP を使用する際の問題のいくつかについて、より詳細に検討する。

7.1. SSRC のタイムアウト

RTP セッションで複数の RTP ストリームを送信する際の SSRC 値のタイムアウトに関して、さまざまな問題が特定されている。

7.1.1. RTP/AVPF の T_rr_interval パラメータの問題点

RTP/AVPF プロファイルには、通常の RTCP レポートが頻繁に送信されすぎるのを防ぐ方法が含まれている。このメカニズムは [RFC4585] のセクション 3.5.3 で記述されており、T_rr_interval パラメータによって制御される。これは次のように機能する。通常の RTCP レポートが送信されると、T_rr_interval の 0.5 倍から 1.5 倍の範囲で一様に抽出された新しいランダム値 T_rr_current_interval が生成される。前の通常の RTCP パケットから T_rr_current_interval 秒より早く通常の RTCP パケットを送信することになり、かつ送信すべきフィードバックメッセージがない場合、その通常の RTCP パケットは抑止され、次の通常の RTCP パケットがスケジュールされる。T_rr_current_interval は、通常の RTCP パケットが送信されるたびに再計算される。抑止の利点は、頻繁な RTCP 送信を必要とするものがない場合に帯域幅の浪費を避けつつ、フィードバックが必要な場合には設定された帯域幅の利用を依然として可能にすることである。

残念ながら、この抑止メカニズムは、通常の RTCP 報告間隔と比較して RTCP 送信間隔の分布を偏らせる。再検討と補償係数を含む標準的な RTCP タイミング規則は、RTCP パケットを送信する間の間隔が、範囲 [0.5/1.21828, 1.5/1.21828]*Td の上限側に偏った分布を持つという結果をもたらす。ここで、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 秒] である。

この効果は、T_rr_interval 抑止を使用する場合に連続する RTCP パケット間の時間が大きくなりうることである。T_rr_interval が使用されている場合の、ある通常の RTCP パケットの送信と次の送信の間の最大時間間隔は、T_rr_current_interval が最大値をとり、抑止期間の終わりに通常の RTCP パケットが抑止され、その後、次の通常の RTCP パケットがその最大可能報告間隔の後にスケジュールされるときに発生する。2 つの間隔の最悪の場合をとると、2 つの RTCP レポート間の最大時間は 1.5T_rr_interval + 1.5/1.21828Td となる。

この動作は、Td と T_rr_interval が同じ値を持つ場合、驚くべきものでありうる。すなわち、T_rr_interval が通常の RTCP 報告間隔に一致するように設定されている場合である。この場合、通常の RTCP パケットは通常のスケジュールに従って送信されるが、フィードバックパケットは早期に送信できると期待するかもしれない。しかし、前述の問題により、RTCP パケットは実際には範囲 [0.41Td, 1.23Td] ではなく、非常に不均一な分布で範囲 [0.5Td, 2.731Td] で送信されることになる。これはおそらく予期しないことであるが、それ自体は問題ではない。しかし、パケット損失と組み合わさると、早期タイムアウトの問題を引き起こす。

7.1.2. 早期タイムアウトの回避

RTP/AVP [RFC3550] では、タイムアウト動作は単純である。それは Td の 5 倍であり、ここで Td は Tmin 値を 5 秒として計算される。言い換えれば、設定された RTCP 帯域幅が 5 秒より短い平均 RTCP 報告間隔を許容する場合、タイムアウトは SSRC からの（RTP または RTCP の）活動がない状態で 25 秒である。そうでなければ、タイムアウトは 5 平均報告間隔である。

RTP/AVPF [RFC4585] は、T_rr_interval の値に応じて異なるタイムアウト動作を導入する。T_rr_interval が 0 の場合、RTP/AVP と同じタイムアウト計算を使用する。しかし、T_rr_interval が非ゼロの場合、タイムアウト計算において Tmin を置き換える。これはおそらく、タイムアウトした SSRC の検出を高速化するためである。しかし、非ゼロの T_rr_interval を使用することは、RTP の動作に 2 つの結果をもたらす。

第一に、抑止により、アクティブな RTP 送信者でない SSRC によって送信される RTP および RTCP パケットの数は、セクション 7.1.1 で論じた問題のために、非常に少なくなりうる。RTCP パケット間隔は 2.73Td にもなりうるため、5Td の期間中に、エンドポイントは実際には 1 つの RTCP パケットのみを送信するかもしれない。長い間隔は RTCP パケットを少なくし、1 つの RTCP パケットの損失が SSRC をタイムアウトさせる結果となりうるほどになる。

第二に、タイムアウト規則に対する RTP/AVPF の変更は、設定ミスに対する堅牢性を低下させる。迅速なフィードバックを可能にするために RTCP パケットを頻繁に送信できるように RTP/AVPF を設定して使用するのが一般的である。しかし、これによりタイムアウトは T_rr_interval に非常に敏感になる。例えば、2 つの SSRC が設定され、一方が T_rr_interval = 0.1 秒、他方が T_rr_interval = 0.6 秒である場合、この小さな違いにより、RTP パケットの送信を停止すると、より短い T_rr_interval を持つ SSRC が他方をタイムアウトさせることになる。なぜなら、他方の RTCP 報告間隔が自身の 5 倍を超えるからである。RTP/AVP が使用される場合、または T_rr_interval = 0 の RTP/AVPF が使用される場合、これは問題にならない。タイムアウト期間が 25 秒となり、設定された RTCP 帯域幅の違いが早期タイムアウトを引き起こしうるのは、報告間隔が 5 秒より大きく、かつ 5 倍異なる場合のみだからである。このような問題のある設定ミスの余地を限定するために、セクション 7.1.4 で RTP/AVPF のタイムアウト規則の更新を定義する。

7.1.3. RTP/AVP と RTP/AVPF の相互運用性

RTP/AVP および RTP/AVPF プロファイル（またはそれらのセキュア変種）を実装するエンドポイントが単一の RTP セッション内で混在し、RTP/AVPF エンドポイントが 5 秒を大幅に下回る非ゼロの T_rr_interval を使用する場合、RTCP タイムアウト規則が異なるため、RTP/AVPF エンドポイントが RTP/AVP エンドポイントの SSRC を早期にタイムアウトさせるリスクがある。逆に、RTP/AVPF エンドポイントが 5 秒を大幅に上回る T_rr_interval を使用する場合、RTP/AVP エンドポイントが RTP/AVPF エンドポイントの SSRC をタイムアウトさせるリスクがある。

2 つの異なる RTP プロファイルを使用するエンドポイントを単一の RTP セッション内で混在させることは推奨されない (NOT RECOMMENDED)。しかし、混合 RTP プロファイルが使用され、RTP/AVPF エンドポイントが本書のセクション 7.1.4 に従うように更新されていない場合、早期タイムアウトを避けるために、RTP/AVPF セッションは T_rr_interval = 4 秒を使用するように設定すべきである (SHOULD)。

相互運用性のための T_rr_interval = 4 秒という選択は奇妙に見えるかもしれない。直感的には、RTP/AVP と RTP/AVPF の両方に同じタイムアウト期間を使用させるために、この値は 5 秒であるべきである。しかし、セクション 7.1.1 で概説した動作は、実際の RTP/AVPF 報告間隔が予想よりも長くなりうることを示している。T_rr_interval = 4 秒に設定すると、実際の RTCP 間隔は RTP/AVP が期待するものに近くなり、相互運用性が確保される。

7.1.4. 更新された SSRC タイムアウト規則

相互運用性を確保し、早期タイムアウトを避けるために、RTP セッション内のすべての SSRC は同じタイムアウト動作を使用しなければならない (MUST)。しかし、以前の仕様はこの点で一貫していない。相互運用性の問題を避けるために、本書はタイムアウト規則を次のように更新する。

• RTP/AVP、RTP/SAVP、RTP/AVPF、および RTP/SAVPF プロファイルについて、タイムアウト間隔は、決定論的な RTCP 報告間隔の 5 倍の乗数を使用して計算するものとする (SHALL)。すなわち、タイムアウト間隔は 5*Td とする (SHALL)。
• RTP/AVP、RTP/SAVP、RTP/AVPF、および RTP/SAVPF プロファイルについて、参加者のタイムアウトを計算する目的に限り、Td の計算は、縮小最小間隔が RTCP パケット送信間隔の計算に使用される場合であっても、縮小最小間隔ではなく Tmin 値 5 秒を使用して行うものとする (SHALL)。

これは、T_rr_interval != 0 の場合の RTP/AVPF または RTP/SAVPF プロファイルの動作を変更する。具体的には、[RFC4585] のセクション 3.5.4 の最初の段落が、RTP/AVPF エンティティのタイムアウト計算において T_rr_interval の代わりに Tmin を使用するように更新される。

7.2. RTCP 送信のチューニング

この節では、共有された RTCP パケット間隔の欠点を減らすためにどのようなチューニングができるかについて論じる。まず、RTP/AVP [RFC3551] プロファイルにどのような可能性があるかを列挙し、続いて RTP/AVPF [RFC4585] が提供する追加のツールについて述べる。

7.2.1. RTP/AVP および RTP/SAVP

RTP/AVP または RTP/SAVP プロファイルを使用する場合、RTCP 報告間隔を調整するオプションは、RTCP の送信者および受信者の帯域幅、および最小 RTCP 間隔を帯域幅に応じてスケーリングするかどうかに限定される。スケジューリングアルゴリズムはランダム化と再検討の両方を含むため、[RFC3550] のセクション 6.3.1 に示されている Td の式を使用して期待される平均送信間隔を単純に計算することはできない。しかし、その式への入力を考慮し、ランダム化と再検討の規則を考慮することにより、RTCP 送信間隔の動作を理解し始めることができる。

いくつかの基本的な観察から始めよう。

1. スケーリングされた最小 RTCP 間隔が使用されない限り、ランダム化と再検討の前の Td は Tmin より小さくなることはない。Tmin の既定値は 5 秒である。
2. スケーリングされた最小 RTCP 間隔が使用される場合、Td は 360 を RTP セッション帯域幅（キロビット毎秒）で割った値まで低くなりうる。SDP では、RTP セッション帯域幅は "b=AS" 行を使用してシグナリングされる。72 kbps の RTP セッション帯域幅では Tmin は 5 秒となる。360 kbps の RTP セッション帯域幅ではもちろん Tmin は 1 秒となり、25 フレーム毎秒の映像ストリームでフレームごとに 1 回に等しい Tmin を達成するには 9 Mbps の RTP セッション帯域幅が必要である。RTP/AVPF または RTP/SAVPF プロファイルを使用すると、後述するように、同じ帯域幅でより頻繁な RTCP レポートが可能になる。
3. Td の値は、全体的な RTCP 帯域幅を一定に保つために、SSRC の数と RTCP レポートの平均サイズに応じてスケーリングする。
4. Td 値に対する実際の送信間隔は範囲 [0.5Td/1.21828, 1.5Td/1.21828] にあり、再検討により分布は偏り、確率質量の大部分は Td より上にある。これは、例えば Td = 5 秒の場合、実際の送信間隔は範囲 [2.052 秒, 6.156 秒] に分布し、その区間の上半分に傾くことを意味する。Tmin パラメータはランダム化と再検討が適用される前の Td の値を制限するため、実際の送信間隔は Tmin を下回る範囲にも及ぶことに注意されたい。

以上を踏まえると、RTCP にセッション帯域幅の 5% が割り当てられた RTP セッションが、Td を Tmin に等しく保ちながらサポートできる SSRC の数 n を計算できる。これは、RTCP オーバーヘッドを許容範囲内に保ちながら、いくつの RTP ストリームについて報告できるかを教えてくれる。計算を単純化するために 2 つの仮定を置く。すべての SSRC が送信者であること、およびそれらがすべて、n-1 個のレポートブロックを持つ SR パケットと、それに続く 16 オクテットの CNAME 値を含む SDES パケットからなる複合 RTCP パケットを送信することである [RFC7022]（このような RTCP パケットは、SR パケットに含めることができる最大 31 個のレポートブロックまで、n に応じて 54 から 798 オクテットの間でサイズが変化する）。このパケットサイズと 5% の RTCP 帯域幅割合を [RFC3550] のセクション 6.3.1 の RTCP 間隔計算に代入し、スケーリングされた最小間隔に対して Td = Tmin を与えるのに必要な n の値を計算すると、n=9 個の SSRC をサポートできることがわかる（報告間隔がセッション帯域幅に応じてスケーリングする方法により、間隔に関係なく）。スケーリングされた最小間隔を変更せずにより多くの SSRC をサポートするには、RTCP 帯域幅割合を 5% から増やす必要があることがわかる。セッション帯域幅をより高い値に変更すると Tmin が減少するであろう。しかし、RTCP 帯域幅の既定の 5% 割り当てを使用する場合、増加は、固定された Td 目標の下でより多くの SSRC がサポートされる結果となる。

以上に基づくと、RTP/AVP プロファイルまたは RTP/SAVP プロファイルを使用する場合、小規模なユニキャストセッションで迅速な RTCP 報告を行うための主要な制限は Tmin 値になるであろう。RTCP で設定される RTP セッション帯域幅は、スケーリングされた最小 RTCP 間隔の規則に従ってアプリケーションが持つ報告目標を達成するのに十分に高くなければならない。

7.2.2. RTP/AVPF および RTP/SAVPF

RTP/AVPF または RTP/SAVPF を使用する場合、RTCP 送信を調整するための強力な追加ツール、すなわち T_rr_interval パラメータがある。このパラメータを使用すると、短い RTCP 報告間隔が可能になる。あるいは、頻繁な通常の RTCP レポートを送信せずに頻繁な RTCP フィードバックを送信する能力を与える。

RTP/AVPF または RTP/SAVPF プロファイルを、Tmin より小さいが 0 より大きい値に設定された T_rr_interval とともに使用すると、所与の RTCP 帯域幅に対して、RTP/AVP または RTP/SAVP プロファイルよりも頻繁な RTCP フィードバックが可能になる。これは、最初の RTCP レポートの送信後に Tmin が 0 に設定され、以降のパケットの報告間隔が、Tmin=0 での通常の RTCP 帯域幅ベースの計算と T_rr_interval によって決定されるためである。これにより、最小間隔（既定の 5 秒の最小値であれ、縮小最小間隔であれ）によってもはや制限されなくなるという効果がある。むしろ、RTCP 帯域幅と T_rr_interval が支配的な要因となり、より迅速なフィードバックが可能になる。迅速な通常の RTCP フィードバックを重視するアプリケーションは、そのプロファイルのフィードバック機能を使用しない場合でも、RTP/AVPF または RTP/SAVPF プロファイルの使用を検討すべきである。

RTP/AVPF または RTP/SAVPF プロファイルを使用すると、通常の RTCP レポートを頻繁に送信する必要なく RTCP フィードバックパケットを頻繁に送信できる。T_rr_interval は通常の RTCP パケットを送信できるレートを制限しつつ、RTCP フィードバックパケットの送信は依然として許可するからである。一部の RTP ストリーム（例えば映像ストリーム）にはフィードバックパケットを使用できるが、他の RTP ストリームには頻繁な通常の報告を望まないアプリケーションは、音声と映像の両方の通常の報告が音声にとって許容できると考えられるレベルになるように T_rr_interval を設定できる。その後、映像の報告には、縮小サイズ RTCP フィードバックパケット [RFC5506] が使用されない限り RTCP SR/RR パケットを含むことになるフィードバックパケットを使用できる。これにより、利用可能な RTCP 帯域幅を、アプリケーションにとって最も有用性の高いフィードバックに充てることができる。

T_rr_interval を使用する場合でも、RTCP 帯域幅の値に適切な値を決定する必要がある。実際、RTCP 送信に影響する制限が少ないため、これは RTP/AVP または RTP/SAVP プロファイルを使用する場合よりも RTCP の動作と性能に影響しやすく、この選択はさらに重要になるかもしれない。

T_rr_interval が非ゼロの場合、避ける必要のある設定がある。選択した RTCP 帯域幅が、Td 値が T_rr_interval より小さいが近い値になるようなものである場合、セクション 7.1.1 で論じたように、実際の通常の RTCP パケット送信間隔が非常に大きくなりうる。したがって、Td を T_rr_interval より小さくする意図がある設定では、Td を T_rr_interval の 1/4 未満の値に目標設定することが推奨される (RECOMMENDED)。これにより、範囲は [0.5T_rr_interval, 1.81T_rr_interval] になる。

RTP/AVPF または RTP/SAVPF プロファイルでは、T_rr_interval = 0 を使用することには有用性があり、RTCP 送信が帯域幅によってのみ制限される、すなわち Tmin の制限がまったくない動作をもたらす。これにより、RTP/AVP プロファイルを使用して達成できるよりも頻繁な通常の RTCP 報告が可能になる。多くの RTCP 設定は、使用するように設定された帯域幅をすべて消費するわけではないが、この設定は与えられた分を消費する。T_rr_interval が Td の 1/3 より小さい限り同じ動作が達成されることに注意されたい。これは、T_rr_interval が送信に影響しないようにするためである。

メディアタイプや個々の RTP ストリームに応じて異なる通常の RTCP 報告間隔を使用する方法は、タイプまたはストリームごとに別々の RTP セッションを使用する以外に存在しない。