要約

  • RTCP の参加者は人間や端末の台数と同じではない。複数の SSRC を持つ端末では、送信元ごとに独立した状態と報告間隔が必要になる。
  • 報告の予定時刻は、その時点の集団規模に基づく仮の判断である。期限が来ても最新の推定で計算し直し、まだ早ければ送らずに待つ。
  • ランダム化、早期フィードバック、報告の集約は別々の問題を扱う。どれか一つが、共有帯域や生存判定の規則を不要にするわけではない。

一台の中にある複数の時計

2017年3月の RFC 8108 は、同じ RTP セッションで複数のメディアストリームを送る場合の規則を整理している。その中で、RTCP にとって各 SSRC は別々の参加者であり、状態も送信間隔も別々に持つことが明確にされている。

SSRC は同期送信元を識別する値だ。画面に表示される人名でも、端末の製造番号でもない。一つの端末から複数の送信元が現れるなら、端末の台数だけを数えた表は、制御報告の規模を表していない可能性がある。

この違いは、単なる用語の細かさではない。RTCP は、同じセッションを観測する参加者たちが、報告のために使う帯域を抑える仕組みを持つ。分配の基礎になる数を小さく見積もれば、各参加者が自分に許された送信頻度を高く見積もりかねない。

一台の内部にいくつ送信元を作っても、最初の送信を無制限に増やしてよいわけでもない。RFC 8108 は、参加直後に遅延なしで送れる複合 RTCP パケットを、一つの端末につき最大四つとしている。四つというのは人や SSRC の数ではなく、パケットの数だ。残りは通常のタイミング規則に従う。

端末という物理的なまとまりと、プロトコルの参加単位を区別しなければ、何を制限しているのかさえ変わってしまう。

音声は増えなくても、報告は増える

問題の起点は、もっと単純なマルチキャストの場面にある。少数の送信元が音声を送り、大勢が受信する。受信者が増えても、音声を送る人が同じなら、メディアの送信量が同じ割合で増えるとは限らない。しかし全受信者が一定間隔で受信状態を報告すれば、制御メッセージの総量は受信者とともに増える。

RFC 3550 が定める RTCP は、受信品質を伝えるだけの付属機能ではない。送信元を識別する情報を運び、その報告を通じてセッションの規模を推定する材料も与える。集団を観測するメッセージが、集団の大きさに応じて自らの頻度を調整する。

基本の計算では、対象となる参加者数、平均 RTCP パケットサイズ、制御用帯域が間隔に関係する。サイズにはネットワーク層とトランスポート層のヘッダーも含まれる。同じ数の参加者でも、一回の報告が大きくなれば、同じ頻度で送り続けてよいとは限らない。

ここで使う帯域は、参加者が共通に扱う設定値であって、経路がその容量を予約したという証明ではない。RTP も RTCP も、それ自体でメディアの確実な配達や一定時間内の到着を保証しない。報告の節度と通信路の保証は、別の約束である。

ランダムなら安全、ではなかった

1996年1月の RFC 1889 には、すでに参加者数に合わせた間隔調整も、送信のランダム化も、初回報告を少し待つ仕組みもあった。2003年になって初めて「同時に送らないようにしよう」と気づいたわけではない。

それでも、大勢が短時間に参加する場合には別の問題が残る。新しい参加者は最初から全員を知っているわけではない。基本手順では自分を含めて一つから数え始め、受信した有効な送信元の情報から規模を学ぶ。まだ小さいと思っていたときに、短い待ち時間を予約してしまうことがある。

その予約をランダムに散らしても、予約の総数に対して待ち時間が短すぎれば、大きな制御トラフィックの山は残る。ばらつきを作ることと、母数を正しく見積もることは違う。

RFC 3550 のタイマー再考は、この時間差を扱う。予定時刻に達したら、最新の推定値で間隔を計算し直す。前回の送信時刻に新しい間隔を加えた時刻が、すでに現在以前なら送信できる。まだ未来なら、そこへ予定を移して送信しない。

新しい参加者を見かけるたびに、直ちに全予定を作り直すという説明ではない。核心は、期限が来たときの再評価にある。時計が鳴ったことは、判断する理由にはなるが、以前の条件のまま送る権利にはならない。

送信できた後には、次回のために新たなランダム間隔を計算する。送信を許すほど短かった今回の値をそのまま再利用すると、選別された値ばかりを使う偏りが生まれる。仕様の付録は、この一見小さな違いにも注意を向けている。

減った集団にも追いつく必要がある

待ち時間を延ばすだけでは十分ではない。多くの参加者が去った後も、大きな集団を前提にした長い間隔を残せば、残った送信元の報告が不必要に少なくなる。報告が少ないことを理由に、さらに別の参加者までいなくなったと判定する危険もある。

