Network Working Group D. Yon Request for Comments: 4145 Tactical Software, LLC Category: Standards Track G. Camarillo Ericsson September 2005 セッション記述プロトコル(SDP)におけるTCPベースのメディアトランスポート (TCP-Based Media Transport in the Session Description Protocol (SDP)) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書は、セッション記述プロトコル(Session Description Protocol/SDP)を 使用してTCP上のメディアトランスポートを表現する方法について説明する。 また、SDPの「TCP」プロトコル識別子、SDPの「setup」属性(接続のセット アッププロシージャを記述)、およびSDPの「connection」属性(接続の確立を 処理)を定義する。 Yon & Camarillo Standards Track [Page 1] RFC 4145 Connection-Oriented Media September 2005 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. プロトコル識別子 . . . . . . . . . . . . . . . . . . . . . . . 3 4. setup属性 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. オファー/アンサーモデルのsetup属性 . . . . . . . . . . . 4 5. connection属性 . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. オファー側の動作 . . . . . . . . . . . . . . . . . . . . 6 5.2. アンサー側の動作 . . . . . . . . . . . . . . . . . . . . 7 6. 接続の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. 接続の確立 . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. 接続の再確立 . . . . . . . . . . . . . . . . . . . . . . 8 6.3. 接続の終了 . . . . . . . . . . . . . . . . . . . . . . . 8 7. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Passive/Active . . . . . . . . . . . . . . . . . . . . . 9 7.2. Actpass/Passive . . . . . . . . . . . . . . . . . . . . 9 7.3. 既存の接続の再利用 . . . . . . . . . . . . . . . . . . . 10 7.4. 既存の接続の拒否 . . . . . . . . . . . . . . . . . . . . 10 8. 他の接続指向トランスポートプロトコル . . . . . . . . . . . . . 11 9. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 12 10. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 13 12.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 13 Yon & Camarillo Standards Track [Page 2] RFC 4145 Connection-Oriented Media September 2005 1. はじめに セッション記述プロトコル[4]は、告知または招待でマルチメディアセッショ ンを記述するために、汎用的な形式を提供している。SDPは、完全にテキスト のデータ形式(UTF-8 [11]のUS-ASCIIサブセット)を使用し、トランスポートに 関するポータビリティを最高にする。SDPではプロトコルを定義していない。 SDPで定義しているのは、マルチメディアセッションを、そのセッションに参 加するために必要な情報と共に記述する構文である。セッション記述は、トラ ンスポート用の任意の既存アプリケーションプロトコルを使用して送信するこ とができる(SAP [9]、SIP [10]、RTSP [6]、email、HTTP [8]など)。 SDP [4]では、RTP/AVPとUDPという2つのプロトコル識別子を定義している。い ずれも、信頼関係のないコネクションレスプロトコルを表す。これらのトラン スポートは、マルチメディアストリームには適切な選択だが、TCPの方がより 適切なアプリケーションもある。本文書では、SDPでTCP接続を記述するために 新しいプロトコル識別子「TCP」を定義する。 TCPでは、セッションを記述するために2つの新しい要因を導入する。つまり、 TCP接続のセットアッププロシージャを実行する方法、およびタイミングであ る。本文書では、TCP接続のセットアップを記述するために、「setup」と 「connection」という新しい属性を2つ定義する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」はRFC2119の BCP 14 [3]に記載されるとおりに解釈されるべきであり、CPL準拠の実装のた めの実装レベルを示すものである。 3. プロトコル識別子 RFC 2327 [4]で規定されている「m」行のABNFを次に示す。 media-field = "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF 本文書は、protoフィールドの新しい値「TCP」を定義する。 「TCP」プロトコル識別子は、トランスポートプロトコルを記述しているだけ で上層のプロトコルについては記述していないという点で、「UDP」プロトコ ル識別子と似ている。「m」行に「TCP」を指定する場合、fmt識別子を使用し Yon & Camarillo Standards Track [Page 3] RFC 4145 Connection-Oriented Media September 2005 て、さらにアプリケーション層プロトコルに条件を付けなければならない [MUST]。「TCP」プロトコル識別子を含む「m」行を使用して記述されたメディ アは、TCP [1]を使用して伝達される。 4. setup属性 「setup」属性は、TCP接続の確立を開始すべき(つまり、最初のTCP SYNを送信 すべき)エンドポイントを指定する。「setup」属性は文字セットに依存せず、 セッションレベル属性またはメディアレベル属性のどちらにもなる。 「setup」属性のABNFを以下に示す。 setup-attr = "a=setup:" role role = "active" / "passive" / "actpass" / "holdconn" 「active」: エンドポイントは送信の接続を開始する。 「passive」: エンドポイントは、受信の接続を受け入れる。 「actpass」: エンドポイントは、受信の接続を受け入れる意思、または送信 の接続を開始する意思がある。 「holdconn」: エンドポイントは、一時的に、接続の確立を望まない。 4.1. オファー/アンサーモデルのsetup属性 RFC 3264 [5]で定義されているオファー/アンサーモデルは、エンドポイント に対してセッションの共有ビューを取得する手段を与えている。セッションパ ラメータの一部(使用するコーデックなど)はネゴシエートされ、他(IPアドレ スなど)は単にあるエンドポイントから他のエンドポイントへ通信される。 「setup」属性の値は、最初のカテゴリに区分される。つまり、双方のエンド ポイントは、オファー/アンサーモデルを使用してその値をネゴシエートす る。 「setup」属性値のネゴシエーションは、次のように実行される。オファーは 実行する意思のある役割(1つまたは複数)を主張し、アンサー側は(オファー側 の意思を考慮して)、接続の確立時に双方のエンドポイントが実際に実行する 役割を選択する。オファー/アンサーの交換で「setup」属性が使用できる値を 次に示す。 Yon & Camarillo Standards Track [Page 4] RFC 4145 Connection-Oriented Media September 2005 オファー アンサー ________________ active passive / holdconn passive active / holdconn actpass active / passive / holdconn holdconn holdconn activeのエンドポイントは、相手側エンドポイントの「m」行にあるポート番 号に対して接続を開始すべきである[SHOULD]。自身の「m」行にあるポート番 号は無関係であり、相手側エンドポイントは、その「m」行で指定されている ポート番号に対して接続の開始を試行してはならない[MUST NOT]。それでも、 「m」行には有効なポート番号が含まれるため、値「active」を使用するエン ドポイントは、その「m」行に9 (放棄ポート)というポート番号を指定すべき である[SHOULD]。エンドポイントは、拒否された、または拒否される「m」行 を示す場合を除き、ゼロのポート番号を指定してはならない[MUST NOT]。 passiveのエンドポイントは、「m」行で指定されたポート番号上で接続を受け 入れる準備をするべきである[SHOULD]。 「actpass」の値は、オファー側が、アンサーの「m」行にあるポート番号に対 する接続を開始すること、またはオファーの「m」行で指定されたポート番号 で接続を受け入れることができることを示す。つまり、オファー側には、接続 の受け入れるかどうかまたは開始するかどうかについて選択権がないため、ア ンサー側に選択させる。 「holdconn」の値は、一時的に接続を確立すべきではないことを示す。 オファー交換でのsetup属性のデフォルト値は、オファーでは「active」、ア ンサーでは「passive」である。 5. connection属性 セッションを開始するSDPを使用する場合に、「setup」属性に先行する記述が 配置される。それでも、セッションの終了、新しいエンドポイントに対するメ ディアのリダイレクト、セッションのメディアパラメータの再ネゴシエートな どのタスクを実現するために、多様なセッション段階でエンドポイント間で SDPを交換する場合がある。最初のセッションが確立された後に、以降のSDP交 換が、オブジェクトが現在のTCP接続を変更せずに使用し続ける確認を表す か、または新しいTCP接続を作成するリクエストを表すかについては不明確な 場合がある。メディアレベルの「connection」属性は文字セット依存だが、こ の2つの状況を明確にするために使用される。「connection」属性のABNFを以 下に示す。 Yon & Camarillo Standards Track [Page 5] RFC 4145 Connection-Oriented Media September 2005 connection-attr = "a=connection:" conn-value conn-value = "new" / "existing" 5.1. オファー側の動作 オファー側およびアンサー側が「connection」属性を使用するのは、新しいト ランスポート接続を確立する必要があるか、または反対に既存のTCP接続をそ のまま使用するかについて決定する場合である。オファー側は、TCPを使用す る「m」行を生成する場合、「m」行を使用するアプリケーションに接続確立を 処理する他の手段がなければ、「m」行にconnection属性を提供すべきである [SHOULD]。 最初のオファー/アンサー交換後は、セッションの何らかの特性(direction属 性など)を変更するときに、任意のエンドポイントが新しいオファーを生成す ることができる。このようなオファー側が、「m」行の確立済みのトランス ポート層の接続を使用し続けたい場合、オファー側は「m」行に「existing」 のconnection値を使用しなければならない[MUST]。反対に、オファー側が 「m」行に新しいトランスポート層接続を確立したい場合、「new」の connection値を使用しなければならない[MUST]。 ただし、この接続の規則に従って、「m」行のトランスポートアドレス(IP アドレスまたはポート番号)を交換するオファーには、「new」の connection値が含まれるということに注意。同様に、最初のオファー(つま り、まだトランスポート接続が確立していない場合)の「connection」属性 では、「new」の値を使用する。 オファー/アンサー交換の結果による「connection」値は、アンサーの 「connection」値である。アンサーの「connection」値が「new」の場合、エ ンドポイントは新しい接続を確立すべきである[SHOULD]。アンサーの 「connection」値が「existing」の場合、エンドポイントは既存の接続を使用 し続けるべきである[SHOULD]。 セクション5.2の規則を考慮して、オファー/アンサー交換で「connection」属 性に使用できる値を次に示す。 オファー アンサー ________________ new new existing existing / new オファー/アンサー交換の結果の「connection」値が「existing」の場合、エ ンドポイントは既存の接続を使用し続ける。最終的に、オファー/アンサー交 換でネゴシエートされるポート番号、IPアドレス、および「setup」属性は、 新しい接続を確立する必要はないため、無視される。 Yon & Camarillo Standards Track [Page 6] RFC 4145 Connection-Oriented Media September 2005 前述の規則が意味するところは、「existing」のconnection値と「passive」 のsetup値を含むオファーを生成するオファー側は、万が一アンサーについて 「new」のconnection値をアンサー側が選択する場合に、アンサー側からの接 続リクエストを受信する準備する必要がある(つまり、リソースを割り当てる 必要がある)。ただし、アンサー側は、アンサーにある「existing」の connection値を使用する場合、オファー側は、接続リクエストが受信されな かったために使用されなかった割り当て済みリソースを割り当て解除する必要 がある。 リソースの不必要な割り当てを回避するために、オファーに「existing」の connection値を使用するオファー側は、「holdconn」のsetup値を使用しても よい。それでも、この方針を使用するオファー側は、アンサー側が「new」の connection値を選択する場合、「holdconn」以外のsetup値を含む新しいオ ファー/アンサー交換(一般的に以前のオファー側が開始したもの)は、新しい 接続を確立する必要がある。当然ながら、これによってTCP接続を使用するア プリケーションで遅延が発生する可能性がある。 オファーとアンサーのどちらも、connection属性のデフォルト値は「new」で ある。 5.2. アンサー側の動作 「m」行のconnection値は、オファー/アンサーモデルを使用してネゴシエート される。オファー/アンサー交換の結果による「connection」値は、アンサー の「connection」値である。オファーのconnection値が「new」の場合、アン サー側はアンサーにも「new」の値を使用しなければならない[MUST]。オ ファーのconnection値が「existing」の場合、アンサー側は、既存の接続を使 用し付けたいときはアンサーに「existing」の値を使用し、新しい接続を確立 したいときは「new」の値を使用する。 サードパーティ呼制御[12]を使用する一部のシナリオでは、エンドポイン トは「existing」のconnection値を含む最初のオファーを受信することが ある。前述の規則に従って、アンサー側はアンサーに「new」のconnection 値を使用する。 オファー/アンサー交換の結果による「m」行のconnection値が「new」の場 合、エンドポイントは、「setup」属性で指定されるとおりに、新しいTCP接続 を確立すべきである[SHOULD]。以前のTCP接続がまだ有効な場合、エンドポイ ントはオファー/アンサー交換が完了した後、できるだけ早くにその接続を閉 じるべきである[SHOULD]。2つのTCP接続間の適切なデータ動機を確実にする方 法は、アプリケーションに委ねられる。 オファー/アンサー交換の結果による「m」行のconnection値が「existing」の 場合、エンドポイントは既存のTCP接続を使用し続けるべきである[SHOULD]。 Yon & Camarillo Standards Track [Page 7] RFC 4145 Connection-Oriented Media September 2005 6. 接続の管理 このセクションでは、接続の確立、接続の再確立、および接続の終了について 扱う。 6.1. 接続の確立 オファー/アンサー交換によると新しいTCP接続を開始することになっているエ ンドポイントは、可能な場合はできるだけ早く開始すべきである[SHOULD]。こ れは、エンドポイントにリモートエンドポイントに対してメディア送信を直ち に送信する意思がない場合にも当てはまる。これによって、必要に応じてリ モートエンドポイントからメディアを流すことができる。 一部のエンドポイントは、接続を確立できるようになる前に発生するイベ ントの一部について、待機する必要がある、ということに注意。たとえ ば、無線端末は、TCP接続を開始できるようになる前に、場合によって無線 ベアラを設定する必要がある。 6.2. 接続の再確立 エンドポイントが「m」行のTCPを閉じ、再確立することを決定する場合、この 「m」行について「new」のconnection値を使用して新しいオファー/アンサー 交換を実行すべきである[SHOULD]。 SDPのdirection属性(「a=sendonly」など)は、TCP接続上で送信されるメ ディアを処理するが、TCP接続自体には影響がないということに注意。 6.3. 接続の終了 一般的に、セッションが期限切れになった場合、明示的に終了された場合、ま たは新しいconnection値が「m」行に指定された場合を除き、エンドポイント はTCP接続を閉じない。さらに、アプリケーションによっては、あるTCP接続を エンドポイントが閉じることができる(接続がhalf-closeステートにある場合 は常に、など)というシナリオを説明できる。TCP接続を終了する必要があると エンドポイントが通知するとすぐに、それを実行すべきである[SHOULD]。 いずれの場合でも、個々のアプリケーションで、ていねいな接続の終了を達成 する方法について、さらに考慮してもよい。たとえば、リモートエンドポイン トからFINを受信するときにTCPを使用するファイルアプリケーションは、場合 によって、自身のFINを送信する前に送信中のファイルを終了させる必要があ る。 Yon & Camarillo Standards Track [Page 8] RFC 4145 Connection-Oriented Media September 2005 7. 例 次の例では、最も一般的な「setup」属性とTCPベースのメディア記述の用法を 示す。簡潔にするために、セッション記述のメイン部分は例では省略し、 「m」行とその属性(「c」行も含む)のみを示す。 7.1. Passive/Active 192.0.2.2のオファー側は、ポート54111でT.38 faxセッションの可用性をシグ ナリングする。 m=image 54111 TCP t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:new このオファーを受信する192.0.2.1のアンサー側は、次のアンサーで応答す る。 m=image 9 TCP t38 c=IN IP4 192.0.2.1 a=setup:active a=connection:new 192.0.2.1のエンドポイントは、192.0.2.2のポート54111にTCP接続を開始す る。 7.2. Actpass/Passive 別の例では、192.0.2.2にいるオファー側は、TCPポート54111でT.38 faxセッ ションの可用性をシグナリングする。さらに、このオファー側は、TCP接続を 開始することでメディアストリームをセットアップする意思もあるる m=image 54111 TCP t38 c=IN IP4 192.0.2.2 a=setup:actpass a=connection:new 192.0.2.1のエンドポイントは、次の記述で応答する。 m=image 54321 TCP t38 c=IN IP4 192.0.2.1 a=setup:passive a=connection:new Yon & Camarillo Standards Track [Page 9] RFC 4145 Connection-Oriented Media September 2005 これによって、オファー側(192.0.2.2)は192.0.2.1のポート54321に対して接 続を開始する。 7.3. 既存の接続の再利用 セクション7.2の交換に続いて、別のオファー/アンサー交換が反対方向で開始 される。192.0.2.1のエンドポイントは、既存の接続を使用し続けることを望 んでいる。 m=image 54321 TCP t38 c=IN IP4 192.0.2.1 a=setup:passive a=connection:existing 192.0.2.2のエンドポイントも既存の接続を使用することを望んでおり、次の 記述で応答する。 m=image 9 TCP t38 c=IN IP4 192.0.2.2 a=setup:active a=connection:existing 192.0.2.2から192.0.2.1への既存の接続が再使用される。 192.0.2.2のエンドポイントは、「setup:passive」のオファーに応答して 「setup:active」を使用し、ポート9を使用する(activeのため)ということ に注意。 7.4. 既存の接続の拒否 セクション7.3の交換に続き、192.0.2.2のエンドポイントが別のオファー/ア ンサー交換を開始する。この場合も、既存の接続を再使用することを望んでい る。 m=image 54111 TCP t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:existing ただし、今回のアンサー側は、古い接続を認識していないため、新しい接続を 確立したいと望んでいる(サードパーティ呼制御経由で転送されると、このよ うな結果になることがある)。「passive」モードで動作することができないた め、「active」として応答する。 Yon & Camarillo Standards Track [Page 10] RFC 4145 Connection-Oriented Media September 2005 m=image 9 TCP t38 c=IN IP4 192.0.2.3 a=setup:active a=connection:new 192.0.2.3のエンドポイントは、TCP接続を192.0.2.2のポート54111に対して開 始し、192.0.2.2のエンドポイントは古い接続を閉じる。 192.0.2.2のエンドポイントは、「existing」のconnection値を使用してい るが、「passive」のsetup値を使用しているということに注意。これが実 行されず、代わりに「holdconn」のsetup値を使用した場合(セクション5.1 で説明されたリソースの割り当てを回避する目的などで)、新しい接続を確 立するには新しいオファー/アンサー交換が必要になる。 8. 他の接続指向トランスポートプロトコル 本文書では、SDPを使用してTCPベースのメディアストリームを記述する方法に ついて規定している。それでも、本文書で定義される属性の一部は、他の接続 指向のトランスポートプロトコルに基づくメディアストリームを記述する場合 にも利用できる可能性がある。このセクションでは、TCP以外の接続指向のト ランスポートプロトコルを処理するSDP拡張仕様を作成するための指針を提示 する。 TCPとメディア自体の間にTCP以外のプロトコル層(TCP上のTLS [7]など)を伴 う、新しいSDPプロトコル識別子を定義する場合、文字列「TCP/」で開始する ことが推奨される(「TCP/TLS」など)。 「setup」属性と「connection」属性は、それぞれセクション4とセクション5 で規定されている。どちらの属性も、「TCP」プロトコル識別子を使用する 「m」行に適用することができるが、汎用的なので、他の接続指向トランス ポートプロトコルでも「m」行に再利用できる。したがって、新しいproto値 が接続指向のトランスポートプロトコルと関連付けられる場合、「setup」属 性と「connection」属性はできるだけ長く再使用することが推奨される。 セクション6では、TCP接続の管理を扱っている。TCPでは双方のエンドポイン トが接続を閉じる必要があるが、他の接続指向トランスポートプロトコルで は、half-close接続の概念を持っていない可能性がある、ということに注意。 このような場合、一方のエンドポイントが接続を閉じるとすぐに接続が終了す る。そのため、他方のエンドポイントは接続を終了する以降のアクションを実 行する必要はない。このようなトランスポートプロトコルを扱う仕様は、接続 の終了に関して、場合によってはやや異なるプロシージャを指定する必要があ る。 Yon & Camarillo Standards Track [Page 11] RFC 4145 Connection-Oriented Media September 2005 9. セキュリティの考慮事項 セッション記述プロトコルに固有のセキュリティや他の考慮事項について、全 般的にはRFC 2327 [4]を参照のこと。 攻撃者は、エンドポイントに不要な接続の再接続を実行させたり、エンドポイ ントが接続できないようにするために、connection属性とsetup属性の値を変 更しようとする場合がある。そのため、完全性の保護がSDPのセッション記述 に適用することが、強く推奨される[RECOMMENDED]。セッション記述をSIP [10]で伝達する場合、RFC 3261[10]に記載されているように、このようなエン ドツーエンドの完全性保護を実現するには、S/MIMEを選択するのが適切であ る。他のアプリケーションでは、別形式の完全性保護を使用してもよい [MAY]。 10. IANA条項 本文書では、setupとconnectionという、セッションレベルおよびメディアレ ベルSDP属性を2つ定義する。これらの形式は、それぞれセクション4とセク ション5で定義されている。これら2つの属性は、「att-field (both session and media level)」以下の「Session Description Protocol (SDP) Parameters」でIANAに登録される。 本文書ではTCPというproto値を定義する。形式はセクション3で定義されてい る。このproto値は、「proto」以下の「Session Description Protocol (SDP) Parameters」でIANAに登録される。 SDP仕様であるRFC 2327では、このRFCで定義されているTCPのproto値のよう な、新しいproto値を定義する仕様の場合、メディア形式(fmt)の名前空間を管 理する規則を定義する必要があると規定されている。TCPプロトコルについ て、新しい形式には関連するMIME登録を行うべきである[SHOULD]。この形式に 既存のMIMEサブタイプを使用することが推奨される。MIMEサブタイプが存在し ない場合、その形式のトランスポートプロトコルを定義する標準化過程のRFC を作成するか参照して、IETFの過程[2]を通じて適切なMIMEサブタイプを登録 することが推奨される。 11. 謝辞 Jonathan Rosenberg、Rohan Mahy、Anders Kristensen、Joerg Ott、Paul Kyzivat、Robert Fairlie-Cuninghame、Colin Perkins、Christer Holmbergか らは、貴重な考察と寄稿をいただいた。 Yon & Camarillo Standards Track [Page 12] RFC 4145 Connection-Oriented Media September 2005 12. 参考文献 12.1. 規範となる参考文献 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [2] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 12.2. 有益な参考文献 [6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [9] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [10] 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. [11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [12] 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. Yon & Camarillo Standards Track [Page 13] RFC 4145 Connection-Oriented Media September 2005 著者の連絡先 David Yon Tactical Software, LLC 1750 Elm St., Suite 803 Manchester, NH 03104 USA EMail: yon-comedia@rfdsoftware.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Yon & Camarillo Standards Track [Page 14] RFC 4145 Connection-Oriented Media September 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年 ----------------------------------------------------------------------- Yon & Camarillo Standards Track [Page 15]