Network Working Group J. Rosenberg Request for Comments: 3262 dynamicsoft Category: Standards Track H. Schulzrinne Columbia U. June 2002 セッション開始プロトコル(SIP)の暫定応答の信頼性 Reliability of Provisional Responses in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書はインターネットコミュニティに対してInternet standards trackプ ロトコルの仕様を定めるものであり、改善のための議論と提案を求めるもの である。標準化の状況と本プロトコルのステータスについては、「Internet Official Protocol Standards (STD 1)」の最新版を参照のこと。本文書の配 布に制限はない。 著作権表記 Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 本文書は、信頼性のある暫定応答メッセージを提供する、SIPの拡張を規定す る。この拡張では、オプションタグ100relを使用し、Provisional Response ACKnowledgement (PRACK)メソッドを定義する。 目次 1 はじめに ............................................ 2 2 述語規則 ............................................ 3 3 UASの動作 ........................................... 3 4 UACの動作 ........................................... 6 5 オファー/アンサーモデルとPRACK ...................... 9 6 PRACKメソッドの定義 ................................. 10 7 ヘッダーフィールドの定義 ............................ 10 7.1 RSeq ................................................ 10 7.2 RAck ................................................ 11 8 IANA条項 ............................................ 11 8.1 100relオプションタグのIANAへの登録 .................. 11 8.2 RSeqおよびRAckヘッダーのIANAへの登録 ................ 12 9 セキュリティの考慮 .................................. 12 10 BNF集 ............................................... 12 11 謝辞 ................................................ 12 12 規範的な参考文献 .................................... 13 13 有益な参考文献 ...................................... 13 Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3262 Reliability of Provisional Responses in SIP June 2002 14 著者の連絡先 ........................................ 13 15. 完全な著作権表記 .................................... 14 1 はじめに SIP(RFC3261、参考文献[1])は、通話セッションを開始し管理するためのリク エスト/応答プロトコルである。SIPは暫定と最終の2つのタイプの応答を定義 する。最終応答は、リクエスト処理の結果を運び、信頼性を持って送信され る。暫定応答は、リクエスト処理の進捗情報を提供するが、RFC3261では信頼 性を持って送信されない。 PSTNとの相互運用を含め、いくつかのケースにおいて信頼性が重要であるこ とが後になってわかった。そのため、暫定応答の確実な送信をサポートする ためのオプションの能力が必要とされた。その能力が本仕様で提供される。 信頼性メカニズムは、INVITEに対する2xx最終応答の現在の信頼性メカニズム を真似ることにより機能する。UACが2xxを受信したことを示す別個のトラン ザクション(ACK)が受信されるまで、リクエストはトランザクションユーザー (TU)によって定期的に送信される。INVITEおよびACKメッセージに対する2xx 応答の信頼性はエンドツーエンドである。暫定応答に対する信頼性を実現す るために、それとほぼ同じことを行う。信頼性のある暫定応答は、指数関数 的に増加する間隔でTUが再送する。この再送は、PRACKメッセージを受信した ときに停止する。PRACKリクエストはACKと同じ役割を演じるが、ACKとは違い、 暫定応答に対して送られる。その一方で、重要な相違がある。PRACKはBYEと 同様、通常のSIPメッセージである。したがって、それ自体の信頼性は各ステ ートフルプロキシを介してホップバイホップで保証される。ACKとは違い、 BYEと同様に、PRACKにはそれ自身に対する応答がある。そうでなければ、 PRACKメッセージは、RFC2543(参考文献[4])に準拠するプロキシサーバーをト ラバースできない。 各暫定応答はシーケンス番号を与えられ、それは応答中のRSeqヘッダーフィ ールドで運ばれる。PRACKメッセージは、ackowledgeされる暫定応答のシーケ ンス番号を示すRAckヘッダーフィールドを含む。ネットワークの混雑を制御 するために、acknowledgementは累積せず、本仕様では未解決の暫定応答を 一度に1つだけにすることを推奨する。 Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3262 Reliability of Provisional Responses in SIP June 2002 2 述語規則 本文書では、次のキーワードはRFC2119(参考文献[2])に記述されているとお りに解釈され、SIPに準拠した実装のための要求レベルを示す。 「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、 「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および 「OPTIONAL」 3 UASの動作 UASは、最初のINVITEリクエスト(暫定応答が信頼性を持って送信されるリクエ スト)がオプションタグ100relを持つSupportedヘッダーフィールドを含んでさ えいれば、INVITEに対してどのような非100暫定応答でも信頼性を持って送っ てもよい[MAY]。本仕様ではINVITE以外のいかなるメソッドに対しても信頼性 のある暫定応答を許可していない。しかし、ダイアログを確立可能な新規メソ ッドを定義する拡張はこのメカニズムを使用できる。 UASは、最初のリクエストがオプションタグ100relを持つRequireヘッダーフ ィールドを含む場合、すべての非100暫定応答を信頼性を持って送信しなけれ ばならない[MUST]。UASがそうすることを望まない場合は、最初のリクエスト を、オプションタグ100relを持つUnsupportedヘッダーフィールドを含む420 (Bad Extension)で拒否しなければならない[MUST]。 UASは100(Trying)応答を信頼性を持って送信しようとしてはならない[MUST NOT]。 101から199の暫定応答だけを信頼性を持って送ることができる。リクエスト がこの機能を示すSupportedまたはRequireヘッダーフィールドを含まない場 合、UASは暫定応答を信頼性を持って送ってはならない[MUST NOT]。 100(Trying)応答はホップバイホップのみである。このため、ここで記述され ている信頼性メカニズム（エンドツーエンド）は使用できない。 プロキシとして動作可能なエレメントも、信頼性のある暫定応答を送信でき る。この場合、それはそのトランザクションにおいてUASとして動作する。し かしながら、それは、Toフィールドにタグを含むリクエストに対してそうし ようとしてはならない[MUST NOT]。すなわち、プロキシはダイアログのコン テキスト内で送られたリクエストに対して信頼性のある暫定応答を生成でき ない。当然ながら、UASとは違い、プロキシエレメントが信頼性がある未解決 の暫定応答にマッチしないPRACKを受信したときは、そのPRACKはプロキシさ れなければならない[MUST]。 UASが信頼性のある暫定応答を送信することを望む理由がいくつかある。一つ の理由として、INVITEトランザクションが最終応答を生成するまでに時間を 要する場合がある。RFC3261のセクション13.3.1.1で議論されているように、 UASはプロキシでのトランザクションの「延長」を要求するために、定期的に 暫定応答を送る必要がある。プロキシはそれらを3分毎に受信することが必要 になるが、パケットロスの可能性があるのでUASはそれらをもっと頻繁(1分毎 が推奨される)に送信する必要がある。 Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3262 Reliability of Provisional Responses in SIP June 2002 より効果的な代替策として、UASは応答を信頼性を持って送ることができる。 この場合、UASは2分30秒に1回、暫定応答を送るべきである[SHOULD]。トラン ザクションを延長するために信頼性のある暫定応答を利用することが推奨さ れる[RECOMMENDED]。 これ以降本文書では、最初のリクエストが100relを持つSupportedまたは Requireヘッダーフィールドを含み、信頼性を持って送信される暫定応答があ ることを前提とする。 信頼性を持って送信される暫定応答は、RFC3261のセクション8.2.6の手順に 従ってUASコアが構築する。トランザクション中の最初の信頼性のある暫定応 答のためのヘッダーフィールド値は、1から2**31 - 1のあいだでなければな らない[MUST]。この範囲から均等に選択されることが推奨される[RECOMMENDED]。 RSeq番号空間は、単一のトランザクション内に存在する。これは、異なるリク エストに対する暫定応答がRSeq番号に同じ値を使用してもよい[MAY]ことを意 味する。 信頼性のある暫定応答はボディを含んでもよい[MAY]。セッション記述の 用法はセクション5で述べられている。 信頼性のある暫定応答は、T1秒で始まり再送のたびに倍になる時間間隔で、 定期的にトランザクションレイヤーに渡される(T1はRFC3261のセクション17 で定義されている)。サーバートランザクションに渡されるとすぐに、それは、 acknowledgeされていない信頼性のある暫定応答の内部リストに追加される。 トランザクションレイヤーはUASコアから渡されたそれぞれの再送を転送 (forward)する。 これは、T2秒が時間間隔の上限になる2xx応答の再送とは異なる。これは、 ACKの再送は2xxの受信によって引き起こされるが、PRACKの再送は1xxの受信 とは無関係に起こるためである。 信頼性のある暫定応答の再送は、UAコアがマッチするPRACKを受信したときに 停止する。PRACKはダイアログ内の他のすべてのリクエストと同様であり、 RFC3261のセクション8.2およびセクション12.2.2の手順に従ってUASコアが処 理する。マッチするPRACKとは、応答と同じダイアログ内にあり、それのメソ ッド、CSeq-num、およびRAckヘッダーフィールドのresponse-numが、それぞ れ、CSeqのメソッド、CSeqのシーケンス番号、および信頼性のある暫定応答 のRSeqのシーケンス番号にマッチするものとして定義される。 Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3262 Reliability of Provisional Responses in SIP June 2002 acknowledgeされていないどの信頼性のある暫定応答にもマッチしないPRACK リクエストをUAコアが受信した場合、UASはそのPRACKに481応答で応答しなけ ればならない[MUST]。PRACKが、acknowledgeされていない信頼性のある暫定 応答にマッチする場合、それは2xx応答で応答されなければならない[MUST]。 この時点でUASは、暫定応答が正常に受信されたことを確信できる。それは、 信頼性のある暫定応答の再送を停止するべきであり[SHOULD]、それを acknowledgeされていない暫定応答のリストから削除しなければならない[MUST]。 対応するPRACKを受信することなく、信頼性のある暫定応答が64*T1秒のあい だ再送された場合、UASはオリジナルリクエストを5xx応答で拒否するべきで ある[SHOULD]。 PRACKがセッション記述を含んでいた場合、それは本文書のセクション5で述 べられている手順で処理される。PRACKがそれ以外のタイプのボディを含んで いた場合、そのボディは、ACKのボディが処理されるのと同じ方法で処理され る。 リクエストに対する最初の信頼性のある暫定応答がacknowledgeされた後、 UASは追加の信頼性のある暫定応答を送信してもよい[MAY]。UASは最初の信頼 性のある暫定応答がacknowledgeされるまで、2番めの信頼性のある暫定応答を 送信してはならない[MUST NOT]。最初の信頼性のある暫定応答の後、前回のも のがacknowledgeされるまで、UASは追加の信頼性のある暫定応答を送信しない ことが推奨される[RECOMMENDED]。最初の信頼性のある暫定応答は、イニシャ ルシーケンス番号を運ぶので、特別な扱いを受ける。最初のものが acknowledgeされる前に、追加の信頼性のある暫定応答が送信された場合、こ れらが順番に受信されたかどうかUASは確証できない。 同一のリクエストに対するそれ以降のそれぞれの信頼性のある暫定応答中の RSeq値は、正確に1ずつ大きくなければならない[MUST]。RSeq番号は繰り返し (wrap around)てはならない[MUST NOT]。最初の値が 2**31 - 1 未満になる ように選択され、最大値が 2**32 - 1 なので、一つのリクエストに対して最 大で 2*31 個の信頼性のある暫定応答を送信可能である。これは十分すぎる 数である。 UASは、最終応答が2xxで、acknowledgeされていないどの信頼性のある暫定応 答もセッション記述を含んでいない限り、すべてのacknowledgeされていない 信頼性のある暫定応答に対するPRACKを受信する前に、最初のリクエストに対 して最終応答を送信してもよい[MAY]。最終応答が2xxで、acknowledgeされて いない信頼性のある暫定応答のいずれかがセッション記述を含んでいる場合、 UASはそれらの暫定応答がacknowledgeされるまで、最終応答を送信してはなら ない[MUST NOT]。信頼性のある応答がまだacknowledgeされていないときに UASが最終応答を送信する場合、UASはacknowledgeされていない信頼性のある 暫定応答の再送を継続するべきではない[SHOULD]が、UASはそれらの未解決の 応答に対するPRACKを処理することに備えなければならない[MUST]。UASは、リ クエストに対して最終応答を送信した後に、(acknowledgeされていないものに 対する再送とは対照的に)新規の信頼性のある暫定応答を送信してはならない [MUST NOT]。 Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3262 Reliability of Provisional Responses in SIP June 2002 4 UACの動作 UACが新規リクエストを生成するとき、そのリクエストに対する暫定応答の信 頼性のある配送を要求することができる。それを行うためにUACは、オプショ ンタグ100relを持つRequireヘッダーフィールドをリクエストに挿入する。 値100relを持つRequireヘッダーは、INVITE以外のいかなるリクエストにも存 在してはならない[MUST NOT]。しかし、SIPの拡張で、他のリクエストメソッ ドでの使用を許可するかもしれない。 Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3262 Reliability of Provisional Responses in SIP June 2002 Header field where PRACK ___________________________________ Accept R o Accept 2xx - Accept 415 c Accept-Encoding R o Accept-Encoding 2xx - Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx - Accept-Language 415 c Alert-Info R - Alert-Info 180 - Allow R o Allow 2xx o Allow r o Allow 405 m Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info - Contact R - Contact 1xx - Contact 2xx - Contact 3xx o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length t Content-Type * CSeq c m Date o Error-Info 300-699 o Expires - From c m In-Reply-To R - Max-Forwards R m Min-Expires 423 - MIME-Version o Organization - 表1: ヘッダーフィールドのまとめ(A〜O) Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3262 Reliability of Provisional Responses in SIP June 2002 Header field where PRACK __________________________________________ Priority R - Proxy-Authenticate 407 m Proxy-Authenticate 401 o Proxy-Authorization R o Proxy-Require R o Record-Route R o Record-Route 2xx,18x o Reply-To - Require c Retry-After 404,413,480,486 o 500,503 o 600,603 o Route R c Server r o Subject R - Supported R o Supported 2xx o Timestamp o To c m Unsupported 420 m User-Agent o Via c m Warning r o WWW-Authenticate 401 m 表2: ヘッダーフィールドのまとめ(P〜Z) UACが、信頼性のある暫定応答の使用を要求することを望まないが、UASがそ の送信を必要とする場合にそれをサポートしていることを単に示すことを望 む場合、オプションタグ100relを持つSupportedヘッダーをリクエストに含め なければならない[MUST]。UACはすべてのINVITEリクエストにこれを含めるべ きである[SHOULD]。 最初のリクエストに対する暫定応答を受信し、その応答がオプションタグ100rel を持つRequireヘッダーフィールドを含む場合、応答は信頼性を持って送られ ることになる。応答が(101から199ではなく)100(Trying)である場合、このオ プションタグは無視しなければならず[MUST]、以下の手順を使用してはなら ない[MUST NOT]。 Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3262 Reliability of Provisional Responses in SIP June 2002 ダイアログがまだ生成されていない場合、暫定応答はダイアログを確立しな ければならない[MUST]。 応答が信頼性を持って送信されることを前提とすると、UACはメソッドPRACKで 新規リクエストを生成しなければならない[MUST]。このリクエストは暫定応答 に関連付けられたダイアログ内で送信される(実際には、この暫定応答がダイ アログを生成したのかもしれない)。PRACKリクエストは、ボディを含んでもよ い[MAY]。このボディは、そのtypeとdispositionに従って解釈される。 PRACKはダイアログ内の他の非INVITEリクエストと同様であるということに注 意すること。特に、UACは、acknowledgeされることになる暫定応答の再送を 受信するときは、(プロトコルエラーを引き起こすわけではないが)PRACKリク エストを再送するべきではない[SHOULD NOT]。 信頼性のある暫定応答を受信するとすぐに、その応答の再送を破棄しなけれ ばならない[MUST]。応答のダイアログID、CSeq、およびRSeqがオリジナルの 応答にマッチするとき、その応答は再送である。UACは、最初のリクエストに 対して最近受信した、順番どおりの信頼性のある暫定応答を示すシーケンス 番号を保持しなければならない[MUST]。このシーケンス番号は、最初のリク エストに対して最終応答を受信するまで保持しなければならない[MUST]。そ れの値は、最初のリクエストに対して受信した最初の信頼性のある暫定応答 中のRSeqヘッダーフィールドで初期化されなければならない[MUST]。 その同じ最初のリクエストに対するこれ以降の信頼性のある暫定応答のハン ドリングは、次の相違を除き、上記と同じルールに従う。 信頼性のある暫定応答は順番どおりであることが保証されている。 結果として、UACが同じリクエストに対する別の信頼性のある暫定応答を受信 し、それのRSeq値がシーケンス番号値より1だけ大きい値でない場合、その応 答はPRACKでacknowledgeされてはならず[MUST NOT]、そのUACで更に処理を継 続してはならない[MUST NOT]。実装は、その応答を破棄してもよいし[MAY]、 あるいは、欠落した応答を受信することを期待してその応答をキャッシュして もよい[MAY]。 UACは、最終応答後に受信した信頼性のある暫定応答をacknowledgeしてもよい し[MAY]、あるいは、破棄してもよい[MAY]。 5 オファー/アンサーモデルとPRACK RFC3261では、オファーおよびアンサー(参考文献[3])が現れるメッセージの セットに対するガイドラインが記述されている。そのガイドラインに基づい て、本拡張ではオファー/アンサー交換に別の機会を提供する。 INVITEがオファーを含む場合、UASは信頼性のある暫定応答中にアンサーを生 成してもよい[MAY](これがUACでサポートされていると仮定している)。これに より、呼が完了する前にセッションが確立することになる。 Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3262 Reliability of Provisional Responses in SIP June 2002 同様に、信頼性のある暫定応答が、UACに送り返された最初の信頼性があるメ ッセージであり、INVITEがオファーを含まなかった場合、その信頼性がある 暫定応答中にそれが現れなければならない[MUST]。 UACがオファーを含む信頼性のある暫定応答を受信する場合(UACがオファーを 含まないINVITEを送信した場合にこれが起こる。この場合、最初の信頼性のあ る暫定応答がオファーを含む)、それはPRACK中にアンサーを生成しなければな らない[MUST]。UACがアンサーを含む信頼性のある暫定応答を受信する場合、 それはPRACK中に追加のオファーを生成してもよい[MAY]。UASがオファーを含 むPRACKを受信する場合、それはPRACKに対する2xx中にアンサーを含めなけれ ばならない[MUST]。 たとえオリジナルのINVITEが応答されていなくとも、UAはアンサーを送信あ るいは受信するとすぐに、オファーおよびアンサーのパラメータに基づいて セッションを確立するべきである[SHOULD]。 INVITEが受け入れられたときに、まだacknowledgeされていない信頼性のある 暫定応答のどれかの中にUASがセッション記述を含めていた場合、UASはその 暫定応答がacknowledgeされるまで2xxの送信を遅らせなければならない[MUST]。 そうしなければ、1xxの信頼性は保証されず、オファー/アンサー交換の適切 な運用のために信頼性が必要とされる。 本拡張をサポートするすべてのユーザーエージェントは、RFC3261のセクショ ン13.2のルールに基づいて可能なすべてのオファー/アンサー交換、リクエス トとしてのINVITEとPRACKおよび非失敗の信頼性のある応答としての2xxおよ び信頼性のある1xxに基づいて可能なすべてのオファー/アンサー交換をサポ ートしなければならない[MUST]。 6 PRACKメソッドの定義 本仕様では新規SIPメソッド、PRACKを定義する。このメソッドのセマンティ クスは上に記述されている。表1および表2は、この新規メソッドのためにRFC 3261の表2および表3を拡張したものである。 7 ヘッダーフィールドの定義 本仕様では2つの新規ヘッダーフィールド、RAckとRSeqを定義する。表3は、 これらのヘッダーのためにRFC3261の表2および表3を拡張したものである。 7.1 RSeq RSeqヘッダーは、暫定応答を信頼性を持って送信するために、暫定応答中で 使用する。それは 1 から 2**32 - 1 のあいだの数値を一つ含む。用法につ いての詳細はセクション3を参照のこと。 Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3262 Reliability of Provisional Responses in SIP June 2002 例: RSeq: 988789 Header field where proxy ACK BYE CAN INV OPT REG PRA ______________________________________________________ RAck R - - - - - - m RSeq 1xx - - - o - - - 表3: RAckおよびRSeqヘッダーフィールド 7.2 RAck RAckヘッダーは、暫定応答の信頼性をサポートするために、PRACKリクエスト で送信される。それは2つの数字と1つのメソッドタグを含む。最初の数字は、 acknowledgeされることになる暫定応答のRSeqヘッダーからの値である。次の 数字およびメソッドは、acknowledgeされることになる応答のCSeqからコピー される。RAckヘッダー中のメソッド名は大文字小文字を区別する。 例: RAck: 776656 1 INVITE 8 IANA条項 本文書では、RFC3261のIANA登録プロセスに基づいて、1つの新規オプション タグ、および2つの新規ヘッダーを登録する。 8.1 100relオプションタグのIANAへの登録 本仕様では、1つのオプションタグ、100relを登録する。この登録のために、 RFC3261で規定されている必要情報は以下のとおりである。 名称: 100rel 説明:このオプションタグは暫定応答の信頼性のためのものである。 Supportedヘッダー中に存在するときは、UAが信頼性のある暫定応答を 送信または受信可能なことを示す。リクエストのRequireヘッダー中に 存在するときは、UASがすべての暫定応答を信頼性を持って送信しなけ ればならない[MUST]ことを示す。信頼性のある暫定応答のRequireヘッ ダー中に存在するときは、応答が信頼性を持って送信されることを示 す。 Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3262 Reliability of Provisional Responses in SIP June 2002 8.2 RSeqおよびRAckヘッダーのIANAへの登録 以下は、RSeqヘッダーの登録内容である。 RFC番号: RFC3262 ヘッダー名: RSeq コンパクトフォーム: なし 以下は、RAckヘッダーの登録内容である。 RFC番号: RFC3262 ヘッダー名: RAck コンパクトフォーム: なし 9 セキュリティの考慮 PRACKリクエストは、信頼性のある暫定応答を強制的に停止させるために、攻 撃者によって注入されることがあり得る。これらの応答は重要な情報を伝え ることがあるので、PRACKメッセージは、他のすべてのリクエストと同様に、 認証されるべきである[SHOULD]。認証手順はRFC3261で規定されている。 10 BNF集 ここでは、RAckとRSeqヘッダー、およびPRACKメソッドのBNFを定義する。 PRACKm = %x50.52.41.43.4B ; PRACKは大文字 Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm / extension-method RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGIT CSeq-num = 1*DIGIT RSeq = "RSeq" HCOLON response-num 11 謝辞 本文書へのコメントに対して、Jo Hornsby、Jonathan Lennox、Rohan Mahy、 Allison Mankin、Adam Roach、およびTim Schroederに感謝したい。 Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3262 Reliability of Provisional Responses in SIP June 2002 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 SDP", RFC 3264, June 2002. 13 有益な参考文献 [4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. 14 著者の連絡先 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: schulzrinne@cs.columbia.edu Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3262 Reliability of Provisional Responses in SIP June 2002 15. 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2003年 --------------------------------------------------------------------------- Rosenberg & Schulzrinne Standards Track [Page 14]