Network Working Group G. Camarillo Request for Comments: 4032 Ericsson Updates: 3312 P. Kyzivat Category: Standards Track Cisco Systems March 2005 セッション開始プロトコル(SIP)の前提条件フレームワークの更新 Update to the Session Initiation Protocol (SIP) Preconditions Framework 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書はRFC 3312を更新するものであり、SIPの前提条件フレームワークを定 義する。ここでは、新しい前提条件タイプを作成する場合の指針を示し、セッ ションの移動性(mobility)が必要な状況においてSIPを使用する方法について 説明する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 新しい前提条件タイプの定義 . . . . . . . . . . . . . . . . . . 3 3.1. 前提条件タイプのタグ . . . . . . . . . . . . . . . . . . 3 3.2. ステータスタイプ . . . . . . . . . . . . . . . . . . . . 3 3.3. 前提条件の強度 . . . . . . . . . . . . . . . . . . . . . 3 3.4. セッション確立の保留と再開 . . . . . . . . . . . . . . . 3 4. セッションの移動性に関連する問題 . . . . . . . . . . . . . . . 4 4.1. RFC3312からの更新内容 . . . . . . . . . . . . . . . . . 5 4.2. 望ましいステータス . . . . . . . . . . . . . . . . . . . 7 5. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 7 6. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 8 Camarillo & Kyzivat Standards Track [Page 1] RFC 4032 SIP Preconditions Framework March 2005 8.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 8 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. はじめに RFC 3312 [3]では、SIP [2]の前提条件に関するフレームワークを定義してい る。これは、SIP UA (User Agent/ユーザーエージェント)が、前提条件に適合 するまでセッションの確立を保留(suspend)することができる、一般的なフ レームワークである。これまでにサービス品質(Quality of Service/QoS)の前 提条件は定義されてきたが、このフレームワークでは、異なる種類の前提条件 に対応する(RFC 3312ではQoSの前提条件も定義されている)。 本文書はRFC 3312の更新であり、新しい前提条件タイプを作成する場合の指針 を示し、定義時に検討が必要な事項について説明する。さらに、セッションの 移動性が必要な状況においてSIPの前提条件を使用する場合向けに、RFC 3312 の手順を更新した。 RFC 3312では、移動しないメディアセッションに焦点が当てられている。つま り、セッションの間、メディアは同じエンドポイント間で送信される。それで も、SIPによって確立されるメディアセッションは常に静的とは限らない。 SIPは、セッションの移動(具体的にはre-INVITE、UPDATE [5])が可能な仕組み である。既存のRFC3312の実装によって、おそらくセッションの移動性を処理 できるが、関連する問題を明確に指摘し、定義されている手順の一部を微修正 する必要がある。本文書で定義する新たな手順を利用すると、前提条件の現在 のステータスに関して前提条件情報を伝達するメッセージは、より明確にな る。 具体的には、本書では現在のステータス値を下方修正するアンサーを許可する ようにした(これはRFC 3312では許可されていなかった)。本文書では、新しい ストリームを確立する場合と同様に、既存のストリームを新しい位置に移動す ることを検討する。したがって、新しい位置にストリームを移動するアンサー では、現在のステータス値をすべて「No」に設定し、最初から前提条件のネゴ シエーションを新規に開始する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119の BCP 14 [1]に記載されるとおりに解釈されるべきであり、CPL準拠の実装のた めの実装レベルを示すものである。 Camarillo & Kyzivat Standards Track [Page 2] RFC 4032 SIP Preconditions Framework March 2005 3. 新しい前提条件タイプの定義 仕様で新しい前提条件タイプを定義する場合、このセクションで説明されてい る事項について検討する必要がある。新しい前提条件を明確に定義すること は、異なる実装間での相互運用性を確保するために必須である。 3.1. 前提条件タイプのタグ 新しい前提条件タイプには、関連する前提条件タイプタグを指定しなければな らない(たとえば、「qos」はQoS前提条件のタグ)[MUST]。新しい前提条件を作 成する場合、RFC 3312のセクション15の指示に従って、新しい前提条件タイプ とそのタグをIANAに登録しなければならない[MUST]。 3.2. ステータスタイプ RFC 3312では、end-to-endとsegmentedという2つのステータスタイプを定義し ている。仕様で新しい前提条件タイプを定義する場合、新しい前提条件に適用 するステータスを示さなければならない[MUST]。新しい前提条件では、1つの ステータスか、両方を使用することができる。たとえば、RFC 3312で定義され ているQoS前提条件では両方を使用できる。 3.3. 前提条件の強度 RFC 3312では、オプションの前提条件と必須の前提条件を定義している。 仕様で新しい前提条件タイプを定義する場合、オプションの前提条件を適用可 能かどうか、適用可能な場合にオプションの前提条件を受信したUAに期待され る動作は何かについて、説明しなければならない[MUST]。 3.4. セッション確立の保留と再開 RFC 3312のセクション6では、複数の前提条件によってセッション確立が保留 された時点以降から、前提条件に適合したときに再開されるまでのUAの動作に ついて説明している。一般的に、前提条件に適合するまで、着呼側ユーザーに は通知されない。 ユーザーに通知しないことだけでなく、各前提条件タイプでは、セッションが 保留したときにUAが実行すべき動作や避けるべき動作をすべて定義しなければ ならない[MUST]。したがって、セッションが保留しているときのメディアスト リームの動作は、特定の前提条件タイプ定義の一部である。前提条件タイプに Camarillo & Kyzivat Standards Track [Page 3] RFC 4032 SIP Preconditions Framework March 2005 よって、セッションの保留中にメディアストリームによるパケットの送受信を 許可する場合や、許可しない場合がある。結果的に、RFC 3312の次の段落は、 QoS前提条件にのみ適用される。 セッション確立が保留されている間、ユーザーエージェントはメディア ストリーム上でデータを送信すべきではない[SHOULD NOT]。RTPの場合、 RTPパケットもRTCPパケットも送信されない。 前の段落を明確に説明すると、接続指向のトランスポートプロトコル(TCP SYN など)で接続を確立するときに使用する制御メッセージは、前述の規則に影響 を受けない。そのため、ユーザーエージェントは、QoS前提条件に関係なく、 標準的な規則(SDPの「setup」属性[7]など)に従って接続を確立するタイミン グを決定する。 新しい前提条件タイプでは、実行中のセッションに関する前提条件が指定され たre-INVITEまたはUPDATEを受信したときに関して、UAの動作も説明しなけれ ばならない[MUST]。 4. セッションの移動性に関連する問題 RFC3312のセクション5には、オファー/アンサーモデル[4]と共にSIP [2]の前 提条件を使用する方法が記載されている。RFC3312では、ユーザーエージェン トが、リモートのユーザーエージェントとの間で、前提条件の現在のステータ ス変化を通信できるようにする規則がいくつか記載されている。 RFC3312の意図は、特定のユーザーエージェントが、ローカル情報(リソース予 約が成功したと指定するRSVP RESVの受け取りなど)を通じて、前提条件(QoS前 提条件の指示を送信など)の一部について現在のステータスを知ることであ る。UAC(User Agent Client/ユーザーエージェントクライアント)は、UAS (User Agent Server/ユーザーエージェントサーバー)にオファーを送信するこ とで、現在のステータス変化について通知する。UACは、次に、(必要に応じ て)オファーをUACに送信して、UAがローカル情報として持っていた前提条件の 一部のステータスについて知らせることができる。 ただし、通常、UASは現在のステータスの変更をUACには送信しない、とい うことに注意。理由は、すべての前提条件を満たす場合に、UASはセッショ ン確立を再開(resume)するためである。したがって、UACにすべての前提条 件が満たされていることを知らせるには、オファー/アンサー交換を実行す るのではなく、セッション確立が再開されたことを示す180 (Ringing)応答 を送信するだけである。 Camarillo & Kyzivat Standards Track [Page 4] RFC 4032 SIP Preconditions Framework March 2005 RFC 3312では、上記の方法を使用して、現在のステータス情報を更新すること が許容されているが、現在のステータス値をアンサーで下方修正することは許 容されていない(RFC 3312の表3の3行目参照)。図1に、アンサーでの下方修正 が必要になる場合を示す。 3pcc A コントローラ B C | | | | |<-dialog 1->|<-dialog 2->| | | | | | | *********************** | | |* メディア *| | | *********************** | | | | | | | | | | |<-dialog 1->|<------dialog 3----->| | | | | | ******************************** | |* メディア *| | ******************************** | | | | | | | | | 図1: 3pccを使用したセッションの移動性 図1の3PCC(サードパーティ呼制御、[6])コントローラは、Aに対するdialog 1 とBに対するdialog 2を使用して、A、B間のセッションを確立した。この時点 で、コントローラは、AにBではなくCとセッションを持たせようとしている。A からCに転送(transfer)するために(設定は図1の下を参照)、コントローラは空 の(オファーなしの)re-INVITEをAに送信する。Aはセッションの移動を認知し ていないため、200 OKに含まれるオファーでは、送信方向のメディアストリー ムについて、現在のステータスは「Yes」であると提示される。コントローラ は、dialog 3を確立したCと通信した後、アンサーをAに返す。このアンサーに はメディアの新規送信先(C)が含まれる。また、AとC間のリソース予約はない ため、このアンサーでメディアストリームの現在のステータスが「No」に下方 修正される。 4.1. RFC3312からの更新内容 上記の問題に対応するために、RFC 3312を更新する新規則を以下に提示する。 Camarillo & Kyzivat Standards Track [Page 5] RFC 4032 SIP Preconditions Framework March 2005 以下の規則は、メディアストリームを新規アドレスに移動するオファー側に適 用される。 ストリームが新規の伝送アドレスに移動されるとき、オファー側は、ローカル 情報を持たない現在のステータス値すべてを、「No」に設定しなければならな い[MUST]。 セグメント化されたステータスを使用するストリームの場合(エンドツーエン ドのステータスとは反対に)、ローカルセグメントにおけるメディアストリー ムのアドレスが変更されることによって、リモートセグメントにおける前提条 件のステータスに影響する可能性もあるが、影響しない可能性もある、という ことに注意。ただし、既存のストリームを、前提条件の観点から新規の場所に 移動することは、新規のストリームを確立するときと似ている。したがって、 現在のステータス値すべてを「No」に設定し、前提条件のネゴシエーションを スクラッチから新規に開始するのが適切である。 以下に記載する更新後の表と規則は、メディアストリームを移動するアンサー 側に適用される。オファー側は、オファーを生成した時点で移動は意識してい なかった。 RFC3312の表3は、アンサー側で現在のステータス値を下方修正することを許容 するように更新する必要がある。次の表に結果を示す。 トランザクション ローカル 新規値のトランザクション ステータステーブル ステータステーブル /ローカル ____________________________________________________________________ no no no/no yes yes yes/yes yes no ローカル情報による no yes ローカル情報による アンサー側は、オファーで受け取った現在のステータス値についてローカル情 報を持っている場合、あるいは、メディアストリームが新規の伝送アドレスに 移動されている場合、そのステータス値を下方修正しなければならない [MUST]。 セグメント化されたステータスを使用するストリームの場合、アンサー側にお けるアドレスの変更によって、オファー側のセグメントにおける前提条件のス テータスに影響する可能性もあるが、影響しない可能性もある、ということに 注意。ただし、前述のように、既存のストリームを、前提条件の観点から新規 の場所に移動することは、新規のストリームを確立するときと似ている。した がって、現在のステータス値すべてを「No」に設定し、前提条件のネゴシエー ションをスクラッチから新規に開始するのが適切である。 以下の新たな表は、ローカルのステータス表を更新するか下方修正する、アン サーを受け取るオファー側に適用される。 Camarillo & Kyzivat Standards Track [Page 6] RFC 4032 SIP Preconditions Framework March 2005 オファー側は、次の表で示されるアンサーを受け取ったときに、ローカルのス テータス表を更新すべきである。 トランザクション ローカル 新規値の ステータステーブル ステータステーブル ローカルステータス _________________________________________________________________ no no no yes yes yes yes no yes no yes no 4.2. 望ましいステータス UAにとって、ストリームが新規の伝送アドレスに移動された後のメディアスト リーム向け希望ステータス(desired status)は、元々のストリーム向けにネゴ シエートされた希望ステータスとは異なる可能性がある。たとえば、UAは、狭 い帯域のリンク上ではQoSを必須と要求するが、ストリームが広帯域のリンク に移動された場合は、QoSはオプションでも満足する、という可能性がある。 新規の希望ステータスが、以前のものよりも高い場合(たとえば、オプション から必須など)、UAは、RFC3312の手順に従って、オファーまたはアンサーに含 まれる希望ステータスを更新してもよい。新規の希望ステータスが、以前のも のよりも低い場合(つまり、必須からオプションなど)、UAは、同様にRFC3312 の手順に従って、オファーに含まれる希望ステータスは下方修正してもよい (つまり、アンサーは不可)。 5. セキュリティの考慮事項 セッション記述に前提条件を追加したり、既存の前提条件を修正する攻撃者 は、セッションの確立を阻害することができる。セッション記述から前提条件 を削除する攻撃者は、必須の前提条件を満たさなくても、セッションを強制的 に確立することができる。 したがって、整合性の保護がSDPのセッション記述に適用することが、強く推 奨される[RECOMMENDED]。RFC3261 [2]に記載されているように、このようなエ ンドツーエンドの整合性保護を実現するには、S/MIMEを選択するのが適切であ る。 6. IANA条項 前提条件フレームワークのIANA登録要件は、RFC 3312で定義されている。新し い前提条件は、いずれもIANA条項で管理される。 Camarillo & Kyzivat Standards Track [Page 7] RFC 4032 SIP Preconditions Framework March 2005 7. 謝辞 本文書について、Dave OranとAllison Mankinから有益なコメントをいただい た。 8. 参考文献 8.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. 8.2. Informational References [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [6] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [7] Yon, D. and Camarillo, G., "TCP-Based Media Transport in the Session Description Protocol (SDP)", Work In Progress, November 2004. Camarillo & Kyzivat Standards Track [Page 8] RFC 4032 SIP Preconditions Framework March 2005 著者の連絡先 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue, BXB500 C2-2 Boxborough, MA 01719 USA EMail: pkyzivat@cisco.com Camarillo & Kyzivat Standards Track [Page 9] RFC 4032 SIP Preconditions Framework March 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載され ている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Camarillo & Kyzivat Standards Track [Page 10]