5. 複数のメディアストリームを送信するエンドポイントによる RTCP の使用

RTCP は [RFC3550] のセクション 6 で定義されている。このプロトコルの記述は、各エンドポイントが単一の SSRC を持つ参加者であるという前提の下で、RTP セッションにおける「参加者 (participant)」の動作という観点から表現されている。しかし、エンドポイントが複数の SSRC 値を持つ場合に正しく動作するためには、実装は各 SSRC を RTP セッション内の別個の参加者として扱わなければならない (MUST)。その結果、複数の SSRC を持つエンドポイントは複数の参加者として数えられる。

5.1. RTCP 報告の要件

複数の SSRC を持つ RTP エンドポイントは、各 SSRC を RTP セッション内の別個の参加者として扱わなければならない (MUST)。各 SSRC は自身の RTCP 関連の状態情報を維持し、したがって、RTCP レポートを送信する時期を決定する自身の RTCP 報告間隔を持つ。[MULTI-STREAM-OPT] のメカニズムが使用されない場合、各 SSRC は、同じエンドポイントに同居するものを含め、他のすべての SSRC に対する RTCP レポートを送信する。

エンドポイントが、データを送信している SSRC と受信のみを行う SSRC の両方を持つ場合、それらは RTCP 帯域幅の異なる割り当て分を受け取り、異なる基本 RTCP 報告間隔を計算する。そうでなければ、エンドポイント内のすべての SSRC は同じ基本 RTCP 報告間隔を計算する。各 SSRC の実際の報告間隔は通常どおりランダム化されるが、セクション 5.3 で記述するようにレポートを集約できる。

5.2. 初期報告間隔

参加者がユニキャストセッションに参加する場合、[RFC3550] のセクション 6.2 の次の記述が関連する。「ユニキャストセッションでは…最初の複合 RTCP パケットを送信するまでの遅延はゼロでもよい (MAY)。」基本的な想定は、これは複数の SSRC の場合にも当てはまるべきであるというものである。しかし、多数の SSRC を持つエンドポイント（またはミドルボックス）がユニキャストセッションに参加する場合には注意が必要である。なぜなら、多数の RTCP レポートを即座に送信すると、かなりのトラフィックバーストが発生し、キューオーバーフローによる一時的な輻輳とパケット損失を引き起こす可能性があるからである。

RTP エンドポイントが生成する初期トラフィックバーストが TCP 接続によって生成される量を超えないようにするため、RTP エンドポイントは、RTP セッションに参加する際、エンドポイントが使用する SSRC の数に関係なく、初期遅延ゼロで 4 つを超える複合 RTCP パケットを送信してはならない (MUST NOT)。これらの初期複合 RTCP パケットのそれぞれは、複合 RTCP パケットの合計サイズが MTU を超えず、avg_rtcp_size がセクション 5.3.1 と同様に維持される限り、複数の SSRC からの集約されたレポートを含んでもよい (MAY)。初期複合 RTCP パケットで複数の SSRC からのレポートを集約することで、かなりの数の SSRC が即座に報告できる。エンドポイントは、最も即座に有用である可能性が高い SSRC、例えば初期に送信者である SSRC に関するレポートを優先すべきである (SHOULD)。

即座に送信できる 4 つの複合 RTCP レポートに収まるよりも多くの SSRC について報告する必要があるエンドポイントは、タイマーの再検討を含む通常の RTCP タイミング規則に従って、残りのレポートを後で送信しなければならない (MUST)。これらのレポートは、セクション 5.3 で記述するように集約してもよい (MAY)。

注: 上記は、4 パケットという TCP の最大初期ウィンドウ [RFC3390] に合わせて選ばれたものであり、実験が進行中のより大きな TCP 初期ウィンドウ [RFC6928] に合わせたものではない。この理由は、保守的でありたいという願いによるものである。なぜなら、RTP エンドポイントは多くの場合、これらの初期 RTCP パケットの送信と同時に RTP データパケットの送信も開始するからである。

5.3. 複合 RTCP パケットへのレポートの集約

セクション 5.1 で概説したように、複数の SSRC を持つエンドポイントは、RTCP レポートの送信に関して各 SSRC を別個の参加者として扱わなければならない。これにより、各 SSRC は各報告間隔で複合 RTCP パケットを送信することになる。これらのパケットは同じエンドポイントから来ているため、オーバーヘッドを削減するためにそれらを集約できると期待するのは妥当であろう。実際、[RFC3550] のセクション 6.1 は、RTP トランスレータとミキサーが同様の状況でパケットを集約することを認めている。

