要約

  • Lauri IlolaとLukasz Kondradが著したRFC 10034は、V3CアトラスNALのRTP搬送と、同じ表現を構成する媒体行を示すSDPのV3Cグループを定義する。
  • 受信側は媒体行ごとに拒否でき、部分集合だけを選べる。断片の欠落、復号順、パラメータセットの不適合、ストリーム間の時間差は、いずれも再構成を止め得る。
  • ペイロード形式は一つの安全機構を強制しない。各RTPストリームと、それらを結ぶSDP・RTCPの真正性、完全性、機密性は個別に確かめなければならない。

ネットワーク監視では、四つのストリームが同時に動いているだけで一つの成功に見える。SDPにもa=group:V3Cがあり、すべてのmidが並んでいる。だが、プレーヤーの中ではまだ仕事が始まったばかりである。

V3Cは三次元フレームを複数の二次元成分へ展開する。占有情報はどの画素が再構成に参加するかを示し、幾何は点の位置を与え、属性は色や材質などを加える。アトラスのパッチは、それらの領域を三次元空間へ戻す手掛かりを持つ。

2026年8月にIETFのStandards Trackとして公開されたRFC 10034は、この分割をRTPとSDPで扱えるようにした。アトラスをどうパケット化するか、V3C固有のパラメータをどう伝えるか、別々の媒体行をどう一つの表現として示すかを定める。分割を消す標準ではなく、分割を相互運用可能にする標準である。

受信パケット数ではNALの完成を証明できない

アトラスNALには三つの運び方がある。一つを一つのRTPパケットに入れる形式、小さなNALを二つ以上まとめる集約パケット、そして大きなNALを複数のRTPパケットに分けるフラグメンテーションユニットである。

集約パケットは一つのIPパケットに収まり、IP断片化を避ける大きさが望ましい。集約パケットそのものをさらに分割することはできない。FUの中にFUを入れることもできない。同じNALの断片は連続して昇順のRTPシーケンス番号で送られる。途中を失ったなら、受信側はそのNALに続く断片を捨てるべきだとされる。

つまり、ほぼすべてのRTPパケットが到着しても、重要なアトラスNALが一つ成立しない場合がある。総パケット数は、開始断片と終了断片がそろったか、APを解析できたか、欠落後に何を捨てたかを示さない。FU/APの境界と再組み立て結果が別の証跡になる。

復号順にも独自の状態がある。sprop-max-don-diffがゼロなら送信順と復号順は同じでなければならない。ゼロより大きい場合、DON/DONLを使って受信側が復号順へ戻す。RTPの番号はネットワーク上の順番を追うが、媒体が要求する順番を常に表すわけではない。

アトラスのRTPクロックは90 kHzで、表示にはRTPタイムスタンプを用いる。それでも、別ストリームの占有、幾何、属性が同じ再構成時刻へ入ったことまでは証明しない。同期の証跡は、複数成分を実際に消費する地点で取る必要がある。

グループは「一緒に使う予定」を記述する

RFC 5888のSDPグループ枠組みに、RFC 10034はV3Cという意味を加えた。グループ行のトークンは各媒体行のmidを指す。アトラスはm=applicationとv3cを用い、映像成分はm=videoのまま各コーデックのRTP形式を使う。

この設計によって、異なる成分を一つの不透明なペイロードへ押し込まずに関連付けられる。同時に、グループは宣言でしかないことも明確になる。

ユニキャストのoffer/answerでは、送信側が利用可能な成分と一緒に消費すべき組を示す。受信側はそれを受け入れてもよいし、不要な媒体行のポートをゼロにして拒否してもよい。受信側がV3C符号化を完全または部分的に理解していない場合の部分選択も仕様に含まれる。

したがって、正しいanswerが不完全な表現を意図的に選ぶことがある。色属性を省いた幾何が用途に足りる場合もあれば、アトラスの欠落で何も再構成できない場合もある。セッションの継続だけでは、どちらか判定できない。

V3Cパラメータセットは必要な復号・再構成資源を示す。一般に帯域外で知らせる利点がある。成分の受信後に動的に届き、受信側が必要能力を持たないと、動作は未定義になり得る。パラメータを記録しただけでは足りず、能力判定と実際のデコーダ結果を残すべきである。

信頼は同じグループにいるだけでは移らない

RFC 10034はRTPの安全方式を一つに決めない。アプリケーションが環境に応じて機密性、完全性、送信元認証を選ぶ。その対象は一つのお気に入りストリームではなく、すべての構成ストリームとSDP、RTCPである。

幾何ストリームが認証済みでも、出所不明のアトラスを混ぜれば全体の真正性は成立しない。RTPを守ってもグループやパラメータのシグナリングが改変可能なら、成分同士の関係が攻撃面に残る。

マルチキャストでは、パラメータセットを元の送信元に結び付け、その送信元のビットストリームだけに使わなければならない。値が一致したことは、別の送信元から状態を借りる許可ではない。

RFC 7201はRTPを保護する選択肢を示し、RFC 7202はペイロード形式が万能の一方式を命じない理由を説明する。運用記録には、実際に選んだ方式、対象ストリーム、鍵と信頼根、検証結果、除外範囲が必要だ。「RTP受信」や「V3Cグループ検出」は安全評価ではない。

Kondradの仕事は境界を保ったことに価値がある

Nokiaの公式プロフィールはKondradをPrincipal Standardization Specialistとし、ISO/IECとIETFで没入型メディア標準に関わると説明する。RFC 10034はその接点にある。ISO/IEC 23090-5がV3C符号化を定め、IETF側のRTP、SDP、グループ、安全の仕組みが搬送を支える。

これは共同作業である。Ilolaは共著者で、既存RFCが基盤を提供し、IANAはapplication/v3c、v3cfmtp、V3Cグループを登録する。登録は実装の座標であって普及率ではない。Kondradの肩書もNokia製品の稼働証拠にはならない。

狭い標準だからこそ、運用上の責任を分けられる。パケット化、順序、時刻、パラメータ、グループ、交渉、輻輳、安全をそれぞれ検査できる。

Heng LuのRunning-Code Primacyに従えば、宣言より実行結果を保存する。正確なoffer/answer、すべてのmid、受諾・拒否した媒体行、パラメータセットのハッシュ、成分対応、SSRC、安全状態、欠番、DON/DONL、AP/FU、ストリーム間同期、デコーダの版とエラー、再構成フレームとシーン検査を一組にする。

同じグループに記載されたことが最初の証跡である。パケット到着、真正性、完全性、順序、同期、復号には別の証跡がある。再構成されたシーンは最後にしか現れない。RFC 10034はその道筋を定義したのであって、途中を省略してはいない。

情報源