要約

  • RFC 5368 は、一つの REFER から有効な各宛先へ別々の SIP 要求を生成する。親 REFER の応答は、その複数要求の成否をまとめた結果ではない。
  • 複数の結果を従来の message/sipfrag 購読で表せないため、norefersub と Refer-Sub: false が推奨される。ただし抑止は REFER が分岐しないと確信できる場合に限られる。
  • 証拠には非分岐の根拠、返された Refer-Sub、Content-ID の参照先、正規化後の宛先、子要求、サービス固有の状態が必要である。RFC 8262 は後に、参照が MIME 部分または本文全体を指せることを明文化した。

通知を消すと、分岐を見つける窓も消える

単一宛先の REFER は通常、refer イベントへの暗黙の購読を作る。NOTIFY に含まれる message/sipfrag は、REFER を受けた側が開始したトランザクションの進行を発行者へ伝える。

この購読にはもう一つ役割がある。REFER が fork すれば、複数の受信 UA と複数のダイアログが生じ得る。NOTIFY は発行者にその枝の存在を知らせる。購読を抑止しておきながら要求を分岐させれば、見えない実行主体が増える。

RFC 4488 が Refer-Sub: false の使用を非分岐が確実な場合に限定するのはこのためだ。RFC 5368 の例は Request-URI に GRUU を使う。これは見栄えのためではない。一つの UA に届くという根拠を作り、一つの応答で購読方針を決められるようにする。

運用記録には Request-URI、Route、GRUU など非分岐を支える性質、応答 branch、実際の受信主体を残す必要がある。ロードバランサの背後で最終的に一台が処理した、という実装上の結果だけでは、SIP の fork がなかった証拠にはならない。

複数の結果を一つの sipfrag に押し込まなかった

RFC 5368 は Refer-To が cid: でリソースリストを指す形を定義する。受信者は有効な REFER-Target ごとに新しい SIP 要求を作る。宛先 A は成功し、B は拒否し、C はタイムアウトできる。

通常の暗黙購読は、一つのトリガーされたトランザクションを報告する設計だった。複数トランザクションについて、どの状態がどの宛先に属するか、並行中の状態をどう配列するか、最終状態をどう閉じるかは定義されていない。

そこで仕様は偽の集約を作らない。norefersub を Require に置き、適切なら Refer-Sub: false を送ることを推奨する。受信者も 200 に false を返し、暗黙購読を作らないことが望ましい。

この後に NOTIFY が来ないのは成功の証拠ではない。結果経路を意図的に外した結果である。監視が「エラー通知なし」を「全宛先成功」に変換すれば、仕様が避けた集約をダッシュボードが勝手に復活させる。

要求値と応答値は別の証拠だった

発行者が false を求めても、受信者が同意したとは限らない。2xx に Refer-Sub: false があれば抑止が成立する。フィールドがない、または true なら通常の暗黙購読が作られる。

したがって送信ログだけでは購読状態を決められない。要求と応答を同じ取引として保存し、option-tag、応答コード、返却値を比較する必要がある。

未知の相手に Require: norefersub を送れば、非対応時に 420 が返る。これは要求した拡張がその相手で利用できないことを示す。リスト内の人が操作を拒んだ証拠ではない。Require を削って再送するなら、結果観測の設計も変わったと記録しなければならない。

202 は子要求より先に存在した

RFC の会議例では、発行者が複数参加者への BYE を一度に依頼する。会議サーバは 202 を返し、その後に個々の BYE を送る。

時間順序から、202 は子要求の完了を意味し得ない。それは会議サーバが親命令を受理したという出来事である。BYE が対象ダイアログに結び付いたか、送信されたか、遠端が受け入れたか、会議状態から参加者が消えたかは後の出来事だ。

記録モデルには親 ID と子 ID が必要である。親は発行者、認証、承認、リスト参照、正規化、応答を持つ。子は対象 URI、方法、Call-ID、CSeq、送信と応答を持つ。親が 2xx でも子は未知、失敗、成功を別々に取れる。

cid はどの物体を指したのか

Refer-To の Content-ID URL は制御ヘッダと本文中のリストを結ぶ。証拠として使うには、cid: 値、Content-ID、MIME 境界、Content-Type、Content-Disposition、本文ハッシュを一緒に残す。

RFC 8262 は過去の曖昧さを明示した。RFC 5368 などの例は本文全体を識別していたが、既存の規則は body part の参照しか定義していなかった。後の更新は、body part または message-body 全体を指せること、MIME または SIP Content-ID を使えることを規範化した。

古いパケットを読む際は、現在のルールを自動的に遡及させてはいけない。実装が何を対象と解釈したかを、フレーミングとバイト列から確かめる必要がある。

リスト書式は方法の意味を決めなかった

RFC 4826 と RFC 5364 の書式は copyControl や匿名化を表せる。INVITE では受信履歴の見せ方に意味を持つが、既存ダイアログの BYE に to、cc、bcc を適用しても同じ意味にはならない。

受信者はアプリケーションを理解し、理解しない方法を受け入れてはならない。発行者を認証し、操作権限と opt-in を確認し、対象ダイアログの所有関係を評価する。multiple-refer の対応表示は、その判断を代行しない。

重複 URI も正規化される。提出された項目数と送信要求数が違うとき、その理由が等価比較なのか欠落なのかを示す記録が必要だ。

会議状態は別の時間軸を見た

仕様は、会議の参加者変化なら conference state を使えるとする。この購読はサービス状態を観測するもので、親 REFER の遅延した応答ではない。

通知は version を持ち、full または partial で、購読断の穴も生じる。参加者が消えた事実は重要だが、特定 BYE の因果を単独では証明しない。本人の離脱や別管理者の操作もあり得る。

要求、子トランザクション、対象応答、会議状態を別台帳で結ぶべきである。食い違いは、発行漏れ、方針拒否、観測欠落を見つける材料になる。

証拠の境界

成功応答から言えるのは、特定の受信者が、特定の Content-ID 参照と有効リストを持つ REFER を、特定の購読条件で受理したことまでである。全対象の実行や業務結果は含まれない。

最低限、発行者と権限、非分岐根拠、要求と応答、返された Refer-Sub、参照対象とハッシュ、元リストと有効集合、子要求、各応答、版付きサービス状態、人間または商取引の結果を分離して保存する。

一つの命令にまとめる効率と、一つの証拠に潰すことは別である。RFC 5368 は前者だけを提供した。