トランスレータとミキサーは、転送する複数のソースからの個々の RTCP パケットを、パケットオーバーヘッドを償却するために実行可能な場合は常に 1 つの複合パケットに結合することが推奨される (RECOMMENDED)（セクション 7 を参照）。ミキサーによって生成される可能性のある複合 RTCP パケットの例を図 1 に示す。複合パケットの全長がネットワークパスの MTU を超える場合、基盤となるプロトコルの別々のパケットで送信される、より短い複数の複合パケットに分割すべきである (SHOULD)。各複合パケットは少なくとも 1 つの別個の参加者を表すため、これは RTCP 帯域幅の推定を損なわない。各複合パケットは SR または RR パケットで始まらなければならない (MUST) ことに注意されたい。

これにより、RTP トランスレータとミキサーは、異なる SSRC からの複数の送信者レポート (SR) または受信者レポート (RR) パケット、およびその他の任意のパケットタイプを含む複合 RTCP パケットを生成できる。複合 RTCP パケットが SR または RR パケットで始まるという通常の規則を除き、複合パケット内で RTCP パケットが出現しうる順序に制限はない。この規則により、正しく実装された RTP エンドポイントは、複数の SSRC に関連する RTCP パケットを含む複合 RTCP パケットを処理できる。

したがって、複数の SSRC を使用するエンドポイントは、1) 結果として得られる複合 RTCP パケットが SR または RR パケットで始まること、2) セクション 5.3.1 で記述するように平均 RTCP パケットサイズを維持すること、3) セクション 5.3.2 で記述するようにパケット送信をスケジュールし集約を管理すること、を条件として、異なる SSRC が送信する RTCP パケットを複合 RTCP パケットに集約できる。

5.3.1. AVG_RTCP_SIZE の維持

[RFC3550] の RTCP スケジューリングアルゴリズムは SSRC 単位で動作する。各 SSRC は各 RTCP 報告間隔で 1 つの複合 RTCP パケットを送信する。エンドポイントが複数の SSRC を使用する場合、その SSRC が送信する複合 RTCP パケットを集約し、より大きな複合 RTCP パケットを形成することでオーバーヘッドを削減することが望ましい。この集約は、平均 RTCP パケットサイズの計算を次のように更新することを条件として、セクション 5.3.2 で記述するように行うことができる。

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

ここで、div_packet_size は packet_size をその複合パケット内で報告している SSRC の数で割ったものである。複合パケット内で報告している SSRC の数は、複合 RTCP パケット内で SR または RR RTCP パケットのソースとなっている異なる SSRC の数を数えることによって決定される。非複合 RTCP パケット（すなわち、SR または RR パケットを含まない RTCP パケット [RFC5506]）は、単一の SSRC について報告するものと見なされる。

上記の規則に従わず、代わりに完全な RTCP 複合パケットサイズを使用して avg_rtcp_size を計算する参加者は、複合 RTCP パケットに集約される SSRC の数、および参加者の総数に対する集約される SSRC 集合のサイズに比例する係数だけ過大な RTCP 報告間隔を導出することになる。この増加した RTCP 報告間隔は、複合 RTCP を理解し多数の SSRC からのレポートを集約する SSRC が選択する間隔の 5 倍を超える場合、早期タイムアウトを引き起こす可能性がある。1500 オクテットの MTU は、典型的なサイズのレポートを 5 つ複合 RTCP パケットに収めることができるため、エンドポイントが複数の SSRC からの RTCP レポートを集約する場合、これは現実的な懸念である。

前の段落で提起された問題は、本書のセクション 7.1.2 で規定されるタイムアウト動作の変更によって緩和される。この緩和は、RTCP 帯域幅が十分に高く、報告する SSRC の数を考慮せずに計算された avg_rtcp_size を使用するエンドポイントが、およそ 5 秒ごとよりも頻繁に送信できる場合に有効である。ただし、更新されていないエンドポイントの SSRC の早期タイムアウトが回避されたとしても、その RTCP 報告は依然として悪影響を受けることに注意されたい。更新されていないエンドポイントとの互換性が懸念される場合、単一の複合 RTCP パケットに集約される異なる SSRC からのレポートの数は、2 つのレポートに限定すべきである (SHOULD)、あるいは集約をまったく使用すべきではない。これにより、更新されていないエンドポイントの RTCP 報告間隔は、本書に従うエンドポイントが選択する RTCP 報告間隔の 2 倍以下に制限される。

