Network Working Group G. Camarillo, Ed. Request for Comments: 3312 Ericsson Category: Standards Track W. Marshall, Ed. AT&T J. Rosenberg dynamicsoft October 2002 リソース管理とSIPの統合 Integration of Resource Management and Session Initiation Protocol (SIP) 本文書の位置付け 本文書はインターネットコミュニティに対してInternet standards trackプ ロトコルの仕様を定めるものであり、改善のための議論と提案を求めるもの である。標準化の状況と本プロトコルのステータスについては、「Internet Official Protocol Standards (STD 1)」の最新版を参照のこと。本文書の配 布に制限はない。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本文書は、IANAへの登録によって拡張可能なプリコンディションの包括的な フレームワークを定義する。本文書はまた、SIPがイニシエートしたセッショ ンの確立のためのプリコンディションが、サービスのネットワーク品質をど のように達成するかについても論ずる。これらのプリコンディションは、セ ッションを継続する前に、参加者がネットワークリソースを予約することを 要求する。我々は、新たなQoS予約メカニズムを定義しない。これらのプリコ ンディションは、セッションを開始する前に参加者に既存のリソース予約メ カニズムを使用することを要求するだけである。 Camarillo, et. al. Standards Track [Page 1] RFC 3312 Integration of Resource Management and SIP October 2002 目次 1 はじめに ....................................................... 2 2 用語 ........................................................... 3 3 概要 ........................................................... 3 4 SDPパラメータ .................................................. 4 5 オファー/アンサーでのプリコンディションの用法 .................. 7 5.1 オファーの生成 ............................................... 8 5.1.1 SDPエンコーディング ........................................ 9 5.2 アンサーの生成 ............................................... 10 6 セッション確立のサスペンドおよびレジューム ..................... 11 7 ステータス確認 ................................................. 12 8 オファーの拒否 ................................................. 13 8.1 メディアストリームの拒否 ..................................... 14 9 未知のプリコンディションタイプ ................................. 15 10 メディアストリーム1つあたり複数のプリコンディション ........... 15 11 プリコンディション用のオプションタグ .......................... 16 12 能力表示 ...................................................... 16 13 例 ............................................................ 16 13.1 End-to-endステータスタイプ .................................. 17 13.2 Segmentedステータスタイプ ................................... 21 13.3 SIP応答中のオファー ......................................... 23 14 セキュリティの考慮 ............................................ 26 15 IANA条項 ...................................................... 26 16 知的所有権に関する注記 ........................................ 27 17 参考文献 ...................................................... 27 18 貢献者 ........................................................ 28 19 謝辞 .......................................................... 28 20 著者の連絡先 .................................................. 29 21 完全な著作権表記 .............................................. 30 1 はじめに 一部のアーキテクチャーは、セッション確立時に着呼側がいったんアラート されると、セッション確立失敗の確率が最小限になることを要求する。失敗 の1つの要因は、セッションのためのネットワークリソースを予約する能力の 欠如である。「ghost rings」を最小限に抑えるため、着呼側がアラートされ る前に、セッションのためのネットワークリソースを予約する必要がある。 しかしながらネットワークリソースの予約には、ほとんどの場合、着呼側か らIPアドレス、ポート、セッションパラメータを確認することが必要になる。 この情報は、SIPで伝えられる最初のオファー/アンサー交換の結果として取 得される。通常、この交換により「電話が鳴る」ので、「ニワトリが先か卵 が先か」の問題(最初のオファー/アンサー交換を実行しないとリソースを予 約できず、また、リソース予約を実行しないと最初のオファー/アンサー交換 ができない)が起こる。 Camarillo, et. al. Standards Track [Page 2] RFC 3312 Integration of Resource Management and SIP October 2002 解決策は、プリコンディションという考えの導入である。プリコンディショ ンとはオファー内に導入される、セッションに関する制約のセットである。 オファーの受信側はアンサーを生成するが、ユーザーにアラートしないでセ ッションの確立を進める。これは、プリコンディションが満たされたときに のみ起こる。これは、ローカルイベント(リソース予約の確認など)、あるい は発呼側が送信した新規オファーを介して知ることができる。 本文書では、シグナリングプロトコルとしてSIP(参考文献[1])、セッション パラメータの記述にSDP(参考文献[2])を使用するセッションを扱う。 プリコンディションはストリーム固有なので、我々は、QoSプリコンディショ ンをSIPヘッダーではなくSDP記述に含めることを選択した。 2 用語 本文書では、次のキーワードはBCP14、RFC2119(参考文献[3])に記述されてい るとおりに解釈される。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 3 概要 特定のプリコンディションが満たされるまでセッション確立が起こらないこ とを確実にするため、特定のメディアストリームに影響する2つの異なるステ ート変数(current status と desired status)を区別する。本文書は、QoSス テータスを定義する。 desired statusは、current statusのための閾値からなる。セッション確立 は、current statusがこの閾値に到達するか越えるまで停止される。この閾 値に到達するか超えるとすぐに、セッション確立が再開される。 例えば、以下のcurrent status と desired statusの値はセッション確立が 再開されることを認めない。 current status = 送信方向で予約されたリソース desired status = 両方向(sendrecv)で予約されたリソース その一方、以下の例の値はセッション確立を再開させる。 current status = 両方向(sendrecv)で予約されたリソース desired status = 送信方向で予約されたリソース Camarillo, et. al. Standards Track [Page 3] RFC 3312 Integration of Resource Management and SIP October 2002 これら2つのステート変数は、directionアトリビュートや使用中のコーデッ クが別のステート要素を定義するのと同じように、メディアストリームの特 定のステート要素を定義する。結果として、我々は、SIP(参考文献[4])で使 用されるオファー/アンサーモデルで他のSDPアトリビュートが扱われるのと 同じ方法で、これら2つの新規変数を扱う。それらは、セッションステータス の共有ビューを持つために、オファーとアンサーを使用して2つのUA間で交換 される。 図1は、プリコンディションを使用する2つのSIP UA間の、典型的なメッセー ジ交換を示している。Aは最初のINVITEのSDPに、QoSプリコンディションを含 める。Aは、エンドツーエンドで両方向に(sendrecv)ネットワークリソースが 予約されるまで、Bがアラートされることを望まない。Bは、着呼側にアラー トする前に、このセッションのためのネットワークリソースを予約すること に同意する。Bは、B→A方向のリソース予約をハンドリングするが、A→B方向 のハンドリングはAが行う必要がある。そう示すためにBはAに、リソース予約 を開始してA→B方向がセッションのために準備できたらすぐにBに確認するよ うに依頼する183(Session Progress)応答をAに返す。A、B双方はリソースの 予約を開始する。BはB→A方向のリソース予約を終えるが、両方向のネットワ ークリソースが必要なので、まだユーザーにアラートしない。AがA→B方向の リソース予約を終えるとき、AはBにUPDATE(参考文献[5])を送信する。BはUPDATE に対して200(OK)応答を返し、セッションのためのすべてのプリコンディショ ンが満たされたことを示す。この時点で、Bはユーザーにアラートを開始し、 セッション確立は通常どおり完了する。 4 SDPパラメータ 以下のメディアレベルSDPアトリビュートを定義する。 current-status = "a=curr:" precondition-type SP status-type SP direction-tag desired-status = "a=des:" precondition-type SP strength-tag SP status-type SP direction-tag confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag precondition-type = "qos" | token strength-tag = ("mandatory" | "optional" | "none" = | "failure" | "unknown") status-type = ("e2e" | "local" | "remote") direction-tag = ("none" | "send" | "recv" | "sendrecv") Current status: current statusアトリビュートは、特定のメディアスト リームのためのネットワークリソースの現在のステータスを伝える。 Camarillo, et. al. Standards Track [Page 4] RFC 3312 Integration of Resource Management and SIP October 2002 Desired status: desired statusアトリビュートは、特定のメディアスト リームのためのプリコンディションを伝える。特定のストリームに 対する、任意のprecondition-type/status-typeを持つcurrent status アトリビュートのdirection-tagが、そのストリームに対する、そ れと同じprecondition-type/status-typeを持つdesired statusア トリビュートのdirection-tagと等しい(または優れている[better]) とき、そのストリームに対してそのプリコンディションは満たされ ているとみなされる。 Confirmation status: confirmation statusアトリビュートは、メディア ストリームのための閾値条件を伝える。ネットワークリソースのス テータスがこれらの条件に達したとき、そのピアUAは、この特定の メディアストリームのための更新されたcurrent statusアトリビュ ートを含む、セッション記述の更新を送信する。 Precondition type: 本文書は、QoSプリコンディションを定義する。拡張 で他のタイプのプリコンディションを定義できる。 Strength tag: strength-tagは、ネットワークがプリコンディションを満 たすことに失敗した場合に、着呼側にアラートできるかどうかを示 す。 Status type: 2つステータスタイプ(end-to-endとsegmented)を定義する。 end-to-endステータスは、リソースのエンドツーエンド予約のステ ータスを示す。segmentedステータスは、双方のUAのアクセスネッ トワーク予約のステータスを示す。end-to-endステータスは上で定 義されている「e2e」タグに対応し、segmentedステータスは「local」 と「remote」タグに対応する。end-to-endステータスは、エンドツ ーエンドのリソース予約メカニズムが利用可能なときに有用である。 segmentedステータスは、一方もしくは双方のUAが各々のアクセス ネットワーク上でリソース予約を実行するときに有用である。 Camarillo, et. al. Standards Track [Page 5] RFC 3312 Integration of Resource Management and SIP October 2002 A B | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(4) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-------------(7) 180 Ringing---------------| | | |-----------------(8) PRACK----------------->| | | |<------------(9) 200 OK (PRACK)-------------| | | | | | | |<-----------(10) 200 OK (INVITE)------------| | | |------------------(11) ACK----------------->| | | | | 図1: プリコンディションを用いた基本的なセッション確立 Direction tag: direction-tagは、特定のアトリビュート(current、 desired、またはconfirmationのステータス)を適用可能な方向を示す。 Camarillo, et. al. Standards Track [Page 6] RFC 3312 Integration of Resource Management and SIP October 2002 「send」、「recv」、「local」、「remote」タグ値は、SDP記述を生成する エンティティの視点に相当する。オファーにおいて、「send」はオファー側 からアンサー側の方向で、「local」はオファー側のアクセスネットワークで ある。アンサーにおいて、「send」はアンサー側からオファー側の方向で、 「local」はアンサー側のアクセスネットワークである。 以下の例は、セッション記述の2つのメディア行にある、これら新規SDPアト リビュートを示している。 m=audio 20000 RTP/AVP 0 a=curr:qos e2e send a=des:qos optional e2e send a=des:qos mandatory e2e recv m=audio 20002 RTP/AVP 0 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos mandatory remote sendrecv 5 オファー/アンサーでのプリコンディションの用法 SIPでのパラメータのネゴシエーションは、参考文献[4]で述べられているオ ファー/アンサーモデルを使用して行われる。このモデルの背後にある考えは、 オファー側が一旦アンサーを受信したら、両方のUAに対してセッションパラ メータの共有ビューを提供することである。このセクションでは、アンサー 中で新規SDPアトリビュートのどの値をとることができるか(オファー中の新 規SDPアトリビュートの値に応じて)を述べる。 メディアストリームのステータスの共有ビューを実現するために、3つのテー ブルからなるモデルを定義する。それらのテーブルは、双方のUAが実装する ローカルステータステーブルと、各オファー/アンサー交換が持つそれらに関 連付けられたトランザクションステータステーブルである。オファー側は、 それのローカルステータステーブルと同一のトランザクションステータステ ーブルを生成し、それをオファーでアンサー側に送信する。アンサー側はそ れのローカルステータステーブルを更新するために、このトランザクション ステータステーブルの情報を使用する。またアンサー側は、トランザクショ ンステータステーブルの期限切れになったフィールドを更新し、このテーブ ルをアンサーでオファー側に返す。それからオファー側は、アンサーで受信 した情報で、ローカルステータステーブルを更新できる。このオファー/アン サー交換の後、双方のUAのローカルステータステーブルは同期される。双方 のUAは、メディアストリームのステータスの共通のビューを持つことになる。 いくつかのメディアストリームに関与するセッションは、これらのテーブル をメディアストリームごとに持つ。しかしながら、これはUA動作のモデルで あって、ソフトウェアのモデルではないということに注意すること。実装で は、このモデルが定義する外部動作を再現するどのようなアプローチをとる こともできる。 Camarillo, et. al. Standards Track [Page 7] RFC 3312 Integration of Resource Management and SIP October 2002 5.1 オファーの生成 双方のUAは、「ローカルステータステーブル」と呼ばれる、ローカルのプリ コンディションのステータスを保持しなければならない[MUST]。表1と表2は、 end-to-endとsegmented双方のステータスタイプのテーブルフォーマットを示 している。end-to-endステータスタイプの表は、それぞれの方向(sendとrecv) のための2つの行を含む。「Current」フィールドの「yes」という値は、対応 する方向の、そのリソース予約が成功することを示す。「No」はまだリソー スが予約されていないことを示す。「Desired Strength (望ましい強度)」フ ィールドは、対応する方向でのプリコンディションの強度を示す。segmented ステータスタイプの表は、4つの行を含む(ローカルのアクセスネットワーク の両方向およびピアのアクセスネットワークの両方向)。フィールドの意味は、 end-to-endの場合と同じである。 オファーを生成する前に、オファー側は各メディアストリームに対して、current statusとdesired statusを持つトランザクションステータステーブルを構築 しなければならない[MUST]。desired-statusアトリビュートのstrength-tag の各値は、以下のセマンティクスを持つ。 o None: リソース予約は不要。 o Optional: UAはリソース予約の提供を試みるべき[SHOULD]であるが、 この提供が可能かどうかに関わらず、セッションは継続する。 o Mandatory: UAはリソース予約を提供しなければならない[MUST]。そう しなければ、セッション確立を継続してはならない[MUST NOT]。 それからオファー側は、end-to-endステータスタイプまたはsegmentedステー タスタイプを使用するかどうかを決定する。メディア行のステータスタイプ をend-to-endにする場合、UAは表１に示されているように、それぞれの方向 ごと(send と recv)にdesired statusとcurrent statusを持つレコードを生 成する。 Direction Current Desired Strength ____________________________________ send no mandatory recv no mandatory 表1: end-to-endステータスタイプの表 メディア行のステータスタイプをsegmentedにする場合、UAは表2に示されて いるように、それぞれの方向ごと(send と recv)およびそれぞれのセグメン トごと(local と remote)にdesired statusとcurrent statusを持つレコード を生成する。 Camarillo, et. al. Standards Track [Page 8] RFC 3312 Integration of Resource Management and SIP October 2002 Direction Current Desired Strength ______________________________________ local send no none local recv no none remote send no optional remote recv no none 表2: segmentedステータスタイプの表 オファーを送信するとき、オファー側のローカルステータステーブルとトラ ンザクションステータステーブルは同じ値を含む。 トランザクションステータステーブルで、UAは、セクション4のシンタックス と下記のセクション5.1.1で述べられているルールに従って、current-status とdesired-status行を生成しなければならない[MUST]。 5.1.1 SDPエンコーディング end-to-endステータスタイプにおいて、UAは、メディアストリームに対して、 タグ「e2e」を持つ1つのcurrent status行を生成しなければならない[MUST]。 トランザクションステータステーブルで両方向のstrength-tagが等しい場合( 例えば、両方「mandatory」)、UAはタグ「sendrecv」を持つ1つのdesired status 行を追加しなければならない[MUST]。両方のタグが異なる場合、UAは2つのdesired status行(1つはタグ「send」を持ち、もう1つはタグ「recv」を持つ)を含め なければならない[MUST]。 一方が「send」タグ、もう一方が「recv」タグで、同じstrength-tagを持 つ2つの行のセマンティクスは、「sendrecv」を持つ1つの行と同じである。 しかしながら、よりコンパクトなエンコーディングを実現するために、後 者のフォーマットにすることを義務付けることにした。 segmentedステータスタイプでは、UAは、2つのcurrent status行を生成しな ければならない[MUST]。1つは「local」タグを持つもので、もう一つは「remote 」タグを持つものである。UAは、セグメントごとに(すなわち、localとremote) 1つまたは2つのdesired status行を追加しなければならない[MUST]。特定のセ グメント(localまたはremote)に対して、トランザクションステータステーブ ル中の両方向のタグが等しい場合(例えば、両方「mandatory」)、UAはタグ「 sendrecv」を持つ1つのdesired status行を追加しなければならない[MUST]。 両方のタグが異なる場合、UAは2つのdesired status行(1つはタグ「send」を 持ち、もう1つはタグ「recv」を持つ)を含めなければならない[MUST]。 上記のルールはdesired status-tag 「none」にも適用されるということに注 意すること。このように、QoSをサポートするがそれの使用を望まないUAは、 strength-tag「none」を持つdesired-status行を追加する。このタグは、セ クション5.2で述べられているように、アンサー中でアップグレードできるの で、アンサー側は別のオファー/アンサー交換をすることなしにQoS予約を要 求できる。 Camarillo, et. al. Standards Track [Page 9] RFC 3312 Integration of Resource Management and SIP October 2002 以下の例は、表1と表2に対応するSDPを示す。 m=audio 20000 RTP/AVP 0 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv m=audio 20002 RTP/AVP 0 a=curr:qos local none a=curr:qos remote none a=des:qos optional remote send a=des:qos none remote recv a=des:qos none local sendrecv 5.2 アンサーの生成 アンサー側がオファーを受信するとき、それはオファーに含まれるSDPアトリ ビュートを使用して、トランザクションステータステーブルを再生成する。 アンサー側は、それのローカルステータステーブルとトランザクションステ ータステーブルを以下のルールに従ってアップデートする。 Desired Strength: strength-tag (none、optional、mandatory)の絶対的 なオーダーを決定する。「Mandatory」は最高のグレードを持つタ グであり、「none」は最低のグレードを持つタグである。アンサー 側は、トランザクションステータステーブルのどのエントリにある desired strengthもアップグレードしてよい[MAY]が、ダウングレー ドしてはならない[MUST NOT]。したがって、行を「none」から 「optional」、「none」から「mandatory」、「optional」から 「mandatory」にアップグレードしてもよいが、その逆はだめである。 Current Status: トランザクションステータステーブルおよびアンサー側 のローカルステータステーブル中のすべての行の「Current」フィ ールド値は、比較されなければならない。表3は4つのあり得る組み 合わせを示す。両方のフィールドが同じ値を持つ場合(表3の最初の 2行)、何もアップデートされる必要はない。トランザクションステ ータステーブルの「Current」フィールドが「Yes」で、ローカルス テータステーブルのそのフィールドが「No」の場合(表3の3行め)、 後者は「Yes」に設定されなければならない[MUST]。トランザクシ ョンステータステーブルの「Current」フィールドが「No」で、ロ ーカルステータステーブルのそのフィールドが「Yes」の場合(表3 の4行め)、アンサー側はその特定のcurrent statusに関するローカ ルの情報(例えば、リソース予約の確認を受信したこと)を持ってい るかどうかチェックする必要がある。持っていれば、トランザクシ ョンステータステーブルの「Current」フィールドは「Yes」に設定 される。アンサー側がそのcurrent statusに関するローカル情報を 持っていない場合、ローカルステータステーブルの「Current」フ ィールドは「No」に設定されなければならない[MUST]。 Camarillo, et. al. Standards Track [Page 10] RFC 3312 Integration of Resource Management and SIP October 2002 Transac. status table Local status table New values transac./local ____________________________________________________________________ no no no/no yes yes yes/yes yes no yes/yes no yes depends on local info 表3: 「Current」フィールドに可能な値 両方のテーブルがアップデートされたら、表4に示されているように「send」、 「receive」、「local」、「remote」タグがアンサー中で反転されなければ ならないことを考慮して、セクション5.1.1に述べられているルールに従って、 アンサーが生成されなければならない[MUST]。 Offer Answer ______________ send recv recv send local remote remote local 表4: オファーとアンサー中のタグ値 アンサーを送信するとき、トランザクションステータステーブルとアンサー 側のローカルステータステーブルとは同じ値を含む。したがって、このアン サーは、current-statusアトリビュート中、およびdesired-statusアトリビ ュート中のネゴシエートされたstrength-tagとdirection-tagに、media行の ステータスの共有ビューを含む。 使用されるリソース予約メカニズムが両方のUAの参加を要求する場合、アン サー側はアンサーを送信した後にリソース予約を開始するべき[SHOULD]であ り、オファー側はアンサーを受信したらすぐにリソース予約を開始するべき である[SHOULD]。ピアUAの参加が必要ない場合(例：segmentedステータスタ イプ)、オファー側はオファー送信前にリソース予約を開始してよく[MAY]、 アンサー側はアンサー送信前にリソース予約を開始してよい[MAY]。 メディア行のリソース予約のステータスは、連続した2つのオファー/アンサ ー交換間で変わることができる。したがって双方のUAは、セッションが継続 するあいだじゅうローカル情報を使用して、ローカルステータステーブルを 最新の状態に保っていなければならない[MUST]。 6 セッション確立のサスペンドおよびレジューム プリコンディションを含むオファーを受信するUASは、すべての必須の(mandatory) プリコンディションが満たされるまでユーザーにアラートするべきではない[SHOULD NOT]。 つまり、セッション確立はそのときまでサスペンドされる(例：PSTNゲートウ ェイはPSTNにシグナリングを送信しないでリソースを予約する)。 Camarillo, et. al. Standards Track [Page 11] RFC 3312 Integration of Resource Management and SIP October 2002 UASはオファーを持たないINVITEリクエストを受信するかもしれない。この場 合、参考文献[1]と[5]で定義されている通常の手順に従って、UASは信頼性の ある1xx応答中でオファーを提示する。UACは別のSIPリクエスト(すなわち、1xx に対するPRACK)でアンサーを送信する。オファーとアンサーがプリコンディ ションを含む場合、UASはアンサー中のすべての必須の(mandatory)プリコン ディションが満たされるまで、ユーザーにアラートするべきではない[SHOULD NOT]。 この場合、UASは最初のオファーをプリコンディションとともに提示し、 UASはすべてのプリコンディションが満たされるまでユーザーにアラー トできないので、プリコンディションを持つ180(Ringing)応答は決し て送信されない、ということに注意すること。 すべての必須の(mandatory)プリコンディションを一方的に満たすことができ ないUASは、それが送信するSDP(オファーまたはアンサー)にconfirm-status アトリビュートを含めなければならない[MUST](セクション7参照)。更に、こ のconfirm-statusアトリビュートを含むSDP(オファーまたはアンサー)は、SIP のオファー/アンサールールで可能になったらすぐに送信されなければならな い[MUST]。 セッション確立がサスペンドされているあいだ、UAはすべてのメディアスト リーム上でいかなるデータも送信するべきではない[SHOULD not]。RTP(参考 文献[6])の場合は、RTPパケットもRTCPパケットも送信されない。 UASは、それのローカルステータステーブルのstrength-tagが「mandatory」 であるすべての行が「yes」値を持つときに、メディア行に対してすべてのプ リコンディションが満たされたことがわかる。セッションのすべてのメディ ア行のプリコンディションが満たされたとき、セッション確立はレジューム されるべきである[SHOULD]。 最初のINVITEにおいて、セッション確立のサスペンドとレジュームは非常に 直感的(intuitive)である。着呼側は、すべての必須の(mandatory)プリコン ディションが満たされるまでアラートされない。しかしながら、セッション 進行中に送信される、プリコンディションを含むオファーは更なる説明を要 する。双方のUAは、すべての必須のプリコンディションが満たされるまで、 古いセッションパラメータの使用を継続するべきである[SHOULD]。その時[訳 注：満たされたとき]、UAは新しいセッションパラメータの使用を開始できる。 セクション13に、このシチュエーションの例がある。 7 ステータス確認 confirm-statusアトリビュートは、オファーとアンサー双方で使用してよい[MAY]。 このアトリビュートは、リソース予約の閾値を表す。この閾値に到達するか 越えるとき、UAはピアUAに、SIPのオファー/アンサールールで可能になった らすぐに、メディア行の新しいcurrent statusを反映したオファーを送信し なければならない[MUST]。この閾値を再びまたぐとき(例：ネットワークがメ ディアストリームに対してのリソース提供を停止するとき)、UAは同様に、SIP のオファー/アンサールールで可能になったらすぐに新規オファーを送信しな ければならない[MUST]。 Camarillo, et. al. Standards Track [Page 12] RFC 3312 Integration of Resource Management and SIP October 2002 ピアが特定のストリーム上で確認を要求する場合、エージェントはそれのロ ーカルステータステーブル内でそのストリームにフラグを立てなければなら ない[MUST]。このフラグを持つすべての行が「yes」という「Current」値を持つ とき、UAは新規オファーをピアに送信しなければならない[MUST]。このオフ ァーは、current-statusアトリビュートにリソース予約の現在のステータス を含む。後に、このフラグを持つ行のどれかが「No」に移行する場合、同様 に新規オファーが送信されなければならない[MUST]。 確認(confirmation)のアトリビュートはネゴシエートされない。アンサー側 は、オファー中のconfirm-statusアトリビュート値を使用し、オファー側は アンサー中のこのアトリビュートの値を使用する。 例えば、UAが以下のアトリビュートを持つSDP記述を受信する場合、 m=audio 20002 RTP/AVP 0 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv アクセスネットワーク(受信メッセージ中の「remote」タグ)中で双方向(sendrecv) に対してリソースを予約するとすぐに、オファーを送信する。 8 オファーの拒否 以下の新規SIPステータスコードを定義する。 Server-Error = "580" ;Precondition Failure (プリコンディション失敗) アンサー側として動作しているUASが、オファー中のプリコンディションを満 たせない、あるいは満たすつもりがないとき、それは580(Precondition Failure) 応答を返すことでオファーを拒否するべきである[SHOULD]。 580(Precondition Failure)ステータスコードをオファーを拒否するために使 用することは、オファーがINVITEまたはUPDATEリクエスト中で送られてくる ときに有用である。その一方、SIPは、INVITEに対する応答(1xxまたは2xx) 中で到達するオファーを拒否する手段を提供しない。UACが、オファーを持た ない最初のINVITEを生成し、受け入れ不可能なオファーを1xxまたは2xx応答 で受信する場合、それはこのオファーに正しく形成されたアンサーで応答し てから直ちにCANCELまたはBYEを送信するべきである[SHOULD]。 Camarillo, et. al. Standards Track [Page 13] RFC 3312 Integration of Resource Management and SIP October 2002 オファーがre-INVITEに対する1xxまたは2xx応答中で送られてくる場合、Aは セッションを切断する以外にそれを拒否する手段を持たないだろう。参考文 献[1]のセクション15.2で与えられているのと同じアドバイスがここでも適用 される。 UASは、セッション記述が以前のセッション記述と、メディアフォーマ ット、トランスポート、相手側のサポートを必要とする他のパラメー タにおいて、重複することを保証しなければならない[MUST]。これは、 相手がセッション記述を拒否する必要性を避けるためである。しかし ながら、それがAにとって受け入れられないものである場合、Aは有効 なセッション記述を持つアンサーを生成し、次いでそのセッションを 終了するためにBYEを送るべきである[SHOULD]。 ある特定のプリコンディションを満たすことに失敗したことを示す580(Precondition Failure)応答とBYEリクエストとCANCELリクエストは、どのdesired statusが 失敗を引き起こしたかを示すSDP記述を含むべきである[SHOULD]。このSDP記 述は、セッションの確立をもたらさないので、オファーでもアンサーでもな いということに注意すること。このような記述のフォーマットは、リモート のUAから受信した直近のSDP(オファーまたはアンサー)を基にしている。 受信した直近のSDP記述中の各「m=」行に対応する「m=」行が、失敗を示すSDP 記述中になければならない[MUST]。このSDP記述は、受信した直近のSDP記述 と正確に同じ数の「m=」行を含まなければならない[MUST]。すべての「m=」 行のポート番号は、ゼロに設定されなければならない[MUST]が、コネクショ ンアドレスは任意である。 失敗を引き起こしたプリコンディションに対応するdesired status行は、以 下の例に示すように、「failure」というstrength-tagを使用しなければなら ない[MUST]。 m=audio 20000 RTP/AVP 0 a=des:qos failure e2e send 8.1 メディアストリームの拒否 オファー/アンサーモデルでは、アンサー側がメディアストリームを拒否する ことを望むとき、それのポート番号をゼロに設定する。プリコンディション が存在してもこの動作は変更されない。つまり、ストリームは依然として、 それのポート番号をゼロに設定することで拒否される。 オファー側とアンサー側双方は、ポート番号がゼロに設定されたストリーム に影響を及ぼすすべてのプリコンディションを無視しなければならない[MUST]。 それらは、セッション確立がレジュームできるかどうか決定するためには考 慮されない。 Camarillo, et. al. Standards Track [Page 14] RFC 3312 Integration of Resource Management and SIP October 2002 9 未知のプリコンディションタイプ 本文書は、QoSプリコンディションのために「qos」タグを定義する。将来定 義される新規precondition-typeは、それに関連付けられた新規タグを持つだ ろう。オファー中で「mandatory」というstrength-tagを持つ未知のprecondition-type を受信するUAは、未知のmandatoryプリコンディションだけが「local」タグ を持つのでないなら、そのオファーを拒否しなければならない[MUST]。この 場合UAは、プリコンディションを満たすために関与する必要はない。UAは、 プリコンディションの確認を依頼し、その確認が到着するときに、セッショ ン確立をレジュームする。 オファーを拒否するUAは、セクション8で述べられているルールに従うが、以 下の例に示されているように、「failure」タグの代わりに「unknown」タグ を使用する。 m=audio 20000 RTP/AVP 0 a=des:foo unknown e2e send 10 メディアストリーム1つあたり複数のプリコンディション 1つのメディアストリームは複数のプリコンディションを含んでもよい[MAY]。 異なるプリコンディションは、同一のprecondition-typeと異なるstatus-type を持つか(例：end to endとsegmentedのQoSプリコンディション)、あるいは 異なるprecondition-typeを持つか(本文書は「qos」というprecondition-type のみを定義するが、将来拡張で別のprecondition-typeを定義できる)してよ い[MAY]。 1つのメディアストリームに対するすべてのプリコンディションは、セッショ ン確立をレジュームするために、満たされなければならない[MUST]。以下の 例は、1つのメディアストリームに対してend-to-endとsegmented双方のstatus-type を使用するセッション記述を示す。 m=audio 20000 RTP/AVP 0 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=curr:qos e2e none a=des:qos optional e2e sendrecv Camarillo, et. al. Standards Track [Page 15] RFC 3312 Integration of Resource Management and SIP October 2002 11 プリコンディション用のオプションタグ RequireとSupportedヘッダーフィールドで使用するための「precondition」 というオプションタグを定義する。オファー側は、オファーが1つ以上の 「mandatory」strength-tagを含む場合、Requireヘッダーフィールドにこの タグを含めなければならない[MUST]。記述中のすべてのstrength-tagが 「optional」か「none」の場合、オファー側はSupportedまたはRequireヘッ ダーフィールドのどちらかにこのタグを含めなければならない[MUST]。しか しながら、この場合にはSupportedヘッダーフィールドを使用することが推奨 される。アンサー中にプリコンディションがないことは、アンサー側がこの 拡張をサポートしないことを示すことになる。 SIPリクエストと応答に対するオファーとアンサーのマッピングは、参考文献 [5]で与えられているルールに従って行われる。したがって、SDPにプリコン ディションを含めるUAは、PRACKとUPDATEメソッドをサポートしなければなら ない[MUST]。結果としてそれは、Supportedヘッダーフィールドに「100rel」 タグ(参考文献[7])を含めなければならず[MUST]、「UPDATE」タグ(参考文献[5]) を持つAllowヘッダーフィールドを含めるべきである[SHOULD]。 12 能力表示 オファー/アンサーモデル(参考文献[4])は、能力を示すためのセッション記 述のフォーマットを説明する。このフォーマットはOPTIONSリクエストに対す る応答で使用される。プリコンディションをサポートするUAは、各メディア ストリームに対して、サポートするprecondition-typeを含むdesired status 行を追加するべきである[SHOULD]。これらの行は以下の例に示すように、 「none」というstrength-typeを持たなければならない[MUST]。 m=audio 0 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=des:foo none e2e sendrecv a=des:qos none local sendrecv 本文書が発行されたとき、「foo」というprecondition-typeは登録されてい なかったということに注意すること。これは、複数のprecondition-typeがあ る例を提示するために、上記のセッション記述で使用されている。 本フレームワークをサポートするUAは、OPTIONSリクエストに対する応答の Supportedヘッダーフィールドに「precondition」タグを追加するべきであ る[SHOULD]。 13 例 以下の例はend-to-endとsegmented双方のステータスタイプを対象とする。 Camarillo, et. al. Standards Track [Page 16] RFC 3312 Integration of Resource Management and SIP October 2002 13.1 End-to-endステータスタイプ 図2のコールフローはend-to-endステータスタイプを使用した基本的なセッシ ョン確立を示す。この例のSDP記述を以下に示す。 SDP1: Aは最初のオファーにend-to-endのQoSプリコンディションを含める。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SDP2: BはRSVPを使用するので、いつ「send」方向のリソースが利用可能にな るか知ることができる(ネットワークからRESVメッセージを受信するので)。 しかしながら、もう一方の方向の予約ステータスは知らない。Bはアンサーで、 相手UAであるAに「recv」方向のリソース予約に対する確認を要求する。 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv アンサー送信後、Bはメディアストリームのためのネットワークリソースの予 約を開始する。Aがこのアンサーを受信するとき(2)、Aは同様にリソース予約 を開始する。双方のUAはRSVPを使用しているので、AはBにPATHメッセージを 送信し、BはAにPATHメッセージを送信する。 時間が経つと、Bは予約を確認するRESVメッセージを受信する。しかしながら Bは、もう一方の方向のリソースが同様に予約されるまで待機する。なぜなら、 Bは何ら確認を受信しておらず、プリコンディションはまだ満たされていない からである。 SDP3: AがRESVメッセージを受信するとき、AはBに更新されたオファー(5)を 送信する。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv Camarillo, et. al. Standards Track [Page 17] RFC 3312 Integration of Resource Management and SIP October 2002 SDP4: Bは、リソース予約の現在のステータスを含むアンサー(6)で応答する (すなわち、sendrecv)。 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv この時点で、セッション確立はレジュームされ、Bは180(Ringing)応答(7)を 返す。 Camarillo, et. al. Standards Track [Page 18] RFC 3312 Integration of Resource Management and SIP October 2002 A B | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(4) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-------------(7) 180 Ringing---------------| | | |-----------------(8) PRACK----------------->| | | |<------------(9) 200 OK (PRACK)-------------| | | | | | | |<-----------(10) 200 OK (INVITE)------------| | | |------------------(11) ACK----------------->| | | | | 図2: end-to-endステータスタイプを使用する例 Camarillo, et. al. Standards Track [Page 19] RFC 3312 Integration of Resource Management and SIP October 2002 セッションの最中に、メディアを受信しているIPアドレスを変更することをA が望むとする。図3はこのシナリオを示す。 SDP1: Aはre-INVITE(1)にオファーを含める。Aは古いIPアドレス(192.0.2.1) でメディア受信を継続するが、新しいIPアドレス(192.0.2.2)でのメディア受 信も準備できている。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.2 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SDP2: Bはアンサーに「conf」アトリビュートを含める。Bは古いリモートIP アドレス(192.0.2.1)にメディアを送信し続ける。 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv SDP3: AがRESVメッセージを受信するとき、AはBに更新されたオファー(5)を 送信する。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.2 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv SDP4: Bは、プリコンディションが満たされたことを示す(current statusが 「sendrecv」)アンサー(6)で応答する。Bが新しいリモートIPアドレス (192.0.2.2)にメディアを送り始めるのはこのときである。 Camarillo, et. al. Standards Track [Page 20] RFC 3312 Integration of Resource Management and SIP October 2002 A B | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(4) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-----------(7) 200 OK (INVITE)-------------| | | |------------------(8) ACK------------------>| | | | | 図3: プリコンディションでのセッション修正 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv 13.2 Segmentedステータスタイプ 図4のコールフローはsegmentedステータスタイプを使用した基本的なセッシ ョン確立を示す。この例のSDP記述を以下に示す。 Camarillo, et. al. Standards Track [Page 21] RFC 3312 Integration of Resource Management and SIP October 2002 SDP1: Aは最初のオファーにlocalとremoteのQoSプリコンディションを含める。 最初のオファーを送信する前に、Aはアクセスネットワークでリソースを予約 する。これは、以下のSDPのlocalのcurrent statusで示される。 m=audio 20000 RTP/AVP 0 8 c=IN IP4 192.0.2.1 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv SDP2: Bはアクセスネットワークでリソースを予約し、すべてのプリコンディ ションが満たされたので、180(Ringing)応答(3)でアンサーを返す。 m=audio 30000 RTP/AVP 0 8 c=IN IP4 192.0.2.4 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv この応答を受信した後に、Aが、PCM u-lawとA-law(ペイロード8)両方ではな く、PCM u-law(ペイロード0)だけを使用しようと決心したとする。AはBに、 おそらくINVITEに対する200(OK) (5)を受信する前に、UPDATEを送信する。こ のSDPは以下のようになる。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv Bは、このオファーに対するアンサーを生成し、それをUPDATEに対する200(OK) に入れる。 この最後の、サポートするCODEC数を減らすためのオファー/アンサーは、 200(OK)応答が生成された後にUASに到着するかもしれない、ということに注 意すること。これは、サポートするCODEC数をAが削減する前にセッションが 確立されることを意味する。この状況を避けるために、UACは自身のlocal current statusを「sendrecv」に設定する前に、UAからの最初のアンサーを 待つことができる。 Camarillo, et. al. Standards Track [Page 22] RFC 3312 Integration of Resource Management and SIP October 2002 13.3 SIP応答中のオファー 図5のコールフローは、最初のオファーが信頼性のある1xx応答中にある場合 の基本的なセッション確立を示す。この例ではend-to-endステータスタイプ を使用する。この例のSDP記述を以下に示す。 最初のINVITE(1)はセッション記述を含まない。したがって、最初のオファー は信頼性のある183(Session Progress)応答でBによって送られる。 SDP1: Bは最初のオファーにend-to-endのQoSプリコンディションを含める。 BはRSVPを使用するので、いつ「send」方向のリソースが利用可能になるか知 ることができる(ネットワークからRESVメッセージを受信するので)。しかし ながら、もう一方の方向の予約ステータスは知らない。Bはアンサーで、相手 UAであるAに「recv」方向のリソース予約に対する確認を要求する。 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv SDP2: Aは183(Session Progress)応答に対するPRACKにアンサーを含める。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv Camarillo, et. al. Standards Track [Page 23] RFC 3312 Integration of Resource Management and SIP October 2002 A B | *** | | *R* | | *E* | | *S* | | *E* | | *R* | | *V* | | *A* | | *T* | | *I* | | *O* | | *N* | | *** | |-------------(1) INVITE SDP1--------------->| | *** | | *R* | | *E* | | *S* | | *E* | | *R* | | *V* | | *A* | | *T* | | *I* | | *O* | | *N* | | *** | |<----------(2) 180 Ringing SDP2-------------| | | |----------------(3) PRACK------------------>| | | |<-----------(4) 200 OK (PRACK)--------------| | | | | |<-----------(5) 200 OK (INVITE)-------------| | | |------------------(6) ACK------------------>| | | | | 図4: segmentedステータスタイプを使用する例 Camarillo, et. al. Standards Track [Page 24] RFC 3312 Integration of Resource Management and SIP October 2002 A B | | |----------------(1) INVITE----------------->| | | |<------(2) 183 Session Progress SDP1--------| | | |---------------(3) PRACK SDP2-------------->| | *** *** | |<-*R*--------(4) 200 OK (PRACK)-------*R*---| | *E* *E* | | *S* *S* | | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | |-------------(5) UPDATE SDP3----------***-->| | *** | |<--------(6) 200 OK (UPDATE) SDP4-----***---| | *** | | *** | | *** | |<-------------(7) 180 Ringing---------------| | | |-----------------(8) PRACK----------------->| | | |<------------(9) 200 OK (PRACK)-------------| | | | | | | |<-----------(10) 200 OK (INVITE)------------| | | |------------------(11) ACK----------------->| | | 図5: 1xx応答中の最初のオファーの例 アンサー送信後、Aはメディアストリームのためのネットワークリソースの予 約を開始する。Bがこのアンサー(3)を受信するとき、Bは同様にリソース予約 を開始する。双方のUAはRSVPを使用しているので、AはBにPATHメッセージを 送信し、BはAにPATHメッセージを送信する。 Camarillo, et. al. Standards Track [Page 25] RFC 3312 Integration of Resource Management and SIP October 2002 SDP3: AがRESVメッセージを受信するとき、AはBに更新されたオファー(5)を 送信する。 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 a=curr:qos e2e send a=des:qos mandatory e2e sendrecv SDP4: Bは、リソース予約の現在のステータスを含むアンサー(6)で応答する (すなわち、recv)。 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 a=curr:qos e2e recv a=des:qos mandatory e2e sendrecv 時間が経つと、Bは予約を確認するRESVメッセージを受信する。この時点で、 セッション確立はレジュームされ、Bは180(Ringing)応答(7)を返す。 14 セキュリティの考慮 セッションを確立する2つのUAの間にいるエンティティが、セッション確立を 不可能にするdesired-statusアトリビュートを追加するかもしれない。それ はまた、プリコンディションを満たさずにセッションが確立されるように、 current-statusパラメータの内容を修正することがあり得る。これらの攻撃 を避けるために、完全性保護(integrity protection)を使用できる。 プリコンディションを伝える認証されていないリクエストの受信時にリソー ス予約を実行するエンティティは、DoS攻撃の格好の標的である。プリコンデ ィションを含むリクエストは認証されるべきである[SHOULD]。 15 IANA条項 本文書は、メディアレベルの3つのSDPアトリビュート(desired-status、 current-status、conf-status)を定義する。それらのフォーマットはセクシ ョン4で定義されている。 本文書は、SIPとともにプリコンディションを使用するためのフレームワーク を定義する。このフレームワークで使用されるprecondition-typeは、Standards Track RFCとして発行されるときに、IANAによって登録される。RFCの「IANA 条項」セクションは、発表されるRFCの番号と共にIANAレジストリに現れる、 以下の情報を含まなければならない[MUST]。 Camarillo, et. al. Standards Track [Page 26] RFC 3312 Integration of Resource Management and SIP October 2002 o precondition-typeの名称。名称はどのような長さでもよい[MAY]が、 10文字以下であるべきである[SHOULD]。 o 拡張を説明する説明文。 当面のエントリは以下のものだけである。 Pecondition-Type Reference Description ---------------- --------- ----------- qos RFC 3312 Quality of Service preconditions 本文書は、新規SIPステータスコード(580)も定義する。これのデフォルトの 理由フレーズはセクション8で定義されている。 本文書は、セクション11でSIPオプションタグ(precondition)を定義する。 16 知的所有権に関する注記 IETFは本文書に含まれる仕様の一部またはすべてに関する知的所有権請求の 通知を受けている。更なる情報については、オンラインの特許請求リストを 閲覧のこと。 17 参考文献 [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] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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, September 2002. [6] Schulzrinne, S., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. Camarillo, et. al. Standards Track [Page 27] RFC 3312 Integration of Resource Management and SIP October 2002 [8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," in Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), Mar. 2000. 18 貢献者 以下の人々が本仕様の初期バージョンに貢献してくれ、また共著者となって くれた。 K. K. Ramakrishnan (TeraOptic Networks)、Ed Miller (Terayon)、 Glenn Russell (CableLabs)、Burcak Beser (Pacific Broadband Communications)、Mike Mannette (3Com)、Kurt Steinbrenner (3Com)、 Dave Oran (Cisco)、Flemming Andreasen (Cisco)、Michael Ramalho (Cisco)、John Pickens (Com21)、Poornima Lalwaney (Nokia)、Jon Fellows (Copper Mountain Networks)、Doc Evans (D. R. Evans Consulting)、Keith Kelly (NetSpeak)、Adam Roach (dynamicsoft)、 Dean Willis (dynamicsoft)、Steve Donovan (dynamicsoft)、Henning Schulzrinne (Columbia University)。 多数の人々が著した本文書は、多くの個人(そのほとんどはここと以下の「謝 辞」セクションに列挙されている)による2年以上にわたる研究の成果である。 特に感謝したいのは、以前の非SIP準拠「2段階INVITE」プロポーザルからの、 最初の「単一INVITE」QoSプリコンディション研究を先導してくれた、Flemming Andreasen、Burcak Beser、Dave Boardman、Bill Guckel、Chuck Kalmanek、 Keith Kelly、Poornima Lalwaney、John Lawser、Bill Marshall、Mike Mannette、 Dave Oran、K.K. Ramakrishnan、Michael Ramalho、Adam Roach、Jonathan Rosenberg 、およびHenning Schulzrinneに対してである。この「2段階INVITE」プロポ ーザルは、PacketCableのDistributed Call Signaling研究が元になっている。 それは次に、AT&TのDistributed Open Systems Architecture (DOSA)研究(参 考文献[8])からアーキテクチャーの要素を得た。 19 謝辞 PacketCableプロジェクトのDistributed Call Signaling作業は、多くの異な る企業から集まった多数の人々からなる研究である。著者は以下の方々の支 援に理解と感謝をしたい。John Wheeler、Motorola；David Boardman、Daniel Paul、Arris Interactive；Bill Blum、Jay Strater、Jeff Ollis、Clive Holborow、 General Instruments；Doug Newlin、Guido Schuster、Ikhlaq Sidhu、3Com； Jiri Matousek、Bay Networks；Farzi Khazai、Nortel；John Chapman、Bill Guckel、Cisco；Chuck Kalmanek、Doug Nortz、John Lawser、James Cheng、 Tung-Hai Hsiao、Partho Mishra、AT&T；Telcordia Technologies；およびLucent Cable Communications。 Camarillo, et. al. Standards Track [Page 28] RFC 3312 Integration of Resource Management and SIP October 2002 Miguel Angel Garcia-Martin、Rohan Mahy、およびMark Watsonは役に立つコ メントと提案をしてくれた。 20 著者の連絡先 Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Bill Marshall AT&T Florham Park, NJ 07932 USA EMail: wtm@research.att.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Camarillo, et. al. Standards Track [Page 29] RFC 3312 Integration of Resource Management and SIP October 2002 21 完全な著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。 インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。 またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFCエディターの活動のための資金は、現在インターネットソサエティによっ て提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2002年 --------------------------------------------------------------------------- Camarillo, et. al. Standards Track [Page 30]