要約

  • SSRCは一つの時刻・シーケンス空間を束ねるが、RTPセッション内で一意になるよう無作為に選ぶ交換可能な値だった。
  • 自分のSSRCとの衝突を検出した送信元は、旧値にRTCP BYEを送り、既知の値と重ならない新候補を選んだ。
  • 同じSSRCと異なる送信アドレスは、衝突だけでなくループ、NAT再割当て、中継再起動、移動も示し得る。CNAMEは連続性を助けるが認証ではない。

受信側にとってSSRCは再生状態の入口だった

RTP受信側はSSRCごとにシーケンス番号、タイムスタンプ、受信統計、再生用の状態をまとめる。独立した二つの送信元が同じ値を使えば、本来別の時計と欠損履歴が一つに見える。衝突は単なる重複番号ではなく、再生の根拠を混ぜる問題だった。

1996年のRFC 1889はSSRCを32ビットとし、ネットワークアドレスから独立させた。マルチキャストや変換器、ミキサーを通る会議では、アドレスを普遍的な送信元名にはできない。各同期元はセッション内で一意になることを意図して無作為な値を選ぶ。

中央の採番所を不要にした代わりに、偶然は参加者自身が処理する。衝突確率が小さいことと、回復を実装しなくてよいことは同義ではなかった。

32ビットの余裕にも失敗経路があった

RFC 3550は、千の送信元が同時に開始する場合に少なくとも一組が衝突する確率をおよそ10^-4、千の既存値に一つの新規送信元が加わる場合をおよそ2×10^-7と例示した。これは数学モデルであり、運用上の発生率ではない。

ローカルIPアドレスをそのまま使えば、私設空間や同一ホストの複数送信元で重なる。初期化の弱い乱数器は、同時起動したプロセスに同じ系列を与え得る。新規参加者は最初の送信前に受信し、すでに見えた候補を捨てられる。

設計の中心は無謬な番号ではない。選び方を改善し、なお失敗したときの手続きを共通化することだった。

BYEの後にも同じメディアは続けられた

自分のSSRCを別の送信元が使っていると分かったら、送信元は旧SSRCを載せたRTCP BYEを送り、別の無作為値を選ぶ。候補は送信元テーブルで照合し、使用済みなら再度生成する。

ここで退場するのは古い同期空間である。カメラやマイクそのものとは限らない。RFC 7656は、一つのRTPストリームが同時点で持つSSRCは一つだが、衝突などを理由に時間とともに変更できると整理した。

SSRCを人の永続IDにしてしまう画面は、同じ発話者に退場と再入場を表示する。録画をSSRCだけで分割すれば、一続きのメディアを二つの主体にしてしまう。

第三者の受信側は所有者を決めなかった

二つの他者が衝突している場合、受信側は送信アドレスやCNAMEの違いを使い、一方を維持して他方を捨ててもよい。番号を実際に変更する責任は衝突した送信元に残る。

先に確立した状態を保つのは混線を抑えるための方針であり、番号の所有権ではない。BYEが届けば旧エントリは終了し、届かなければタイムアウトが判断材料を変える。

RTPとRTCPは別のUDP送信ポートを使い得るため、テーブルはデータ用と制御用の最初の送信アドレスを分けて持つ。ミキサーの向こうでアドレスが一つに見えても、同じSSRCに異なるCNAMEを含むSDESが現れれば衝突を疑える。

自分のパケットが戻ると衝突と同じ形になった

転送ループも、同じSSRCを別アドレスから戻す。最初の不一致だけでは、別送信元なのか自分の反射なのかを決められない。

RFC 3550の処理は、競合するRTP・RTCPアドレスを時刻付きで記録する。自分のSSRCに初めて競合したときだけ改名し、その経路を記憶する。同じ経路から反射が続けば無視する。毎回新たな衝突と扱うと、ループがBYEと改名を無限に発生させるからだ。

ミキサーと変換器は自ら生み得るループを切らなければならない。ただしRFC 7667が示すように、検出にはSSRC/CSRCが正しく保存された共通空間が必要である。独立したセッションをつなぐ構成や一部の転送方式では、その証拠が途切れる。

アドレス変更には複数の正しい説明があった

RFC 3550は、送信アドレスが変われば必ずSSRCも変えるという旧規則を緩和した。移動する端末では、同じストリームが新しいアドレスへ移ることがある。受信側は新経路を採用できるが、本物の衝突時に二つの経路を行き来しない工夫が要る。

変換器が再起動してUDPポートを変えるだけでも、その下流のSSRCはループに見える。RFC 5135はNATの写像が変わる場合を扱う。同じSSRCに新しいIPやポートが結び付くと衝突検出が動き、診断やジッターバッファに影響し得る。

したがって、アドレス不一致は有力な観測だが、攻撃者や故障機器を確定する証明ではない。

CNAMEは別の時間幅を選べた

RFC 7022では、衝突や再起動でSSRCが変わっても、RTCP CNAMEはendpointや同期すべき関連ストリームを結ぶために保てる。監視のため長く維持する設計も、追跡を減らすためセッションごとに変える設計も可能である。

しかしCNAMEも証明書ではない。参加者が自ら選び、他者の値をまねることもできる。連続性の手掛かりと本人認証は別である。

RFC 8834はWebRTCでも無作為SSRCとRFC 3550の衝突処理を必須とした。信号で値を伝えられても、双方が確認前に新値を使うことがあり、再送用などの補助ストリームは未通知のSSRCを生む。

情報源と限界

起点はRFC 1889、現行の衝突・ループ処理はRFC 3550にある。NATはRFC 5135、CNAMEはRFC 7022、ストリーム語彙はRFC 7656、トポロジーはRFC 7667、WebRTCはRFC 8834が根拠である。現在の衝突件数、製品適合、人物、内容真正性、再生成功は証明しない。