Network Working Group J. Rosenberg Request for Comments: 3311 dynamicsoft Category: Standards Track September 2002 セッション開始プロトコル（SIP）のUPDATEメソッド The Session Initiation Protocol (SIP) UPDATE Method 本文書の位置付け 本文書はインターネットコミュニティに対してInternet standards trackプ ロトコルの仕様を定めるものであり、改善のための議論と提案を求めるもの である。標準化の状況と本プロトコルのステータスについては、「Internet Official Protocol Standards (STD 1)」の最新版を参照のこと。本文書の配 布に制限はない。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本仕様ではセッション開始プロトコル(SIP)のための新しいUPDATEメソッドを 定義する。UPDATEは、クライアントがセッションのパラメータ（例えば、メ ディアストリームのセットとそれらのCODEC）を更新することを可能にするが、 ダイアログのステートには影響を与えない。その意味ではre-INVITEに似てい るが、re-INVITEとは違い、最初のINVITEが完了する前に送信することができ る。このことが、earlyダイアログ内でセッションパラメータを更新するため に、UPDATEを非常に有用なものとしている。 Rosenberg Standards Track [Page 1] RFC 3311 SIP UPDATE Method September 2002 目次 1 はじめに .................................................. 2 2 用語 ...................................................... 3 3 操作概要 .................................................. 3 4 本拡張に対するサポートの確定 .............................. 3 5 UPDATEのハンドリング ...................................... 4 5.1 UPDATEの送信 .............................................. 4 5.2 UPDATEの受信 .............................................. 5 5.3 UPDATE応答の処理 .......................................... 6 6 プロキシの動作 ............................................ 7 7 UPDATEメソッドの定義 ...................................... 7 8 コールフロー例 ............................................ 7 9 セキュリティの考慮 ........................................ 11 10 IANA条項 .................................................. 11 11 知的所有権に関する注記 .................................... 11 12 規範となる参考文献 ........................................ 11 13 謝辞 ...................................................... 12 14 著者の連絡先 .............................................. 12 15 完全な著作権表記 .......................................... 13 1 はじめに セッション開始プロトコル（SIP）（参考文献[1]）は、セッションの開始と 変更のためにINVITEを定義している。しかしながら、このメソッドは実質的 に、ステートの重要な2つの部分に影響を与える。それは、セッション（SIP がセットアップするメディアストリーム）およびダイアログ（SIP自身が定義 するステート）に影響する。多くの場合これは理にかなっているが、このカ ップリングが問題を引き起こす、重要なシナリオが存在する。 主要な問題は、最初のINVITEが返答される前にセッションのアスペクトが変 更される必要があるときである。このシチュエーションの例は「earlyメディ ア」（INVITE自体が受け入れられる前に、呼のプログレスを伝えるため、セ ッションが確立される状態）である。呼が返答される前に、発呼側または着 呼側がそのセッションの特性（characteristics）の変更（例えば、earlyメ ディアを保留する）が可能であることが重要である。しかしながら、re-INVITE はセッションに加えてダイアログのステートにも影響するため、re-INVITEは このためには使用できない。 その結果として、発呼側または着呼側が、最初のINVITEリクエストに対する 応答が生成される前に、更新されたセッション情報を提供することを可能に するソリューションが必要とされる。ここで定義されるUPDATEメソッドがこ の需要を満たす。それは、ダイアログのステート自身には影響せずに、セッ ションパラメータを更新するために、ダイアログ内（earlyまたはconfirmed） でUAが送信できる。 Rosenberg Standards Track [Page 2] RFC 3311 SIP UPDATE Method September 2002 2 用語 本文書では、次のキーワードはBCP14、RFC2119(参考文献[2])に記述されてい るとおりに解釈され、SIPに準拠した実装のための要求レベルを示す。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、 「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 3 操作概要 本拡張の操作は単純明快である。発呼側はまず、通常どおりに進行するINVITE トランザクションを開始する。一旦ダイアログ（earlyまたはconfirmed）が 確立されると、発呼側は、セッションを更新するためのSDPオファー（参考文 献[3]）を含むUPDATEメソッドを生成できる。UPDATEメソッドに対する応答は アンサーを含む。同様に、一旦ダイアログが確立されると、着呼側はオファー を含むUPDATEを送信でき、発呼側はそのUPDATEに対する2xx中にアンサーを置 く。UPDATEメソッドのサポートを示すために、Allowヘッダーフィールドが使 用される。UPDATEがいつ使用できるかに関して、オファー/アンサーモデルの 制限に基づく、別の制限がある。 4 本拡張に対するサポートの確定 セッションの開始は、RFC3261（参考文献[1]）に規定されているように行う。 しかしながら、本仕様に準拠するUACは、UPDATEリクエストの受信能力を示す ために、INVITEリクエストに、メソッドUPDATEをリストするAllowヘッダーフ ィールドも含めるべきである[SHOULD]。 本仕様に準拠するUASが新規ダイアログのためのINVITEリクエストを受信し、 SDPを含む信頼性のある暫定応答を生成するとき、その応答はUPDATEメソッド をリストするAllowヘッダーフィールドをふくむべきである[SHOULD]。これは 発呼側に、着呼側がいつでもUPDATEリクエストを受信できることを知らせる。 信頼性の無い暫定応答はUPDATEメソッドをリストするAllowヘッダーフィール ドを含んでもよく[MAY]、2xx応答はUPDATEメソッドをリストするAllowヘッダ ーフィールドを含むべきである[SHOULD]。 応答は通常どおりRFC3261（参考文献[1]）のように処理され、信頼性のある 暫定応答の場合は参考文献[4]に従う。信頼性のある暫定応答はUACにおいて 常にearlyダイアログを生成する、ということに注意することが重要である。 このダイアログの生成は着呼側からUPDATEリクエストを受信するために必須 である。 応答が値「UPDATE」を含むAllowヘッダーフィールドを含む場合、UACは、着 呼側がUPDATEをサポートするので、UACがセクション5.1の手順に従うことが 可能なことを知る。 Rosenberg Standards Track [Page 3] RFC 3311 SIP UPDATE Method September 2002 5 UPDATEのハンドリング 5.1 UPDATEの送信 UPDATEリクエストは、既存ダイアログ内の他のいかなるリクエストとも同じ ように、RFC3261のセクション12.2.1に述べられているように構築される。そ れはearlyおよびconfirmedダイアログの双方に対して送信してもよく[MAY]、 発呼側または着呼側のいずれから送信してもよい[MAY]。UPDATEはconfirmed ダイアログ上で使用できるが、代わりにre-INVITEの使用が推奨される[RECOMMENDED]。 これは、UPDATEが、ユーザーの同意（user approval）の可能性を考慮せず、 直ちに返答される必要があるためである。そのような同意（approval）は頻 繁に必要とされ、re-INVITEで可能である。 UACは、表1および2で定義されている、オプションのヘッダーをUPDATEに追加 してよい[MAY]。 UPDATEはターゲットリフレッシュリクエストである。RFC3261（参考文献[1]） で規定されているように、これは、それがダイアログのリモートターゲット を更新できることを意味する。UAが、INVITEトランザクション進行中に、リ モートターゲットを修正するためにUPDATEリクエストまたは応答を使用し、 そのUAがそのINVITEトランザクションにおいてUASである場合、それは、それ がUPDATEリクエストまたは応答に置いたのと同じ値を、INVITEに対する2xxの Contactヘッダーフィールドに置かなければならない[MUST]。 RFC3261のセクション13.2.1で定義されている、SIPメッセージにオファーと アンサーを含めるためのルールを依然として適用する。これらのルールは、 セッションステートの一貫したビューを保証するために存在する。これは発 呼側にとって以下のことを意味する。 o 最初のINVITEトランザクションの完了前にUPDATEが送信されようとし ており、最初のINVITEがオファーを含んでいた場合、着呼側が信頼性 のある暫定応答中でアンサーを生成しており、かつ、発呼側がPRACKま たはUPDATEで送信した他のすべてのオファーに対するアンサーを受信 しており、かつ、着呼側からのUPDATE中で受信したすべてのオファー に対するアンサーを生成していれば、そのUPDATEはオファーを含むこ とができる。 o 最初のINVITEトランザクションの完了前にUPDATEが送信されようとし ており、最初のINVITEがオファーを含んでいなかった場合、着呼側が 信頼性のある暫定応答中でオファーを生成しており、かつ、UACがそれ に対応するPRACK中でアンサーを生成していれば、そのUPDATEはオファ ーを含むことができる。当然ながら、それがPRACKまたはUPDATEで送信 した他のすべてのオファーに対するアンサーを受信していないか、あ るいは、着呼側からのUPDATEで受信した他のすべてのオファーに対し てアンサーを生成していない場合、それはUPDATEを送信できない。 Rosenberg Standards Track [Page 4] RFC 3311 SIP UPDATE Method September 2002 o 最初のINVITEトランザクションの完了後にUPDATEが送信されようとし ている場合、発呼側がre-INVITEまたはUPDATEでオファーを生成または 受信し、それがまだアンサーされていないなら、それはオファーを含 むことができない。 着呼側にとっては以下のことを意味する。 o INVITEトランザクションの完了前にUPDATEが送信されようとしており、 最初のINVITEがオファーを含んでいた場合、着呼側が信頼性のある暫 定応答中でアンサーを生成し、その信頼性のある暫定応答に対して PRACKを受信し、まだアンサーしていないオファーを含むいかなるリク エスト（PRACKまたはUPDATE）も受信しておらず、かつ、まだアンサー されていないオファーを含むいかなるUPDATEリクエストも送信してい ない、のでなければ、そのUPDATEはオファーとともに送信できない。 o INVITEトランザクションの完了前にUPDATEが送信されようとしており、 最初のINVITEがオファーを含んでいなかった場合、着呼側が信頼性の ある暫定応答中でオファーを送信し、PRACKでアンサーを受信し、かつ、 まだアンサーしていないオファーを含むいかなるUPDATEリクエストも 受信しておらず、かつ、まだアンサーされていないオファーを含むい かなるUPDATEリクエストも送信していない、のでなければ、その UPDATEはオファーとともに送信できない。 o 最初のINVITEトランザクションの完了後にUPDATEが送信されようとし ている場合、着呼側がre-INVITEまたはUPDATEでオファーを生成または 受信し、それがまだアンサーされていないなら、それはオファーとと もに送信できない。 5.2 UPDATEの受信 UPDATEは、他のいかなるダイアログ内（mid-dialog）ターゲットリフレッシュ リクエストとも同じように、RFC3261（参考文献[1]）のセクション12.2.2で 述べられているように、処理される。このリクエストが概ね受け入れ可能で あれば、以下に記述されているように処理は継続する。この処理はRFC3261 （参考文献[1]）のセクション14.2の処理とほぼ同じであるが、UPDATEの場合 のために一般化されている。 前回のUPDATEに対する最終応答を生成する前に、同一ダイアログ上でUPDATE を受信するUASは、新しいUPDATEに対して500応答を返さなければならず[MUST]、 0から10秒のあいだでランダムに選択した値を持つRetry-Afterヘッダーフィー ルドを含めなければならない[MUST]。 オファーを含むUPDATEを受信し、かつ、まだアンサーを受信していないオフ ァーを（UPDATE、PRACK、またはINVITE中で）UASが生成していた場合、UASは そのUPDATEを491応答で拒否しなければならない[MUST]。同様に、オファーを 含むUPDATEを受信し、かつ、まだアンサーを生成していないオファーを （UPDATE、PRACK、またはINVITE中で）UASが受信していた場合、UASはその UPDATEを500応答で拒否しなければならず[MUST]、0から10秒のあいだでラン Rosenberg Standards Track [Page 5] RFC 3311 SIP UPDATE Method September 2002 ダムに選択した値を持つRetry-Afterヘッダーフィールドを含めなければなら ない[MUST]。 UAが既存のダイアログに対するUPDATEを受け取る場合、セッション記述中の バージョン識別子または(バージョン識別子がない場合は)セッション記述の コンテンツを、それが変更されていないかどうか確認するために、チェック しなければならない[MUST]。セッション記述が変更されていた場合、UASは、 セッションパラメータをしかるべく調整して2xx応答でアンサーを生成しなけ ればならない[MUST]。しかしながら、re-INVITEとは違い、UPDATEは迅速に応 答されなければならず[MUST]、それゆえ、一般的に、ユーザーはセッション の変更に同意することを促されることはない。UASが、ユーザーに促すことな しにセッションパラメータを変更できない場合、それは504応答でそのリクエ ストを拒否するべきである[SHOULD]。新しいセッション記述が受け入れられ ない場合、UASはUPDATEに対して488(Not Acceptable Here)応答を返すことで それを拒否できる。この応答はWarningヘッダーフィールドを含むべきである [SHOULD]。 5.3 UPDATE応答の処理 UACでのUPDATE応答の処理は、RFC3261（参考文献[1]）のセクション12.2.1.2 にあるターゲットリフレッシュリクエストのためのルールに従う。その処理 が完了すると、以下に規定されているように処理を継続する。この処理は RFC3261（参考文献[1]）のセクション14.1の処理とほぼ同じであるが、UPDATE の場合のために一般化されている。 UAがUPDATEに対する非2xx最終応答を受け取る場合、あたかもUPDATEが発行さ れなかったかのように、セッションパラメータは変更されずにそのままでな ければならない[MUST]。RFC3261（参考文献[1]）のセクション12.2.1で述べ られているように、非2xx応答が、481(Call/Transaction Does Not Exist)、 408(Request Timeout)、またはUPDATEに対する応答が何もない(すなわち、 UPDATEクライアントトランザクションによってタイムアウトが返された)場合、 UACはダイアログを終了するということに注意すること。 UACがUPDATEに対する491応答を受け取る場合、UACは以下のようにして選ばれ たタイマーTを開始するべきである[SHOULD]。 1. UACがそのダイアログIDのCall-IDの所有者である場合(つまり、その UACがその値を生成した場合)、Tは2.1秒から4秒のあいだで10ミリ秒単 位でランダムに選択された値を持つ。 2. UACがそのダイアログIDのCall-IDの所有者でない場合、Tは0秒から2秒 のあいだで10ミリ秒単位でランダムに選択された値を持つ。 タイマーが切れるとき、そのセッション修正を行うことをまだ望むなら、UAC はUPDATEをもう一度試みるべきである[SHOULD]。たとえば、呼がBYEで既に切 断されていた場合、UPDATEは行われないだろう。 Rosenberg Standards Track [Page 6] RFC 3311 SIP UPDATE Method September 2002 6 プロキシの動作 UPDATEリクエストのプロキシでの処理は、他のすべての非INVITEリクエスト と同じである。 7 UPDATEメソッドの定義 UPDATEメソッドのセマンティクスは上に詳述されている。本拡張は、RFC3261 に記述されているMethod BNFに別の値を追加する。 UPDATEm = %x55.50.44.41.54.45 ; UPDATE in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / UPDATEm / extension-method 表1はUPDATEメソッドのために、RFC3261の表2を拡張するものである。 表2はUPDATEメソッドのために、RFC3261の表3を拡張するものである。 8 コールフロー例 このセクションは、UPDATEメソッドを使用したコールフローの例を提示する。 コールフローは図1に示されている。発呼側がオファーを含む最初のINVITE（1） を送信する。着呼側はそのオファーに対するアンサーを持つ180応答（2）を 生成する。オファー/アンサー交換が完了するとセッションが確立されるが、 ダイアログはまだearlyステートである。発呼側は180を承認（acknowledge） するためにPRACK（3）を生成し、そのPRACKは200 OK（4）で応答される。発 呼側はセッションの一部のアスペクトを更新することにする（例えば、保留 する）。そこで、新しいオファーを持つUPDATEリクエスト（5）を生成する。 このオファーは、そのUPDATEに対する200応答（6）でアンサーされる。その すぐ後に、着呼側がセッションの一部のアスペクトを更新しようとし、オフ ァーを持つUPDATEリクエスト（7）を生成する。それから200応答（8）でアン サーが送信される。最後に、着呼側が呼び出しに答え、その結果としてINVITE に対する200 OK応答（9）、およびそれに次ぐACK（10）がもたらされる。 INVITEに対する200 OKもACKも、SDPを含まない。 Rosenberg Standards Track [Page 7] RFC 3311 SIP UPDATE Method September 2002 Header field where proxy UPDATE ____________________________________________ Accept R o Accept 2xx o Accept 415 c Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 c Alert-Info - Allow R o Allow 2xx o Allow r o Allow 405 m Allow-Events (1) - Authentication-Info 2xx o Authorization R o Call-ID c r m Call-Info ar o Contact R m Contact 1xx o Contact 2xx m Contact 3xx d o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length ar t Content-Type * CSeq c r m Date a o Error-Info 300-699 a o Event (1) - Expires - From c r m In-Reply-To - Max-Forwards R amr m Min-Expires - MIME-Version o Organization ar o 表1: ヘッダーフィールドのまとめ(A〜O)。(1)は参考文献[5]で定義。 Rosenberg Standards Track [Page 8] RFC 3311 SIP UPDATE Method September 2002 Header field where proxy UPDATE ____________________________________________________ Priority - Proxy-Authenticate 407 ar m Proxy-Authenticate 401 ar o Proxy-Authorization R dr o Proxy-Require R ar o RAck R - Record-Route R ar o Record-Route 2xx,18x mr o Reply-To - Require ar c Retry-After 404,413,480,486 o 500,503 o 600,603 o Route R adr c RSeq - - Server r o Subject - - Subscription-State (1) - Supported R o Supported 2xx o Timestamp o To c r m Unsupported 420 m User-Agent o Via R amr m Via rc dr m Warning r o WWW-Authenticate 401 ar m WWW-Authenticate 407 ar o 表2: ヘッダーフィールドのまとめ(P〜Z)。 Rosenberg Standards Track [Page 9] RFC 3311 SIP UPDATE Method September 2002 Caller Callee | | | | |(1) INVITE with offer 1 | |---------------------------->| | | | | |(2) 180 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) UPDATE with offer 2 | |---------------------------->| | | | | |(6) 200 UPDATE with answer 2 | |<----------------------------| | | | | |(7) UPDATE with offer 3 | |<----------------------------| | | | | |(8) 200 UPDATE with answer 3 | |---------------------------->| | | | | |(9) 200 INVITE | |<----------------------------| | | | | |(10) ACK | |---------------------------->| | | | | | | | | 図1: UPDATEのコールフロー Rosenberg Standards Track [Page 10] RFC 3311 SIP UPDATE Method September 2002 9 セキュリティの考慮 UPDATEのためのセキュリティ考慮はre-INVITEのためのものと同じである。 UPDATEが、完全性保護（integrity protected）され、ダイアログの他端のエ ンティティと同一のソースから来ることが認証されることが重要である。 RFC3261（参考文献[1]）は、これらの機能を実現するためのセキュリティメ カニズムを議論している。 10 IANA条項 RFC3261（参考文献[1]）のセクション27.4に従い、本仕様はSIP UPDATEリク エストメソッドの登録の役割を果たす。レジストリに追加される情報は以下 である。 RFC 3311: 本仕様はUPDATEリクエストメソッドを登録するためのRFCとし ての役割を果たす。 メソッド名： UPDATE 理由フレーズ： Not applicable. 11 知的所有権に関する注記 IETFは本文書に含まれる仕様の一部またはすべてに関する知的所有権請求の 通知を受けている。更なる情報については、オンラインの特許請求リストを 閲覧のこと。 12 規範となる参考文献 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Rosenberg Standards Track [Page 11] RFC 3311 SIP UPDATE Method September 2002 13 謝辞 コメントをくれたJo Hornsby、Markus Isomaki、Rohan Mahy、およびBob Penfieldに感謝したい。 14 著者の連絡先 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Rosenberg Standards Track [Page 12] RFC 3311 SIP UPDATE Method September 2002 15 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネット協会もしくは他のインターネット関連団体への参照を取り 除くなどの変更を加えてはならない。 インターネット標準を開発するために 必要な場合は例外とされるが、その場合はインターネット標準化過程で定義さ れている著作権のための手続きに従わなければならない。 またRFCを英語以外 の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはそ の継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ ト協会およびIETFは、この情報がいかなる権利も侵害していないという保証、 商用利用および特定目的への適合性への保証を含め、また、これらだけに限ら ずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFCエディターの活動のための資金は、現在インターネット協会によっ て提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Rosenberg Standards Track [Page 13]