要約

  • SDPのo=行は、安定したセッションの識別tupleと、独立したsess-versionを並べる。説明が変わってもセッションを改名する必要はない。
  • 一般のSDPは変更時の版上昇を求める。Offer/Answerでは、変更したofferはversionだけを一つ進め、同じversionを再利用するならSDP全体を同一にする。
  • 新しい版は古い説明を排除する手掛かりでしかない。送信者の認証、提案の承認、mediaの到達や利用者の同意を証明しない。

一つの説明では一つの番号が足りなかった

multimedia sessionは説明文より長く生きる。会議時刻が変わり、callにvideoが増え、受信addressが移ることもある。変更ごとに新しいidentityを発行すれば、参加者は継続性を失う。identityだけを固定して版を持たなければ、遅れて届いた古いannounceが最新に見える。

SDPはorigin行に二つの答えを置いた。

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

username、session ID、network/address type、origin addressの組がsession lineageを識別し、sess-versionがその中のdescriptionを区別する。比較の順序は重要である。まず同じorigin tupleかを確かめ、その後にversionを比べる。異なるtupleの数値に共通の時間軸はない。

Originは本人確認ではなかった

usernameはlogin名の場合もあるが、意味のあるuser IDがなければでもよい。現行仕様はprivacyのため、tuple全体の一意性を保つ限り、任意のusernameとprivate origin addressも認める。

つまりo=はdescriptionのnamespaceであってcredentialではない。origin addressはmediaの送受信先とも限らない。同じsess-idだけを共有しても、他の座標が違えば同じsessionの改訂とは言えない。

作成toolはsession IDをlocalに割り当てる。NTP epoch由来のtimestampはcollisionを避ける手段として推奨されたが、時計の正確さ、作成時刻、addressの所有を証明する証明書ではない。

中央の版管理者なしに古さを判断した

descriptionを変更した作成toolはsess-versionを増やす。receiverは、受理したorigin tuple、version、本文fingerprintを保存し、後から来た古いcopyで新しい状態を上書きしないようにできる。

この仕組みにglobal revision serviceは要らない。各receiverが同じlineage内で判断する。ただし一般SDPが求めるのは「増加」であり、常に+1ではない。timestamp風の値もcivil timeではなく、異なるorigin間を並べる根拠にもならない。

意味のある記録は「42を見た」ではない。「このsignaling contextのこのorigin tupleで、version 42のこのbyte列を受け、local policyがこう判断した」である。

Offer/Answerは改訂契約を厳しくした

SDPはdescription formatとして始まった。二者が共通状態を作るOffer/Answerは、SIPなどのhigher-layer protocolにtransport、context、ordering、rejection、同時offerの解決を委ねた。

agentが以前のofferを変更するとき、新しいo=行はversion以外を同一に保ち、versionを正確に一つ増やす。固定部分が同じ提案lineageを示し、一歩の増加が次のrevisionを示す。

versionを変えない場合、SDPはそのversionに対応する以前の本文と同一でなければならない。同じofferをno-opとして再送することはでき、answererは有効なanswerを返す。しかし古いversionに新しいbyteを載せることはできない。

同じ(origin, version)から異なる本文が現れたら、それは二つの選択肢ではなく矛盾したevidenceである。最後に届いた方を自動採用しても矛盾は消えない。

Offer/Answerではsession IDとversionをsigned 64-bitに収め、初期versionを2^62 - 1未満にする。rollover回避の運用条件であり、全SDPに通用するcircular arithmeticではない。

次の版も、まだofferにすぎない

versionを作る権限と、変更を受け入れる権限は別である。answererはcompatibleなstreamだけを認めたり、signaling protocolを通じてofferをrejectしたりできる。rejectされればsessionは以前のdescription stateへ戻る。

並行処理もversionの大小では決まらない。自分のofferへの回答待ち、またはpeerへの回答前に新しいofferを出してはならない。双方が同時に更新するglareはhigher layerが解決する。「最大値が勝つ」という規則はない。

valid answerもmediaの実績ではない。packet到達、codec動作、firewall通過、人の同意、recordingの適法性、billingやservice完了を証明しない。

Freshnessはtrustを作らなかった

攻撃者も大きな整数を書ける。だからOffer/Answerは、運搬するapplication signalingにend-to-end authenticationとintegrity protectionを要求する。receiverはさらにadmissionとconsentをlocalに判断する。

authenticationは認めたsource、integrityは輸送中の改変、origin tupleはlineageの主張、versionはrevisionの主張、Offer/Answer stateは提案と受否、media telemetryは実際の効果を扱う。どれも他を代行しない。

SDPの持続的な設計は、権威ある数字を作ったことではない。identityとchangeを別々に記録し、中央管理者なしでも古い説明を拒みつつ、受け入れる権限を各receiverに残したことにある。

情報源と証拠の限界

仕様の系譜は RFC 2327、RFC 4566、RFC 8866、RFC 3264 にある。grammarとOffer/Answer ruleは示すが、現在のproduct実装、live senderのidentity、media delivery成功は示さない。