要約

  • RFC 6665のSubscription-State: terminatedが終わったと断定する対象は購読であり、監視されるリソースではない。
  • deactivatedは移行、timeoutは更新失敗、invariantは予見可能な期間の不変性を示し、リソース状態の消滅を明言するのはnoresourceである。
  • 証拠として残すなら、購読のライフサイクル、リソース本文、NOTIFYトランザクション、イベントパッケージによる解釈、後続の判断を別々に結び付ける必要がある。

赤い表示が二つの状態機械を一つにしてしまう

「terminated」という語は、画面上で隣にある名詞を修飾しているように見える。端末、アカウント、通話、監視対象の横に出れば、それ自体が終了したと読みたくなる。しかしRFC 6665でこの値の主語となるのは購読だ。受信した購読者は、その購読を終了済みと扱わなければならない。結論は強いが、射程は限定されている。

リソースには別の状態機械がある。その意味を決めるのは個々のイベントパッケージであり、本文が完全状態か差分か、本文の欠如をどう扱うか、中立状態が何かもパッケージに委ねられる。汎用的なSIPイベント枠組みは、プレゼンス、メッセージ待機、通話情報、各種アプリケーション状態を一つのモデルへ押し込まない。

観測関係が壊れても対象は健全なままかもしれない。対象が消えた後も最終通知だけが移動中かもしれない。この両方を単一の「終了」列に格納すれば、観測不能と対象変化を見分ける証拠が失われる。

七つの理由は同じ結末を指していない

RFC 6665の終了理由には運用上の差がある。deactivatedなら直ちに新しい購読を作るよう求められ、通知側ノードの移行が代表的な用途になる。probationは再試行を先へ延ばす。rejectedは認可方針の変化を示し、再試行を勧めない。timeoutは期限までに更新されなかったことを表し、直ちに購読し直せる。giveupでは通知側が間に合うよう認可を得られなかった。

境界を最も明瞭にするのはnoresourceとinvariantの対比だ。前者は監視されていたリソース状態がもう存在しないことを、後者は予見可能な将来にその状態が変化しないと保証されていることを示す。どちらも再購読を勧めないが、一方は不在、もう一方は持続を表す。同じ「終了」に正規化してはならない。

理由が欠ける、または未知である場合もある。そのときはretry-afterを考慮して再購読できるが、受信側がnoresourceを補完してよいわけではない。終了値に付いたexpiresも手掛かりにはならない。仕様上、その組み合わせのexpiresには意味がなく、無視しなければならない。

最後の通知が最後のリソース値を運ぶとは限らない

購読解除はExpires: 0を持つSUBSCRIBEで行う。成功すれば最後のNOTIFYが送られるが、RFC 6665は、その要求がリソース状態を含む場合と含まない場合の両方があると明記する。購読者はどちらにも対応しなければならない。

本文がなければ、分かったのは関係が終わったことだけで、対象の最終値ではない。本文があれば、メディア型、パッケージ規則、完全・部分状態の区別、版情報に従って解釈する必要がある。ヘッダーが別仕様に属する本文の意味を代行することはない。

NOTIFYへの200応答も境界がある。通知を受け入れられるなら速やかに返すべきで、利用者の操作を待ってトランザクションを開いたままにしてはならない。したがって200はSIP要素による自動処理の受理を示すが、既読、担当者の確認、後工程完了を証明しない。

購読の成立通知は会話上の順序を追い越し得る

購読成立を確認するのは最初のNOTIFYだ。SUBSCRIBEへの2xxは要求が受理され、直ちにNOTIFYが送られることを意味するものの、再順序化、損失、フォークによって、NOTIFYがSUBSCRIBEトランザクションの完了より先に着くこともある。最初のNOTIFYまでは、リソースをイベントパッケージ所定の中立状態として扱う。

ここには少なくとも三つの時計がある。要求と応答のトランザクション、作成・更新・期限切れ・終了の購読、パッケージが伝えるリソース変化だ。さらに受信、解析、表示を行う観測システムの時計が加わる。取得時刻だけで並べ、最後の行を真実と呼べば、原因と結果が逆転しかねない。

監査可能な記録には、ローカル購読キー、Call-IDとタグ、Event値、宛先、NOTIFY CSeq、状態ヘッダー、理由、再試行間隔、受信時刻、認証結果、応答を残す。別枠で本文の有無、メディア型とダイジェスト、パッケージとパーサーの版、完全・部分状態の属性、アプリケーションが導いた値を保存する。

usageが終わってもdialogは続き得る

RFC 6665は購読をdialogに関連付けられたアプリケーション状態として定義する。Robert SparksのRFC 5057は、その関連を同一性と取り違えてはいけない理由を示す。複数のdialog usageはdialog状態を共有しながら独立した寿命を持つ。転送ではinvite usageとsubscription usageが同じdialogにあり、購読だけが終わってinvite側は残ることがある。

後続仕様は制御面をさらに整理した。RFC 7621はGRUUを用いて意図したユーザーエージェントのインスタンスへ要求を届ける方法を明確にする。SparksとRoachによるRFC 7647は、REFERが暗黙に作る購読とdialog再利用の問題を扱う。宛先の精度と構造の明瞭さは、どのusageがイベントを生んだかという曖昧さを減らすが、terminatedの対象をリソースへ広げない。

「セッション終了」という表示も同じ罠を持つ。購読、dialog、dialog usage、通話、通知側インスタンス、パッケージ定義のリソースは関係していても同義ではない。それぞれに識別子と後継状態が要る。

Roachが標準に残したのは、境界を守るための構造だった

RFC 6665は2012年7月にStandards Trackとして発行され、RFC 3265を置き換えた。両文書の単独著者はAdam Roachである。現在のIETF人物ページには、1998年からの参加、2017年から2020年までのApplications and Real-Time Area Director、XCON、SIPCORE、NETVCの議長歴が記され、RFCは23件、2026年4月22日時点で現職はない。

これは標準策定への貢献の来歴であって、特定の配備環境を支配した証明ではない。理由の対応付け、タイマー、画面表示は製品と運用者の責任だ。Roachの名は枠組みの出所を示すが、実装やリソース判断を保証しない。

一つの証拠束で五つの問いを分ける

購読の同一性は、どのdialog、イベントパッケージ、宛先、ローカルキーか。ライフサイクルは、どの状態、理由、期限規則、受信時刻か。リソースは、本文があり、何が解釈し、どのダイジェストと版だったか。通信上の保管は、通知側、認証、トランザクション、応答が何か。行動は、再試行、待機、移行、警告、案件終了のどれを、誰の規則で選んだか。

分離は自動化を弱くしない。timeoutをリソース死亡ではなく監視空白として扱える。deactivatedを後継購読の最初のNOTIFYまで未確定にできる。noresourceの後に不可逆な処理をするなら、アプリケーション側の裏付けを要求できる。理由なしは正直に不明と表示できる。

運用画面には短い状態が必要だという反論は正しい。だからこそ、短い表示は「購読終了、理由は既知または不明、リソース証拠は有りまたは無し」と、プロトコルが証明した範囲を示すべきだ。赤を使うなら、凡例まで正確でなければならない。

出典