メインコンテンツまでスキップ

13. セッションの開始 (Initiating a Session)

13 セッションの開始 (Initiating a Session)

13.1 概要 (Overview)

ユーザエージェントクライアントがセッション (たとえば音声, 映像, ゲーム) を開始したい場合, INVITE 要求を作成します. INVITE 要求はサーバにセッションの確立を求めます. この要求はプロキシによって転送され, 最終的に招待を潜在的に受諾できる 1 つ以上の UAS に到達します. これらの UAS は, 招待を受諾するかどうかユーザに問い合わせる必要があることがよくあります. しばらくすると, それらの UAS は 2xx 応答を送信することで招待を受諾できます (つまりセッションが確立されることを意味します). 招待が受諾されない場合は, 拒否の理由に応じて 3xx, 4xx, 5xx, または 6xx 応答が送信されます. 最終応答を送信する前に, UAS は一時応答 (1xx) を送信して, 呼び出し先ユーザへの接触の進捗を UAC に通知してもよい (MAY) です.

1 つ以上の一時応答を受信した後, UAC は 1 つ以上の 2xx 応答, または 1 つの非 2xx 最終応答を受信します. INVITE の最終応答を受信するのに時間がかかることがあるため, INVITE トランザクションの信頼性メカニズムは, 他の要求 (OPTIONS など) のメカニズムと異なります. 最終応答を受信すると, UAC は受信した各最終応答に対して ACK を送信する必要があります. この ACK の送信手順は応答の種類によって異なります. 300 から 699 までの最終応答については, ACK 処理はトランザクション層で行われ, 一連の規則に従います (セクション 17 参照). 2xx 応答については, ACK は UAC コアによって生成されます.

INVITE に対する 2xx 応答はセッションを確立し, また INVITE を発行した UA と 2xx 応答を生成した UA の間にダイアログを作成します. したがって, 複数の 2xx 応答が異なるリモート UAS から受信された場合 (INVITE がフォークしたため), 各 2xx は異なるダイアログを確立します. これらのダイアログはすべて同じコールの一部です.

このセクションでは, INVITE を使用したセッション確立の詳細について説明します. INVITE をサポートする UA は, ACK, CANCEL, BYE もサポートしなければなりません (MUST).

13.2 UAC 処理 (UAC Processing)

13.2.1 初期 INVITE の作成 (Creating the Initial INVITE)

初期 INVITE はダイアログ外の要求を表すため, その構築はセクション 8.1.1 の手順に従います. INVITE の具体的なケースについては, 追加の処理が必要です.

Allow ヘッダフィールド (セクション 20.5) は INVITE に存在すべきです (SHOULD). これは, ダイアログの期間中, INVITE を送信する UA 上でダイアログ内で呼び出し可能なメソッドを示します. たとえば, ダイアログ内で INFO 要求 [34] を受信できる UA は, INFO メソッドを列挙した Allow ヘッダフィールドを含めるべきです (SHOULD).

Supported ヘッダフィールド (セクション 20.37) は INVITE に存在すべきです (SHOULD). これは UAC が理解するすべての拡張を列挙します.

Accept ヘッダフィールド (セクション 20.1) は INVITE に存在してもよい (MAY) です. これは, UA が受信する応答, および INVITE によって確立されたダイアログ内で UA に送信される以降の要求の両方において, 受け入れ可能な Content-Type を示します. Accept ヘッダフィールドは, さまざまなセッション記述形式のサポートを示すのに特に有用です.

UAC は, 招待の有効期間を制限するために Expires ヘッダフィールド (セクション 20.19) を追加してもよい (MAY) です. Expires ヘッダフィールドで示された時間に達し, INVITE の最終応答が受信されていない場合, UAC コアはセクション 9 に従って INVITE の CANCEL 要求を生成すべきです (SHOULD).

UAC は, Subject (セクション 20.36), Organization (セクション 20.25), User-Agent (セクション 20.41) などのヘッダフィールドを追加するのも有用と考えるかもしれません. これらはすべて INVITE に関連する情報を含みます.

UAC は INVITE にメッセージ本文を追加することを選択してもよい (MAY) です. セクション 8.1.1.10 は, メッセージ本文を記述するために必要なヘッダフィールド (Content-Type など) の構築方法を扱います.

