Network Working Group R. Sparks Request for Comments: 5057 Estacado Systems Category: Informational November 2007 セッション開始プロトコル(SIP)における複数のダイアログ用法 Multiple Dialog Usages in the Session Initiation Protocol 本文書の位置付け 本文書は、インターネットコミュニティに情報を提供するためのものであ る。いかなるインターネット標準も規定しない。本文書の配信は無制限であ る。 概要 セッション開始プロトコル(Session Initiation Protocol/SIP)の一部のメ ソッドは、エンドポイント間にダイアログという関連付けを作成することが できる。これらのメソッドの一部は、既存のダイアログ内に異なるが関係が ある関連付けを作成することもできる。各ダイアログは独立したライフサイ クルを持つが、共通するダイアログステートを共有するため、こうした複数 の関連付け、つまりダイアログ用法には、慎重に調整された処理が必要であ る。複数のダイアログ用法を正しく処理する方法は、完全には理解されてい ない。わかっているのは、実装が難しい、ということである。 本文書は、複数のダイアログ用法を回避すべきであるということについて論 じる。また、複数のダイアログ用法の代替策について論じ、現在回避できな い要素の主要な動作を明確にする。 これは参考文書であり、規範的な記述はまったく行わない。 Sparks Informational [Page 1] RFC 5057 Multiple Dialog Usages November 2007 目次 1. 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 複数使用の使用 . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. 転送 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. 相互のサブスクリプション . . . . . . . . . . . . . . . . 6 4. 用法の作成と破壊 . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. 招待用法 . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. サブスクライブ用法 . . . . . . . . . . . . . . . . . . . 9 5. 複数の用法の正しい処理 . . . . . . . . . . . . . . . . . . . . 9 5.1. 用法とダイアログに関するエラー応答の影響に 関する調査 . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. トランザクションのタイムアウト . . . . . . . . . . . . . 15 5.3. リクエストと用法のマッチング . . . . . . . . . . . . . . 16 5.4. ターゲットの更新リクエスト . . . . . . . . . . . . . . . 17 5.5. 用法の更新と終了 . . . . . . . . . . . . . . . . . . . . 17 5.6. 新しい用法の拒否 . . . . . . . . . . . . . . . . . . . . 18 5.7. 用法の置換 . . . . . . . . . . . . . . . . . . . . . . . 18 6. 複数の用法の回避 . . . . . . . . . . . . . . . . . . . . . . . 18 7. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 23 8. まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 24 1. 概要 これは参考文書である。規範的な記述はまったく行わない。本文書は、セッ ション開始プロトコル(Session Initiation Protocol/SIP [1])に記載され るダイアログ用法の概念を再定義し、ダイアログ用法の存在に導くものにつ いて論じる。また、1つのダイアログを共有する複数のダイアログ用法を処 理するときに関連付けられるあいまいさについても詳しく調査する。特に、 トランザクション、ダイアログ用法、ダイアログステートに関するSIPエ ラー応答の影響について調査する。本文書は、複数のダイアログ用法を正し く処理するために必要なことを実装者が理解する一助となり、RFC 3261や他 の関連文書を明確にする今後の標準化過程の研究に情報を提供する。最後 に、本文書は、複数のダイアログ用法と置き換える単一の用法のダイアログ について詳しく調査する。 2. はじめに 一部のSIPメソッドはダイアログを確立することができる。この場合、その ダイアログ内のエンドポイント間に関連付けも確立する。この関連付けは、 開発者の間で、ときには「ダイアログ用法(dialog usage)」と呼ばれてき た。INVITEリクエストで開始されたダイアログには招待用法がある。 SUBSCRIBEリクエストで開始されたダイアログにはサブスクライブ用法があ Sparks Informational [Page 2] RFC 5057 Multiple Dialog Usages November 2007 る。REFERリクエストで開始されたダイアログにはサブスクライブ用法があ る。 複数の用法があるダイアログは、用法の作成動作が、既存のダイアログ内で 発生する場合である。このような動作には、たとえばINVITEリクエストで確 立したダイアログ内で発行されるREFERやSUBSCRIBEの受け入れが含まれる。 ダイアログ内の複数のREFERによって複数のサブスクリプションが作成され、 それぞれが、共通のダイアログステートを共有する新しいダイアログ用法に なる([2]に規定されているサブスクリプションの抑制メカニズムを利用して 発行されるREFERは、新規のメッセージを作成しないことに注意)。同様に、 INVITEで確立したエンドポイントは、相手のKey Press Markup Language (KPML) [3]にサブスクライブし、後でREFERを発行した結果、共通のダイア ログステートを共有する3つのダイアログ用法になる。 すべての用法が共有するダイアログの共通ステートは、以下のとおりである。 o Call-ID o ローカルタグ o リモートタグ o ローカルのCSeq o リモートのCSeq o Route-set o ローカルコンタクト o リモートターゲット o セキュアフラグ 用法には、ダイアログで共有しないステートメントがある。たとえば、サブ スクリプションには、継続期間と、その他の用法固有のステートがある。 同じダイアログの複数のサブスクリプションには、それぞれ独自の継続期間 がある。 ダイアログは最初の用法の作成とともに作成され、最後の用法が終了するま で継続する(参照のカウント)。残念ながら、認証など、SIPの用法管理が持 つ側面の多くは、1つのダイアログにつき1つの用法がある、という暗黙的な 前提で元々設計されていた。その結果、複合した影響が出て、一部は用法に 影響を及ぼし、一部はダイアログ全体に影響を及ぼした。 Sparks Informational [Page 3] RFC 5057 Multiple Dialog Usages November 2007 現在の仕様は、招待とサブスクライブという2つの用法を定義している。 1つのダイアログは、最大で1つの招待用法と、任意の数のサブスクライブ用 法を共有することができる。 RFC 3261 [1]は、ユーザーエージェントはCall-IDを再利用し、一連の登録 リクエストでCSeqを増分するように記述しているため(また、一部の例では、 to-タグは登録応答にも出現する)、一部の実装はダイアログ内にあるかのよ うにREGISTERを扱った。 ただし、RFC 3261は明示的に、REGISTERはダイアログを作成しない、と記述 している。一連のREGISTERリクエストでは、用法もダイアログも作成されな い。同様に、PUBLISH [4]は用法またはダイアログを作成しない。 3. 複数使用の使用 3.1. 転送 図1では、Aliceが、Bobから受信した通話をCarolに転送する。 AliceとBob間のダイアログ(およびinviteのダイアログ用法)は、F1の200 OKと 同時に成立する。第2の用法(イベントのREFERに対するサブスクリプション)は、 F2のNOTIFYと同時に成立する。この第2の用法は、サブスクリプションがF3の NOTIFYトランザクションによって終了したときに終了する。ダイアログにはま だ1つの用法(invite用法)があり、F4のBYEトランザクションが終了するまで続 く。 この時点で、ダイアログには残りの用法がないため、ダイアログは存在しなく なる。各メッセージの詳細を図2に示す。 Sparks Informational [Page 4] RFC 5057 Multiple Dialog Usages November 2007 Alice Bob Carol | INVITE | | |<----------------| | Dialog 1 Usage 1 | 200 OK (F1) | | -start- -start- ----------->|---------------->| | | | | ACK | | | | |<----------------| | | | | reINVITE/200/ACK| | | | | (hold) | | | | |---------------->| | | | | REFER | | | | Dialog 1 |---------------->| | | | Usage 2 | NOTIFY (F2) | | | | -start- -->|<----------------| INVITE | | | | | 200 NOTIFY |----------->| | | | |---------------->| 200 OK | | | | | 200 REFER |<-----------| | | | |<----------------| ACK | | | | | NOTIFY (F3) |----------->| | | | |<----------------| | | | | | 200 | . | | | -end- -->|---------------->| . | | | | BYE (F4) | Dialog 2 | | | |<----------------| proceeds | | | | 200 | . | -end- -end- ------------>|---------------->| . | 図1 メッセージの詳細(ダイアログまたは用法の詳細のみを示すために要約) F1 SIP/2.0 200 OK Call-ID: dialog1@bob.example.com CSeq: 100 INVITE To: ;tag=alicetag1 From: ;tag=bobtag1 Contact: F2 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 Event: refer Call-ID: dialog1@bob.example.com CSeq: 101 NOTIFY To: ;tag=alicetag1 From: ;tag=bobtag1 Contact: Sparks Informational [Page 5] RFC 5057 Multiple Dialog Usages November 2007 F3 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 Event: refer Subscription-State: terminated;reason=noresource Call-ID: dialog1@bob.example.com CSeq: 102 NOTIFY To: ;tag=alicetag1 From: ;tag=bobtag1 Contact: Content-Type: message/sipfrag SIP/2.0 200 OK F4 BYE sip:aliceinstance@alice.example.com SIP/2.0 Call-ID: dialog1@bob.example.com CSeq: 103 BYE To: ;tag=alicetag1 From: ;tag=bobtag1 Contact: 図2 3.2. 相互のサブスクリプション 図3では、AliceがBobのプレゼンスにサブスクライブする。簡単にするため に、BobとAliceはいずれも、プロキシサーバーではなくそれぞれのエンドポ イントから自分のプレゼンスを提供している。重要な点に集中できるよう に、AliceがBobのエンドポイントを見つけるランデブーシグナリングを図か ら除外している。 BobもAliceのプレゼンスに関心があるため、Aliceにサブスクライブする(よ く使われているプレゼンス/IMシステムの用語では、相互にウォッチしてい る)。Bobは、Aliceとすでにダイアログを使用中なので、ランデブー手順を スキップすることを決定し、そのダイアログ内でSUBSCRIBEを送信する(初期 の少数のSIMPLEクライアントはまったくこの通りに動作していた)。 ダイアログと最初の用法がF1に達すると、AliceのBobに対するサブスクリプ ションが確立する。F2で第2の用法が開始され、BobのAliceに対するサブス クリプションが確立する。これら2つのサブスクリプションは独立してい る。区別され、有効期限も違うが、すべてのダイアログステートを共有して いる。 最初の用法は、AliceがF3でサブスクライブの解除を決定したときに終了 する。BobのAliceに対するサブスクリプションと当然ながらダイアログは、 以降も存在する。 AliceとUAは、最初の段階で存在していたサブスクリプションが現在は終了 しているとしても、ダイアログステートを維持する必要がある。 Sparks Informational [Page 6] RFC 5057 Multiple Dialog Usages November 2007 第2の用法は、BobのサブスクリプションをF4で終了することをAliceが決定 したときに終了する(おそらく、Aliceは後でBobにサブスクライブする準備 が整うまで、Bobからの再サブスクリプションの試行をすべて拒否するつも りである)。これは最後の用法だったので、ダイアログも終了する。 各メッセージの詳細を図4に示す。 Alice Bob | | | SUBSCRIBE | |------------------->| Dialog Usage 1 | NOTIFY (F1) | -start- -start- --------->|<-------------------| | | | 200 SUBSCRIBE | | | |<-------------------| | | | 200 NOTIFY | | | |------------------->| | | | SUBSCRIBE | | | |<-------------------| | | Usage 2 | NOTIFY (F2) | | | -start- -->|------------------->| | | | | 200 SUBSCRIBE | | | |------------------->| | | | | 200 NOTIFY | | | | |<-------------------| | | | | : | | | | | : | | | | | (un)SUBSCRIBE (F3) | | | | |------------------->| | | | | 200 | | | | |<-------------------| | | | | NOTIFY | | | | |<-------------------| | | | | 200 | | -end- ----------->|------------------->| | | | : | | | | : | | | | NOTIFY (F4) | | | | (Terminated) | | | |------------------->| | | | 200 | -end- -end- -->|<-------------------| | | 図3 Sparks Informational [Page 7] RFC 5057 Multiple Dialog Usages November 2007 メッセージの詳細(ダイアログまたは用法の詳細のみを示すために要約) F1 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 Event: presence Subscription-State: active;expires=600 Call-ID: alicecallid1@alice.example.com From: ;tag=bobtag2 To: ;tag=alicetag2 CSeq: 100 NOTIFY Contact: F2 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 Event: presence Subscription-State: active;expires=1200 Call-ID: alicecallid1@alice.example.com To: ;tag=bobtag2 From: ;tag=alicetag2 CSeq: 500 NOTIFY Contact: F3 SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0 Event: presence Expires: 0 Call-ID: alicecallid1@alice.example.com To: ;tag=bobtag2 From: ;tag=alicetag2 CSeq: 501 SUBSCRIBE Contact: F4 NOTIFY sip:bobinstance@bob.example.com SIP/2.0 Event: presence Subscription-State: terminated;reason=deactivated Call-ID: alicecallid1@alice.example.com To: ;tag=bobtag2 From: ;tag=alicetag2 CSeq: 502 NOTIFY Contact: 図4 Sparks Informational [Page 8] RFC 5057 Multiple Dialog Usages November 2007 4. 用法の作成と破壊 ダイアログは最初の用法と共に存在するようになる。また、ダイアログは最 後の用法が破棄されるときに終了する。用法を作成および破棄するメッセー ジは、用法によって異なる。このセクションでは、このようなメッセージの 詳細な分類を提示する。ここでは、REGISTER疑似ダイアログについて検討し ない。 4.1. 招待用法 作成: INVITEに対する非100暫定応答。INVITEに対する200応答。 破棄: BYEに対する200応答。INVITE、UPDATE、PRACK、INFO、またはBYEに 対する特定のエラー応答。ダイアログやすべての用法を破棄する何らか のもの。 4.2. サブスクライブ用法 作成: SUBSCRIBEに対する200クラス応答。REFERに対する200クラス応 答。NOTIFYリクエスト。 破棄: NOTIFY-terminatedに対する200クラス応答。NOTIFYまたは更新の SUBSCRIBEリクエストのタイムアウト。NOTIFYまたはSUBSCRIBEに対する 特定のエラー応答。ネットワークの問題によって終了のNOTIFYが届かな い場合、更新なしの有効期限切れ。ダイアログとすべての用法を破棄す る何らかのもの。 5. 複数の用法の正しい処理 セクション3の説明は単純なケースで、ダイアログの開始時と終了時が明確 である。残念ながら、このような明確さに欠けるシナリオも多数ある。たと えば、図1では、NOTIFY (F2)に対する応答が481の場合はどうなるだろうか。 参照のサブスクリプションのみが終了するだけだろうか、それとも全体のダ イアログが終了するだろうか。このセクションでは、これまでに確認されて きた複数の用法で発生する問題について検討する。 5.1. 用法とダイアログに関するエラー応答の影響に関する調査 この調査では、招待用法で確立したダイアログ内の用法について検討する。 ここでは、特記がない限り、サブスクライブ用法内でNOTIFYを発行するクラ イアントがエラー応答を受信した場合の、各用法とダイアログに関する影響 について説明する(referイベントに対するNOTIFYを発行する被転送端末など)。 また、特記がない限り、結論は任意の複数の用法に適用される。 Sparks Informational [Page 9] RFC 5057 Multiple Dialog Usages November 2007 この調査は、エラー応答を受信するクライアントの観点から書いている。ダ イアログと用法に関する影響は、応答を発行するサーバーでも同じである。 3xx応答: ダイアログ中のリダイレクトはSIPではよく理解されていないが、 内容を問わずダイアログ全体とすべての用法に同様に影響がある。この シナリオ例では、サブスクリプションと招待用法はいずれもこの単一の 応答でリダイレクトされる。 エラー応答コードが400以上の場合、エラーがトランザクション、用法、およ びダイアログステートに与える一般的な影響は3つある。 トランザクションのみ: エラーはトランザクションのみに影響があり、トラ ンザクションが発生する用法やダイアログには(ローカルのCSeqに対する 影響以外の)影響がない。そのダイアログの他の用法には影響がない。エ ラーはこのトランザクションに対する苦情であり、トランザクションが 発生する用法やダイアログに対するものではない。 用法の破棄: このエラーはその用法を破棄するが、ダイアログは破棄しな い。このダイアログを共有するその他の用法には影響がない。 ダイアログの破棄: このエラーはダイアログと、ダイアログを共有する すべての用法を破棄する。 表1と表2に、各応答コードがトランザクション、用法、またはダイアログス テートに与える影響について示す。応答コード固有のコメントと例外につい ては表外で説明する。 +----------------------+----------------+-----------------+ | トランザクションのみ | 用法の破棄 | ダイアログの破棄| +----------------------+----------------+-----------------+ | 400 (または不明な4xx)| 405, 480 | 404, 410, 416 | | 401, 402, 403, 406 | 481, 489 | 482, 483 | | 407, 408, 412-415 | 501 | 484, 485 | | 417, 420, 421, 422 | | 502, 604 | | 423, 428, 429 | | | | 436-438, 486, 487 | | | | 488, 491, 493, 494 | | | | 500 (or unknown 5xx) | | | | 503, 504, 505 | | | | 513, 580 | | | | 600 (or unknown 6xx) | | | | 603, 606 | | | +----------------------+----------------+-----------------+ 表1 Sparks Informational [Page 10] RFC 5057 Multiple Dialog Usages November 2007 +---------+---------------------------------+-------------+-------+ | コード | 理由 | 影響 | 備考 | +---------+---------------------------------+-------------+-------+ | 400/4xx | Bad Request | Transaction | | | 401 | Unauthorized | Transaction | | | 402 | Payment Required | Transaction | (1) | | 403 | Forbidden | Transaction | | | 404 | Not Found | Dialog | (2) | | 405 | Method Not Allowed | Usage | (3) | | 406 | Not Acceptable | Transaction | | | 407 | Proxy Authentication Required | Transaction | | | 408 | Request Timeout | Transaction | (4) | | 410 | Gone | Dialog | (2) | | 412 | Conditional Request Failed | Transaction | | | 413 | Request Entity Too Large | Transaction | | | 414 | Request-URI Too Long | Transaction | | | 415 | Unsupported Media Type | Transaction | | | 416 | Unsupported URI Scheme | Dialog | (2) | | 417 | Unknown Resource-Priority | Transaction | | | 420 | Bad Extension | Transaction | | | 421 | Extension Required | Transaction | | | 422 | Session Interval Too Small | Transaction | (5) | | 423 | Interval Too Brief | Transaction | | | 428 | Use Identity Header | Transaction | | | 429 | Provide Referrer Identity | Transaction | (6) | | 436 | Bad Identity-Info | Transaction | | | 437 | Unsupported Certificate | Transaction | | | 438 | Invalid Identity Header | Transaction | | | 480 | Temporarily Unavailable | Usage | (7) | | 481 | Call/Transaction Does Not Exist | Usage | (8) | | 482 | Loop Detected | Dialog | (9) | | 483 | Too Many Hops | Dialog | (10) | | 484 | Address Incomplete | Dialog | (2) | | 485 | Ambiguous | Dialog | (2) | | 486 | Busy Here | Transaction | (11) | | 487 | Request Terminated | Transaction | | | 488 | Not Acceptable Here | Transaction | | | 489 | Bad Event | Usage | (12) | | 491 | Request Pending | Transaction | | | 493 | Undecipherable | Transaction | | | 494 | Security Agreement Required | Transaction | | | 500/5xx | Server Internal Error | Transaction | (13) | | 501 | Not Implemented | Usage | (3) | | 502 | Bad Gateway | Dialog | (14) | | 503 | Service Unavailable | Transaction | (15) | | 504 | Server Time-Out | Transaction | (16) | | 505 | Version Not Supported | Transaction | | | 513 | Message Too Large | Transaction | | Sparks Informational [Page 11] RFC 5057 Multiple Dialog Usages November 2007 | 580 | Precondition Failure | Transaction | | | 600/6xx | Busy Everywhere | Transaction | (17) | | 603 | Decline | Transaction | | | 604 | Does Not Exist Anywhere | Dialog | (2) | | 606 | Not Acceptable | Transaction | | +---------+---------------------------------+-------------+-------+ 表2 (1) 402 Payment Required: これは予約済みの応答コードである。この応答 コードが発生した場合、不明な4xxとして扱うべきである。 (2) 404 Not Found: 410 Gone: 416 Unsupported URI Scheme: 484 Address Incomplete: 485 Ambiguous: 604 Does Not Exist Anywhere: 拒否されたRequest-URIは、相手側が提示したContactで設定されたリモー トターゲットである。この応答の受信は、ダイアログステートの何かが 根本的に間違った方向に進んでいることを意味する。 (3) 405 Method Not Allowed: 501 Not Implemented: いずれの応答も、このシナリオ例では通常は発生しない。NOTIFYメソッ ドのサポートが、この用法では必須のためである。この場合、UAは状況 が回復不能であることを認識し、その用法についてNOTIFYの送信を終了 すべきである。すべての更新サブスクリプションは拒否すべきである。 一般的に、これらのエラーが用法に最も影響がある。リクエストが用法 にとって不可欠なものではなかった場合(不明なメソッドを使用した場 合や、招待用法内のINFOだった場合など)、トランザクションのみに影響 が及ぶ。 (4) 408 Request Timeout: 408の受信は、セクション5.2に記載している実 際のトランザクションタイムアウトと同じ影響を用法とダイアログに及 ぼす。 Sparks Informational [Page 12] RFC 5057 Multiple Dialog Usages November 2007 (5) 422 Session Interval Too Small: どの用法内のリクエストでも、この 応答は意味がない。この応答を受信した場合、リクエストのパス内の用 法がプロトコルに違反しているので、受信側は不明な4xx応答として扱う べきである。 (6) 429 Provide Referrer Identity: このシナリオ例では、NOTIFYに対し てこの応答が返されることはない。ただし、REFERに対して返された場合、 REFERリクエストのみに対するエラーである。 (7) 480 Temporarily Unavailable: RFC 3261は、用法内のリクエストについ てこの応答が返されたときの意味について明確にしていない。RFC 3261の 今後の更新で、リクエストが発生した用法に対してのみ、この応答の影響 が及ぶということが明確されると期待される。その他の用法には影響がな い。応答にRetry-Afterヘッダーフィールドが含まれていた場合、以降、 指定された時間が経過するまで、その用法のリクエストは送信すべきでは ない。この場合、他の用法のリクエストはいつでも送信することができ る。 (8) 481 Call/Transaction Does Not Exist: この応答は、相手側がダイア ログ用法の状態の複製を失ったことを示す。それが最後の用法だった場 合を除き、ダイアログを破棄すべきではない。 ダイアログと用法に対する481の影響は、すべての最終応答の中で最もあ いまいである。本文書で推奨した手法を選択した実装と、終了していな い複数の用法に関係なく全体のダイアログを破棄する実装がある。この 明確化をさらに進めることによって、用法のみが破棄されるという前提 の実装が、より広範な数の実装と連携することができる。ダイアログ内 のすべての用法を破棄するという既存の実装は、現在と同様に機能し続 ける。ただし、推奨に従う相手側が、他の用法に対して何か処理を実行 しようとして、すべての用法が破棄されるまでそれぞれに481を返す場合 を除く。ただし、RFC 3261に必要な明確化では、全体のダイアログとは 無関係に481を使用して用法を終了する機能は、1つのダイアログで複数 の用法があることを考慮して新しいアプリケーションを設計するための 正当な理由ではないことを明確にする必要がある。 CANCELに対する481応答は異なる扱いをする必要がある。CANCELの場合、 481は、UASが一致するトランザクションを見つけることができないこと を意味する。CANCELに対する481応答は、CANCELトランザクションにのみ 影響がある。INVITEに関連付けられている用法には影響がない。 Sparks Informational [Page 13] RFC 5057 Multiple Dialog Usages November 2007 (9) 482 Loop Detected: この応答はダイアログ中には通常発生しない。こ の応答が発生するのは、ダイアログの最初の用法をセットアップするとき に関わったプロキシが、Record-Routeヘッダーフィールドを不適切に構築 された場合、またはダイアログ中のリクエストが分岐し、マージされた場 合(ただし、このような状況は発生しない)のみである。このダイアログス テートを使用する以降のリクエストも失敗する。 リクエストを送信する要素には、RFC 3263のフェイルオーバー時(この 場合、クライアントからのリクエストが複数の宛先に分岐する)に周辺 条件が存在する。最初の候補となる場所がすぐに応答しないときに、 RFC 3263に従って次の候補となる場所をすぐに試行する場合、一部の 実装はこの周辺条件に入るリスクが向上する。クライアントが同じリ クエストを複数のエンドポイントに送信する状況では、各分岐から応 答を受信することに備える必要がある(また、分岐するプロキシと同じ ガイドラインに従って動作するには、「最適な」応答を選択すべきで ある)。この競合条件では、複数の分岐が応答する場合、1つを除いて すべての分岐が482 Merged Requestを返す可能性が非常に高い。クラ イアントはそれ以外の非482応答を「最適な」応答として選択すべき である。 (10) 483 Too Many Hops: 482と同様に、ダイアログ中には通常受信するこ とはない。482とは異なり、Max- Forwardsを増やすことで回復できる場合 がある(ただし、リクエスト側がダイアログ中のリクエストでMax-Forwards に最初のリクエストより低い値を使用するような通常とは異なることをし ないという前提)。Max-Forwardsを増やしてリクエストを試行しない場合、 エージェントは「ダイアログの破棄」動作に従うべきである。 (11) 486 Busy Here: 本文書のシナリオ例や、確立した用法内でこの応答を 受信するシナリオでは、この応答は無意味である。この状況でこの応答が 発生する場合、不明な4xx応答として扱うべきである。 (12) 489 Bad Event: 本文書のシナリオ例の場合、[5]は、NOTIFYが送信され るサブスクリプション用法は終了する。 SUBSCRIBEとNOTIFYのコンテキストでのみ、この応答は有効である。他のメ ソッドに対してこの応答を受信する場合のUACの動作は規定されていない が、不明な4xxとして扱う方法が妥当な実装である。 (13) 500および5xxの認識されていない応答: 応答にRetry-Afterヘッダー フィールド値が含まれる場合、サーバーは条件を一時的として扱い、指定 された間隔の後にリクエストを試行することができる。応答にRetry-After ヘッダーフィールド値が含まれる場合、UAは選択した間隔の後に再試行す るか、通常の方法でその用法を終了することができる。他の用法を終了す るかどうかは、アプリケーションによって異なる。この用法を通常の方法 Sparks Informational [Page 14] RFC 5057 Multiple Dialog Usages November 2007 で終了する試行に対する応答として、UAが500 (または認識されていない 5xx)を受信した場合、この用法を終了済みとして扱うことができる。それ がダイアログを共有する最後の用法の場合、ダイアログも終了される。 (14) 502 Bad Gateway: この応答はダイアログ中には通常発生しない。この 応答が発生するのは、ダイアログの最初の用法をセットアップするときに 関わったプロキシが、Record-Routeヘッダーフィールドを不適切に構築し た場合のみである。このダイアログステートを使用する以降のリクエスト も失敗する。 (15) 503 Service Unavailable: [6]に従って、トランザクションに関して SIPサーバーの位置を指定するロジックを使用して、503リクエストを処 理することができる(結果的に、これに続いて、DNSの結果に基づいてエ ンドポイントで分岐が発生する)。この処理によってよりよい応答が発生 しない場合、トランザクションユーザーに対して503が返される場合があ る。500応答と同様に、このエラーは、用法ではなくトランザクションに 対する苦情である。 確立した用法(したがって既存のダイアログ)のコンテキストでこの応答 が発生したため、ルールセットはすでに構築済みで、代替のサーバーを 試行する機会([1]の推奨に従う)は、RFC 3263ロジックによってなくなっ ている。 (16) 504 Server Time-out: 既存のダイアログ内のリクエストに対してこ の応答が返される状況は明確ではない。 (17) 600 and 6xx unrecognized responses: 400 Bad Requestとは異なり、 600応答コードは、送信されたリクエストではなく受信ユーザーに関する ものである。このエンドユーザーは、通信する意思がないことを示して いる。応答にRetry-Afterヘッダーフィールドが含まれる場合、ユーザー は後で通信する意思を示しているため、指定の間隔の後にリクエストが 再試行される可能性がある。 この用法と、そのダイアログを共有する他の用法は、影響を受けない。 応答にRetry-Afterヘッダーフィールド値が含まれる場合、UAは選択した 間隔の後に再試行するか、通常の方法でその用法を終了することができ る。他の用法を終了するかどうかは、アプリケーションによって異なる。 この用法を通常の方法で終了する試行に対する応答として、UAが600 (また は認識されていない6xx)を受信した場合、この用法を終了済みとして扱う ことができる。それがダイアログを共有する最後の用法の場合、ダイア ログも終了される。 5.2. トランザクションのタイムアウト [1]には、ダイアログ内で送信されたリクエストに対して応答が送信されな かった場合、UACは(BYEを送信して)ダイアログを終了するように記載されて いる。この推奨は、ダイアログ全体ではなく、招待用法に限定すべきだった。 [5]には、NOTIFYのタイムアウトによってサブスクリプションは削除される Sparks Informational [Page 15] RFC 5057 Multiple Dialog Usages November 2007 が、481以外の応答で失敗するSUBSCRIBEは(サブスクリプションを)削除しな いことが記載されている。これらの記載を前提にすると、招待用法と共有さ れるダイアログで、更新のSUBSCRIBEが発行された場合、タイムアウト時に 用法とダイアログのどちらが破棄されるかが不明である。 一般的に、トランザクションのタイムアウトは、発生したトランザクション の用法にのみ影響を及ぼすべきである。ダイアログを共有する他の用法には 影響を及ぼすべきではない。全体的な送信が失敗したために発生するタイム アウトの最悪のケースでは、ダイアログからすべての用法を削除するために、 複数のエラーメッセージが必要になる可能性がある(最低でも1つの用法につ き1つ)。 どの用法にも属さないダイアログ中のメッセージも一部にはある。 このようなメッセージがタイムアウトした場合、ダイアログや用法には影響 が及ばない。 5.3. リクエストと用法のマッチング ダイアログ中のリクエストが多数ある場合、属する用法を特定する方法は明 らかである。1つのダイアログには招待用法が最高でも1つしかないため、 INVITE、UPDATE、PRACK、ACK、CANCEL、BYE、INFOの各リクエストは、招待 用法に属する。SUBSCRIBE、NOTIFY、REFERの各リクエストが属する用法(つ まり、特定のサブスクライブ用法)は、リクエストのEventヘッダーフィール ドから判断することができる。(疑似)ダイアログ内のREGISTERリクエストは、 登録用法に属する(前述のように)実装では登録用法と他の用法を混同しない ため、本文書ではこの不正な動作の影響について検討しない。 [1]には、「ダイアログ内で受信したOPTIONSリクエストによって生成され る200 OK応答は、ダイアログ外で構築されるものと同一であり、そのダイア ログにまったく影響がない(an OPTIONS request received within a dialog generates a 200 OK response that is identical to one constructed outside a dialog and does not have any impact on that dialog)」と記 載されている。したがって、OPTIONSはどの用法にも属さない。セクション 5.1とセクション5.2で論じられているダイアログ全体を破棄するエラーの場 合にのみ、失敗したOPTIONSリクエストとダイアログを共有する用法に何ら かの影響がある。 ダイアログ内のMESSAGEリクエストは推奨されない。連続するMESSAGEリクエ ストを伝達する目的で用法を作成する実装は制限されている(ただし、一部 の実装は標準の推奨に反してこの方法を使用している)。既存のダイアログ 内で失敗したエラーのMESSAGEは、失敗したOPTIONSリクエストと同じ影響を ダイアログと用法に及ぼす。 不明なメソッドを含むダイアログ中のリクエストは、用法とマッチングする ことはできない。サーバーはエラー応答(501など)を返す。クライアントま たはサーバーのダイアログと用法に与える影響は、失敗したOPTIONSリクエ ストの影響と同様である。 Sparks Informational [Page 16] RFC 5057 Multiple Dialog Usages November 2007 メッセージを用法にマッチングさせる(または用法がないことを判断する)た めのこれらのガイドラインは、UAS、UAC、またはサードパーティが用法とダ イアログステートを追跡するときと同様に、2つのエンドポイント間のすべ てのメッセージを調べて適用される。 5.4. ターゲットの更新リクエスト ターゲットの更新リクエストが正常に処理されると、ダイアログのリモー トターゲットが更新される。現在定義されているターゲットの更新リクエス トは、INVITE、UPDATE、SUBSCRIBE、NOTIFY、REFERである[7]。 リモートターゲットはダイアログステートの一部である。ターゲット更新リ クエストがダイアログステートに影響を及ぼす場合、そのダイアログを共有 するすべての用法にも影響がある。 サブスクリプションと招待用法が1つのダイアログを共有する場合、コンタ クトが異なる更新のSUBSCRIBEを送信すると、相手側からのre-INVITEは、そ の異なるコンタクトに送信される。 UASは、ターゲット更新リクエストに対して200クラス応答を送信する場合に のみ、リモートターゲットを更新する。UACは、ターゲット更新リクエスト に対して200クラス応答を受信する場合にのみ、リモートターゲットを更新 する。この場合も、ダイアログのリモートターゲットに対する更新は、その ダイアログのすべての用法に影響を与える。 暫定応答がリモートターゲットに与える影響については既知のあいまいさが あり、今後の仕様で明確化される予定である。さらに、リモートターゲット は用法ステートではなくダイアログステートの一部なので、同じダイアログ で複数の用法について同時に進行中のターゲット更新リクエストがある場合 も、あいまいさが存在する。実装の設計者は、このような条件を慎重に検討 すべきである。 5.5. 用法の更新と終了 サブスクリプションと登録用法は、時間の経過に従って期限切れになるため、 更新する必要がある(更新のSUBSCRIBEなどを使用する)。この期限切れはダイ アログステートではなく用法ステートである。複数のサブスクリプションが ダイアログを共有する場合、いずれかを更新したときに、他の有効期限に影 響は及ばない。 用法の通常の終了は、同じダイアログを共有する他の用法に影響を与えない。 たとえば、NOTIFY/Subscription-State:でサブスクリプションを終了する場 合、同じダイアログを共有する招待用法は終了しない。同様に、招待用法を BYEで終了しても、そのダイアログで確立したアクティブなEvent:の参照サ ブスクリプションは終了しない。 Sparks Informational [Page 17] RFC 5057 Multiple Dialog Usages November 2007 5.6. 新しい用法の拒否 エラー応答の影響の調査が示すように、既存のダイアログ内で新しい用法を 拒否する場合は注意が必要である。誤った応答を選択すると、ダイアログと、 すべての用法が終了する。一般的に、603 Declineを返すことは、新しい用法 を拒否する上で最も安全な方法である。 5.7. 用法の置換 [8]は、1つの用法が他の用法を置換するメカニズムを定義している。 たとえば、セカンダリコールありの転送中に、転送のターゲットが関係する 2つのダイアログを関連付けるときに使用することができる。「ダイアログ」 という用語を使用して説明しているが、対象とするダイアログの招待用法に のみ影響が及ぶことを示している。このダイアログ内の他の用法には影響が ない。アプリケーションによっては、他の用法も意味がなくなるため、すべ て同様に終了する場合もある。 ただし、Replacesと複数のダイアログ用法間の相互作用については、まだよ く調査されていない。この話題についてより詳細な議論が必要である。実装 では、このシナリオを完全に回避すべきである。 6. 複数の用法の回避 複数の用法を正しく処理する方法は、完全には理解されていない。 わかっているのは、実装が困難で、相互運用上の問題を引き起こす可能性が 高いということである。このような複雑さに付随するトラブルを回避する最 適な方法は、完全に回避することである。 SIPダイアログを使用する新しいアプリケーションまたは機能を設計する場 合、エンドポイントは、アプリケーションに参加するとき、または機能を使 用するとき、複数の用法を構築する必要はない。エンドポイントを設計する 場合は、現存する複数の用法のシナリオにできる限り対処すること。 そのシナリオ以外については、1つのダイアログ内で相手側が2つ目の用法を 作成しようと思試行した場合、拒否すること。 残念ながら、現在のところ複数の用法を必要とする既存のアプリケーション (転送)が存在するため、「実行するな」という単純な解決策には、何らかの 暫定的な作業が必要になる。このセクションは、既存の複数の用法を引き起 こす圧力に注目し、代替策を提案する。 転送の実行時、転送指示端末と被転送端末は、2端末間のダイアログ内で招待 用法とサブスクリプション用法を共有している。これは、招待用法によって 確立したダイアログ内でREFERリクエストを送信した結果である。実装では、 主に以下の問題によって、この動作が発生した。 Sparks Informational [Page 18] RFC 5057 Multiple Dialog Usages November 2007 1. 新しいダイアログ上のREFERを、転送に関わる特定のエンドポイントへ確 実に送信する方法がなかった。実装の詳細、INVITEとREFER間におけるプ ロキシルーティングの変更など、多くの要因によって、REFERが誤った場 所に送信される。REFERを既存のダイアログで発信することで、ダイアロ グを確立したのと同じエンドポイントに到達するように確保した。 2. 既存の招待用法と、新しいダイアログでREFERを到達させることを関連付 ける方法は不明だった。一方、INVITEで使用したダイアログでREFERが送 信された場合、関連付けは明確だった。 3. ダイアログ外のREFERを認可することに懸案があった。ほとんどの実装で は、REFERの認可ポリシーは、INVITEの認可ポリシーと抱き合わせである (ほとんどの場合、「この呼を発呼した、またはこの呼に応答した」のみ に基づく)。 Globally Routable User Agent (UA) URIs (GRUUs) [9]は、特定のユーザー エージェントに到達するURIを提供するという方法で、特に問題1に対処する ために定義された。Target-Dialogヘッダーフィールド[10]は、問題2と3に 対処するために作成された。このヘッダーフィールドを使用すると、他のダ イアログのダイアログ識別子をリクエストで示すことができるようになる。 また、認可の判断に使用できる他のダイアログとの関連付けを提供する。 Join [11]とReplaces [8]も、問題1を解決するために使用できる。この技術 を使用すると、多数のエンドポイント(当該のエンドポイントを含む)に分岐 することを予想して、新しいリクエストがダイアログ外で送信される。この リクエストには、進行中のダイアログのダイアログ識別子が列挙されたヘッ ダーフィールドが含まれる。その識別子と一致するダイアログを保持するエ ンドポイントのみが、そのリクエストを受け入れる。リクエストの分岐先で ある他のエンドポイントは、エラーで応答する。このメカニズムは適度に堅 牢であり、失敗するのは、ダイアログ外のリクエストのルーティングロジッ クが変化した結果、当該のダイアログを保持するエンドポイントに新しいリ クエストが到達しなくなる場合のみである。 GRUUを使用して問題1に対処するという到達可能性の側面は、Join/Replacesと Target-Dialogのメカニズムが持つ「他のダイアログとの関連付け」の側面と 組み合わせることができる。ダイアログ外で送信されたREFERリクエストを GRUU宛てに送信し、受信側が使用すべきコンテキストの一部として既存のダイ アログを識別することができるようになる。Target-Dialogヘッダーフィール ドは、関連付けられているダイアログが列挙されたREFERに含めることができ る。図5に、ダイアログを再利用することなく転送を実現するための使用方法 を示す。簡単にするために、図とメッセージの詳細には、GRUUのルーティング Sparks Informational [Page 19] RFC 5057 Multiple Dialog Usages November 2007 に関わるexample.comのサーバーは示していない。この詳細については、[9]を 参照のこと。 Alice Bob Carol | | | | F1 INVITE (Bob's AOR) | | | Call-ID: (call-id one) | | | Contact: (Alice's-GRUU) | | |------------------------------->| | | F2 200 OK | | | To: <>;tag=totag1 | | | From: <>;tag=fromtag1 | | | Call-ID: (call-id one) | | | Contact: (Bob's-GRUU) | | |<-------------------------------| | | ACK | | |------------------------------->| | | : | | | (Bob places Alice on hold) | | | : | F3 INVITE (Carol's AOR) | | | Call-ID: (call-id two) | | | Contact: (Bob's-GRUU) | | |----------------------------->| | | F4 200 OK | | | To: <>;tag=totag2 | | | From: <>;tag=fromtag2 | | | Call-ID: (call-id two) | | | Contact: (Carol's-GRUU) | | |<-----------------------------| | | ACK | | |----------------------------->| | | : | | | (Bob places Carol on hold) | | F5 REFER (Alice's-GRUU) | : | | Call-ID: (call-id three) | | | Refer-To: (Carol's-GRUU) | | | Target-Dialog: (call-id one,totag1,fromtag1) | | Contact: (Bob's-GRUU) | | |<-------------------------------| | | 202 Accepted | | |------------------------------->| | Sparks Informational [Page 20] RFC 5057 Multiple Dialog Usages November 2007 | NOTIFY (Bob's-GRUU) | | | Call-ID: (call-id three) | | |------------------------------->| | | 200 OK | | |<-------------------------------| | | | | | F6 INVITE (Carol's-GRUU) | | Call-ID: (call-id four) | | Contact: (Alice's-GRUU) | |-------------------------------------------------------------->| | 200 OK | | Contact: (Carol's-GRUU) | |<--------------------------------------------------------------| | ACK | |-------------------------------------------------------------->| | | | | F7 NOTIFY (Bob's-GRUU) | | | Call-ID: (call-id three) | | |------------------------------->| | | 200 OK | | |<-------------------------------| | | BYE (Alice's-GRUU) | | | Call-ID: (call-id one) | | |<-------------------------------| BYE (Carol's-GRUU) | | | Call-ID: (call-id two) | | 200 OK |----------------------------->| |------------------------------->| 200 OK | | |<-----------------------------| | | | 図5: ダイアログの再利用なしの転送 メッセージF1で、AliceはBobを招待し、GRUUのサポートを示す(また、自分の GRUUを提示する)。 メッセージF1 (関連するフィールドを詳細に示し、他は省略) INVITE sip:bob@example.com SIP/2.0 Call-ID: 13jfdwer230jsdw@alice.example.com Supported: gruu Contact: Sparks Informational [Page 21] RFC 5057 Multiple Dialog Usages November 2007 メッセージF2はBobのGRUUをAliceに送信する。 メッセージF2 (関連するフィールドを詳細に示し、他は省略) Supported: gruu To: ;tag=totag1 From: ;tag=fromtag1 Contact: Bobは、AliceをCarrolに転送するために、Aliceを保留にし、INVITEをCarrol に送信する。CarrolとBobは、F1とF2の処理と同様に、GRUUのサポートをネゴ シエートする。 メッセージF3 (関連するフィールドを詳細に示し、他は省略) INVITE sip:carol@example.com SIP/2.0 Supported: gruu Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com Contact: メッセージF4 (関連するフィールドを詳細に示し、他は省略) SIP/2.0 200 OK Supported: gruu To: ;tag=totag2 From: ;tag=fromtag2 Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com Contact: Carrolに相談した後、BobはCarrolを保留にし、メッセージF5を使用してAlice をCarrolに回送する。このとき、Refer-To URIはCarrolのGRUUであり、メッ セージF1とは異なるContent-IDであることに注意(本文書では、Refer-Toヘッ ダーフィールドのURIは読みやすいように改行されているが、実際のメッセー ジでURLを改行すると無効になる)。 メッセージF5 (関連するフィールドを詳細に示し、他は省略) REFER sip:aanewmr203raswdf@example.com SIP/2.0 Call-ID: 39fa99r0329493asdsf3n@bob.example.com Refer-To: Target-Dialog: 13jfdwer230jsdw@alice.example.com; local-tag=fromtag1;remote-tag=totag1 Supported: gruu Contact: Sparks Informational [Page 22] RFC 5057 Multiple Dialog Usages November 2007 AliceはTarget-Dialogヘッダーフィールドの情報を使用して、Bobとの間で使 用中のダイアログとこのREFERが関連付けられていると判断する。Aliceは、 「この人物と通話するか?」という、ダイアログ内のREFERに使用したのと同じ 受信ポリシーを使用する状況になった。AliceはREFERを受け入れ、Bobに必須 のNOTIFYを即時に送信してから、メッセージF6でCarrolをINVITEする。 メッセージF6 (関連するフィールドを詳細に示し、他は省略) sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits) \ / \ / | | v v INVITE SIP/2.0 Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; to-tag=totag2;from-tag=fromtag2 Supported: gruu Contact: CarrolはAliceの招待を受け入れ、Bobとのダイアログ(招待用法)を置換し、F7 を使用して、REFERされたINVITEが作成したことをBobに通知する。 メッセージF7 (関連するフィールドを詳細に示し、他は省略) NOTIFY sip:boaiidfjjereis@example.com SIP/2.0 Subscription-State: terminated;reason=noresource Call-ID: 39fa99r0329493asdsf3n@bob.example.com Contact: Content-Type: message/sipfrag SIP/2.0 200 OK BobはBYEを使用して、AliceとCarrolの両方との招待用法を終了する。 7. セキュリティの考慮事項 1つのダイアログ内で複数の用法を処理することは複雑であり、何をすべきか が明確ではない状況が発生する。応答コードを不適切に選択すると、本文書 で説明したあいまいさによって通信の予期しない中断が発生する可能性があ る。また、このあいまいさは、特に未認証のリクエストや不適切な応答を挿 入するサードパーティによって悪用される可能性もある。 1つのダイアログ内で複数の用法を作成または許容することを実装で選択する Sparks Informational [Page 23] RFC 5057 Multiple Dialog Usages November 2007 場合、[1]のセキュリティの考慮事項(特に、リクエストの認証と応答の処理 に関する部分)に十分に注意する必要がある。 サービスの実装では、このようなあいまいな状況の中で、異なる選択を行う相 手側のサービスに与える影響について十分に考慮すべきである。複数の用法を 必要とするサービスでは、サービス側が破棄すべきと考えているダイアログ を、クライアントが破棄するのに失敗したときに、サービスとネットワークの 使用に与える影響について、特に注意する必要がある。複数の用法を許可して いないサービスの場合、たとえば1つの用法のみを破棄すべきときにダイアロ グ全体を破棄したクライアントに与える影響について考慮すべきである。不正 な動作をする多数のクライアントが自動的に複数の用法を作成しようとするネ ットワークに、サービスが配置される、という最悪のケースでは、雪崩的な再 起動と同様の再試行の嵐が発生する可能性がある。 8. まとめ 1つのダイアログ内で複数の用法を処理することは複雑であり、何をすべきか が明確ではない状況が発生する。 実装では、可能な限り、複数の用法になる状況を回避すべきである。新しいア プリケーションを設計する場合、複数の用法を導入すべきではない。 現在のところ、転送など、複数の用法が必要なSIPの実装は一部にあり、受け 入れられている。ただし、最近の研究、特にGRUUによって、このような実装は 不要になってきている。このような実装の規格をできるだけ早く改版して、1 つの用法のダイアログのみを使用するようにすべきである。 9. 謝辞 本文書のアイデアは、多数が参加したいくつかのIETFミーティングで改善され てきた。特に、Adam Roach、Alan Johnston、Ben Campbell、Cullen Jennings、Jonathan Rosenberg、Paul Kyzivat、およびRohan Mahyによる多大 な貢献があった。また、reSIProcateプロジェクトのメンバーとは、複数用法 のダイアログハンドラを実装する一方で、困難な問題と発見を共有した。 10. 有益な参考文献 [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] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006. Sparks Informational [Page 24] RFC 5057 Multiple Dialog Usages November 2007 [3] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [8] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, June 2006. [10] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. [11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. 著者の連絡先 Robert J. Sparks Estacado Systems EMail: RjS@estacado.net Sparks Informational [Page 25] RFC 5057 Multiple Dialog Usages November 2007 完全な著作権表記 Copyright (C) The IETF Trust (2007). 本文書は、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の原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2007年 ------------------------------------------------------------------------- Sparks Informational [Page 26]