要約

  • RFC 3136は、電話網から始まるサービスでインターネット利用者に着信を知らせ、その希望を電話側へ返すSPIRITSの構成を示した。
  • 利用者の選択は電話網の動作そのものではない。ゲートウェイとSPIRITS Clientが希望を運び、SCFが動作へ置き換え、交換機が呼処理を再開して初めて、その先の結果が生じる。

2001年のダイヤルアップ接続では、一本の電話線をモデムと通話で同時に使うのは難しかった。インターネット接続中にその番号へ電話がかかると、パソコンはデータ通信を、電話網は着信をそれぞれ扱っていた。Internet Call Waitingは、この二つを一時的な判断の流れでつなごうとした。

画面には発信者の番号や名前を表示し、接続を切って応答する、別の番号へ転送する、留守番電話に送る、録音した案内を流す、拒否するといった選択肢を示せる。しかし、利用者がボタンを押しても、電話交換機の状態が直接変わるわけではない。インターネット端末にあるのは意向であり、保留中の呼を扱う権限と状態は電話網側にある。その間には通知、ゲートウェイ、サービス制御、交換機という別々の責任が並ぶ。

RFC 3136は2001年6月にInformational文書として発行された。完全なプロトコル仕様ではなく、電話網で始まりインターネットとの連携を要するサービスについて、構成要素と論理的な接続点を記述したものだ。アーキテクチャ図に線があることは、必要な役割の関係を示すにすぎない。特定の事業者網がその線を実装し、相互運用し、利用者の呼を意図どおり完了した証拠にはならない。

まず電話網が着信を認識する

最初の事実はブラウザーからではなく交換機から生じる。通常は交換機にあるService Switching Function（SSF）がIntelligent Networkのトリガーを認識し、Service Control Function（SCF）と連携する。SCFはサービスの判断処理を担い、呼をどう完了するかを交換機へ指示する。

ここで「電話が鳴った」「トリガーが検出された」「SCFが呼処理に入った」は別々の事実だ。トリガーが未設定、未検出、またはSCFへ届いていないなら、インターネット通知で欠けた最初の段階を補うことはできない。逆にトリガーが動作しても、利用者へ通知されたとは限らない。

SPIRITS Clientは電話制御側に置かれ、SCFから要求を受けて応答を返す。SCFと同じ場所に置くことも、Interface Dを介して接続することもできた。この説明により、図の箱をそのまま物理装置だと読む誤りを避けられる。論理上の役割は責任範囲を示し、別個の機器、ベンダー、組織を意味するとは限らない。

Gatewayは電話側とインターネット側の機能を仲介する。PINTの構成要素と同居する場合もある。SPIRITS Serverは利用者とのやり取りを担当し、着信を通知して選択された処理を返す。箱が同じ機器にまとまっていても、記録上の段階が一つに消えるわけではない。

AからEまでの接続点は異なる証拠を運ぶ

Interface Aは利用者端末のPINT ClientからPINT Serverへ要求を送り、主にサービス・セッションの登録と有効化に使われた。登録が成功すれば、その期間の利用関係が設定されたとは言える。しかし、後の着信トリガー、端末への到達性、通話処理の実行までは証明しない。

Interface BはSPIRITS ServerとGatewayをつなぐ。主な役割は二つあり、発信者名や番号が得られる場合はそれも含めて着信を通知すること、そして利用者がその場で選んだ処理をGatewayへ返すことだった。通知を受け取ったことと応答が返ることは、別々のメッセージである。選択を送っただけではGatewayが受理・転送したとは限らない。

Interface CはGatewayとSPIRITS Clientの間にあった。GatewayはServerへ中継する場合も、仮想Serverとして要求を終端する場合もある。したがって、Gatewayの記録にある「ここで終端」は、構成上の正規な終点かもしれないし、先の処理へ進んだ証拠がないという意味かもしれない。実際の構成を見ずにログの意味を決められない。

Interface DはSPIRITS ClientとSCFを結ぶ。トリガーのパラメーターはSCFからClientへ渡り、利用者が選んだ処理はSCFへ戻る。RFC 3136は、この選択を適切な動作へ「変換」し、SSPで保留されていた呼処理を再開するのはSCFだと明記した。画面上の選択と電話網での動作の間に、誰が判断するかを置いたのである。

Interface EはPINT要求をSCFへ送り、電話サービスを実行させる経路だった。PINTはインターネット側から電話網へサービスを求め、SPIRITSは電話網で起きた事象からインターネットとの連携を求める。構成要素の共有は、この向きの違いや各段階の記録を一つにしない。

希望は電話網が理解する動作へ置き換えられる