セッション記述を含むメッセージ本文には特別な規則があります — それに対応する Content-Disposition は "session" です. SIP はオファー/アンサー (offer/answer) モデルを使用します. ここでは 1 つの UA がセッション記述 (オファーと呼ばれる) を送信し, それにはセッションの提案された記述が含まれます. オファーは, 望ましい通信手段 (音声, 映像, ゲーム), それらの手段のパラメータ (コーデックの種類など), および応答者からメディアを受信するためのアドレスを示します. もう 1 つの UA は, 別のセッション記述 (アンサーと呼ばれる) で応答し, そこにはどの通信手段が受け入れられるか, それらの手段に適用されるパラメータ, およびオファー者 (offerer) からメディアを受信するためのアドレスが示されます. オファー/アンサー交換はダイアログのコンテキスト内で行われます. したがって, SIP INVITE が複数のダイアログをもたらした場合, それぞれは個別のオファー/アンサー交換です. オファー/アンサーモデルは, オファーとアンサーをいつ作成できるか (たとえば, 進行中のオファーがある間は新しいオファーを作成できない) に関する制限を定義します. これにより, SIP メッセージ内でオファーとアンサーを配置できる場所に制限が生じます. 本仕様では, オファーとアンサーは INVITE 要求, 応答, および ACK にのみ現れます. オファーとアンサーの使用はさらに制限されます. 初期 INVITE トランザクションの規則は次のとおりです.

  o 初期オファーは INVITE になければならない (MUST) か, 存在しない場合は, UAS から UAC に戻る最初の信頼できる非失敗メッセージになければなりません (MUST). 本仕様では, それは最終的な 2xx 応答です.

  o 初期オファーが INVITE 内にある場合, アンサーはその INVITE と相関する UAS から UAC への信頼できる非失敗メッセージ内になければならない (MUST). 本仕様では, それはその INVITE に対する最終的な 2xx 応答のみです. その同じ正確なアンサーは, アンサーより前に送信される任意の一時応答にも配置してもよい (MAY) です. UAC は, 受信した最初のセッション記述をアンサーとして扱わなければならず (MUST), 初期 INVITE に対する以降の応答内のセッション記述を無視しなければなりません (MUST).

  o 初期オファーが UAS から UAC へ戻る最初の信頼できる非失敗メッセージ内にある場合, アンサーはそのメッセージに対する確認応答 (本仕様では 2xx 応答に対する ACK) 内になければならない (MUST).

  o 最初のオファーに対するアンサーを送信または受信した後, UAC は, 以前のすべてのオファーに対する応答を受信しており, かつ応答を得ていないオファーを送信していない場合に限り, そのメソッドに指定された規則に基づいて要求内に後続のオファーを生成してもよい (MAY) です.

  o UAS が初期オファーに対するアンサーを送信または受信すると, 初期 INVITE に対するいかなる応答内でも後続のオファーを生成してはならない (MUST NOT). これは, 本仕様のみに基づく UAS は, 初期トランザクションが完了するまで後続のオファーを決して生成できないことを意味します.

具体的には, 上記の規則は本仕様のみに準拠する UA に対して 2 つの交換を規定します — オファーは INVITE 内に, アンサーは 2xx 内に (場合によっては 1xx 内にも同じ値で) あります. あるいは, オファーは 2xx 内に, アンサーは ACK 内にあります. INVITE をサポートするすべてのユーザエージェントは, これら 2 つの交換をサポートしなければなりません (MUST).

セッション記述プロトコル (SDP, RFC 2327 [1]) は, セッションを記述する手段としてすべてのユーザエージェントによってサポートされなければならず (MUST), オファーとアンサーを構築するためのその使用法は [13] で定義された手順に従わなければなりません (MUST).

上述のオファー/アンサーモデルの制限は, Content-Disposition ヘッダフィールドの値が "session" である本文にのみ適用されます. したがって, INVITE と ACK の両方に本文メッセージが含まれる可能性があります (たとえば, INVITE は写真 (Content-Disposition: render) を, ACK はセッション記述 (Content-Disposition: session) を運びます).

Content-Disposition ヘッダフィールドが欠落している場合, Content-Type application/sdp の本文は配置 "session" を意味し, その他の Content-Type は "render" を意味します.

INVITE が作成されると, UAC はダイアログ外で要求を送信するために定義された手順 (セクション 8) に従います. これにより, 最終的に要求を送信し, 応答を UAC に配信するクライアントトランザクションが構築されます.