5.3.2. 複数の SSRC を集約する際の RTCP のスケジューリング

この節では、複数の報告 SSRC が自身の RTCP パケットを同じ複合 RTCP パケットに集約している場合に RTCP パケットをスケジュールし送信する際に取るべき行動に関して、[RFC3550] のセクション 6.3 で定義された動作、および RTP/AVPF プロファイルまたは RTP/SAVPF プロファイルが使用される場合は [RFC4585] のセクション 3.5.3 で定義された動作を改訂し拡張する。RTCP スケジューリング規則に対するこれらの変更は、パケット間の分布、およびフラッシュジョインやその他のセッション参加者数の変化の際の動作を含む、重要な RTCP タイミング特性を維持するために必要である。

以下で使用される変数 tn、tp、tc、T、および Td は、[RFC3550] のセクション 6.3 で定義されている。変数 T_rr_interval および T_rr_last は、[RFC4585] で定義されている。

各エンドポイントは、使用中の RTP プロファイルに対する通常の tn の計算を使用して、自身の各 SSRC について独立に RTCP 送信をスケジュールしなければならない (MUST)。SSRC についてタイマー tn が満了するたびに、エンドポイントは RTCP タイマーの再検討を実行し、該当する場合は T_rr_interval に基づく抑止を実行しなければならない (MUST)。結果が、その SSRC によって複合 RTCP パケットが送信されるべきであり、かつその送信が早期 RTCP パケット [RFC4585] でないことを示す場合、エンドポイントは、将来スケジュールされている追加の SSRC の RTCP パケットを、送信前に複合 RTCP パケットに集約しようとすべきである (SHOULD)。後方互換性の理由から集約を制限する、または行わない理由については、セクション 5.3.1 で論じる。

集約は次のように進む。エンドポイントは、現在時刻 tc より後の最小の tn 値を持つ SSRC を選択し、そのタイマー tn が tc に満了した場合にその SSRC が送信するであろう RTCP パケットを準備する。それらの RTCP パケットが、パス MTU と以前に追加された RTCP パケットを考慮して、生成中の複合 RTCP パケットに収まる場合、それらは複合 RTCP パケットに追加される。そうでなければ、それらは破棄される。この処理は、複合 RTCP パケットがいっぱいになるか、すべての SSRC が集約されるまで、tn の昇順で各 SSRC について繰り返される。その時点で、複合 RTCP パケットが送信される。

複合 RTCP パケットが送信されると、エンドポイントは、含まれた各 SSRC について tp、tn、および（該当する場合は）T_rr_last を更新しなければならない (MUST)。これらの変数は次のように更新される。

1. 複合 RTCP パケット内で最初に報告した SSRC について、その SSRC の実効送信時刻 tt を tc に設定する。
2. 複合 RTCP パケット内で報告した追加の各 SSRC について、その SSRC が複合 RTCP パケットに集約されなかった場合に持ったであろう送信時刻を計算する。これは、その SSRC の tn を取り、tp + T <= tn となるまで再検討を実行して tn を更新することによって導出される。これが完了したら、その SSRC の実効送信時刻 tt を計算された tn の値に設定する。RTP/AVPF プロファイルまたは RTP/SAVPF プロファイルが使用されている場合、この計算において T_rr_interval に基づく抑止を使用してはならない (MUST NOT)。
3. 複合 RTCP パケットで送信されたすべての SSRC の tt 値に基づいて、その複合 RTCP パケットの平均実効送信時刻 tt_avg を計算する。複合 RTCP パケットで送信された各 SSRC の tp を tt_avg に設定する。RTP/AVPF プロファイルまたは RTP/SAVPF プロファイルが使用されている場合、複合 RTCP パケットで送信された各 SSRC の T_tt_last を tt_avg に設定する。
4. 複合 RTCP パケットで送信された各 SSRC について、更新されたパラメータと通常の RTCP タイミング規則に基づいて新しい tn 値を計算し、タイマーを再スケジュールする。

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 に更新される。

逆再検討は、[RFC3550] のセクション 6.3.4 に従って実行しなければならない (MUST)。場合によっては、これにより逆再検討後の tp の値が tc より大きくなることがある。これは問題ではなく、グループサイズの縮小に正比例して報告間隔が縮小するにつれて、tp 値（および tn）を tc に向かって比例的に引き寄せるという望ましい効果を持つ。

