Network Working Group G. Camarillo Request for Comments: 5368 Ericsson Category: Standards Track A. Niemi M. Isomaki Nokia M. Garcia-Martin Ericsson H. Khartabil Ericsson Australia October 2008 セッション開始プロトコル(SIP)における複数リソースの参照 Referring to Multiple Resources in the Session Initiation Protocol (SIP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過 程プロトコルを規定し、改善のための議論や提案を依頼するものである。 標準化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は 無制限である。 概要 本文書は、単一のリクエストで複数のリソースを参照するときに使用でき るように、SIP REFERメソッドの拡張を定義する。 この拡張には、Refer-ToヘッダーフィールドのURI (Uniform Resource Identifier)リストに対するポインタ、および"multiple-refer" SIPオプ ションタグの用法が含まれる。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 操作の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. multiple-refer SIPオプションタグ . . . . . . . . . . . . . . . 4 5. REFERの暗黙的サブスクリプションの抑制 . . . . . . . . . . . . 4 6. URIリスト形式 . . . . . . . . . . . . . . . . . . . . . . . . 5 7. SIP REFER発行端末の動作 . . . . . . . . . . . . . . . . . . . 6 8. REFER受信端末の動作 . . . . . . . . . . . . . . . . . . . . . 6 9. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 10 11. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 10 12.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 11 Camarillo, et al. Standards Track [Page 1] RFC 5368 SIP Multiple REFER October 2008 1. はじめに RFC 3261 (SIP) [RFC3261]は、REFERメソッドに関するRFC 3515 [RFC3515] で拡張されている。ユーザーエージェントはREFERメソッドを使用すること で、第2のUAに対して、サードパーティにSIPリクエストを送信するよう要 求することができる。たとえば、AliceがBobと通話中で、BobとCarolが話 す必要があると判断した場合、Aliceは自身のSIP UAに指示し、CarolのSIP コンタクト情報を提示してBobのUAにREFERリクエストを送信することがで きる。Bobが許可した場合、BobのUAはそのコンタクトを使用してCarolへの 発信を試みる。 つまり、BobのUAはINVITEリクエストをそのコンタクトに送信する。 多くのアプリケーションは、この第2のUAに対して、複数の宛先とのトラン ザクションを開始するように要求することを必須としている。一例を挙げ ると、カンファレンスのモデレータは、カンファレンスサーバーに対して、 BYEリクエストを参加者グループに送信するように希望する可能性がある。 また、カンファレンスのモデレータが、カンファレンスサーバーに対して、 新しい参加者グループをINVITEするように希望する例もある。 本文書では、REFERリクエストを使用して複数の宛先に対して、他のユー ザーエージェント(カンファレンスサーバーなど)を参照できるようにする REFERメソッドの拡張を定義する。さらに、このメカニズムでは、RFC 4488 [RFC4488]に規定されているREFERメソッドの暗黙的サブスクリプションの 抑制を使用する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119 [RFC2119]のBCP 14 に記載されるとおりに解釈されるべきであり、本文書に準拠する際の実装 レベルを示すものである。 本文書は、RFC 3261 [RFC3261]に定義されている以下の用語を再利用する。 o ユーザーエージェント(User Agent/UA) o ユーザーエージェントクライアント(User Agent Client/UAC) o ユーザーエージェントサーバー(User Agent Server/UAS) 本文書では、以下の新しい用語を定義する。 REFER発行端末(REFER-Issuer): REFERリクエストを発行するユーザーエー ジェント。 REFER受信端末(REFER-Recipient): REFERリクエストを受信者、SIPリクエ ストを複数のREFERターゲット端末に回送するエンティティ。REFER受信 端末は、一般的にURIリストサーバーなどのネットワークエンティティ であり、REFERリクエストのUAS、およびSIPリクエストのUACとして動作 する。 Camarillo, et al. Standards Track [Page 2] RFC 5368 SIP Multiple REFER October 2008 REFERターゲット端末(REFER-Target): REFER受信端末が生成したSIPリクエ ストの最終的な対象受信者のUA。 3. 操作の概要 本文書では、URIリストサービスがターゲットのリストを含むSIP REFERリ クエストを受信できるURIリストサービス[RFC5363]の応用について説明す る。URIリストサービスは、要求されたSIPメソッドをリストに含まれる各 ターゲットに対して呼び出す。 このタイプのURIリストサービスは、本文書ではREFER受信端末 (REFER-Recipient)と呼ぶ。 本文書は、RFC 3515 [RFC3515]に規定されているSIP REFERメソッドの拡張 を定義する。この拡張によって、SIP UACは、REFERリクエストにREFERター ゲット端末のURIリスト(RFC 4826 [RFC4826]で規定)を含め、REFER受信端 末に送信できるようになる。REFER受信端末は、URIリストの各エントリに ついて新しいSIPリクエストを作成し、各REFER受信端末に送信する。 送信者は、ターゲットリストを含むURIリストをRFC 5364 [RFC5364]と組み 合わせて使用することで、REFERターゲット端末をシグナリングで呼び出す 役割(たとえば、'to'、'cc'、匿名など)を示すことができる。 本文書では、RFC 4826 [RFC4826]の規定に従い、URIリストを使用して REFERリクエストの複数のターゲットを表現する。複数の宛先に対して REFER受信端末を参照させたいREFER発行端末は、SIP REFERリクエストを作 成する。Refer-Toヘッダーフィールドには、(ボディ部に含まれる)URIリス トへのポインタと、Requireヘッダーフィールドのオプションタグ" multiple-refer"が含まれる。このオプションタグは、本仕様で説明する機 能をサポートするための要件を示す。 REFER受信端末は、こうしたリクエストを受信した場合、REFERターゲット ごとに新しいリクエストを作成し、それを各REFERターゲットに送信する。 本文書は、REFER発行端末が複数のREFERターゲットを含むREFERリクエスト の結果について知ることができるメカニズムを一切提供しない。さらに、 SIP REFERメソッドの一部である暗黙的なサブスクリプションメカニズムも サポートしない。 REFER発行端末にREFERの結果について通知し続ける方法は、サービス固有 の問題である。たとえば、カンファレンスに複数の参加者を招待するREFER リクエストを送信するREFER発行端末は、RFC 4575 [RFC4575]に規定されて いるカンファレンスステートイベントパッケージにサブスクライブするこ とで、カンファレンスへの参加が成功した参加者を検出することができる。 Camarillo, et al. Standards Track [Page 3] RFC 5368 SIP Multiple REFER October 2008 4. multiple-refer SIPオプションタグ 本文書では、RequireおよびSupportedヘッダーフィールド用のSIPオプショ ンタグ"multiple-refer"を定義する。 ユーザーエージェントはSupportedヘッダーフィールドに"multiple-refer" オプションタグを含めることで、本仕様への準拠を示す。 Refer-ToヘッダーフィールドのURIリストに対するポインタを含むREFERを 生成するユーザーエージェントは、REFERのRequireヘッダーフィールドに" multiple-refer"を含めなければならない[MUST]。 5. REFERの暗黙的サブスクリプションの抑制 REFERターゲット(REFER-Target)が単一のREFERリクエストによって、参照 イベントに対するサブスクリプションが暗黙的に確立する。REFER発行端末 (REFER-Issuer)には、この暗黙的サブスクリプションを通じて、REFERター ゲットに対するトランザクションの結果について通知される。RFC 3515 [RFC3515]に記載されているように、REFERリクエストによって作成された 暗黙的サブスクリプションの結果として送信されたNOTIFYリクエストには、 タイプ"message/sipfrag" (RFC 3420 [RFC3420])のボディが含まれる。こ のボディには、REFER受信端末(REFER-Recipient)が開始したトランザク ションのステータスが記述される。 REFER発行端末が複数のREFERターゲット端末に対してREFERを生成する場合、 一般的に、REFER発行端末は、REFERターゲット端末に対するトランザク ションの結果について情報を提供できる他のイベントパッケージへすでに サブスクライブ済みである。たとえば、モデレータがカンファレンスサー バーに対してBYEリクエストを複数の参加者に送信するように指示する場合、 一般的に、そのモデレータはカンファレンスのカンファレンスステートイ ベントパッケージにサブスクライブしている。このイベントパッケージに 対する通知によって、モデレータとその他のサブスクライバは最新のカン ファレンス参加者リストを把握し続けることができる。 本文書で説明する複数のREFERテクノロジを使用するアプリケーションのほ とんどは、この暗黙的サブスクリプションを必要としない。 結果として、複数のREFERターゲット端末に対してREFERリクエストを生成 するSIP REFER発行端末は、Requireヘッダーフィールドに"norefersub"オ プションタグを含めるべきである[SHOULD]。また、"false"に設定した Refer-Subヘッダーフィールドを含めることで、リクエストに関する通知が REFER発行端末へまったく送信されなかったことを示すべきである[SHOULD]。 REFER受信端末はその示唆を尊重し、"false"に設定したRefer-Subヘッダー フィールドを200 (OK)応答にも含めるべきである[SHOULD]。"norefersub" SIPオプションタグとRefer-Subヘッダーフィールドについては、RFC 4488 [RFC4488]で規定されている。 RFC 4488 [RFC4488]は、REFER発行端末がRefer-Subヘッダーを含めるた めの条件は、REFER発行端末がREFERリクエストが分岐しないと確信して いる場合である、と示している。 Camarillo, et al. Standards Track [Page 4] RFC 5368 SIP Multiple REFER October 2008 本文書の執筆時点で、REFERダイアログに関連付けられた暗黙的サブスクリ プション上で、複数のトランザクションのステータスを報告できる拡張は ない。本文書が"norefersub"オプションタグの使用を推奨するのは、この ためである。将来的に、このような拡張が定義された場合、その拡張を使 用するREFER発行端末は、"norefersub"オプションタグの使用を禁止し、新 しい拡張を代わりに使用することができる。 6. URIリスト形式 RFC 5363 [RFC5363]に記載されているように、特定のサービス内で使用す る'recipient-list'ボディのデフォルト形式を指定する必要がある。 REFER発行端末とREFER受信端末の'recipient-list'ボディのデフォルト形 式は、RFC 5364 [RFC5364]で拡張したRFC 4826 [RFC4826]である。 'recipient-list'ボディを処理するREFER受信端末は、これら両方の形式を サポートしなければならない[MUST]。REFER発行端末とREFER受信端末はい ずれも他の形式をサポートしてもよい[MAY]。 RFC 5364 [RFC5364]に記載されているように、"to"、"cc"、または"bcc"に 設定した'copyControl'属性を使用して、各URIにタグを付けることができ る。これは、ターゲット端末が参照されたSIPリクエストを取得する際の役 割を示す。ただし、ターゲットのSIPメソッドによっては、'copyControl' 属性の意味はなくなる。たとえば、'copyControl'属性はINVITEリクエスト に適用できるが、BYEリクエストなど、ダイアログ中のリクエストには意味 がない。 'copyControl'属性の他に、URIに'anonymize'属性(これもRFC 5364 [RFC5364]で規定)でタグを付けることで、REFER受信端末がURIリストの ターゲットURIを公開することを回避することができる。 さらに、RFC 5364 [RFC5364]では、ターゲットのリストを含む 'recipient-list-history'ボディを定義している。カンファレンスサービ スの'recipient-list-history'ボディのデフォルト形式も、RFC 5364 [RFC5364]で拡張したRFC 4826 [RFC4826]である。本仕様をサポートする REFER受信端末は、これらの形式両方をサポートしなければならない[MUST]。 REFERターゲット端末は、これらの形式をサポートしてもよい[MAY]。REFER 受信端末とREFERターゲット端末はいずれも他の形式をサポートしてもよい [MAY]。 ただし、RFC 4826 [RFC4826]には、階層的リストや、XML Configuration Access Protocol (XCAP)ルートURIに対する相対参照によってエントリを含 める機能などが用意されている。これらの機能は本文書で定義している多 重REFERサービス(multiple REFER service)には不要である。 Camarillo, et al. Standards Track [Page 5] RFC 5368 SIP Multiple REFER October 2008 図1は、リソースリストドキュメントに従う単一階層リストの一例である。 図1: URIリスト 7. SIP REFER発行端末の動作 セクション4と5で説明しているように、複数のREFERターゲット端末に対し てREFERリクエストを作成するSIP REFER発行端末は、"multiple-refer"と" norefersub"オプションタグをRequireヘッダーフィールドに含める。また、 必要に応じて、Refer-Subヘッダーフィールドを"false"に設定する。REFER 発行端末は、recipient-listボディに複数のREFERターゲット端末を含める。 こボディのディスポジションタイプは、RFC 5363 [RFC5363]の定義に従い、 'recipient-list'である。URIリストボディの詳細については、セクション 6を参照のこと。 複数のREFERターゲット端末に対するREFERリクエストのRefer-Toヘッダー フィールドには、URIリストを含むボディ部を示すポインタ(つまり、RFC 5363 [RFC5363]に従い、Content-ID Uniform Resource Locator (URL))を 含めなければならない[MUST]。REFER発行端末は、特定のURIをURIリストに 複数回含めるべきではない[SHOULD NOT] RFC 4826 [RFC4826]には、階層的リストや、XCAPルートURIに対する相対参 照でエントリを含めることができる機能などが用意されている。ただし、 これらの機能は本文書で定義している多重REFERサービスには不要である。 したがって、デフォルトのリソースリストドキュメントを使用する場合、 複数のREFERターゲット端末に対してREFERリクエストを生成するSIP REFER 発行端末は、単一階層のリスト(つまり非階層的リスト)を使用すべきであ る[SHOULD]。また、要素を使用すべきではない[SHOULD NOT] 8. REFER受信端末の動作 REFER受信端末は、RFC 3515 [RFC3515]のセクション2.4.2の規則に従って、 REFERに対する応答のステータスコードを決定する。 REFER受信端末は暗黙的サブスクリプションを作成すべきではない[SHOULD NOT]。また、"false"に設定したRefer-Subヘッダーフィールドを200 (OK) 応答に含めるべきである[SHOULD]。 Camarillo, et al. Standards Track [Page 6] RFC 5368 SIP Multiple REFER October 2008 通常、受信REFERリクエストにはURIリストドキュメント、または実際の ターゲットリストへの参照が含まれる。このURIリストに"to"または"cc"の 値に設定された'copyControl'属性でタグを付けられたリソースが含まれる 場合、かつそのリクエストがサービスに適している場合(たとえば、ダイア ログ中に受信していないなど)、REFER受信端末は各送信リクエストにURIリ ストを含めるべきである[SHOULD]。このリストは、RFC 4826 [RFC4826]と RFC 5364 [RFC5364]に従って書式を設定すべきである[SHOULD]。REFER受信 端末は、'anonymize'、'count'、および'copyControl'の各属性の処理に関 して、RFC 4826 [RFC5364]に規定されている手順に従わなければならない [MUST]。 RFC 5363 [RFC5363]のセクション4では、URIリストに重複するURIが見つ かった場合について論じている。重複するリクエストを回避するために、 REFER受信端末はRFC 5363 [RFC5363]に規定されている動作を考慮して、同 じターゲットに重複するリクエストが送信されることを回避しなければな らない[MUST]。 REFER受信端末が送信INVITEリクエストにURIリストを含める場合、値を 'recipient-list-history'に設定したContent-Dispositionヘッダーフィー ルド([RFC2183]で規定)を含め、さらに"optional"に設定した'handling'パ ラメータ([RFC3204]で規定)を含めなければならない[MUST]。 多重REFERサービスは階層的リストも、XCAPルートURIに対する参照でエン トリを含めるリストも使用しないため、URIリストを受信するREFER受信端 末は、その範囲を超える情報を含むURIリストを受信した場合、その余計な 情報をすべて破棄してもよい[MAY]。 REFER受信端末は、RFC 3515 [RFC3515]の規則に従い、URIリストのURIごと に、通常の(URIリストではない)REFERを受信した場合と同様に行動して、 REFERターゲット端末に対して必要なリクエストを生成する。 9. 例 図2は、REFER発行端末が多重REFERリクエスト(multiple-REFER request)を カンファレンスのフォーカスに送信した場合のフロー例である。REFER受信 端末はREFERターゲット端末ごとにBYEリクエストを生成する。REFERリクエ ストを使用して、カンファレンスから参加者を削除する方法の詳細につい ては、RFC 4579 [RFC4579]に規定されている。 Camarillo, et al. Standards Track [Page 7] RFC 5368 SIP Multiple REFER October 2008 +--------+ +---------+ +--------+ +--------+ +--------+ | REFER | | REFER | | REFER | | REFER | | REFER | | issuer | |recipient| |target 1| |target 2| |target 3| | | | | | | | | | | | Carol | | (focus) | | Bill | | Joe | | Ted | +--------+ +---------+ +--------+ +--------+ +--------+ | 1. REFER | | | | | ---------------->| | | | | 2. 202 Accepted | | | | |<---------------- | 3. BYE | | | | | ----------->| | | | | 4. BYE | | | | | ----------------------->| | | | 5. BYE | | | | | ----------------------------------->| | | 6. 200 OK | | | | |<----------- | | | | | 7. 200 OK | | | | |<----------------------- | | | | 8. 200 OK | | | | |<----------------------------------- | | | | | | | | | | | | | | | | 図2: 複数のREFERターゲット端末を含むREFERリクエストのフロー例 REFERリクエスト(1)には、メッセージボディへにポインタを含むRefer-To ヘッダーフィールドが含まれる。このボディには、REFERターゲット端末の URIのリストが含まれる。この例では、URIリストに'copyControl'属性拡張 が含まれない。REFERのRequireヘッダーフィールドには、"multiple-refer "および"norefersub"オプションタグが含まれる。Request-URIは、(REFER リクエストが分岐しない保証として)Globally Routable User Agent URI (GRUU) [SIP-GRUU]に設定される。 Refer-Subヘッダーフィールドを"false"に設定することで、暗黙的サブス クリプションの抑制を要求する。図3はREFERリクエストの一例である。リ ソースリストドキュメントには、REFERターゲット端末のURIリストととも に、REFER受信端末が生成するSIPリクエストのメソッドが含まれる。 Camarillo, et al. Standards Track [Page 8] RFC 5368 SIP Multiple REFER October 2008 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conference 123" From: Carol ;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 2 REFER Contact: Refer-To: Refer-Sub: false Require: multiple-refer, norefersub Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Allow-Events: dialog Accept: application/sdp, message/sipfrag Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-Length: 362 Content-ID: 図3: 複数のREFERターゲット端末に対するREFERリクエスト 図4は、REFER受信端末が最初のREFERターゲット端末に送信するBYEリクエ スト(3)の例である。 BYE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP conference.example.com ;branch=z9hG4bKhjhs8assmm Max-Forwards: 70 From: "Conference 123" ;tag=88734 To: ;tag=29872 Call-ID: d432fa84b4c34098s812 CSeq: 34 BYE Content-Length: 0 図4: BYEリクエスト Camarillo, et al. Standards Track [Page 9] RFC 5368 SIP Multiple REFER October 2008 10. セキュリティの考慮事項 RFC 5363 [RFC5363]では、SIP URIリストサービスに関連する問題について 論じている。 複数のREFERターゲット端末に対するREFERリクエストを受け入れるREFER受 信者が、URIリストサービスとして動作する場合、このタイプのサーバー実 装は、RFC 5363 [RFC5363]のセキュリティ関連の規則に従わなければなら ない[MUST]。この規則には、クライアントのオプトインリストおよび必須 の認証と認可が含まれる。 さらに、REFER受信端末は、REFER受信端末が理解するアプリケーション(た とえば、カンファレンスアプリケーション)のコンテキスト内でのみ、 REFERリクエストを受け入れるべきである[SHOULD]。つまり、REFER受信端 末は、理解できないメソッドのREFERリクエストを受け入れてはならない [MUST NOT]。これら2つの規則の背景にある意図は、REFER受信端末を、理 解できないランダムなメッセージを並べるしか機能がない無能なサーバー として使用しない、ということである。 11. IANA条項 本文書は新しいSIPオプションタグ"multiple-refer"を定義する。このオプ ションタグは、「SIP Parameters」項目に登録済みである。 以下の行が「SIP Parameter Registry」の「Option Tags」セクションに追 加された。 +-----------------+-------------------------------------+-----------+ | Name | Description | Reference | +-----------------+-------------------------------------+-----------+ | multiple-refer | This option tag indicates support | [RFC5368] | | | for REFER requests that contain a | | | | resource list document describing | | | | multiple REFER targets. | | +-----------------+-------------------------------------+-----------+ 表1: SIPの'multiple-refer'オプションタグの登録 12. 参考文献 12.1. 規範となる参考文献 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. Camarillo, et al. Standards Track [Page 10] RFC 5368 SIP Multiple REFER October 2008 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001. [RFC3261] 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. [RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006. [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services", RFC 5363, October 2008. [RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008. 12.2. 有益な参考文献 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006. [SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2007. Camarillo, et al. Standards Track [Page 11] RFC 5368 SIP Multiple REFER October 2008 著者の連絡先 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland EMail: Aki.Niemi@nokia.com Markus Isomaki Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland EMail: markus.isomaki@nokia.com Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain EMail: miguel.a.garcia@ericsson.com Hisham Khartabil Ericsson Australia EMail: hisham.khartabil@gmail.com Camarillo, et al. Standards Track [Page 12] RFC 5368 SIP Multiple REFER October 2008 完全な著作権表記 Copyright (C) The IETF Trust (2008). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イ ンターネット協会、IETF TSUST、およびIETFは、この情報がいかなる権利 も侵害していないという保証、商用利用および特定目的への適合性への保 証を含め、また、これらだけに限らずすべての保証について、明示的もし くは暗黙的の保証は行われない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、 知的所有権または他の諸権利の有効性または範囲に関して、またはこのよ うな権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関し て、何ら見解を持たない。このような権利を確認する独自の取り組みを 行ったことも示さない。RFC文書の権利に関する手続きの情報は、BCP 78お よびBCP 79に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実 装者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果 については、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取 得可能である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性 がある、すべての著作権、特許または特許アプリケーション、あるいは他 の所有権について、すべての関連団体に対して配慮するよう依頼している。 情報は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2009年 ----------------------------------------------------------------------- Camarillo, et al. Standards Track [Page 13]