13.2.2 INVITE 応答の処理 (Processing INVITE Responses)

INVITE が INVITE クライアントトランザクションに渡されると, UAC は INVITE の応答を待ちます. INVITE クライアントトランザクションが応答ではなくタイムアウトを返した場合, TU はセクション 8.1.3 で説明されているように, 408 (Request Timeout) 応答を受信したかのように動作します.

13.2.2.1 1xx 応答 (1xx Responses)

1 つ以上の最終応答が受信される前に, ゼロ, 1, または複数の一時応答が到着することがあります. INVITE 要求に対する一時応答は「早期ダイアログ (early dialog)」を作成できます. 一時応答の To フィールドにタグがあり, かつその応答のダイアログ ID が既存のダイアログと一致しない場合, セクション 12.1.2 で定義された手順を使用して構築されます.

初期 INVITE トランザクションが完了する前に, UAC がダイアログ内のピアに要求を送信する必要がある場合にのみ, 早期ダイアログは必要になります. 一時応答内のヘッダフィールドは, ダイアログが早期状態にある間は適用可能です (たとえば, 一時応答内の Allow ヘッダフィールドには, ダイアログが早期状態にある間にダイアログ内で使用できるメソッドが含まれます).

13.2.2.2 3xx 応答 (3xx Responses)

3xx 応答には, 被呼者が到達可能な可能性のある新しいアドレスを提供する 1 つ以上の Contact ヘッダフィールド値が含まれることがあります. 3xx 応答のステータスコード (セクション 21.3 参照) に応じて, UAC はそれらの新しいアドレスを試行することを選択してもよい (MAY) です.

13.2.2.3 4xx, 5xx, 6xx 応答 (4xx, 5xx and 6xx Responses)

INVITE に対して単一の非 2xx 最終応答が受信されることがあります. 4xx, 5xx, 6xx 応答には, エラーに関する追加情報が見つかる場所を示す Contact ヘッダフィールド値が含まれることがあります. 後続の最終応答 (エラー条件下でのみ到着する) は無視されなければなりません (MUST).

非 2xx 最終応答を受信すると, すべての早期ダイアログは終了したとみなされます.

非 2xx 最終応答を受信した後, UAC コアは INVITE トランザクションが完了したとみなします. INVITE クライアントトランザクションは, 応答に対する ACK の生成を処理します (セクション 17 参照).

13.2.2.4 2xx 応答 (2xx Responses)

フォークプロキシのために, 単一の INVITE 要求に対して複数の 2xx 応答が UAC に到着することがあります. 各応答は To ヘッダフィールド内の tag パラメータによって区別され, それぞれが異なるダイアログ識別子を持つ異なるダイアログを表します.

2xx 応答内のダイアログ識別子が既存のダイアログのダイアログ識別子と一致する場合, そのダイアログは「確認済み (confirmed)」状態に遷移しなければならず (MUST), ダイアログの route set はセクション 12.2.1.2 の手順を使用して 2xx 応答に基づいて再計算されなければなりません (MUST). それ以外の場合は, セクション 12.1.2 の手順を使用して「確認済み」状態の新しいダイアログを構築しなければなりません (MUST).

  再計算される状態の唯一の要素は route set であることに注意してください. ダイアログ内で送信された最高シーケンス番号 (リモートおよびローカル) などのその他の状態は再計算されません. route set だけが後方互換性のために再計算されます. RFC 2543 は 1xx での Record-Route ヘッダフィールドのミラーリングを義務付けていませんでした (2xx のみ). ただし, 初期ダイアログ内で (シーケンス番号を変更するなどして) ダイアログ途中の要求が送信されている可能性があるため, ダイアログの状態全体を更新することはできません.

UAC コアは, トランザクション層から受信した各 2xx に対して ACK 要求を生成しなければならなければなりません (MUST). ACK のヘッダフィールドは, CSeq および認証に関連するヘッダフィールドを除き, ダイアログ内で送信される任意の要求と同じ方法で構築されます (セクション 12 参照). CSeq ヘッダフィールドのシーケンス番号は, 確認される INVITE と同じでなければならない (MUST) が, CSeq メソッドは ACK でなければなりません (MUST). ACK は INVITE と同じ資格情報を含まなければなります (MUST). 2xx にオファーが含まれている場合 (上記の規則に基づき), ACK はその本文にアンサーを含まなければなりません (MUST). 2xx 応答内のオファーが受け入れられない場合, UAC コアは ACK 内に有効なアンサーを生成しなければならず (MUST), その後直ちに BYE を送信しなければなりません (MUST).

