要約

  • SDPには別々の二つの版がある。v=0 はSDP形式のプロトコル版であり、o= 内の sess-version は、識別された一つのセッション記述が変わるたびに増える改訂番号である。
  • 版番号の比較範囲はoriginの五要素で決まる。異なるoriginの数字を直接並べたり、時刻印らしい値を認証済み時刻として扱ったりすると、継続性の根拠が失われる。

フェイルオーバーで「最大値」が嘘をつく

主系の会議制御サーバーが停止し、待機系がSDPを送り始めたとする。主系のoriginは controller-a.example、待機系は controller-b.example だ。双方が独立に版番号を生成しているなら、402が391より新しいという関係は、それぞれの系列の内側にしか存在しない。

受信順も代わりにはならない。後で届いた文書、作成者が大きい番号を付けた文書、正当に後継として承認された文書は、同じものではない。構文検査が通っても、その三つを結合する証拠は生まれない。o= は結合に必要な名前を与えるが、承認そのものではない。

v=0 は通話の初版を意味しない

RFC 8866では、SDP記述の最初の行は v=0 である。これはSession Description Protocol自体の版を示し、マイナー版はない。映像を追加したり、codecやメディア宛先を変更したりしても v=1 にしてはならない。

次の必須行 o= は、username、session ID、session version、network type、address type、unicast addressの六値を持つ。ここで sess-version はセッション記述の改訂であり、作成ツールは記述を変更したときに値を増やす。RFCは値の割り当てに時刻印を推奨している。

したがって、v= を上げれば内容変更を新しいプロトコル形式と誤記し、内容を変えたまま sess-version を据え置けば異なるバイト列を同じ改訂に見せる。保存時には両方が必要だが、意味は交換できない。

五つが名前を作り、一つが改訂を並べる

現行RFCは、username、session ID、network type、address type、unicast addressの組を、セッションの世界的に一意な識別子とする。一つの値だけでは足りない。別ホストが同じsession IDを使っても同じ系列にはならず、usernameは人の認証にならず、アドレス変更は自動的な継承でもない。

1998年のRFC 2327は、版番号の目的をより具体的に説明した。HandleyとVan Jacobsonは、同じセッションについて複数の代理公告があるとき、どれが最新かを見分けるために必要だとした。「同じセッション」が比較の境界である。RFC 4566を経てRFC 8866になっても、識別子の組と変更時の増分は残った。

運用DBが session_id と最大版だけをキーにすれば、標準にない全体順序を作ってしまう。計画された切替でoriginが変わるなら、旧系列、新系列、承認者、有効時点、引き継ぐ状態、撤回条件を記した別の移行記録が要る。

offer/answerでは同じ版は同じ内容である

RFC 3264は、offer/answerで既存セッションを変更する場合を厳密にする。新しいofferの o= は、versionを一つ増やす部分を除き、以前のSDPと同一でなければならない。versionが増えないならSDPも同一でなければならない。同じ版の再送は実質的にno-opだが、answererは有効なanswerを返す。

この規則は監査に鋭い判定を与える。同じorigin、同じ版、異なる内容は「最後に届いた方」を採れば済む再送ではない。双方の原文とhashを残し、系列を不整合として扱い、実装のエラー方針に渡すべきだ。

一方、版が増えた事実は、作成者が変更を宣言したことしか示さない。相手がofferを受理したこと、RTPが新しい宛先に到着したこと、利用者が音声を聞けたことは別の証拠対象である。

時刻印に見えても時刻証明ではない

RFC 8866はsession IDに1900年1月1日UTCからの秒数を推奨し、session versionにも時刻印を推奨する。作成者が重複しにくく増加する十進値を得るには便利だ。しかし値を記入するのは作成者であり、時計同期、受信時刻、組織上の権限を証明する仕組みではない。

同じRFCのSecurity Considerationsは、既知で信頼できる送信元から、認証され完全性を保護されたtransportで得ない限り、session descriptionは信頼できないと明記する。よって改訂記録にはoriginだけでなく、transport、認証principal、完全性検証結果が必要だ。

SAPのhashもSDPの版にはならない

RFC 2974のSession Announcement Protocolは、originating sourceとmessage identifier hashを別に持つ。SAP側のhash変更は、受信者に公告内容を再解析させる。payloadのSDPは、なお独自のoriginとsession versionを持つ。配布層の変化信号と記述層の改訂系列は交換できない。

SDPそのものもtransportではなく記述形式であり、内容やencodingの交渉自体を担うものではない。SIPのoffer/answerはSDPを使って限定的な交渉を行い、SAP、HTTP、メールはSDPを運べる。到着、記述の身元、交渉の決定、メディア結果は接続されるべきだが、一つの版番号に畳み込めない。

Mark Handleyを単独発明者にしない

RFC 2327の著者はMark HandleyとVan Jacobson、RFC 4566はHandley、Jacobson、Colin Perkins、現行RFC 8866はAli Begen、Paul Kyzivat、Perkins、Handleyである。これは共同で継承された標準であり、一人の発明として語るべきではない。著者の系列を保つ態度は、originの系列を保つ設計とも響き合う。

Royal Societyの公式プロフィールは、HandleyをUCLのProfessor of Networked Systems、多数のインターネット標準の著者、元Internet Architecture Boardメンバーと紹介する。ACM SIGCOMMは2019年、インターネットmultimedia、multicast、congestion control、multipath networkと標準化への貢献を理由に賞を授与した。

証明できる範囲を小さく保つ

完全なorigin、正確なSDPバイト列、信頼できる取得記録がそろえば、sess-version は「この作成者が、同じセッション記述の後の改訂として示した」と言える。RFC 3264の範囲では、同版異内容や、変更したofferの版を進めなかった矛盾も検出できる。

別originの正当な後継、時計の正確さ、送信権限、offer受理、packet到達、利用者の成果は証明しない。それぞれ移行承認、transport認証、offer/answer記録、packet観測、結果試験が必要である。

出典