[要約] RFC 5057は、セッション開始プロトコル（SIP）での複数のダイアログ使用に関するガイドラインを提供しています。このRFCの目的は、SIPのダイアログの使用方法を明確にし、効果的な通信を実現することです。
Network Working Group R. Sparks
Request for Comments: 5057 Estacado Systems
Category: Informational November 2007
Multiple Dialog Usages in the Session Initiation Protocol
セッション開始プロトコルでの複数のダイアログ使用
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
セッション開始プロトコル（SIP）のいくつかの方法は、ダイアログとして知られるエンドポイント間の関連を作成できます。これらの方法のいくつかは、既存のダイアログ内に異なるが関連する関連性を作成することもできます。これらの複数の関連性、またはダイアログの使用は、独立したライフサイクルがあるため、慎重に調整された処理が必要ですが、共通のダイアログ状態を共有します。複数のダイアログ使用法を正しく処理することは完全には理解されていません。理解されていることは、実装するのが難しいです。
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.
このメモは、複数のダイアログ使用を避けるべきだと主張しています。それは彼らの使用の代替案について議論し、現在それらを避けることができない要素の本質的な行動を明確にします。
This is an informative document and makes no normative statements of any kind.
これは有益な文書であり、いかなる種類の規範的な声明もしません。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4
3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 6
4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 9
4.1. Invite Usages . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 9
5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 9
5.1. A Survey of the Effect of Failure Responses on Usages
and Dialogs . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Transaction Timeouts . . . . . . . . . . . . . . . . . . . 15
5.3. Matching Requests to Usages . . . . . . . . . . . . . . . 16
5.4. Target Refresh Requests . . . . . . . . . . . . . . . . . 17
5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17
5.6. Refusing New Usages . . . . . . . . . . . . . . . . . . . 18
5.7. Replacing Usages . . . . . . . . . . . . . . . . . . . . . 18
6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 24
This is an informative document. It makes no normative statements of any kind. This document refines the concept of a dialog usage in the Session Initiation Protocol (SIP [1]), and discusses what led to its existence. It explores ambiguity associated with processing multiple dialog usages that share a dialog. In particular, it surveys the effect of SIP failure responses on transaction, dialog usage, and dialog state. This document will help the implementer understand what is required to process multiple dialog usages correctly, and will provide information for future standards-track work that will clarify RFC 3261 and other related documents. Finally, the document explores single-usage dialog alternatives (using SIP extensions) to multiple dialog usages.
これは有益なドキュメントです。それはいかなる種類の規範的な声明もしません。このドキュメントでは、セッション開始プロトコル（SIP [1]）でのダイアログ使用の概念を改善し、その存在につながったものについて説明します。ダイアログを共有する複数のダイアログ使用の処理に関連するあいまいさを探ります。特に、トランザクション、ダイアログの使用、およびダイアログ状態に対するSIP障害応答の効果を調査します。このドキュメントは、実装者が複数のダイアログ使用を正しく処理するために必要なものを理解するのに役立ち、RFC 3261およびその他の関連ドキュメントを明確にする将来の標準トラック作業の情報を提供します。最後に、ドキュメントでは、単一使用のダイアログの代替案（SIPエクステンションを使用）を複数のダイアログの使用法に探索します。
Several methods in SIP can establish a dialog. When they do so, they also establish an association between the endpoints within that dialog. This association has been known for some time as a "dialog usage" in the developer community. A dialog initiated with an INVITE request has an invite usage. A dialog initiated with a SUBSCRIBE request has a subscribe usage. A dialog initiated with a REFER request has a subscribe usage.
SIPのいくつかの方法は、ダイアログを確立できます。彼らがそうするとき、彼らはまた、そのダイアログ内のエンドポイント間の関連を確立します。この協会は、開発者コミュニティの「対話使用」としてしばらくの間知られています。招待リクエストで開始されたダイアログには、招待状の使用があります。サブスクライブリクエストで開始されたダイアログには、サブスクライブの使用があります。参照要求で開始されたダイアログには、購読使用があります。
Dialogs with multiple usages arise when a usage-creating action occurs inside an existing dialog. Such actions include accepting a REFER or SUBSCRIBE issued inside a dialog established with an INVITE request. Multiple REFERs within a dialog create multiple subscriptions, each of which is a new dialog usage sharing common dialog state. (Note that any REFER issued utilizing the subscription-suppression mechanism specified in [2] creates no new usage.) Similarly, an endpoint in a dialog established with an INVITE might subscribe to its peer's Key Press Markup Language (KPML) [3] and later issue a REFER, resulting in three dialog usages sharing common dialog state.
複数の使用法を持つダイアログは、既存のダイアログ内で使用法を作成するアクションが発生すると発生します。このようなアクションには、招待状リクエストで確立されたダイアログ内で発行された紹介または購読を受け入れることが含まれます。ダイアログ内の複数の参照複数のサブスクリプションは、それぞれが共通のダイアログ状態を共有する新しいダイアログ使用です。（[2]で指定されたサブスクリプションサプレーションメカニズムを使用して発行された紹介は、新しい使用法を作成しません。）同様に、招待状で確立されたダイアログのエンドポイントは、ピアのキープレスマークアップ言語（KPML）[3]に登録する可能性があります。後で紹介を発行し、3つのダイアログ使用が共通のダイアログ状態を共有します。
The common state in the dialog shared by any usages is exactly:
使用法で共有されるダイアログの共通の状態は、正確に次のとおりです。
o the Call-ID
o call-id
o the local Tag
o ローカルタグ
o the remote Tag
o リモートタグ
o the local CSeq
o 地元のCSEQ
o the remote CSeq
o リモートCSEQ
o the Route-set
o ルートセット
o the local contact
o ローカルコンタクト
o the remote target
o リモートターゲット
o the secure flag
o 安全なフラグ
Usages have state that is not shared in the dialog. For example, a subscription has a duration, along with other usage-specific state. Multiple subscriptions in the same dialog each have their own duration.
使用法には、ダイアログで共有されていない状態があります。たとえば、サブスクリプションには、他の使用状態固有の状態とともに期間があります。同じダイアログの複数のサブスクリプションには、それぞれ独自の期間があります。
A dialog comes into existence with the creation of the first usage, and continues to exist until the last usage is terminated (reference counting). Unfortunately, many of the usage management aspects of SIP, such as authentication, were originally designed with the implicit assumption that there was one usage per dialog. The resulting mechanisms have mixed effects, some influencing the usage, and some influencing the entire dialog.
ダイアログは、最初の使用法の作成とともに存在し、最後の使用法が終了するまで存在し続けます（参照カウント）。残念ながら、認証など、SIPの使用管理の側面の多くは、ダイアログごとに1つの使用法があるという暗黙の仮定で元々設計されていました。結果として生じるメカニズムには、さまざまな効果があり、使用に影響を与え、ダイアログ全体に影響を与えるものもあります。
The current specifications define two usages, invite and subscribe. A dialog can share up to one invite usage and arbitrarily many subscribe usages.
現在の仕様では、招待と購読という2つの使用法を定義します。ダイアログは、最大1つの招待状の使用法と任意の多くのサブスクライブの使用を共有できます。
Because RFC 3261 [1] states that user-agents should reuse Call-ID and increment CSeq across a series of registration requests (and that to-tags appear in register responses in some of the examples), some implementations have treated REGISTER as if it were in a dialog. However, RFC 3261 explicitly calls out that REGISTER does not create a dialog. A series of REGISTER requests does not create any usage or dialog. Similarly, PUBLISH [4] does not create any usage or dialog.
RFC 3261 [1]は、ユーザーエージェントが一連の登録要求（およびいくつかの例のレジスタ応答に表示されるタグが表示される）でコールアイドと増分CSEQを再利用する必要があると述べているため、いくつかの実装は登録をあたかも扱いました。ダイアログにありました。ただし、RFC 3261は、レジスタがダイアログを作成しないことを明示的に呼び出します。一連のレジスタリクエストでは、使用法やダイアログは作成されません。同様に、Publish [4]は使用法やダイアログを作成しません。
In Figure 1, Alice transfers a call she received from Bob to Carol. A dialog (and an invite dialog usage) between Alice and Bob comes into being with the 200 OK labeled F1. A second usage (a subscription to event refer) comes into being with the NOTIFY labeled F2. This second usage ends when the subscription is terminated by the NOTIFY transaction labeled F3. The dialog still has one usage (the invite usage), which lasts until the BYE transaction labeled F4. At this point, the dialog has no remaining usages, so it ceases to exist. Details of each of these messages are shown in Figure 2.
図1では、アリスはボブからキャロルに受け取った電話を転送します。アリスとボブの間のダイアログ（および招待ダイアログの使用）は、F1というラベルが付いた200 OKと一緒になります。2番目の使用法（イベント参照のサブスクリプション）は、Notify Labed F2とともに発生します。この2番目の使用法は、F3とラベル付けされたNotifyトランザクションによってサブスクリプションが終了すると終了します。ダイアログにはまだ1つの使用法（招待状使用）があり、これはF4とラベル付けされたBYEトランザクションまで続きます。この時点で、ダイアログには残りの使用法がないため、存在しなくなります。これらの各メッセージの詳細を図2に示します。
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- ------------>|---------------->| . |
Figure 1
図1
Message Details (abridged to show only dialog or usage details)
F1
SIP/2.0 200 OK
Call-ID: dialog1@bob.example.com
CSeq: 100 INVITE
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:aliceinstance@alice.example.com>
F2
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: refer
Call-ID: dialog1@bob.example.com
CSeq: 101 NOTIFY
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
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: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
Content-Type: message/sipfrag
SIP/2.0 200 OK
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: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
Figure 2
図2
In Figure 3, Alice subscribes to Bob's presence. For simplicity, assume Bob and Alice are both serving their presence from their endpoints instead of a presence server. To focus on the essential points, the figure leaves out any rendezvous signaling through which Alice discovers Bob's endpoint.
図3では、アリスはボブの存在を購読しています。簡単にするために、ボブとアリスがプレゼンスサーバーの代わりにエンドポイントから自分の存在を提供していると仮定します。本質的なポイントに焦点を当てるために、この図は、アリスがボブのエンドポイントを発見するランデブーシグナル伝達を除外します。
Bob is interested in Alice's presence too, so he subscribes to Alice (in most deployed presence/IM systems, people watch each other). He decides to skip the rendezvous step since he's already in a dialog with Alice, and sends his SUBSCRIBE inside that dialog (a few early SIMPLE clients behaved exactly this way).
ボブはアリスの存在にも興味があるので、彼はアリスに購読しています（ほとんどの展開された存在/IMシステムでは、人々はお互いを見ています）。彼はすでにアリスとの対話をしているので、ランデブーステップをスキップすることにし、その対話内に購読するようにサブスクライブします（いくつかの初期の単純なクライアントはまさにこのように動作しました）。
The dialog and its first usage comes into being at F1, which establishes Alice's subscription to Bob. Its second usage begins at F2, which establishes Bob's subscription to Alice. These two subscriptions are independent - they have distinct and different expirations, but they share all the dialog state.
ダイアログとその最初の使用法は、F1になり、AliceのBOBへのサブスクリプションを確立します。2番目の使用法はF2で始まり、ボブのアリスに対するサブスクリプションを確立します。これらの2つのサブスクリプションは独立しています - それらは明確で異なる有効期限がありますが、すべてのダイアログ状態を共有しています。
The first usage ends when Alice decides to unsubscribe at F3. Bob's subscription to Alice, and thus the dialog, continues to exist. Alice's UA must maintain this dialog state even though the subscription that caused it to exist in the first place is now over. The second usage ends when Alice decides to terminate Bob's subscription at F4 (she's probably going to reject any attempt on Bob's part to resubscribe until she's ready to subscribe to Bob again). Since this was the last usage, the dialog also terminates. Details of these messages are shown in Figure 4.
最初の使用法は、アリスがF3で登録解除することを決定したときに終了します。ボブのアリスへのサブスクリプション、したがってダイアログは存在し続けています。アリスのUAは、そもそも存在するサブスクリプションが終わったとしても、このダイアログ状態を維持する必要があります。2番目の使用法は、AliceがF4でボブのサブスクリプションを終了することを決定したときに終了します（彼女はおそらく、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- -->|<-------------------|
| |
Figure 3
図3
Message Details (abridged to show only dialog or usage details)
F1
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: presence
Subscription-State: active;expires=600
Call-ID: alicecallid1@alice.example.com
From: <sip:Bob@bob.example.com>;tag=bobtag2
To: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 100 NOTIFY
Contact: <sip:bobinstance@bob.example.com>
F2
NOTIFY sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Subscription-State: active;expires=1200
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 500 NOTIFY
Contact: <sip:aliceinstance@alice.example.com>
F3
SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Expires: 0
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 501 SUBSCRIBE
Contact: <sip:aliceinstance@alice.example.com>
F4
NOTIFY sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Subscription-State: terminated;reason=deactivated
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 502 NOTIFY
Contact: <sip:aliceinstance@alice.example.com>
Figure 4
図4
Dialogs come into existence along with their first usage. Dialogs terminate when their last usage is destroyed. The messages that create and destroy usages vary per usage. This section provides a high-level categorization of those messages. The section does not attempt to explore the REGISTER pseudo-dialog.
ダイアログは、最初の使用法とともに存在します。ダイアログは、最後の使用法が破壊されたときに終了します。使用法を作成および破壊するメッセージは、使用ごとに異なります。このセクションでは、これらのメッセージの高レベルの分類を提供します。このセクションでは、登録擬似ダイアログを探索しようとはしません。
Created by: non-100 provisional responses to INVITE; 200 response to INVITE
作成：招待への非100の暫定的な応答。招待への200の応答
Destroyed by: 200 responses to BYE; certain failure responses to INVITE, UPDATE, PRACK, INFO, or BYE; anything that destroys a dialog and all its usages
破壊：さようならに対する200の応答。招待、更新、プラック、情報、またはさようならの特定の障害応答。ダイアログとそのすべての使用法を破壊するもの
Created by: 200 class responses to SUBSCRIBE; 200 class responses to REFER; NOTIFY requests
作成：購読に対する200のクラス応答。参照への200のクラスの応答。リクエストに通知します
Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or refresh-SUBSCRIBE request timeout; certain failure responses to NOTIFY or SUBSCRIBE; expiration without refresh if network issues prevent the terminal NOTIFY from arriving; anything that destroys a dialog and all its usages
破壊された：通知を通知するための200のクラスの応答。リクエストタイムアウトを通知または更新します。通知または購読するための特定の障害応答。ネットワークの問題が端末の通知の到着を妨げている場合、更新なしで有効期限。ダイアログとそのすべての使用法を破壊するもの
The examples in Section 3 show straightforward cases where it is fairly obvious when the dialog begins and ends. Unfortunately, there are many scenarios where such clarity is not present. For instance, in Figure 1, what would it mean if the response to the NOTIFY (F2) were a 481? Does that simply terminate the refer subscription, or does it destroy the entire dialog? This section explores the problem areas with multiple usages that have been identified to date.
セクション3の例は、ダイアログが開始および終了するときにかなり明白である簡単なケースを示しています。残念ながら、そのような明確さが存在しない多くのシナリオがあります。たとえば、図1では、Notify（F2）への応答が481であった場合、それはどういう意味ですか？それは単に紹介サブスクリプションを終了しますか、それともダイアログ全体を破壊しますか？このセクションでは、これまでに特定された複数の使用法で問題領域を調査します。
For this survey, consider a subscribe usage inside a dialog established with an invite usage. Unless stated otherwise, we'll discuss the effect on each usage and the dialog when a client issuing a NOTIFY inside the subscribe usage receives a failure response (such as a transferee issuing a NOTIFY to event refer). Further, unless otherwise stated, the conclusions apply to arbitrary multiple usages. This survey is written from the perspective of a client receiving the error response. The effect on dialogs and usages at the server issuing the response is the same.
この調査では、招待状使用で確立されたダイアログ内の購読使用量を検討してください。特に明記しない限り、サブスクライブの使用法内で通知を発行するクライアントが障害応答を受け取る場合（イベントへの通知を発行する譲受人など）、各使用法とダイアログに対する影響について説明します。さらに、特に明記しない限り、結論は任意の複数の使用法に適用されます。この調査は、クライアントがエラー応答を受信したという観点から書かれています。応答を発行するサーバーでのダイアログと使用に対する影響は同じです。
3xx responses: Redirection mid-dialog is not well understood in SIP, but whatever effect it has impacts the entire dialog and all of its usages equally. In our example scenario, both the subscription and the invite usage would be redirected by this single response.
3XX応答：リダイレクトミッドダイアログはSIPではよく理解されていませんが、それがどのような効果があり、ダイアログ全体とそのすべての使用が等しく影響します。この例のシナリオでは、サブスクリプションと招待使用の両方がこの単一の応答によってリダイレクトされます。
For the failure responses with code 400 and greater, there are three common ways the failure can affect the transaction, usage, and dialog state.
コード400以上の障害応答の場合、障害がトランザクション、使用状況、およびダイアログ状態に影響を与える可能性のある3つの一般的な方法があります。
Transaction Only The error affects only the transaction, not the usage or dialog the transaction occurs in (beyond affecting the local CSeq). Any other usage of the dialog is unaffected. The error is a complaint about this transaction, not the usage or dialog that the transaction occurs in.
トランザクションエラーのみは、トランザクションのみに影響し、トランザクションが発生する（ローカルCSEQに影響を与えることを超えて）使用する使用またはダイアログではありません。ダイアログのその他の使用は影響を受けません。エラーは、このトランザクションに関する苦情であり、トランザクションが発生する使用法やダイアログではありません。
Destroys Usage The error destroys the usage, but not the dialog. Any other usages sharing this dialog are not affected.
使用の破壊エラーは使用状況を破壊しますが、ダイアログは破壊されません。このダイアログを共有する他の使用法は影響を受けません。
Destroys Dialog The error destroys the dialog and all usages sharing it.
ダイアログを破壊するエラーはダイアログを破壊し、それを共有するすべての使用法が破壊されます。
Table 1 and Table 2 display how the various codes affect transaction, usage, or dialog state. Response code specific comments or exceptions follow the table.
表1と表2は、さまざまなコードがトランザクション、使用状況、またはダイアログ状態にどのように影響するかを示しています。応答コード固有のコメントまたは例外は、テーブルに従います。
+----------------------+----------------+-----------------+
| Transaction Only | Destroys Usage | Destroys Dialog |
+----------------------+----------------+-----------------+
| 400 (or unknown 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 | | |
+----------------------+----------------+-----------------+
Table 1
表1
+---------+---------------------------------+-------------+-------+
| Code | Reason | Impact | Notes |
+---------+---------------------------------+-------------+-------+
| 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 | |
| 580 | Precondition Failure | Transaction | |
| 600/6xx | Busy Everywhere | Transaction | (17) |
| 603 | Decline | Transaction | |
| 604 | Does Not Exist Anywhere | Dialog | (2) |
| 606 | Not Acceptable | Transaction | |
+---------+---------------------------------+-------------+-------+
Table 2
表2
(1) 402 Payment Required: This is a reserved response code. If encountered, it should be treated as an unrecognized 4xx.
(1) 402支払いが必要：これは予約された応答コードです。遭遇した場合、認識されていない4xxとして扱う必要があります。
(2) 404 Not Found:
(2) 404お探しのページが見つかりませんでした：
410 Gone:
410 GONE：
416 Unsupported URI Scheme:
416サポートされていないURIスキーム：
484 Address Incomplete:
484アドレス不完全：
485 Ambiguous:
485あいまい：
604 Does Not Exist Anywhere:
604はどこにも存在しません：
The Request-URI that is being rejected is the remote target set by the Contact provided by the peer. Getting this response means that something has gone fundamentally wrong with the dialog state.
拒否されているリクエストURIは、ピアが提供する連絡先によって設定されたリモートターゲットです。この応答を取得することは、ダイアログ状態に何かが根本的に間違っていることを意味します。
(3) 405 Method Not Allowed:
(3) 405メソッドは許可されていません：
501 Not Implemented:
501実装されていない：
Either of these responses would be aberrant in our example scenario since support for the NOTIFY method is required by the usage. In this case, the UA knows the condition is unrecoverable and should stop sending NOTIFYs on the usage. Any refresh subscriptions should be rejected. In general, these errors will affect at most the usage. If the request was not integral to the usage (it used an unknown method, or was an INFO inside an INVITE usage, for example), only the transaction will be affected.
これらの応答のいずれかは、notifyメソッドのサポートが使用法で必要であるため、例のシナリオでは異常です。この場合、UAは条件が回復できないことを知っており、使用に関する通知の送信を停止する必要があります。更新サブスクリプションは拒否する必要があります。一般に、これらのエラーは最大の使用に影響します。リクエストが使用法に不可欠ではない場合（たとえば、不明な方法を使用したか、招待状の使用が施された情報であった場合、トランザクションのみが影響を受けます。
(4) 408 Request Timeout: Receiving a 408 will have the same effect on usages and dialogs as a real transaction timeout as described in Section 5.2.
(4) 408リクエストタイムアウト：408を受信すると、セクション5.2で説明されているように、実際のトランザクションタイムアウトと同じ効果が使用されます。
(5) 422 Session Interval Too Small: This response does not make sense for any mid-usage request. If it is received, an element in the path of the request is violating protocol, and the recipient should treat this as it would an unknown 4xx response.
(5) 422セッション間隔が小さすぎる：この応答は、中程度のリクエストでは意味がありません。受信した場合、リクエストのパス内の要素はプロトコルに違反しており、受信者は未知の4xx応答のようにこれを扱う必要があります。
(6) 429 Provide Referrer Identity: This response won't be returned to a NOTIFY as in our example scenario, but when it is returned to a REFER, it is objecting only to the REFER request itself.
(6) 429リファラーIDを提供する：この応答は、例のシナリオのように通知に返されることはありませんが、紹介に返されると、紹介要求自体にのみ反対します。
(7) 480 Temporarily Unavailable: RFC 3261 is unclear on what this response means for mid-usage requests. Future updates to that specification are expected to clarify that this response affects only the usage in which the request occurs. No other usages are affected. If the response included a Retry-After header field, further requests in that usage should not be sent until the indicated time has past. Requests in other usages may still be sent at any time.
(7) 480一時的に利用できません：RFC 3261は、この応答が中程度のリクエストに対して何を意味するのか不明です。その仕様の将来の更新は、この応答がリクエストが発生する使用法のみに影響することを明確にすることが期待されます。他の使用は影響を受けません。応答に再試行後のヘッダーフィールドが含まれている場合、指定された時間が過ぎるまでその使用法をさらに要求するべきではありません。他の使用法のリクエストは、いつでも送信される場合があります。
(8) 481 Call/Transaction Does Not Exist: This response indicates that the peer has lost its copy of the dialog usage state. The dialog itself should not be destroyed unless this was the last usage.
(8) 481コール/トランザクションは存在しません。この応答は、ピアがダイアログ使用状態のコピーを失ったことを示しています。ダイアログ自体は、これが最後の使用法でない限り、破壊されるべきではありません。
The effects of a 481 on a dialog and its usages are the most ambiguous of any final response. There are implementations that have chosen the meaning recommended here, and others that destroy the entire dialog without regard to the number of outstanding usages. Going forward with this clarification will allow those deployed implementations that assumed only the usage was destroyed to work with a wider number of implementations. Existing implementations that destroy all other usages in the dialog will continue to function as they do now, except that peers following the recommendation will attempt to do things with the other usages and this element will return 481s for each of them until they are all gone. However, the necessary clarification to RFC 3261 needs to make it very clear that the ability to terminate usages independently from the overall dialog using a 481 is not justification for designing new applications that count on multiple usages in a dialog.
ダイアログに対する481の効果とその使用法は、最終的な応答の中で最も曖昧です。ここで推奨される意味を選択した実装と、未解決の使用数に関係なくダイアログ全体を破壊する他の実装があります。この明確化を進めることで、使用量のみが破壊され、より多くの実装で動作すると想定される展開された実装が可能になります。ダイアログ内の他のすべての使用法を破壊する既存の実装は、現在もそうであるように機能し続けます。ただし、推奨に従うピアが他の使用法で物事を行おうとし、この要素はすべてがなくなるまでそれぞれに481を返します。ただし、RFC 3261の必要な明確化は、481を使用してダイアログ全体から独立して使用を終了する能力は、ダイアログ内の複数の使用法を考慮した新しいアプリケーションを設計するための正当化ではないことを明確にする必要があります。
The 481 response to a CANCEL request has to be treated differently. For CANCEL, a 481 means the UAS can't find a matching transaction. A 481 response to a CANCEL affects only the CANCEL transaction. The usage associated with the INVITE is not affected.
キャンセル要求に対する481の応答は、異なる方法で扱わなければなりません。キャンセルの場合、481はUASがマッチングトランザクションを見つけることができないことを意味します。キャンセルに対する481の応答は、キャンセルトランザクションのみに影響します。招待に関連する使用は影響を受けません。
(9) 482 Loop Detected: This response is aberrant mid-dialog. It will only occur if the Record-Route header field were improperly constructed by the proxies involved in setting up the dialog's initial usage, or if a mid-dialog request forks and merges (which should never happen). Future requests using this dialog state will also fail.
(9) 482ループが検出された：この応答は異常な途中で異常です。これは、ダイアログの最初の使用法のセットアップに関与するプロキシによってレコードルートヘッダーフィールドが不適切に構築された場合、またはミッドアダイアログリクエストのフォークとマージ（決して起こらないはずです）の場合にのみ発生します。このダイアログ状態を使用した将来のリクエストも失敗します。
An edge condition exists during RFC 3263 failover at the element sending a request, where the request effectively forks to multiple destinations from the client. Some implementations increase risk entering this edge condition by trying the next potential location as determined by RFC 3263 very rapidly if the first does not immediately respond. In any situation where a client sends the same request to more than one endpoint, it must be prepared to receive a response from each branch (and should choose a "best" response to act on following the same guidelines as a forking proxy). In this particular race condition, if multiple branches respond, all but one will most likely return a 482 Merged Request. The client should select the remaining non-482 response as the "best" response.
リクエストを送信する要素のRFC 3263フェールオーバー中にエッジ条件が存在し、リクエストはクライアントから複数の宛先に効果的にフォークされます。いくつかの実装は、最初の潜在的な位置を非常に迅速に試しているように、次の潜在的な場所を試して、最初の潜在的な場所を試して、このエッジ状態に入るリスクを高めます。クライアントが同じ要求を複数のエンドポイントに送信する状況では、各ブランチから応答を受信する準備をする必要があります（フォーキングプロキシと同じガイドラインに従って行動するための「最良の」応答を選択する必要があります）。この特定の人種条件では、複数のブランチが応答する場合、1つを除くすべてが482のマージされた要求を返す可能性が高いです。クライアントは、「最良の」応答として残りの非482応答を選択する必要があります。
(10) 483 Too Many Hops: Similar to 482, receiving this mid-dialog is aberrant. Unlike 482, recovery may be possible by increasing Max-Forwards (assuming that the requester did something strange like using a smaller value for Max-Forwards in mid-dialog requests than it used for an initial request). If the request isn't tried with an increased Max-Forwards, then the agent should follow the Destroy Dialog actions.
（10）483あまりにも多くのホップ：482と同様に、このミッドダイアログを受け取るのは異常です。482とは異なり、Max-Forwardsを増やすことで回復が可能になる場合があります（リクエスターは、最初のリクエストに使用されるよりもMid-DialogリクエストでMax-Forwardsに少ない値を使用するような奇妙なことをしたと仮定します）。マックスフォワードが増加してリクエストが試されていない場合、エージェントはDestroyダイアログアクションに従う必要があります。
(11) 486 Busy Here: This response is nonsensical in our example scenario, or in any scenario where this response comes inside an established usage. If it occurs in that context, it should be treated as an unknown 4xx response.
（11）486ここで忙しい：この応答は、例のシナリオ、またはこの応答が確立された使用法の中にあるシナリオで無意味です。そのコンテキストで発生する場合は、未知の4xx応答として扱う必要があります。
(12) 489 Bad Event: In our example scenario, [5] declares that the subscription usage in which the NOTIFY is sent is terminated. This response is only valid in the context of SUBSCRIBE and NOTIFY. UAC behavior for receiving this response to other methods is not specified, but treating it as an unknown 4xx is a reasonable practice.
（12）489悪いイベント：例のシナリオでは、[5]は、通知が送信されるサブスクリプションの使用が終了することを宣言しています。この応答は、購読と通知のコンテキストでのみ有効です。他の方法に対するこの応答を受信するためのUACの動作は指定されていませんが、それを未知の4xxとして扱うことは合理的な慣行です。
(13) 500 and 5xx unrecognized responses: If the response contains a Retry-After header field value, the server thinks the condition is temporary, and the request can be retried after the indicated interval. If the response does not contain a Retry-After header field value, the UA may decide to retry after an interval of its choosing or attempt to gracefully terminate the usage. Whether or not to terminate other usages depends on the application. If the UA receives a 500 (or unrecognized 5xx) in response to an attempt to gracefully terminate this usage, it can treat this usage as terminated. If this is the last usage sharing the dialog, the dialog is also terminated.
（13）500および5XXの認識されていない応答：応答に再試行後のヘッダーフィールド値が含まれている場合、サーバーは条件が一時的であると考え、指定されたインターバル後にリクエストを再試行することができます。応答に再試行後のヘッダーフィールド値が含まれていない場合、UAは、選択の間隔または使用を優雅に終了しようとする後に再試行することを決定する場合があります。他の使用法を終了するかどうかは、アプリケーションによって異なります。UAがこの使用法を優雅に終了しようとする試みに応じて500（または認識されていない5xx）を受け取った場合、この使用法を終了したように扱うことができます。これがダイアログを共有する最後の使用法である場合、ダイアログも終了します。
(14) 502 Bad Gateway: This response is aberrant mid-dialog. It will only occur if the Record-Route header field were improperly constructed by the proxies involved in setting up the dialog's initial usage. Future requests using this dialog state will also fail.
（14）502 Bad Gateway：この応答は異常な途中で異なります。これは、ダイアログの最初の使用法のセットアップに関与するプロキシによって、レコードルートヘッダーフィールドが不適切に構築された場合にのみ発生します。このダイアログ状態を使用した将来のリクエストも失敗します。
(15) 503 Service Unavailable: As per [6], the logic handling locating SIP servers for transactions may handle 503 requests (effectively, sequentially forking at the endpoint based on DNS results). If this process does not yield a better response, a 503 may be returned to the transaction user. Like a 500 response, the error is a complaint about this transaction, not the usage. Because this response occurred in the context of an established usage (hence an existing dialog), the route-set has already been formed and any opportunity to try alternate servers (as recommended in [1]) has been exhausted by the RFC3263 logic.
（15）503サービス利用不能：[6]によると、トランザクション用のSIPサーバーの検索を503リクエストを処理するロジック（DNSの結果に基づいてエンドポイントで順次分岐）を処理する場合があります。このプロセスでより良い応答が得られない場合、503がトランザクションユーザーに返される場合があります。500の応答のように、このエラーはこのトランザクションに関する苦情であり、使用法ではありません。この応答は確立された使用法（したがって既存のダイアログ）のコンテキストで発生したため、ルートセットはすでに形成されており、代替サーバー（[1]で推奨される）を試す機会がRFC3263ロジックによって使い果たされました。
(16) 504 Server Time-out: It is not obvious under what circumstances this response would be returned to a request in an existing dialog.
（16）504サーバーのタイムアウト：既存のダイアログでこの応答がどのような状況でリクエストに返されるかは明らかではありません。
(17) 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 response code says something about the recipient user, not the request that was made. This end user is stating an unwillingness to communicate. If the response contains a Retry-After header field value, the user is indicating willingness to communicate later and the request can be retried after the indicated interval. This usage, and any other usages sharing the dialog are unaffected. If the response does not contain a Retry-After header field value, the UA may decide to retry after an interval of its choosing or attempt to gracefully terminate the usage. Whether or not to terminate other usages depends on the application. If the UA receives a 600 (or unrecognized 6xx) in response to an attempt to gracefully terminate this usage, it can treat this usage as terminated. If this is the last usage sharing the dialog, the dialog is also terminated.
（17）600および6XXの認識されていない応答：400の悪い要求とは異なり、600の応答コードは、受信者ユーザーについて何かを述べています。このエンドユーザーは、通信したくないと述べています。応答に再試行後のヘッダーフィールド値が含まれている場合、ユーザーは後で通信する意欲を示しており、指定された間隔の後にリクエストを再試行することができます。この使用法、およびダイアログを共有するその他の使用法は影響を受けません。応答に再試行後のヘッダーフィールド値が含まれていない場合、UAは、選択の間隔または使用を優雅に終了しようとする後に再試行することを決定する場合があります。他の使用法を終了するかどうかは、アプリケーションによって異なります。UAがこの使用法を優雅に終了しようとする試みに応じて600（または認識されていない6xx）を受け取った場合、この使用法を終了したように扱うことができます。これがダイアログを共有する最後の使用法である場合、ダイアログも終了します。
[1] states that a UAC should terminate a dialog (by sending a BYE) if no response is received for a request sent within a dialog. This recommendation should have been limited to the invite usage instead of the whole dialog. [5] states that a timeout for a NOTIFY removes a subscription, but a SUBSCRIBE that fails with anything other than a 481 does not. Given these statements, it is unclear whether a refresh SUBSCRIBE issued in a dialog shared with an invite usage destroys either usage or the dialog if it times out.
[1] ダイアログ内で送信されたリクエストに対して応答がない場合、UACはダイアログを（Byeを送信することによって）終了する必要があると述べています。この推奨事項は、ダイアログ全体ではなく招待状の使用に限定されている必要があります。[5]は、通知のタイムアウトでサブスクリプションを削除するが、481以外のもので失敗するサブスクライブはそうではないと述べています。これらのステートメントを考えると、招待状の使用法と共有されたダイアログで発行された更新サブスクライブが使用されるか、それがタイムアウトした場合にダイアログのいずれかを破壊するかどうかは不明です。
Generally, a transaction timeout should affect only the usage in which the transaction occurred. Other uses sharing the dialog should not be affected. In the worst case of timeout due to total transport failure, it may require multiple failed messages to remove all usages from a dialog (at least one per usage).
一般に、トランザクションタイムアウトは、トランザクションが発生した使用法のみに影響する必要があります。ダイアログを共有する他の使用は、影響を受けるべきではありません。総輸送の故障によるタイムアウトの最悪の場合、ダイアログからすべての使用法を削除するために複数の失敗したメッセージが必要になる場合があります（使用ごとに少なくとも1つ）。
There are some mid-dialog messages that never belong to any usage. If they timeout, they will have no effect on the dialog or its usages.
使用に属することのないミッドダイアログメッセージがいくつかあります。タイムアウトの場合、ダイアログやその使用には影響しません。
For many mid-dialog requests, identifying the usage they belong to is obvious. A dialog can have at most one invite usage, so any INVITE, UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER requests belong to can be determined from the Event header field of the request. REGISTER requests within a (pseudo)-dialog belong to the registration usage. (As mentioned before, implementations aren't mixing registration usages with other usages, so this document isn't exploring the consequences of that bad behavior).
多くの中間追放のリクエストでは、それらが属する使用法を特定することは明らかです。ダイアログには、最大で1つの使用法を招待することができるため、招待、更新、プラック、ACK、キャンセル、バイ、または情報リクエストが属します。使用状況（つまり、特定のサブスクリプション）は、リクエストに属するリクエストを購読、通知、および紹介するリクエストを要求のイベントヘッダーフィールドから決定できます。（pseudo）-dialog内の登録要求は、登録の使用に属します。（前述のように、実装は登録の使用と他の使用法を混合していないため、このドキュメントはその悪い動作の結果を調査していません）。
According to [1], "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". Thus, OPTIONS does not belong to any usage. Only those failures discussed in Section 5.1 and Section 5.2 that destroy entire dialogs will have any effect on the usages sharing the dialog with a failed OPTIONS request.
[1]によると、「ダイアログ内で受信したオプションリクエストは、ダイアログの外部で構築されたものと同一であり、そのダイアログに影響を与えない200 OK応答を生成します」。したがって、オプションは使用に属していません。ダイアログ全体を破壊するセクション5.1およびセクション5.2で議論されているこれらの障害のみが、失敗したオプション要求でダイアログを共有する使用法に影響を与えます。
MESSAGE requests are discouraged inside a dialog. Implementations are restricted from creating a usage for the purpose of carrying a sequence of MESSAGE requests (though some implementations use it that way, against the standard recommendation). A failed MESSAGE occurring inside an existing dialog will have similar effects on the dialog and its usages as a failed OPTIONS request.
メッセージリクエストはダイアログ内で落胆します。実装は、一連のメッセージリクエストを実行する目的で使用法を作成することから制限されています（ただし、一部の実装は、標準的な推奨事項に対してそのように使用します）。既存のダイアログ内で発生するメッセージの失敗は、ダイアログとその使用に同様の効果があり、オプションリクエストに失敗します。
Mid-dialog requests with unknown methods cannot be matched with a usage. Servers will return a failure response (likely a 501). The effect on the dialog and its usages at either the client or the server should be similar to that of a failed OPTIONS request.
未知のメソッドを使用したMid-Dialogリクエストは、使用法と一致することはできません。サーバーは障害応答（おそらく501）を返します。クライアントまたはサーバーのいずれかでのダイアログとその使用に対する影響は、失敗したオプション要求の効果と同様である必要があります。
These guidelines for matching messages to usages (or determining there is no usage) apply equally when acting as a UAS, a UAC, or any third party tracking usage and dialog state by inspecting all messages between two endpoints.
メッセージを使用するためのこれらのガイドライン（または、使用法がない決定）を一致させるためのガイドラインは、2つのエンドポイント間のすべてのメッセージを検査することにより、UAS、UAC、またはサードパーティの追跡使用とダイアログ状態として機能する場合に等しく適用されます。
Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER [7]).
ターゲット更新リクエストは、ダイアログのリモートターゲットが正常に処理されたときに更新されます。現在定義されているターゲットの更新要求は、招待、更新、購読、通知、[7]を参照します。
The remote target is part of the dialog state. When a target refresh request affects it, it affects it for ALL usages sharing that dialog. If a subscription and invite usage are sharing a dialog, sending a refresh SUBSCRIBE with a different contact will cause reINVITEs from the peer to go to that different contact.
リモートターゲットはダイアログ状態の一部です。ターゲット更新要求がそれに影響する場合、そのダイアログを共有するすべての使用法に対してそれに影響します。サブスクリプションと招待状の使用がダイアログを共有している場合、別の連絡先で更新サブスクライブを送信すると、ピアからのラインバイトがその異なる連絡先に移動します。
A UAS will only update the remote target if it sends a 200 class response to a target refresh request. A UAC will only update the remote target if it receives a 200 class response to a target refresh request. Again, any update to a dialog's remote target affects all usages of that dialog.
UASは、ターゲット更新リクエストに200クラスの応答を送信する場合にのみ、リモートターゲットを更新します。UACは、ターゲット更新リクエストに対する200クラスの応答を受信した場合にのみ、リモートターゲットを更新します。繰り返しますが、ダイアログのリモートターゲットの更新は、そのダイアログのすべての使用に影響します。
There is known ambiguity around the effects of provisional responses on remote targets that a future specification will attempt to clarify. Furthermore, because the remote target is part of the dialog state, not any usage state, there is ambiguity in having target refresh requests in progress simultaneously on multiple usages in the same dialog. Implementation designers should consider these conditions with care.
将来の仕様が明確にしようとするリモートターゲットに対する暫定的な応答の影響については、既知のあいまいさがあります。さらに、リモートターゲットは使用状況状態ではなくダイアログ状態の一部であるため、同じダイアログの複数の使用法でターゲット更新リクエストを同時に進行させることにはあいまいさがあります。実装デザイナーは、これらの条件を注意して考慮する必要があります。
Subscription and registration usages expire over time and must be refreshed (with a refresh SUBSCRIBE, for example). This expiration is usage state, not dialog state. If several subscriptions share a dialog, refreshing one of them has no effect on the expiration of the others.
サブスクリプションと登録の使用は時間の経過とともに期限切れになり、更新する必要があります（たとえば、更新サブスクライブで）。この有効期限は、ダイアログ状態ではなく使用状態です。いくつかのサブスクリプションがダイアログを共有している場合、そのうちの1つをリフレッシュすると、他のサブリックの有効期限には影響しません。
Normal termination of a usage has no effect on other usages sharing the same dialog. For instance, terminating a subscription with a NOTIFY/Subscription-State: terminated will not terminate an invite usage sharing its dialog. Likewise, ending an invite usage with a BYE does not terminate any active Event: refer subscriptions established on that dialog.
使用法の通常の終了は、同じダイアログを共有する他の使用法に影響を与えません。たとえば、notify/subscription-state：終了したサブスクリプションを終了すると、ダイアログを共有する招待状の使用が終了しません。同様に、BYEで招待状使用を終了しても、アクティブなイベントは終了しません。そのダイアログで確立されたサブスクリプションを参照してください。
As the survey of the effect of failure responses shows, care must be taken when refusing a new usage inside an existing dialog. Choosing the wrong response code will terminate the dialog and all of its usages. Generally, returning a 603 Decline is the safest way to refuse a new usage.
障害応答の効果の調査が示すように、既存のダイアログ内の新しい使用法を拒否するときは注意が必要です。間違った応答コードを選択すると、ダイアログとそのすべての使用法が終了します。一般的に、603の減少を返すことは、新しい使用を拒否する最も安全な方法です。
[8] defines a mechanism through which one usage can replace another. It can be used, for example, to associate the two dialogs in which a transfer target is involved during an attended transfer. It is written using the term "dialog", but its intent was only to affect the invite usage of the dialog it targets. Any other usages inside that dialog are unaffected. For some applications, the other usages may no longer make sense, and the application may terminate them as well.
[8] ある使用法が別の使用法を置き換えるメカニズムを定義します。たとえば、参加した転送中に転送ターゲットが関与する2つのダイアログを関連付けるために使用できます。「ダイアログ」という用語を使用して書かれていますが、その意図は、対象とするダイアログの招待状の使用にのみ影響することでした。そのダイアログ内のその他の使用は影響を受けません。一部のアプリケーションでは、他の使用法が意味をなさない場合があり、アプリケーションも同様に終了する場合があります。
However, the interactions between Replaces and multiple dialog usages have not been well explored. More discussion of this topic is needed. Implementers should avoid this scenario completely.
ただし、交換と複数のダイアログ使用の間の相互作用は十分に調査されていません。このトピックの詳細については、必要です。実装者は、このシナリオを完全に回避する必要があります。
Processing multiple usages correctly is not completely understood. What is understood is difficult to implement and is very likely to lead to interoperability problems. The best way to avoid the trouble that comes with such complexity is to avoid it altogether.
複数の使用法を正しく処理することは完全には理解されていません。理解されていることは、実装が困難であり、相互運用性の問題につながる可能性が非常に高いです。このような複雑さに伴うトラブルを回避する最良の方法は、それを完全に回避することです。
When designing new applications or features that use SIP dialogs, do not require endpoints to construct multiple usages to participate in the application or use the feature. When designing endpoints, address the existing multiple usage scenarios as best as possible. Outside those scenarios, if a peer attempts to create a second usage inside a dialog, refuse it.
SIPダイアログを使用する新しいアプリケーションまたは機能を設計する場合、アプリケーションに参加するか、機能を使用するために複数の使用法を構築するためにエンドポイントを必要としません。エンドポイントを設計するときは、既存の複数の使用シナリオを可能な限り最善の方法で扱います。これらのシナリオの外では、ピアがダイアログ内で2番目の使用法を作成しようとする場合は、それを拒否します。
Unfortunately, there are existing applications, like transfer, that currently entail multiple usages, so the simple solution of "don't do it" will require some transitional work. This section looks at the pressures that led to these existing multiple usages and suggests alternatives.
残念ながら、転送などの既存のアプリケーションが現在複数の使用法を伴うため、「Do n't Do It」の単純な解決策には、いくらかの移行作業が必要になります。このセクションでは、これらの既存の複数の使用法につながった圧力を調べ、代替案を提案します。
When executing a transfer, the transferor and transferee currently share an invite usage and a subscription usage within the dialog between them. This is a result of sending the REFER request within the dialog established by the invite usage. Implementations were led to this behavior by these primary problems: 1. There was no way to ensure that a REFER on a new dialog would reach the particular endpoint involved in a transfer. Many factors, including details of implementations and changes in proxy routing between an INVITE and a REFER could cause the REFER to be sent to the wrong place. Sending the REFER down the existing dialog ensured it got to the same endpoint with which the dialog was established.
転送を実行すると、譲渡人と譲受人は現在、それらの間のダイアログ内で招待状の使用法とサブスクリプションの使用を共有しています。これは、招待状の使用法によって確立されたダイアログ内で紹介要求を送信した結果です。実装は、これらの主要な問題によってこの動作に導かれました。1。新しいダイアログの参照が転送に関係する特定のエンドポイントに到達することを保証する方法はありませんでした。実装の詳細や招待状と紹介の間のプロキシルーティングの変更など、多くの要因により、紹介が間違った場所に送られる可能性があります。参照を既存のダイアログに送信すると、ダイアログが確立されたのと同じエンドポイントに到達しました。
2. It was unclear how to associate an existing invite usage with a REFER arriving on a new dialog, where it was completely obvious what the association was when the REFER came on the invite usage's dialog.
2. 既存の招待状の使用法を新しいダイアログに到着する紹介に関連付ける方法は不明でした。ここでは、紹介が招待状の使用法のダイアログで紹介されたときに協会が何であるかが完全に明らかでした。
3. There were concerns with authorizing out-of-dialog REFERs. The authorization policy for REFER in most implementations piggybacks on the authorization policy for INVITE (which is, in most cases, based simply on "I placed or answered this call").
3. 外れている言及の許可に懸念がありました。ほとんどの実装での紹介の認可ポリシーは、招待のための承認ポリシーに関するピギーバック（ほとんどの場合、単に「この呼び出しを配置または回答した」に基づいています）。
Globally Routable User Agent (UA) URIs (GRUUs) [9] have been defined specifically to address problem 1 by providing a URI that will reach one specific user-agent. The Target-Dialog header field [10] was created to address problems 2 and 3. This header field allows a request to indicate the dialog identifiers of some other dialog, providing association with the other dialog that can be used in an authorization decision.
グローバルにルーティング可能なユーザーエージェント（UA）URIS（Gruus）[9]は、特定のユーザーエージェントに到達するURIを提供することにより、問題1に対処するために特に定義されています。ターゲットダイアログヘッダーフィールド[10]は、問題2および3に対処するために作成されました。このヘッダーフィールドは、他のダイアログのダイアログ識別子を示すリクエストを許可し、認証決定で使用できる他のダイアログとの関連を提供します。
The Join [11] and Replaces [8] mechanisms can also be used to address problem 1. When using this technique, a new request is sent outside any dialog with the expectation that it will fork to possibly many endpoints, including the one we're interested in. This request contains a header field listing the dialog identifiers of a dialog in progress. Only the endpoint holding a dialog matching those identifiers will accept the request. The other endpoints the request may have forked to will respond with an error. This mechanism is reasonably robust, failing only when the routing logic for out-of-dialog requests changes such that the new request does not arrive at the endpoint holding the dialog of interest.
Join [11]および置き換え[8]メカニズムは、問題1に対処するために使用することもできます。この手法を使用する場合、新しいリクエストは、おそらく私たちを含む多くのエンドポイントにフォークすることを期待して、すべてのダイアログの外に送信されます。このリクエストには、進行中のダイアログのダイアログ識別子をリストするヘッダーフィールドが含まれています。これらの識別子に一致するダイアログを保持しているエンドポイントのみがリクエストを受け入れます。他のエンドポイントは、リクエストがフォークした可能性があり、エラーで応答します。このメカニズムはかなり堅牢であり、ダイアログ外のリクエストのルーティングロジックが変更され、新しいリクエストが関心のあるダイアログを保持しているエンドポイントに到達しないように変更された場合にのみ失敗します。
The reachability aspects of using a GRUU to address problem 1 can be combined with the association-with-other-dialogs aspects of the Join/ Replaces and Target-Dialog mechanisms. A REFER request sent out-of-dialog can be sent towards a GRUU, and identify an existing dialog as part of the context the receiver should use. The Target-Dialog header field can be included in the REFER listing the dialog this REFER is associated with. Figure 5 sketches how this could be used to achieve transfer without reusing a dialog. For simplicity, the diagram and message details do not show the server at example.com that will be involved in routing the GRUU. Refer to [9] for those details.
Gruuを使用して問題1に対処するための到達可能な側面は、結合/交換およびターゲットダイアログメカニズムの他者の側面との関連性と組み合わせることができます。dialogから送信された参照要求は、Gruuに向けて送信し、受信者が使用するコンテキストの一部として既存のダイアログを識別できます。ターゲットダイアログヘッダーフィールドは、これが関連付けられているダイアログのリストに含めることができます。図5は、ダイアログを再利用せずに転送を達成するためにこれを使用する方法をスケッチします。簡単にするために、図とメッセージの詳細は、Gruuのルーティングに関与する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 | |
|------------------------------->| |
| 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 |
| |<-----------------------------|
| | |
Figure 5: Transfer without dialog reuse
図5：ダイアログの再利用なしで転送します
In message F1, Alice invites Bob indicating support for GRUUs (and offering a GRUU for herself):
メッセージF1では、アリスはBobを招待してGruusのサポートを示しています（そして自分のためにGruuを提供します）：
Message F1 (abridged, detailing pertinent fields)
メッセージF1（要約、適切なフィールドの詳細）
INVITE sip:bob@example.com SIP/2.0
Call-ID: 13jfdwer230jsdw@alice.example.com
Supported: gruu
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Message F2 carries Bob's GRUU to Alice.
メッセージF2はボブのグルーをアリスに運びます。
Message F2 (abridged, detailing pertinent fields)
メッセージF2（要約、適切なフィールドの詳細）
SIP/2.0 200 OK
Supported: gruu
To: <sip:bob@example.com>;tag=totag1
From: <sip:alice@example.com>;tag=fromtag1
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Bob decides to try to transfer Alice to Carol, so he puts Alice on hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU support similar to what happened in F1 and F2.
ボブはアリスをキャロルに移そうとすることにしたので、アリスを保留にしてキャロルに招待を送ります。キャロルとボブは、F1とF2で起こったことと同様のGruuサポートを交渉します。
Message F3 (abridged, detailing pertinent fields)
メッセージF3（要約、適切なフィールドの詳細）
INVITE sip:carol@example.com SIP/2.0
Supported: gruu
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Message F4 (abridged, detailing pertinent fields)
メッセージF4（要約、適切なフィールドの詳細）
SIP/2.0 200 OK
Supported: gruu
To: <sip:carol@example.com>;tag=totag2
From: <sip:bob@example.com>;tag=fromtag2
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)>
After consulting Carol, Bob places her on hold and refers Alice to her using message F5. Notice that the Refer-To URI is Carol's GRUU, and that this is on a different Call-ID than message F1. (The URI in the Refer-To header is line-broken for readability in this document; it would not be valid to break the URI this way in a real message.)
キャロルに相談した後、ボブは彼女を保留にし、メッセージF5を使用してアリスを彼女に紹介します。URIへの紹介はキャロルのGruuであり、これはメッセージF1とは異なるCall-IDにあることに注意してください。（参照ヘッダーのURIは、このドキュメントの読みやすさのためにラインブレイクされています。実際のメッセージでこの方法でURIを破ることは有効ではありません。）
Message F5 (abridged, detailing pertinent fields)
メッセージF5（要約、適切なフィールドの詳細）
REFER sip:aanewmr203raswdf@example.com SIP/2.0
Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Refer-To: <sip:carol@example.com;g=urn:uid:(Carol's UA's bits)
?Replaces=23rasdnfoa39i4jnasdf@bob.example.com;
to-tag=totag2;from-tag=fromtag2>
Target-Dialog: 13jfdwer230jsdw@alice.example.com;
local-tag=fromtag1;remote-tag=totag1
Supported: gruu
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Alice uses the information in the Target-Dialog header field to determine that this REFER is associated with the dialog she already has in place with Bob. Alice is now in a position to use the same admission policy she used for in-dialog REFERs: "Do I have a call with this person?". She accepts the REFER, sends Bob the obligatory immediate NOTIFY, and proceeds to INVITE Carol with message F6.
アリスは、ターゲットダイアログヘッダーフィールドの情報を使用して、この紹介がボブと既に導入されているダイアログに関連付けられていると判断します。アリスは現在、彼女がダイアログ内に使用したのと同じ入場ポリシーを使用する立場にあります：「私はこの人に電話がありますか？」。彼女は紹介を受け入れ、ボブに必須の即時通知を送り、メッセージF6でキャロルを招待します。
Message F6 (abridged, detailing pertinent fields)
メッセージ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: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Carol accepts Alice's invitation to replace her dialog (invite usage) with Bob, and notifies him that the REFERenced INVITE succeeded with F7:
キャロルは、アリスの対話（招待状の使用）をボブに置き換えるというアリスの招待を受け入れ、参照された招待がF7で成功したことを彼に通知します。
Message F7 (abridged, detailing pertinent fields)
メッセージF7（要約、適切なフィールドの詳細）
NOTIFY sip:boaiidfjjereis@example.com SIP/2.0
Subscription-State: terminated;reason=noresource
Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Content-Type: message/sipfrag
SIP/2.0 200 OK
SIP/2.0 200 OK
Bob then ends his invite usages with both Alice and Carol using BYEs.
ボブは、招待状の使用法を終了し、アリスとキャロルの両方を使用して使用します。
Handling multiple usages within a single dialog is complex and introduces scenarios where the right thing to do is not clear. The ambiguities described here can result in unexpected disruption of communication if response codes are chosen carelessly. Furthermore, these ambiguities could be exploited, particularly by third-parties injecting unauthenticated requests or inappropriate responses. Implementations choosing to create or accept multiple usages within a dialog should give extra attention to the security considerations in
単一のダイアログ内で複数の使用法を処理することは複雑であり、正しいことが明確ではないシナリオを紹介します。ここで説明するあいまいさは、応答コードが不注意に選択された場合、予期しないコミュニケーションの混乱をもたらす可能性があります。さらに、これらのあいまいさは、特に、無慈悲な要求または不適切な応答を注入するサードパーティによって活用される可能性があります。ダイアログ内で複数の使用法を作成または受け入れることを選択する実装は、セキュリティの考慮事項に特に注意を払う必要があります
[1], especially those concerning the authenticity of requests and processing of responses.
[1]、特にリクエストの信頼性と応答の処理に関するもの。
Service implementations should carefully consider the effects on their service of peers making different choices in these areas of ambiguity. A service that requires multiple usages needs to pay particular attention to the effect on service and network utilization when a client fails to destroy a dialog the service believes should be destroyed. A service that disallows multiple usages should consider the effect on clients that, for instance, destroy the entire dialog when only a usage should be torn down. In the worst case of a service deployed into a network with a large number of misbehaving clients trying to create multiple usages in an automated fashion, a retry storm similar to an avalanche restart could be induced.
サービスの実装は、これらの曖昧さの分野でさまざまな選択をする仲間のサービスへの影響を慎重に検討する必要があります。複数の使用法を必要とするサービスは、クライアントがサービスが破壊されるべきであると考えているダイアログを破壊することに失敗した場合、サービスとネットワークの利用に対する影響に特に注意を払う必要があります。複数の使用法を許可するサービスは、たとえば、使用法のみを取り壊す必要がある場合にダイアログ全体を破壊するクライアントへの影響を考慮する必要があります。自動化された方法で複数の使用法を作成しようとする多数の不正行為クライアントとともに、ネットワークに展開されたサービスの最悪の場合、雪崩の再起動に似た再試行嵐を誘導することができました。
Handling multiple usages within a single dialog is complex and introduces scenarios where the right thing to do is not clear. Implementations should avoid entering into multiple usages whenever possible. New applications should be designed to never introduce multiple usages.
単一のダイアログ内で複数の使用法を処理することは複雑であり、正しいことが明確ではないシナリオを紹介します。実装は、可能な限り複数の使用法を入力することを避ける必要があります。新しいアプリケーションは、複数の使用法を導入しないように設計する必要があります。
There are some accepted SIP practices, including transfer, that currently require multiple usages. Recent work, most notably GRUU, makes those practices unnecessary. The standardization of those practices and the implementations should be revised as soon as possible to use only single-usage dialogs.
現在、複数の使用法が必要な、転送を含むいくつかの受け入れられているSIPプラクティスがあります。最近の研究、特にGruuは、これらの慣行を不必要にしています。これらのプラクティスと実装の標準化は、単一使用ダイアログのみを使用するためにできるだけ早く修正する必要があります。
The ideas in this document have been refined over several IETF meetings with many participants. Significant contribution was provided by Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate project also shared their difficulties and discoveries while implementing multiple-usage dialog handlers.
このドキュメントのアイデアは、多くの参加者とのいくつかのIETF会議で洗練されています。Adam Roach、Alan Johnston、Ben Campbell、Cullen Jennings、Jonathan Rosenberg、Paul Kyzivat、およびRohan Mahyによって重要な貢献が提供されました。Resiprocate Projectのメンバーは、複数の使用ダイアログハンドラーを実装しながら、困難と発見も共有しました。
[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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[2] Levin、O。、「セッション開始プロトコルの抑制（SIP）は、メソッドの暗黙的なサブスクリプションを参照」、RFC 4488、2006年5月。
[3] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[3] Burger、E。and M. Dolly、「キープレス刺激用のセッション開始プロトコル（SIP）イベントパッケージ（KPML）」、RFC 4730、2006年11月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[4] Niemi、A。、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」、RFC 3903、2004年10月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[8] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[8] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, June 2006.
[9] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2006年6月、進行中の作業。
[10] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[10] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による承認を要求する」、RFC 4538、2006年6月。
[11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[11] Mahy、R。およびD. Petrie、「セッション開始プロトコル（SIP）」「Header」に参加、RFC 3911、2004年10月。
Author's Address
著者の連絡先
Robert J. Sparks Estacado Systems
ロバート・J・スパークス・エスタカド・システム
EMail: RjS@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。