要約

  • RFC 5359 の Call-ID 再利用、CSeq の初期化、未計算 Digest、Content-Length: ... は可読性のための編集処理である。テストでは一意な識別子、正確な長さ、実際の認証値と最終バイト列を生成し直す必要がある。
  • 文書は例を慎重に確認された作業部会レビュー済みシナリオと呼ぶ一方、プロトコル上の決定事項は参照仕様にあり、B2BUA や 3pcc を含む別方式も認める。レビューは実装経路や製品動作の証明ではない。
  • メッセージ受理、トランザクション、ダイアログ、加入状態、本人性、グループ権限、SDP、メディア、利用者結果は別々の証拠である。同じ矢印列だけではサービス成功を宣言できない。

再利用された識別子には編集上の出所がある

例の目的は、多数のサービスを人が比較できる形で示すことにある。そのため Call-ID が別例でも現れ、CSeq はしばしば単純な値から始まる。ヘッダー順も整えられ、最小限の集合が示される。

実運用では識別子がトランザクションとダイアログの帰属を支える。並行テストで再利用すれば、応答を誤った状態に結び付けたり、再送と新規要求を混同したりする。

例から fixture を作る処理はコンパイラーである。元の節、文書版、置換規則、生成器版、一意値、任意分岐、完成バイト列とハッシュを保存すべきだ。

それがなければ緑の結果は、試験器が自分の補完を受け入れたことしか証明しない。

省略記号はパーサーを通過しない

RFC 5359 は Digest 応答が実際の MD5 計算ではなく、本文長が ... で示される場合があると明記する。説明資料としては合理的だが、ネットワークメッセージとしては未完成である。

正確な Content-Length は本文のオクテット数と一致しなければならない。認証値はその実行のチャレンジ、資格情報、メソッド、URI によって決まる。仮値を通す寛容な試験は実装適合性を測らない。

完成した fixture には、全ヘッダー、本文、計算根拠、送信時刻、受信側パーサー判断を結び付ける必要がある。

編集上の空欄を埋める行為を隠さないことが、文書と実行の境界を守る。

作業部会レビューは単一構成を強制しない

シナリオは慎重に確認され、仕様の companion としてレビューされた。これは設計参照として大きな価値を持つ。

同じ箇所は、SIP と参照 RFC がプロトコル問題の決定源であり、例は唯一の実装法ではないと述べる。3pcc や B2BUA は、UA と proxy 中心の例とは異なる証拠保管点を作る。

レビューは図の整合性を支える。仕様は義務を定める。配備構成は役割を選ぶ。実行ログは一回の結果を示す。この四層を統合してはいけない。

BCP の肩書も、現在の製品が全機能を実装し、相互運用し、利用者に正しい結果を届けた証明にはならない。

メッセージ順と状態遷移を別々に記録する

図の F1、F2 などは詳細メッセージを参照し、必須・任意制御とメディア経路を区別する。しかし矢印は受信側の内部状態を保持しない。

構文解析に成功してもトランザクション照合で失敗し得る。正しい応答も期限後なら無効になり得る。proxy が転送しても UA が拡張を拒否できる。機能完了後に古いダイアログが残る場合もある。

バイト列、時刻、方向、branch、tag、Call-ID、CSeq、Route、認証判断、トランザクション、ダイアログ、加入状態を一つの台帳で結ぶべきだ。

見た目が同じ列でも、終状態が違えば同じ実行ではない。

信号と音声は異なる観測である

文書は SIP signaling を中心にし、単純な音声 SDP を使う。高度な offer/answer は別文書に委ねられる。図でも媒体線は制御線と異なる。

INVITE と 200 OK が成立しても、アドレス、codec、ネットワーク方針、媒体中継、端末レンダリングで音声は失敗する。保留も方向性を持ち、sendonly、inactive、受信、再生は同義ではない。

古い 0.0.0.0 保留方法が方向属性に置き換えられたという説明も、文字列だけで利用者の聴取状態を判断できないことを示す。

offer、answer、SDP 版、方向、アドレス、codec、両方向カウンター、再生状態、利用者観測を独立に残す必要がある。

sips は握手の代わりにならない

例の Secure SIP URI は各 hop の TLS と証明書検証を想定する。Digest を使う例もあり、他の保護方式も許される。

URI には証明書チェーン、信頼ストア、名前検証、TLS 条件、終端点、アプリケーション本人性は入っていない。同じ表記でも検証を誤る実装や、途中で信頼境界を変える B2BUA があり得る。

実行時の握手証拠、証明書、検証結果、対向本人性、保護区間、Digest 状態、その後の認可を保存する。

例が前提を置いたことは、その前提が今回成立した証明ではない。

グループ所属は機能権限そのものである

Call Pickup などは部署、家庭内線、コールセンターといったグループを使う。構成員は第三者が見られない詳細ダイアログ情報や操作権限を得ることがある。

RFC 5359 は証明書や共有秘密など通常の SIP 手段で構成員を認証するよう求める。しかし認証された本人性だけでは所属と権限は決まらない。権威ある名簿と版管理された方針が必要だ。

正しい識別子を持つ真正な要求でも、pickup や Join を許されない場合がある。真正な NOTIFY も過剰開示になり得る。

本人性、所属元、有効時点、方針、要求権限、判断、開示項目を別々に記録する。

REFER、Replaces、Join は段階的な結果を持つ

REFER の 2xx は依頼受理を示し、参照先の応答、媒体移動、旧ダイアログ終了や利用者結果までは示さない。後続 NOTIFY もそれぞれの範囲の進捗証拠である。

Replaces は既存ダイアログを新しいものに置換する関係を、Join は既存ダイアログへ新しいものを参加させる関係を表す。正しい Call-ID と tags は対象を特定するが、操作権限を付与しない。

発信者本人性、Refer-To、認可、加入、通知、対象照合、新旧状態、媒体、後始末、利用者結果を段階ごとに保存する。

対象を正しく指すことは参照証拠であり、権限証拠ではない。

後続 RFC と errata は版境界を必要とする

RFC 5359 が参照した SIP Events は当時 RFC 3265 にあった。RFC 6665 は実装経験を反映し、後にこれを廃止して後方互換の改善を定めた。

この関係は規範環境の変化を示すが、製品の採用や古いトレースの自動更新を証明しない。現在の試験は適用仕様版と変換方法を明示すべきだ。

凍結した RFC Editor errata ページには Rejected が一件表示され、Verified、Held for Document Update、Reported の表示群はなかった。これは日付付き状態であり、完全無欠の証明でも、拒否内容を密かに採用する許可でもない。

文書履歴、実装対応、実行結果を別々の台帳に保つ必要がある。