逆方向の再考は、人数の推定が減ったときに、新旧の比率で残り時間と経過時間を調整する。全員が同時に同じ名簿を得るのではなく、減少を観測した側が自分の時計を修正する仕組みだ。

離脱を伝える BYE 自体にも、大きな集団での集中を避ける手順がある。一方で、すべての離脱が明示通知になるわけではない。通知せずに去った参加者は、ほかの側でやがてタイムアウトする。見えていないことと存在しないことは、最初から同一ではない。

RTCP が持つのは、この不確かさを扱うための状態であって、完全な出席簿ではない。しかも SSRC を数えられることは、その背後の人や装置を認証したことを意味しない。参加規模を見積もる手順に、身元保証まで背負わせることはできない。

速いフィードバックにも別の条件がある

規模に合わせて定期報告を遅くすると、ある種のフィードバックは役に立つ時期を逃す。2006年7月の RFC 4585 は、AVPF で早期フィードバックを扱う。出来事に反応するメッセージを、条件が整えば通常の報告予定より前に送れる。

グループでは、短いランダム待機の間に同等のフィードバックを聞き、自分の重複報告を抑えることもある。これは全受信者がすぐ同じ要求を送る仕組みではないし、制御帯域を無視してよい例外でもない。定期的な状態報告と、時間に敏感な出来事の通知を区別している。

2009年4月の RFC 5506 では、その一部を小さい RTCP パケットで送れるようにした。しかし通常の定期報告まで小さい形式に置き換えたのではない。少なくとも一つ複合パケットを送った後に、適用される早期・即時フィードバックで縮小サイズの形式を使え、定期報告は複合形式のまま続く。

小さい形式を理解すると相手が宣言していても、途中の装置が通してくれるとは限らない。仕様は継続的な配達失敗を検出する仕組みを求め、検証に失敗した場合には複合形式へ戻すことを強く勧める。通信を観測する仕組み自体が、観測できなくなる可能性を考えている。

まとめて送ると、時間の帳尻がずれる

複数 SSRC の報告を一つのパケットにまとめると、ヘッダーなどの費用を分け合える。ただし、一つにまとめたパケット全体のサイズを各 SSRC の費用として計上すれば、必要以上に長い報告間隔を計算してしまう。RFC 8108 は、異なる報告元 SSRC の数でサイズを割り、各送信元の平均サイズへ反映する。

時間にも同じ注意が要る。ある送信元の定期報告を送るついでに、まだ期限が来ていない別の送信元の報告を一緒に入れることができる。だが、そのたびに未来の予定を前倒しし続ければ、まとめられた送信元は本来より頻繁に報告する。

この偏りを避けるため、仕様は各送信元の有効な将来の送信時刻を計算し、その平均を使って次のスケジュールの基準を更新する。状態の時刻が現在より先を指す場合もある。それは時計の故障ではなく、実際に今送ったことと、本来いつ送る配分だったかを区別するためだ。

したがって、状態変数をすべて「最後に実際に送った時刻」と表示すると、診断を誤る可能性がある。パケットをまとめる実装の効率と、送信元ごとの帯域配分を両立させるには、物理的な送信履歴だけでは足りない。

RFC 8108 は、関連するプロファイル間で参加者のタイムアウト計算も整理した。定期報告の抑制や送信間隔の短縮を認める規則と、生存を判断する規則が食い違うと、静かな送信元を誤って消してしまう。これは「五秒無言なら離脱」という一律の期限ではない。

形式が同じでも、振る舞いは変えられる

RFC 3550 は、RFC 1889 から通信路上のパケット形式を変えていないと明記する。中心的な変更は、同時参加などに対応するタイマーの改善だった。旧実装が読み取れるメッセージのまま、新しい実装は送信の判断を変えられる。

ただし互換性は、新しい振る舞いが全員へ瞬時に行き渡ることを意味しない。仕様の付録は、旧新が混ざるときの改善を新しい参加者の割合に応じたものとして説明している。本稿はその説明を史料として扱っており、現在の製品を測定した結果ではない。

2026年8月26日に確認した RFC 3550 の正誤情報 にも、このタイマーの核心を置き換える確認済みの訂正はない。文書更新待ちと却下済みの記録を、承認済みの改訂として読んではならない。

制御帯域の設定をより明示した RFC 3556 は、不合理な帯域値が過剰送信を招く危険も指摘する。共通の計算式があるだけでは、入力が正当であるとは限らない。報告の時計が教えるのは、共通規則に従うことと、観測した条件を確かめることの両方が必要だということだ。