12. Dialogs

12 Dialogs

ダイアログは, 一定期間継続する 2 つのユーザエージェント間のピアツーピアの SIP 関係です. ダイアログは, 呼 (call) を確立する手段として (セクション 13), また呼を変更し, 終了するために使用されます (セクション 14 および 15). ダイアログはより高度な機能の基盤を形成します (たとえば, 1 人の参加者から他へのメディアのリソースへの参照のための PRESENCE および REFER [1]) は後で定義されます.

ダイアログは Call-ID とローカルタグおよびリモートタグ (それぞれは To および From タグとして知られています) によって識別されます (これらは一意のダイアログ識別子を形成します). ダイアログ内で送信される一連のメッセージは, そのダイアログのリモートターゲット (ダイアログ内でメッセージを送信するための URI) と, ダイアログ内で送信される要求に対応するルートセット (プロキシのセット) を含むダイアログ状態の維持を含みます. ダイアログは, この章全体で説明されるように, 確立された UAS と UAC の両方の動作によって作成されます.

この節では, ダイアログ状態の概念を導入します. この状態は, 各ダイアログ内で送信される要求をルーティングするために必要です. この状態は, 各 UA の "側" から追跡されます. すなわち, 特定のダイアログ内で, UAC と UAS はそれぞれ異なる状態を維持します. UA は, ダイアログの "ローカル" および "リモート" 側の概念を使用して状態を記録します. UAS のローカル URI, リモートターゲット URI, リモートシーケンス番号, およびリモートタグは, UAC のリモート URI, ローカルターゲット URI, ローカルシーケンス番号, およびローカルタグに対応します. ダイアログ状態の各側は, 1 組のダイアログ識別子 (Call-ID, ローカルタグ, およびリモートタグ), ローカルシーケンス番号 (UAC のみ), リモートシーケンス番号, リモート URI (UAS がメッセージを送信するか, メッセージをどこへ送信するかを決定するために使用), リモートターゲット URI, およびルートセットから構成されます.

  第 12 章の "リモート" および "ローカル" という用語は, 第 8 章の一般的な UAS および UAC の動作ではなく, 特定のダイアログ状態を指します.

サイドは, ダイアログを作成し, 初期 INVITE 応答 (成功または不成功) の処理を通して, およびダイアログ内で送信される以降の要求を通して, ダイアログ状態を維持します.

12.1 Creation of a Dialog

ダイアログは, それを作成する UAS と UAC の両方の動作によって作成されます. UAS の動作についてはセクション 12.1.1 に, UAC の動作についてはセクション 12.1.2 に記載されています. ダイアログは, To フィールド内にタグがあり, かつ応答が 2xx または 101-199 応答コードであるという条件の下で, 新しい INVITE の UAS 応答によって作成されます. リダイレクト 3xx 応答によっては, ダイアログは作成されません.

  注: RFC 2543 では, ダイアログは呼 (call) と呼ばれていましたが, 現在はダイアログと呼ばれています. これにより, 呼 (call) という用語は非公式な意味に残ります (例: 呼のセットアップ). ダイアログは, セッションを確立するための INVITE の初期交換によって確立されます. ただし, ダイアログは必ずしもセッションと 1 対 1 に対応するわけではありません. 複数のダイアログ (したがって複数の呼) が同じセッションに関連付けられる可能性があります. ユーザエージェントが同じセッションに対する再 INVITE を送信する場合, セクション 12.2 で説明されるように, 新しいダイアログは作成されません. しかし, ユーザが別のダイアログをもたらす新しい INVITE を送信し, その INVITE が同じセッション内の別のユーザを指す場合, 別のダイアログ (したがって別の呼) が作成されます. これは, たとえば, 通話中にユーザがコール転送を使用して最初の呼を終了し, 新しい呼を開始する場合に発生します.

12.1.1 UAS Behavior

