14. 既存のセッションの変更 (Modifying an Existing Session)
14 既存のセッションの変更 (Modifying an Existing Session)
成功した INVITE 要求 (セクション 13 参照) は, 2 つのユーザエージェント間のダイアログと, オファー/アンサーモデルを使用したセッションの両方を確立します. セクション 12 は, ターゲットリフレッシュ要求 (たとえば, ダイアログのリモートターゲット URI の変更) を使用して既存のダイアログを変更する方法を説明します. このセクションでは, 実際のセッションを変更する方法について説明します. この変更には, アドレスやポートの変更, メディアストリームの追加, メディアストリームの削除などが含まれる場合があります. これは, セッションを確立した同じダイアログ内で新しい INVITE 要求を送信することによって実現されます. 既存のダイアログ内で送信される INVITE 要求は, 再 INVITE (re-INVITE) と呼ばれます.
単一の再 INVITE で, ダイアログとセッションパラメータを同時に変更できることに注意してください.
発信者または着信者のいずれもが既存のセッションを変更できます.
メディア障害を検出した際の UA の動作はローカルポリシーの問題です. ただし, 輻輳時にトラフィックでネットワークをあふれさせないように, 再 INVITE や BYE の自動生成は推奨されません (NOT RECOMMENDED). いずれにせよ, これらのメッセージが自動的に送信される場合は, 何らかのランダムな間隔の後に送信されるべきです (SHOULD).
上記の段落は, 自動生成された BYE と再 INVITE に関するものであることに注意してください. ユーザがメディア障害時に電話を切った場合, UA は通常通り BYE 要求を送信します.
14.1 UAC の動作 (UAC Behavior)
INVITE 内のセッション記述に適用されるのと同じオファー/アンサーモデル (セクション 13.2.1) が, 再 INVITE にも適用されます. その結果, たとえばメディアストリームを追加したい UAC は, そのメディアストリームを含む新しいオファーを作成し, INVITE 要求でピアに送信します. 送信されるのは, 変更だけでなくセッションの完全な記述であることが重要です. これは, さまざまな要素でのステートレスなセッション処理をサポートし, フェイルオーバーおよび復旧機能をサポートします. もちろん, UAC はセッション記述なしの再 INVITE を送信してもよく (MAY) ます. その場合, 再 INVITE に対する最初の信頼できる非失敗応答にオファーが含まれます (本仕様では, それは 2xx 応答です).
セッション記述フォーマットにバージョン番号の機能がある場合, オファー側はセッション記述のバージョンが変更されたことを示すべきです (SHOULD).
再 INVITE の To, From, Call-ID, CSeq, Request-URI は, セクション 12 で説明されている既存のダイアログ内の通常の要求と同じ規則に従って設定されます.
UAC は, Alert-Info ヘッダフィールドや Content-Disposition が "alert" である本文を再 INVITE に追加しないことを選択してもよい (MAY) です. なぜなら, UAS は通常, 再 INVITE の受信時にユーザに警告しないためです.
フォークする可能性のある INVITE と異なり, 再 INVITE がフォークすることはなく, したがって常に単一の最終応答のみを生成します. 再 INVITE がフォークしない理由は, Request-URI がユーザの address-of-record ではなく, そのダイアログを確立した UA インスタンスをターゲットとして識別するためです.
UAC は, 別の INVITE トランザクションがいずれかの方向で進行中に, ダイアログ内で新しい INVITE トランザクションを開始してはならない (MUST NOT) ことに注意してください.
1. 進行中の INVITE クライアントトランザクションがある場合, TU は新しい INVITE を開始する前に, トランザクションが完了または終了状態に達するまで待たなければなりません (MUST).
2. 進行中の INVITE サーバトランザクションがある場合, TU は新しい INVITE を開始する前に, トランザクションが確認または終了状態に達するまで待たなければなりません (MUST).
ただし, UA は INVITE トランザクションの進行中に通常のトランザクションを開始してもよく (MAY), INVITE トランザクションを通常のトランザクションの進行中に開始してもよい (MAY) です.
UA が再 INVITE に対する非 2xx 最終応答を受信した場合, セッションパラメータは, 再 INVITE が発行されなかったかのように変更されないままでなければなりません (MUST). セクション 12.2.1.2 で述べたように, 非 2xx 最終応答が 481 (Call/Transaction Does Not Exist) または 408 (Request Timeout) である場合, あるいは再 INVITE に対する応答がまったく受信されない場合 (つまり, INVITE クライアントトランザクションによってタイムアウトが返される場合), UAC はダイアログを終了することに注意してください.
再 INVITE に対する 491 応答を UAC が受信した場合, 次のように選択された値 T のタイマーを開始すべきです (SHOULD).
1. UAC がダイアログ ID の Call-ID の所有者 (つまり値を生成した) である場合, T は 10 ms 単位で 2.1 秒から 4 秒の間のランダムに選択された値を持ちます.
2. UAC がダイアログ ID の Call-ID の所有者でない場合, T は 10 ms 単位で 0 から 2 秒の間のランダムに選択された値を持ちます.
タイマーが発火したとき, そのセッション変更を実行したい場合, UAC は再 INVITE をもう一度試行すべきです (SHOULD). たとえば, 通話がすでに BYE で切断されていた場合, 再 INVITE は実行されません.
再 INVITE を送信し, 再 INVITE に対する 2xx 応答用の ACK を生成する規則は, 初期 INVITE の場合 (セクション 13.2.1) と同じです.
14.2 UAS の動作 (UAS Behavior)
セクション 13.3.1 は, 着信する再 INVITE と着信する初期 INVITE を区別し, 既存のダイアログの再 INVITE を処理する手順を説明します.
同じダイアログで, より低い CSeq シーケンス番号を持つ最初の INVITE に対する最終応答を送信する前に 2 番目の INVITE を受信した UAS は, 2 番目の INVITE に対して 500 (Server Internal Error) 応答を返さなければならず (MUST), 0 から 10 秒の間でランダムに選択された値を持つ Retry-After ヘッダフィールドを含まなければなりません (MUST).
あるダイアログ上でそれが送信した INVITE が進行中に, そのダイアログ上で INVITE を受信した UAS は, 受信した INVITE に対して 491 (Request Pending) 応答を返さなければなりません (MUST).
UA が既存のダイアログの再 INVITE を受信した場合, セッション記述内のバージョン識別子を確認しなければならず (MUST), バージョン識別子がない場合は, セッション記述の内容を確認して, それが変更されたかどうかを確認しなければなりません (MUST). セッション記述が変更された場合, UAS はそれに応じてセッションパラメータを調整しなければならず (MUST), 必要に応じてユーザに確認を求めた後である場合があります.
セッション記述のバージョン管理は, 会議への新規参加者の機能への対応, メディアの追加または削除, またはユニキャスト会議からマルチキャスト会議への変更に利用できます.
新しいセッション記述が受け入れられない場合, UAS は再 INVITE に対して 488 (Not Acceptable Here) 応答を返すことでそれを拒否できます. この応答には Warning ヘッダフィールドを含めるべきです (SHOULD).
UAS が 2xx 応答を生成し, ACK をまったく受信しなかった場合, ダイアログを終了するために BYE を生成すべきです (SHOULD).
UAS は, 再 INVITE に対する 180 (Ringing) 応答を生成しないことを選択してもよい (MAY) です. なぜなら UAC は通常この情報をユーザに表示しないためです. 同じ理由で, UAS は再 INVITE に対する応答で Alert-Info ヘッダフィールドや Content-Disposition が "alert" である本文を使用しないことを選択してもよい (MAY) です.
2xx 内でオファーを提供する UAS (INVITE にオファーが含まれていなかったため) は, UAS がまったく新しい通話を行っているかのように, かつ [13] で SDP の場合に説明されている既存のセッションを更新するオファーを送信する制約に従い, オファーを構築すべきです (SHOULD). 具体的には, これは UA がサポートしようとする可能な限り多くのメディアフォーマットとメディアタイプを含めるべき (SHOULD) であることを意味します. UAS は, セッション記述が, ピアのサポートを必要とするメディアフォーマット, トランスポート, またはその他のパラメータにおいて, 以前のセッション記述と重複することを確保しなければなりません (MUST). これは, ピアがセッション記述を拒否する必要がないようにするためです. ただし, UAC がそれを受け入れられない場合, UAC は有効なセッション記述を持つアンサーを生成し, その後 BYE を送信してセッションを終了すべきです (SHOULD).