上記のアルゴリズムは、シミュレーション [Sim88] [Sim92] において、各 SSRC の RTCP パケット間送信時間分布を維持し、集約されていない RTCP パケットと同じ量の帯域幅を消費することが示されている。このアルゴリズムでは、RTCP 複合パケット送信をトリガーする SSRC の実際の送信間隔は、通常の送信規則に従う。値 tp は、tc より [0, 1.5/1.21828*Td] の区間内のどこかに設定される。実際の値は、tc の 1 つのインスタンスと追加の SSRC のランダム化された送信時刻の平均である。したがって、区間の下限側の方がより確からしい。これは、集約に含まれる N 個の SSRC から最短の tn 値を選ぶことによって生じるであろうバイアスを補償する。

このアルゴリズムは、集約パケットに含めることができる SSRC の数が変動する場合も処理する。以前に集約され、パケットに収まらなかった SSRC は、依然として通常の規則に従って自身の送信がスケジュールされている。したがって、それは適切な時期に送信をトリガーするか、あるいはその SSRC は別の集約に含まれることになる。SSRC グループサイズの変化の下でのアルゴリズムの動作は次のとおりである。

SSRC の数が増加している RTP セッション: グループサイズが増加しているとき、Td はグループ内の新しい SSRC の数に比例して増加する。tn タイマーの満了により再検討が実行されると、その SSRC は送信を再検討し、ある確率で tn タイマーを再スケジュールする。再検討アルゴリズムのこの部分は、上記のアルゴリズムが、tp の更新時に実際の最後の送信時刻に設定される代わりに将来の時刻である tp 値を持つことによってのみ影響を受ける。

SSRC の数が減少している RTP セッション: グループが縮小すると、逆再検討は、離脱した時点の参加者の総数と比較してセッションを離れる SSRC の数に比例して、tp および tn の値を tc に向かって移動させる。tc に関して将来の時刻に tp 値を設定することは、悪影響があると考えられるかもしれない。しかし、この設定の理由は、集約された N 個の中から最短の tn を選ぶことによって生じるバイアスを補償することである。このバイアスは SSRC の数の減少にわたって残る。逆再検討は、集約が使用されているかどうかに関係なく、その減少を補償する。SSRC を削除する際に発生しうる悪影響は、最も有利な tn が削除された SSRC に属していたことである。これの影響は、最悪の場合でも送信を 1 報告間隔遅延させることに限定される。

結論として、実施された調査では、スケジューリングアルゴリズムに対する重大な悪影響は見つかっていない。

5.4. RTP/AVPF または RTP/SAVPF フィードバックの使用

この節では、送信側エンドポイントが複数の SSRC を持つ場合の RTP/AVPF フィードバックパケットの送信について論じる。この節のガイドラインは、RTP/SAVPF プロファイルを使用するエンドポイントにも適用される。

5.4.1. フィードバックパケットに使用する SSRC の選択

RTP/AVPF エンドポイントが複数の SSRC を持つ場合、送信する RTCP フィードバックパケットのソースとしてどの SSRC を使用するかを選択できる。その選択にはいくつかの要因が影響しうる。

• 特定のメディアタイプに関連する RTCP フィードバックパケットは、そのメディアタイプを受信する SSRC によって送信されるべきである (SHOULD)。例えば、音声と映像が単一の RTP セッションに多重化されている場合、エンドポイントは自身の音声 SSRC を使用して、他の参加者から受信した音声に関するフィードバックを送信する。
• エンドポイントが処理した RTP データに関する通知または指示である RTCP フィードバックパケットおよび RTCP コーデック制御メッセージは、その RTP データに使用される SSRC から送信しなければならない (MUST)。これには、以前に受信した要求またはコマンドに関連する通知が含まれる [RFC4585][RFC5104]。
• メディアの送信と受信に別々の SSRC が使用される場合、それらは RTCP 帯域幅の割り当て分が異なるため、対応する SSRC をフィードバックに使用すべきである (SHOULD)。これは、その SSRC を即時モードで使用できるかどうかの検討にも影響しうる。
• 一部の RTCP フィードバックパケットタイプは、使用する SSRC の一貫性を必要とする。例えば、一時的最大メディアストリームビットレート要求 (TMMBR) による制限 [RFC5104] が SSRC によって設定された場合、その制限を解除するには同じ SSRC を使用する必要がある。
• 複数の SSRC がフィードバックの送信に適している場合、早期 RTCP パケットとしてフィードバックを送信できる SSRC を使用することが望ましいことがある。