ダイアログを作成する応答 (すなわち, 101-199 または 2xx 応答) を生成する UAS は, 応答 (セクション 8.2.6.2) の To ヘッダフィールド内にタグを含めなければなりません (MUST). このタグは, 応答に含まれる Call-ID 値, および呼の発信者が提供する From タグの値と組み合わせて, ダイアログ識別子の UAS 側を形成します. ダイアログ識別子の UAC 側 (To および From タグの逆) は, ダイアログを作成する要求によって確立されます. したがって, 要求がダイアログを作成しない場合 (例: 非 INVITE 要求), 要求を送信する UAC は, 応答に含まれる To タグの値を記録する必要はありません (NEED NOT). ダイアログ識別子の UAC 側は, 要求内の From タグ, および応答内の To タグ (要求の作成者であり, 応答の作成者でないため) によって形成されます. BYE 要求のような後続の要求は, 要求内の From タグを使用してダイアログ識別子の UAS 側を確立します (その要求の UAC であるため).

呼を確立する UAS は, ダイアログを作成する応答内に Record-Route ヘッダフィールドの値を含めてもよい (MAY) です. これらは, 後のリクエストはこれらを通過することを確認するために, ダイアログ状態に追加されます.

作成されるダイアログのリモートシーケンス番号 (UAS の観点から) は, 応答の CSeq ヘッダフィールド内のシーケンス番号の値に設定されます. リモート URI は, 応答の To ヘッダフィールド内の URI に設定されます. リモートターゲット URI は, 応答の Contact ヘッダフィールド内の URI に設定されます.

12.1.2 UAC Behavior

ダイアログを作成する応答 (すなわち, 2xx または 101-199 暫定的な応答) を受信する UAC は, 応答の To フィールドからダイアログ識別子のリモートタグ部分をコピーしなければなりません (MUST). 応答が 2xx である場合, 一部の要求は受信した以降の 1xx 応答からダイアログ状態を作成する可能性があるため (セクション 13), リモートタグは要求を作成する応答からコピーされる必要があります (MUST). リモート URI は, 応答の To ヘッダフィールド内の URI に設定されます. リモートターゲット URI は, 応答の Contact ヘッダフィールド内の URI に設定されます.

  応答内の Record-Route ヘッダフィールド値が存在する場合 (UAS が提供したもの), UAC はそれらをルートセットの初期値として MUST で保持しなければならず (MUST), それらを反転しなければなりません (MUST) (Record-Route ヘッダフィールドが追加された逆の順序で, それらがリクエスト内に表示されるため). UAC は, ルートセットを使用してダイアログ内で要求を送信します (セクション 12.2.1.1). 後のリクエストがダイアログ内で送信される場合, UAC ごとのローカルシーケンス番号は, 要求の CSeq ヘッダフィールド内のシーケンス番号に設定されます. このシーケンス番号は, ダイアログ内で送信される各要求に対して 1 ずつ増加しなければなりません (MUST).

  注: リダイレクト 3xx 応答はダイアログを作成しません. リダイレクト 3xx 応答は, 既定の要件に従って UAC に処理されます.

12.2 Requests within a Dialog

この節では, ダイアログ内で要求がどのように送信されるかを記述します. これには, 再 INVITE (ダイアログのリモートターゲットを更新するための INVITE) や BYE など, 既存のダイアログ内で送信される要求が含まれます. これらの要求は, セクション 8.1.1 で定義された UAC の一般的な要求構築手順を使用して構築されます. そのため, この節は, それらの手順に対する特定の違いのみを説明します. これらの要求の送信は, ダイアログ内のリクエストのシーケンス番号 (CSeq) を使用しません (警告: いくつかの例外があります). プロキシは, ダイアログ内で送信された要求のルーティングを支援するためのルートセット情報の実体テンプレートを使用してもよい (MAY) です.

表記法: この節では, ダイアログは, 受信側が要求を処理する前に受信側がすでに UAS または UAC として設定されていると仮定します. したがって, 呼の初期 INVITE が作成された場合, その要求は, 初期 INVITE のステータスに関係なく, ダイアログ内の要求として扱われません.

12.2.1 UAC Behavior

ダイアログ内で送信される UAC 要求は, ダイアログ状態を使用してルーティングされなければなりません (MUST).

12.2.1.1 Generating the Request

