要約

  • recipient-list-invite を広告し解釈するのは、初回 INVITE の宛先である会議ファクトリー URI である。Contact で得た会議 URI は別資源であり、re-INVITE のリスト処理を継承しない。
  • 初回の 200 は、会議作成、要求元 UAC の参加、リスト理解だけを示す。リスト中の利用者への発信、認証、収容、ダイアログ、メディア、在席は個別の証拠を要する。
  • 会議 URI にリスト付き re-INVITE を送り拡張を Require すると 420 になる。これは製品非対応ではなく、URI と段階を誤ったことを示す精密な応答になり得る。

機能はホスト名ではなく宛先に属する

運用台帳は機能を製品単位で持ちたがる。「このクラスタは RFC 5366 対応」「このベンダーはリスト会議対応」といった一つの真偽値は検索にも調達にも便利だからだ。

しかし RFC 5366 の手順は、能力を二つの資源に分ける。最初の INVITE は会議ファクトリー URI に送られる。ファクトリーは新しい会議を作り、応答の Contact で実際の会議 URI を返す。後続のダイアログは後者を使う。

ファクトリーは生成命令を受ける場所である。参加者の初期集合を表す本文と recipient-list-invite を理解し、会議を作って招待処理を始める。一方、会議 URI はすでに存在する会議の focus を指し、確立済みダイアログやメディア変更を扱う。

同一ホスト上に実装されていても権限は同一ではない。OPTIONS の Supported に拡張が現れたなら、証明できるのは「この URI が、この時点の応答で、このオプションを広告した」である。隣の URI や将来の会議へ無条件に伝播させてはいけない。

能力インベントリには照会 URI、方式、時刻、応答、オプション集合、認証条件を残す必要がある。単なる製品フラグでは、正しいクライアント設定と誤った資源への送信を区別できない。

Contact は単なる転送先ではない

初回応答に含まれる Contact は、作成された会議を識別する。isfocus はその資源が会議 focus として振る舞うことを示す。ここでクライアントの操作面が切り替わる。

監査にはこの切り替えを結ぶ証拠が要る。ファクトリー宛てトランザクション、入力リストのハッシュ、返された Contact、focus の識別情報、内部会議 ID、作成者のダイアログを関連付ける。Contact を最終 URL として上書きするだけでは、どの作成要求から生まれた会議か分からなくなる。

この結合が失われると、後から参加者別 INVITE や会議状態通知を見つけても、元の要求との因果を説明できない。複数の作成要求が近い時刻に走れば、名前や時刻だけの推測はさらに弱い。

資源の切り替えは権限の切り替えでもある。ファクトリーが「作る」権限を持ち、focus が「入れる」判断を持ち、各ダイアログが「接続した」事実を持つ。一つの Contact 行にこれらを圧縮してはならない。

200 が確認したのは三項目だけ

RFC 5366 は初回 INVITE の 200 の意味を限定する。会議は正常に作られた。INVITE を生成した UAC は会議にいる。サーバーは URI リストを理解した。ほかの利用者を会議へ入れられたかについては情報を与えない。

ここで「理解した」は、本文をサービス用リストとして扱えたという意味である。各 URI が有効だった、追加情報をすべて保持した、全招待を生成した、という完遂証明ではない。

会議作成も人数を含まない。作成者一人だけの会議でも作成は成功している。リスト全員への招待が失敗しても、200 が述べた範囲は変わらない。

利用者画面が「8人の会議を作成しました」と表示するなら、8人の根拠を別途持つべきだ。初期リストの件数は要求数であって参加数ではない。各対象について正規化、INVITE 生成、最終応答、認証、focus 判断、ダイアログ、メディア、状態観測を追跡する。

重要な意思決定者がリストに含まれていたが外向き INVITE が失敗した場合、200 はその人に参加機会があったことを証明しない。議事録や承認記録が初期リストだけを出席者欄へコピーすれば、意図が事実へ変換されてしまう。

re-INVITE では資源も段階も変わっている

ダイアログ確立後の re-INVITE は、作成者と会議サーバーの間のメディア特性を変更するために使える。RFC 5366 公開時点では、その re-INVITE 内の recipient-list に意味は定義されていない。クライアントは入れるべきではない。

それでも recipient-list-invite を Require して送れば、会議資源は未対応拡張として 420 Bad Extension を返し、Unsupported にタグを示す。この 420 は会議消滅や既存メディア障害を意味しない。該当 URI の該当操作では拡張を受けない、という局所的な証言である。