利用者が「拒否」を選んだとする。端末はそのクリックを正確に記録できる。Serverは情報をまとめ、Gatewayが受け、ClientがInterface D経由でSCFへ運ぶ。それでも、発信者に案内が流れたことや、保留中の呼が切断されたことの証明にはならない。

SCFには別の判断がある。サービス規則と現在の呼の状態に照らして選択を解釈し、電話網が処理できる動作へ置き換える必要がある。「拒否」には案内と切断が必要かもしれない。「転送」には宛先、許可、追加の呼処理が要る。「応答」には、同じ回線を音声に使えるよう、先にダイヤルアップ通信を切らなければならない場合がある。

次に交換機が動作しなければならない。SCFの応答待ちで呼が保留されていると、遅れて届いた選択はメッセージとして正しくても、通話処理には間に合わないかもしれない。転送先が有効な番号でも応答しないことがある。案内音声が再生されても、相手が最後まで聞いたとは限らない。留守番電話が応答しても、メッセージが使える形で保存されたとは限らない。RFC 3136はこの最終的な効果をすべて観測する保証を置かなかった。

したがって証拠の階段は、登録、トリガー検出、通知の送信、端末への到達と表示、処理の選択、Server・Gateway・Clientでの受領、SCFによる変換、交換機での再開と実行、宛先側の結果、独立した照合へと続く。前の段階の受領記録に、後の段階の意味を勝手に持たせてはならない。

通話記録も観測者の記述にすぎない

RFC 3136は、その場の選択だけでなく、あらかじめ登録した自動処理も扱った。利用者はすべての着信を留守番電話へ送る設定や、発信者番号ごとの処理を設定できた。その場合、サービスは画面表示を待たずに呼を処理し、後で日付・時刻、発信者番号や名前、処理内容を記録から確認できる。

記録は有用だが、独立した証人ではない。利用者の設定を読み込んだのか、トリガーと番号の対応が正しかったのか、SCFがどの規則を適用したのか、交換機が処理を完了したのか、相手が実際に応答したのかは別の段階だ。ひとつの欄に「処理済み」とあるだけで、それらすべてを確認したことにはならない。

RFC 2995はSPIRITS以前の四つの実装例を記録し、すべてがInternet Call Waitingに対応し、多くがSIPを利用した一方、互いに相互運用できたわけではないとも記した。これは初期の実装が存在した証拠だが、RFC 3136の全インターフェースが共通に配備された、広く普及した、または利用者の通話が成功したという証明ではない。

後続のRFCは設計の発展を示す

RFC 3298は2002年、RFC 3136をもとにSPIRITSの要件を整理した。通知だけなら、PINTや継続的な電話網とのやり取りがなくても成立させられる。電話網の状態を変えない通知機能と、通話処理を動かす機能は別物だと区別した。

RFC 3910は2004年にSIPベースのSPIRITSプロトコルを規定し、登録、通知、電話網の検出点を段階に分けた。たとえば要求検出点は応答を待って呼処理を停止し、通知検出点は報告後に呼処理を続けられる。応答コードひとつも一連の完了を意味しない。202 accepted、検出点の初期化、事象の発生、選択に応じた処理はそれぞれ別の状態である。

RFC 3910はInterface BとCを中心に定め、SCFへ接続するInterface Dは各電話事業者の方針に委ねた。この境界は欠落ではない。利用者の意思を電話サービスの動作へ変える判断点に、各事業者の制度や実装が残ることを認めていた。後年の細かな定義を2001年へ遡らせたり、特定の導入例を裏付けなく推定したりしてはならない。

画面に見える選択と、実行された事実を分ける

証拠の層と実際に動くコードを重視して読むと、RFC 3136の価値はネットワークの先にある。画面上の選択、メッセージ、SCFの判断、交換機の状態、通話記録、人が受けた結果は、それぞれ異なる観測対象だ。実装ごとの構成・プロトコル・障害処理を調べずに、図の論理だけから実際の挙動を断定できない。

RFC 3136は最小限の共通語彙を示しながら、セキュリティやSCF接続の詳しい扱いを一律には決めなかった。共有する枠組みを小さく保ち、実行方法を各事業者に残した設計でもある。これはLu Hengの「Reality Layers」「Running-Code Primacy」「Minimum Initial Specification」を通して読む分析上のレンズであり、RFC 3136の規範や著者の意図だと主張するものではない。

長く残る問いは、画面に着信が出たかではない。希望を動作へ変える権限をどの構成要素が持ち、実行の証拠を誰が記録し、観測がどこで終わったのかである。利用者の選択は境界を越えても、それだけで自分自身を実行する力は得ない。各引き渡しを個別の証跡として残し、所有する側の応答を確認する前に結果を断定しないことが、RFC 3136から引き出せる堅実な教訓だ。

参考資料