要約

  • RFC 3326 は、同じ CANCEL や BYE を発生させた別の分岐、応答、外部プロトコルの原因を、動作とは独立した Reason 値として運べるようにした。
  • Reason は任意で受信者が無視でき、SIP の基本処理を変えない。したがって、存在は出来事の真実、発信者の直接観測、完全な中継、受信側の利用を証明しない。

任意の情報が不在着信を決めた

一つの INVITE が複数の端末へ分岐し、その一つで応答されたとする。プロキシは残る分岐へ CANCEL を送り、呼出しを止める。まだ鳴っていた端末から見ると、発呼者が途中で諦めた場合と同じである。いずれも音が止まり、呼は成立しない。

しかし、履歴の意味は違う。別の端末で本人が応答したなら「不在着信」を増やすべきではない。誰も応答せず発呼者が中止したなら、通知には意味がある。CANCEL は分岐を止める操作を示すが、何がその操作を引き起こしたかは示さない。

RFC 3326 は Reason を定義し、成功した分岐を受けて作られた CANCEL に SIP cause 200 と「別の場所で完了」という説明を載せられるようにした。新しい取消方法を増やさず、同じ操作へ原因を別層として添えたのである。

利用範囲は CANCEL だけではない。ダイアログ内の任意の要求、すべての CANCEL、そしてステータスコードが明示的に許す応答に置ける。成功応答に含まれた提案が受け入れられないクライアントは、ACK の後に BYE を送り、488 を理由として示せる。第三者呼制御装置は B の 486 Busy Here を観測し、A 側のダイアログを BYE で閉じながら原因を渡せる。

これらはすべて、ある場所の出来事が別の場所の要求を生む場面である。後の要求だけを見ても失われる因果を、Reason が細い封筒に入れて運んだ。

無視できることは、無害という意味ではない

仕様はクライアントとサーバーが Reason を無視してよいとし、プロトコル処理には影響しないと明記した。Reason がなくても CANCEL は有効であり、知らない値があっても BYE は終了させる。これは実装の互換性に重要だった。

同時に、無視できる情報が利用者向け結果には影響する。履歴、課金補助、診断、サービス選択が Reason を参照する場合がある。したがって「プロトコル上必須でない」と「運用上どうでもよい」は同じではない。

パケット上の値は限定された証拠である。ある観測点にその文字列が届いたことは示せるが、別分岐が本当に応答したこと、最終送信ノードが直接見たこと、中継中に改変されなかったこと、受信端末が表示に使ったことまでは示せない。使用結果には別のログが必要になる。

値は protocol から始まり、数値 cause、引用された text、拡張を持てる。SIP と Q.850 は別の名前空間である。数だけを保存すれば、異なる規格の意味を混同する。text は人間の助けになるが、翻訳やベンダー表現で変わるため、機械的な根拠は名前空間と cause の組で保たなければならない。

当初は、一つのメッセージ内で複数値を持つなら各値の protocol が異なる必要があった。RFC 9366 は、登録された protocol が同一 protocol の複数値の意味を定義する場合に限り、繰返しを認めた。それ以外は今も一 protocol 一値である。複数値をどう解釈するかを受信実装が勝手に決めてはならない。

外部原因を運ぶと観測点が遠くなる

RFC 3398 は ISUP と SIP の対応を定めた。PSTN 側から REL が届けば、ゲートウェイは SIP CANCEL を生成し、受け取った Q.850 cause を Reason に入れられる。SIP 側は取消という事実だけでなく、電話網側の解釈も受け取る。

RFC 6432 は 100 Trying を除く SIP 応答で Q.850 cause を運べるようにした。RFC 8606 は、利用可能な場合に ISUP の解放位置を location として追加した。この位置は利用者の物理的な場所ではなく、ローカル網、トランジット網、遠端網など、解放したネットワーク部分を粗く示す。

翻訳された値は便利だが、原観測そのものではない。ゲートウェイが受信値をそのまま移したのか、対応表で変換したのか、ローカルに補ったのかを、最終パケットだけからは判断できない。外部メッセージ、対応表の版、ゲートウェイ、時刻、コピー経路を残して初めて由来を説明できる。

RFC 7044 の History-Info と RFC 5806 の Diversion は、再ターゲットや転送の履歴を扱う。Reason は特定の要求や許可された応答がなぜ発生したかを扱う。どこを通ったかと、なぜ終了したかは関連するが同じ事実ではない。

コピーは説明を守り、誤りも守った

Reason を含む CANCEL を受けて次の CANCEL を作るプロキシは、その値をコピーすることが推奨された。コピーしなければ、取消は届いても説明は途中で途切れる。末端は再び動作だけを見ることになる。

ただし、転送された値は直接観測ではない。最後のプロキシは前のプロキシを繰り返しているだけかもしれない。中間装置が text を直し、拡張を落とし、cause を写し間違えれば、誤りにも正規の見た目が与えられる。監査では生成、観測、翻訳、中継を分ける必要がある。

HERFP は改変の結果を深刻にした。分岐した INVITE では、一つの分岐の最終エラーが他の分岐の進行中にはクライアントへ届かないことがある。最終状態を暫定応答へ包む用途が想定され、Reason を偽造または削除すると、クライアントが以前の要求を正しく更新できず、セッション確立が不可能になる場合があった。そこで適切な完全性保護が推奨された。

完全性が確認できても証明範囲は限定される。特定端点間で保護対象のバイトが変わっていないことは示せるが、最初の主張が誠実だったことや対応表が正しいことは示せない。保護がない値は廃棄すべきというより、強い自動判断に使う前に別の分岐応答やゲートウェイ記録で補うべきである。

RFC 3326 の歴史的な教訓は、状態と説明を別々に残した点にある。動作は呼を止める。理由は、その停止をどう理解するかを助ける。二つを分離したからこそ、システムは理由を利用しながら、その理由が証明済みの歴史ではないことも表現できた。

出典