要約

  • RFC 3261のダイアログ識別子は、Call-ID、local tag、remote tagから成る。同じtagでも、相手側から見ればlocalとremoteが反転する。
  • forkされた一つのINVITEは、複数のearly dialogやconfirmed dialogを作り得る。発信側のCall-IDとtagを共有し、各応答側が別のTo-tagを加えることで区別した。
  • ダイアログは後続トランザクションの順序、経路、宛先を保持する。人の身元、メディアストリーム、通話成功を証明する識別子ではない。

「一回の招待」が単数で終わらない

電話をかける、という表現は単純である。一つの宛先を選び、一人が応答し、一つの会話が始まる。しかしSIPの宛先探索では、プロキシが同じINVITEを固定電話、ソフトフォン、ゲートウェイへ同時に送れる。複数の端末が鳴り、複数の応答が返ることもある。

最初のトランザクションの識別だけでは足りない。トランザクションが扱うのは、一つの要求、その再送、そして応答の対応である。応答後のACK、再交渉、BYEは新しいトランザクションになる。途中のプロキシは経路に残りたがり、端末は到達先を変えるかもしれない。必要だったのは一回の交換ではなく、後の要求を解釈するための持続的な文脈だった。

1999年のRFC 2543は、これをcall legと呼び、Call-ID、To、Fromの組み合わせで識別した。この版もforkの問題を理解していた。複数のUASに届き得る要求への応答にはTo-tagを付け、発信側が応答元を区別できるようにした。異なるtagを持つ複数応答は、それぞれ別のcall legだった。

ただしFrom-tagは任意であり、経路の組み立ても十分に規定されていなかった。2002年のSIP 2.0は、callというアプリケーション上の語から一段離れ、プロトコル状態に明確な境界を与えた。

名前の半分は相手が決める

RFC 3261は、dialogを「しばらく持続する二つのユーザーエージェント間のpeer-to-peer SIP関係」と定義した。ダイアログはメッセージを解釈する文脈であり、双方向の順序を整え、後続要求を正しく届けるための状態である。

各UAが持つdialog IDは、Call-ID、local tag、remote tagの三つでできる。localとremoteは視点依存だ。Aliceのlocal tagはBobから見ればremote tagであり、Bobのlocal tagはAlice側のremote tagになる。世界共通の並びではなく、両端が同じ二つの不透明な値を反対向きに見る。

最初の要求にはCall-IDとFrom-tagが入り、RFC 3261の説明では「半分のdialog ID」になる。ダイアログを成立させる応答がTo-tagを加える。発信側ではFrom-tagがlocal、To-tagがremoteとなり、応答側ではその向きが逆になる。

この分担がforkを解いた。すべての分岐は発信側のCall-IDとFrom-tagを引き継ぐ。一方、各応答端末は独自のTo-tagを返す。関連する一群のシグナリングをCall-IDで束ねつつ、複数の相手との状態を同一視せずに済む。

tagは利用者名でも資格情報でもない。RFC 3261は、生成するtagに世界的な一意性と少なくとも32ビットの暗号学的乱数性を求めたが、その目的は一意なdialog IDを作ることだった。推測しにくさは本人確認、権限、表示名の正しさを証明しない。

呼出中にもダイアログは生まれる

INVITEに対してTo-tag付きの101〜199応答が届くと、early dialogが成立する。最終回答の前でも、発信側はその応答元に固有の状態を持てる。対応する2xxが届けばconfirmed dialogへ移り、失敗応答や成功しない分岐ではearly dialogが終わる。

fork中には複数のearly dialogが同時に存在し得る。一台は呼出中、別の一台は進行状況を返し、もう一台は拒否しているかもしれない。発信側の半分を共有しても、remote tagが違うため混ざらない。複数の2xxが届けば、複数のconfirmed dialogをそれぞれACKし、アプリケーションが余分な結果を整理する必要もある。

これはPRACKと隣接するが別の仕組みである。PRACKとRSeq/RAckは重要な暫定応答の信頼性と順序を扱う。tagは、その応答がどのpeer contextに属するかを扱う。early dialogに名前があるから信頼化された暫定応答を置けるのであって、信頼化が名前を作るわけではない。