ACK が構築されると, [4] の手順を使用して宛先アドレス, ポート, トランスポートを決定します. ただし, 要求はクライアントトランザクションではなく, 転送のためにトランスポート層に直接渡されます. これは, ACK の再送信を処理するのがトランザクション層ではなく UAC コアであるためです. ACK は, それを引き起こした 2xx 最終応答の再送信が到着するたびに, クライアントトランスポートに渡されなければなりません (MUST).

UAC コアは, 最初の 2xx 応答を受信してから 64*T1 秒後に INVITE トランザクションが完了したとみなします. この時点で, 確立されたダイアログに遷移していないすべての早期ダイアログは終了します. 一度 UAC コアが INVITE トランザクションを完了したとみなすと, それ以上新しい 2xx 応答は到着しないと予想されます.

INVITE の 2xx 応答を確認した後, UAC がそのダイアログを続行したくない場合, UAC はセクション 15 で説明されているように BYE 要求を送信してダイアログを終了しなければなります (MUST).

13.3 UAS 処理 (UAS Processing)

13.3.1 INVITE の処理 (Processing of the INVITE)

UAS コアはトランザクション層から INVITE 要求を受信します. まず, セクション 8.2 の要求処理手順を実行します. これはダイアログ内およびダイアログ外の両方の要求に適用されます.

これらの処理状態が応答を生成せずに完了したと仮定して, UAS コアは追加の処理ステップを実行します.

  1. 要求が Expires ヘッダフィールドを含む INVITE である場合, UAS コアはヘッダフィールド値で示された秒数のタイマーを設定します. タイマーが発火すると, 招待は期限切れとみなされます. UAS が最終応答を生成する前に招待が期限切れになった場合, 487 (Request Terminated) 応答を生成すべきです (SHOULD).

  2. 要求が mid-dialog 要求である場合, セクション 12.2.2 で説明されたメソッドに依存しない処理が最初に適用されます. これはまたセッションを変更する可能性があります. 詳細はセクション 14 を参照してください.

  3. 要求の To ヘッダフィールドにタグがあるが, ダイアログ識別子が既存のダイアログのいずれとも一致しない場合, UAS はクラッシュして再起動したか, 異なる (おそらく失敗した) UAS への要求を受信した可能性があります. セクション 12.2.2 は, そのような状況下で堅牢な動作を達成するためのガイドラインを提供します.

ここから先の処理は, INVITE がダイアログ外であり, したがって新しいセッションを確立するためのものであることを前提とします.

INVITE はセッション記述を含む場合があり, その場合 UAS にはそのセッションのオファーが提示されます. ユーザがすでにそのセッションの参加者である可能性があります. たとえ INVITE がダイアログ外であっても同様です. これは, ユーザが複数の他の参加者によって同じマルチキャスト会議に招待された場合に発生する可能性があります. 必要に応じて, UAS はセッション記述内の識別子を使用してこの重複を検出してもよい (MAY) です. たとえば SDP は origin (o) フィールドにセッション ID とバージョン番号を含みます. ユーザがすでにセッションのメンバーであり, セッション記述に含まれるセッションパラメータが変更されていない場合, UAS は INVITE を黙って受諾してもよい (MAY) です (つまり, ユーザにプロンプトを表示せずに 2xx 応答を送信する).

INVITE にセッション記述が含まれていない場合, UAS はセッションに参加するよう求められており, UAC は UAS にセッションのオファーを提供するよう求めています. UAS は, UAC に戻る最初の非失敗の信頼できるメッセージでオファーを提供しなければなります (MUST). 本仕様では, それは INVITE に対する 2xx 応答です.

UAS は, 招待の進捗を示す, 受諾する, リダイレクトする, または拒否することができます. これらすべての場合において, セクション 8.2.6 で説明された手順を使用して応答を作成します.

13.3.1.1 進捗 (Progress)

UAS が招待に即座に応答できない場合, UAC に何らかの進捗を示すことを選択できます (たとえば, 電話が鳴っているという表示). これは 101 から 199 の間の一時応答で実現されます. これらの一時応答は早期ダイアログを確立するため, セクション 8.2.6 の手順に加えてセクション 12.1.1 の手順に従います. UAS は好きなだけ多くの一時応答を送信してもよい (MAY) です. それらはそれぞれ同じダイアログ ID を示さなければなりません (MUST). ただし, これらは信頼できる方法で配信されません.