要求の構築中, To, From, Call-ID ヘッダフィールドは, ダイアログ状態のリモート URI, ローカル URI, Call-ID に設定されなければならず (MUST), CSeq ヘッダフィールドは, ダイアログ内で送信される以前の要求の CSeq 値よりも 1 大きい新しい値に設定されなければなりません (MUST). 要求の Request-URI は, ダイアログのリモートターゲット URI に設定されなければなりません (MUST). ルートセットが空でない場合, 要求内の Route ヘッダフィールドの値は, ルートセットの値でなければなりません (MUST). ルートセットが空の場合, Route ヘッダフィールド値は省略されるべきです (SHOULD).

  注: これは, ルートセットが空でない場合, 要求がプロキシを通過することを保証します (これがルートセットを提供した目的です). リモートターゲット URI は, UAC と UAS の間の直接的なルートを提供するため, プロキシをバイパスするために使用されます.

例えば, 単一の Record-Route (proxy) を通じて作成されたダイアログ内で, UAC が再 INVITE を送信する場合:

  Re-INVITE sip:[email protected] SIP/2.0
  Via: SIP/2.0/UDP host.ua1.example.com;branch=z9hG4bKvscx
  Max-Forwards: 70
  To: Bob `&lt;sip:[email protected]>;tag=a6c85cf`
  From: Alice `&lt;sip:[email protected]>`;tag=1928301774
  Call-ID: [email protected]
  CSeq: 314160 INVITE
  Contact: `&lt;sip:[email protected]>`
  Route: `&lt;sip:proxy.example.com>`

注: 唯一の Via ヘッダフィールドは送信者の URI です. 再 INVITE の CSeq 値は, 元の INVITE の CSeq 値よりも大きくなければなりません (MUST). CSeq シーケンス番号を再利用してはならない (MUST NOT) ことに注意してください. Route ヘッダフィールド値は, ルートセットから取得されます.

次の手順は, 要求をダイアログ内で送信するために適用されます. ターゲットリフレッシュ要求 (セクション 12.2.2 で定義) が, ダイアログ内の UAC によって生成される場合, その要求の Contact ヘッダフィールド値は, ダイアログのリモートターゲット URI を更新しなければなりません (MUST).

  一般に, 再 INVITE は, ダイアログのリモートターゲットを更新するために使用されますが, UPDATE 要求や他のターゲット更新要求も使用できます. このセクションで説明した手順 (ルーティングを含む) は, ターゲットリフレッシュ要求がブーリアンを使用して更新できるようにするための汎用ルールです. INVITE 要求の場合, 再 INVITE は, セッション記述の変更 (セクション 14) を初期化するためにも使用する必要があります (MUST).

12.2.1.2 Processing the Response

ダイアログ内で送信された要求に対する応答は, セクション 8.1.3 で説明された手順を使用して処理されます.

ターゲットリフレッシュ要求 (セクション 12.2.2 で定義) に対する 2xx 応答を受信する場合, UAC は, 応答の Contact ヘッダフィールドの URI を使用して, ダイアログのリモートターゲット URI を更新しなければなりません (MUST).

12.2.2 Target Refresh Requests

ターゲットリフレッシュ要求は, ダイアログ内で送信される要求で, ダイアログのリモートターゲットを変更できるものとして定義されます. この仕様における INVITE と UPDATE 要求はターゲットリフレッシュ要求です. ダイアログ内で送信される他の要求 (たとえば BYE) は, リモートターゲット URI を変更するべきではありません (SHOULD NOT).

12.3 Termination of a Dialog

ダイアログは, 成功した (2xx 応答を伴う) 受信 BYE によって, または非 2xx 応答 (例: 拒否された INVITE の 408 または 480) によって終了します (セクション 15 参照). いずれの場合も, 受信側はダイアログ状態をクリアしなければなりません (MUST). 成功した BYE の送信側は, それを BYE を受信した後にのみクリアしなければなりません (MUST) (ただし, 失敗した INVITE の UAC は, ダイアログ状態をすぐにクリアしてもよい (MAY)).

  注: 失敗した INVITE に対応するダイアログは, 受信された最終応答 (成功または失敗) によって終了します. 成功した INVITE に対応するダイアログは, 後続の BYE 要求によってのみ終了します. したがって, 再 INVITE は, 元の INVITE 要求を含むダイアログを終了させません.

  失敗した INVITE は, 簡単なトランザクションとして扱われます. 成功した INVITE に対応するダイアログは, 受信した BYE 要求を介してのみ終了します. 受信した BYE 要求を介して終了した後でさえ, UAC は, ダイアログ内のすべてのトランザクションが完了するまで, 古いダイアログ状態を保持し続ける場合があります (MAY).