Via branchも別階層にある。branchは一つのトランザクションと再送を照合する。Call-IDと両tagは、そのトランザクションが終わった後も、新しいトランザクションを通じて残る。両者を同じキーにすれば、状態を早く消しすぎるか、別の要求を一つの交換へ誤って畳み込む。

三要素の後ろに経路と順序がある

ダイアログはheaderの三値だけではない。RFC 3261は、local/remoteのsequence number、両URI、remote target、secure flag、順序付きroute setも状態として保持する。

CSeqには方向がある。UAは新しいin-dialog要求を出すときlocal sequenceを進め、相手はremote sequenceとして記録する。以前より小さい値は順序違反として拒否できるが、番号の飛びは直ちに異常ではない。途中の認証challengeで一つの試行が宛先まで届かなかった可能性があるからだ。

route setは、どのプロキシが以後のシグナリング経路に残るかを示す。UASは要求のRecord-Route順、UACは応答から逆順に保存する。RFC 3665のcall flowでは、同じCall-IDと二つのtagがACK、BYE、応答に現れ続け、Route headerが選択済みプロキシを通している。

remote targetは現在の相手のContactである。ダイアログ成立時に設定され、成功したtarget-refresh requestで変更できる。INVITEが作ったダイアログでは、RFC 3261の基本的な更新方法はre-INVITEだった。

Contactが変わってもdialog IDは変わらず、route setも書き換えない。tupleは「どの文脈か」、route setは「どの中継点を通るか」、remote targetは「いまどこへ届けるか」を答える。移動性、経路、相関を一つの値へ押し込まなかったことが重要だった。

ダイアログは音声そのものではない

成立後は、どちらのpeerも新しいトランザクションを開始できる。その要求を送る側が今回のUAC、受ける側がUASとなり、最初のINVITEの役割に縛られない。ダイアログは一回のclient/server関係より対称的で長命だった。

RFC 3264のSDP offer/answerは、メディアストリーム、codec、アドレス、portを協議する。交換を関連付ける上位文脈としてSIPなどを仮定し、後のofferでメディアを追加、削除、変更できる。

したがってconfirmed dialogは音声到着の証拠ではない。RTP sourceを識別せず、codec合意や品質も保証しない。シグナリング文脈が成立しても、メディアの成果にはメディア側の証拠が要る。

RFC 4028はre-INVITEまたはUPDATEによるsession timerを加えた。一つのINVITEから生まれた複数ダイアログに、異なる間隔やtimerなしの状態を認めている。refreshは既存ダイアログ内の新トランザクションであり、成功すればsessionを延ばし、失敗すればBYEへ進み得る。識別子は無期限の存続権ではない。

一つのダイアログに複数のusageが乗る

拡張は「一つのダイアログ＝一つの通話」という理解も崩した。INVITEはinvite usageを作るが、ダイアログ内のSUBSCRIBEやREFERは別usageを追加できる。RFC 5057によれば、usageはCall-ID、tag、CSeq、route set、Contact、remote target、secure flagを共有しながら、subscription期間など固有状態を持つ。

一つのusageが終わっても他が必ず終わるわけではない。BYEでinvite usageを終了してもevent subscriptionが残る場合があり、subscription終了もinvite usageを消すとは限らない。ダイアログは共通のシグナリング器であって、全アプリケーション状態の寿命を一つにする宣言ではなかった。

RFC 6665のevent notificationでは、SUBSCRIBEとNOTIFYがダイアログ状態を使いながら、個別subscriptionの照合にEventも使う。forkしたSUBSCRIBEが別々にrefreshされる複数ダイアログを作ることもある。Call-ID/tag tupleは共通文脈を示すが、すべてのusageの完全な識別子ではない。

SIPの三要素は、何でも識別するから強いのではない。トランザクション、移動するContact、固定された経路、変化するメディア、追加usageの間で、ちょうどpeer contextだけを狭く識別したから強かった。