RTCP フィードバックパケットが、複数の SSRC からのレポートを集約する複合 RTCP パケットの一部として送信される場合、その複合パケットが RTCP フィードバックパケットの送信者によって生成された SR または RR パケットを含む必要はない。縮小サイズ RTCP パケットの場合、複数のソースからの RTCP フィードバックパケットの集約は、[RFC5506] のセクション 4.2.2 以上には制限されない。

5.4.2. RTCP フィードバックパケットのスケジューリング

SSRC が早期モードでフィードバックパケットを送信する必要がある場合、それは [RFC4585] のセクション 3.5 のアルゴリズムを次のように変更して、そのパケットをスケジュールしなければならない (MUST)。

• RTP セッションがポイントツーポイントセッションと見なされるか多者間セッションと見なされるかを判定するために、エンドポイントは、受信する RTP データパケットの SSRC フィールドに列挙されている SSRC、および受信する RTCP SR、RR、RTPFB、または PSFB パケットの「送信者の SSRC」フィールドに列挙されている SSRC によって使用される、異なる RTCP SDES CNAME 値の数を数えなければならない (MUST)。それらの SSRC によって複数の CNAME が使用されている場合、その RTP セッションは多者間セッションと見なされる。ただし、シグナリングがそのセッションをポイントツーポイントとして扱うことを示している場合、または RTCP 報告グループ [MULTI-STREAM-OPT] が使用されている場合は除く。RTCP 報告グループが使用されている場合、エンドポイントが単一の報告グループのみを受信するならば RTP セッションはポイントツーポイントセッションと見なされ、複数の報告グループを受信する場合、または報告グループと報告グループの一部でない SSRC の組み合わせを受信する場合は多者間セッションと見なされる。エンドポイントは、使用される接続の種類（ユニキャストまたはマルチキャスト）や、受信する SSRC の数に基づいて、RTP セッションが多者間かポイントツーポイントかを判定してはならない (MUST NOT)。
• フィードバックメッセージを含む複合 RTCP パケットが既にスケジュールされているかどうかを確認する場合（[RFC4585] のセクション 3.5.2 のステップ 2）、その確認はすべてのローカル SSRC を考慮して行わなければならない (MUST)。
• SSRC が早期 RTCP パケットを送信することを許可されていない場合、フィードバックメッセージは、そのフィードバックメッセージの最大有効寿命 (T_max_fb_delay) 内に発生しうる任意の早期または通常のスケジュールされた送信の一部として送信するためにキューに入れてもよい (MAY)。これは、[RFC4585] のセクション 3.5.2 の項目 4a の動作を変更する。

上記の最初の箇条書きは、RTP セッションがポイントツーポイントセッションと見なされるか多者間セッションと見なされるかを判定する規則を規定している。この規則は実装が容易であるが、一部のセッションを多者間セッションとして誤って分類することが知られている。既知の問題は次のとおりである。

複数の同期コンテキストを持つエンドポイント: ポイントツーポイントセッションの一部であるエンドポイントは、例えば外部メディアソースを対話型のリアルタイム会話に転送するために、複数の同期コンテキストを持つことができる。この場合、分類はピアを 2 つのエンドポイントと見なすが、実際の RTP/RTCP 送信は 1 つのエンドポイントの制御下にある。

選択的転送ミドルボックス: [RFC7667] のセクション 3.7 で定義されている選択的転送ミドルボックス (SFM) は、自身と各ピアエンドポイントとの間の送信および構成を個別に制御する。また、個々のレッグ間で転送される RTCP パケットを完全に制御する。したがって、この種のミドルボックスは、自身の SSRC を使用して転送するメディアを混合または選択する RTP ミキサーと比較でき、上記の規則によってポイントツーポイント RTP セッションとして分類されるであろう。

上記の場合、RTCP 報告グループ [MULTI-STREAM-OPT] を使用することは非常に合理的である。その拡張機能が使用される場合、エンドポイントは、単一の報告グループのみを使用することにより、多数の CNAME が実際には単一のエンドポイントまたはミドルボックスの制御下にあることを示すことができる。

上記の規則は、エンドポイントが RTP ミキサーに接続されている一部のセッションもポイントツーポイントとして分類するであろう。例えば、ミキサーは、対象のエンドポイントに対して、Any Source Multicast に基づく RTP セッションへのゲートウェイとして動作することがある。しかし、これはほとんどの場合問題ない。なぜなら、RTP ミキサーはセッションの 2 つの部分の間の分離を提供するからである。各ドメインでそれに応じて動作する責任はミキサーにある。

最後に、規則が誤った分類をもたらす場合にそれを上書きするシグナリングメカニズムを定義できることに言及しておく。