UAS が INVITE に応答するために長期間を必要とする場合, プロキシがトランザクションをキャンセルするのを防ぐために「延長」を要求する必要があります. プロキシは, トランザクション内の応答間に 3 分の間隙がある場合, トランザクションをキャンセルするオプションがあります. キャンセルを防ぐために, UAS は失われた一時応答の可能性に対処するため, 毎分非 100 の一時応答を送信しなければなります (MUST).

  INVITE トランザクションは, ユーザが保留に置かれた場合や, 通話に応答せずに通信を行うことを許可する PSTN システムと相互接続する場合, 長時間継続することがあります. 後者はインタラクティブ音声応答 (IVR) システムで一般的です.

13.3.1.2 INVITE のリダイレクト (The INVITE is Redirected)

UAS が呼をリダイレクトすることを決定した場合, 3xx 応答が送信されます. 300 (Multiple Choices), 301 (Moved Permanently), または 302 (Moved Temporarily) 応答には, 試行される 1 つ以上の新しいアドレスの URI を含む Contact ヘッダフィールドが含まれるべきです (SHOULD). 応答は INVITE サーバトランザクションに渡され, その再送信を処理します.

13.3.1.3 INVITE の拒否 (The INVITE is Rejected)

被呼者が現在, この端末システムで追加の呼を受け取る意思または能力がない場合に, 一般的なシナリオが発生します. そのようなシナリオでは, 486 (Busy Here) を返すべきです (SHOULD). UAS が他の端末システムがこの呼を受け入れられないことを知っている場合は, 代わりに 600 (Busy Everywhere) 応答を送信すべきです (SHOULD). ただし, UAS が一般にこれを知ることができる可能性は低く, したがってこの応答は通常は使用されません. 応答は INVITE サーバトランザクションに渡され, その再送信を処理します.

INVITE に含まれるオファーを拒否する UAS は, 488 (Not Acceptable Here) 応答を返すべきです (SHOULD). そのような応答には, オファーが拒否された理由を説明する Warning ヘッダフィールド値を含めるべきです (SHOULD).

13.3.1.4 INVITE の受諾 (The INVITE is Accepted)

UAS コアは 2xx 応答を生成します. この応答はダイアログを確立するため, セクション 8.2.6 の手順に加えてセクション 12.1.1 の手順に従います.

INVITE に対する 2xx 応答には, Allow ヘッダフィールドと Supported ヘッダフィールドが含まれるべきであり (SHOULD), Accept ヘッダフィールドが含まれてもよい (MAY) です. これらのヘッダフィールドを含めることで, UAC はプローブを行わずに, コールの期間中に UAS がサポートする機能と拡張を決定できます.

INVITE 要求にオファーが含まれており, UAS がまだアンサーを送信していない場合, 2xx にはアンサーが含まれなければなりません (MUST). INVITE にオファーが含まれておらず, UAS がまだオファーを送信していない場合, 2xx にはオファーが含まれなければなりません (MUST).

応答が構築されると, それは INVITE サーバトランザクションに渡されます. ただし, INVITE サーバトランザクションは, この最終応答を受信してトランスポートに渡すと直ちに破棄されることに注意してください. したがって, ACK が到着するまで, 応答をトランスポートに定期的に直接渡す必要があります. 2xx 応答は, T1 秒で開始し, 再送信ごとに 2 倍になり, T2 秒に達するまで (T1 および T2 はセクション 17 で定義) の間隔でトランスポートに渡されます. 応答の再送信は, その応答に対する ACK 要求が受信されると停止します. これは, 応答の送信に使用されるいかなるトランスポートプロトコルとも無関係です.

  2xx はエンドツーエンドで再送信されるため, UAS と UAC の間に UDP のホップが存在する可能性があります. これらのホップを介した信頼できる配信を確保するために, UAS でのトランスポートが信頼できるものであっても, 応答は定期的に再送信されます.

サーバが ACK を受信せずに 2xx 応答を 64*T1 秒間再送信した場合, ダイアログは確認されますが, セッションは終了されるべきです (SHOULD). これはセクション 15 で説明されているように BYE によって行われます.