運用が 420 を一律の製品非対応へ変換すると、ファクトリーで正しく利用できる能力まで無効にしてしまう。逆に一律リトライすると、正しい拒否に対して負荷を増やす。

Require を削って同じ本文を再送しても、意味は生まれない。理解必須の条件を取り除いただけで、会議 URI に参加者追加契約が追加されたわけではない。ファクトリーへ宛先を戻せば、既存会議の変更ではなく新しい会議作成になる可能性がある。

復旧処理は構文ではなく意図を選ぶ。既存会議に人を加えるなら RFC 4579 の適切な参加者追加手段を使う。新会議が必要なら明示的にファクトリーへ要求する。メディアだけを変えるならリストなしの re-INVITE にする。

同じ multipart に入っても結果は共有しない

初回 INVITE は SDP と URI リストを同時に運べる。これにより一往復で会議作成と初期招待開始を要求できるが、二つの本文は異なる処理を起動する。

SDP は作成者とサーバーの offer/answer を構成する。リストはほかの利用者に対する操作の入力である。サーバーから各利用者への INVITE は別ダイアログであり、別のセッション記述、認証、経路、暗号、コーデック結果を持つ。

作成者の音声が通ったからといって、招待者の音声が通ったとは言えない。作成者が映像を許可されても、focus は別の参加者に音声だけを許すかもしれない。ダイアログ成立はパケット受信や再生まで証明しない。

監視は親要求を共有しつつ結果を分離する。初回要求には multipart 各部のハッシュを保存し、作成者側 offer/answer と対象別 offer/answer を別フィールドにする。全員へ作成者の緑表示をコピーする設計は、障害だけでなくアクセシビリティやセキュリティ差も隠す。

リスト掲載は focus の許可ではない

会議サーバーはリストの参加者追加を試みるべきだが、試行と収容は同じではない。会議には、参加できる者、役割、使用可能なメディアなどの規則がある。focus は候補者を認証し、その規則を評価する。

最低でも四つの主体を残す必要がある。認証済みの作成者、リストに書かれた URI、外向き INVITE に応答した端点、focus が最終的に認証して収容した主体である。転送や共有アドレスがあれば一致しない。

最後の主体だけ保存すると、誰を招く意図だったか消える。最初の URI だけ保存すると、誰を収容したか証明できない。変換の辺と、認証方法、ポリシー版、判断理由を持たせるべきだ。

RFC 5363 の認証、認可、opt-in 要件もリストサービスとして適用される。ただし、作成者にリスト機能を許可する判断と、各候補を会議へ収容する判断は別である。

会議状態は後続の観測面である

他の利用者の状態を知りたい UAC に対し、RFC 5366 は RFC 4575 の会議イベントパッケージなど一般的な会議機構を使うよう案内する。初回 200 に含まれない情報を、後続の状態面から得る設計である。

通知は完全または部分で、版番号を持つ。部分通知は有効な基準状態に依存する。途中版を失ったまま残りを足しても完全な名簿にはならない。購読停止中の期間は未知として残す必要がある。

状態には時刻もある。ある版で参加していた端点は次の版で退出しているかもしれない。初回招待に失敗した人が別手段で後から入る場合もある。初期リストにいない人も会議状態には現れ得る。

そこで、要求された集合、focus が処理した集合、状態通知で観測した集合を別々に保つ。差分は異常とは限らず、招待、方針、時間を説明する材料になる。

さらに、状態に現れたことは人間の注意を証明しない。focus が表現した論理状態であり、聞こえた、理解した、発言したという結果は別にある。

平坦なリストは余分な意図を落とし得る

RFC 4826 の形式は階層や XCAP 相対参照を表現できるが、RFC 5366 の会議サービスが必要とするのは平坦な URI リストである。クライアントは余分な機能を使わないことが推奨され、ファクトリーは追加情報を捨ててもよい。

従って「リストを理解した」は、入力構造をすべて保存して実行したという意味ではない。原文バイト、パーサー版、正規化後の集合、無視した要素、実際に生成した操作を残すべきだ。

コピー制御と匿名化は、各招待先へ開示する履歴を変える。その詳細は RFC 5364 の別記事が扱う。本件で重要なのは、開示された履歴も実参加者一覧ではないという点である。

調査の限界

凍結した資料は標準本文、登録語彙、役割と規範要件を示す。特定製品の現在の実装、実会議、障害、侵害を示してはいない。RFC のフローは例であり、パケットキャプチャではない。

確立できるのは資源境界である。ファクトリーが宣言した能力を、同じサービス内の会議 URI へ証拠なしに移すことはできない。