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でのいくつかの方法がダイアログを確立することができます。彼らがそうすると、彼らはまた、そのダイアログ内のエンドポイント間の関連付けを確立します。この関連付けは、開発者コミュニティの「ダイアログの使用」など、いくつかの時間のために知られています。 INVITEリクエストで開始ダイアログが招待用法を持っています。 SUBSCRIBEリクエストで開始ダイアログが加入し、使用しています。 REFERリクエストで開始ダイアログが加入し、使用しています。
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.
利用作成アクションは既存のダイアログ内で発生したときに、複数の用法との対話が発生します。このような行為は、参照するか、INVITEリクエストを確立し、ダイアログ内で発行されたSUBSCRIBEを受け入れています。複数のは、新しいダイアログの使用の共有コモンダイアログの状態で、それぞれが複数のサブスクリプションを作成ダイアログ内指します。 （[2]何の新しい使用を作成しないで指定されたサブスクリプション・抑制機構を利用いずれかが発行され参照していることに注意してください。）同様に、INVITEで確立ダイアログで、エンドポイントをそのピアのキーを押してマークアップ言語（KPML）に加入する可能性がある[3]と後で共通のダイアログ状態を共有する3つのダイアログの用途で、その結果、REFERを発行します。
The common state in the dialog shared by any usages is exactly:
任意の用途で共有ダイアログで共通の状態は正確に次のとおりです。
o the Call-ID
OコールID
o the local Tag
ローカルタグO
o the remote Tag
リモートタグO
o the local CSeq
地元のCSeq O
o the remote CSeq
リモートのCSeq O
o the Route-set
ルートセットO
o the local contact
地元接触O
o the remote target
リモートターゲットO
o the secure flag
secureフラグ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の利用管理面、の多くは、もともとダイアログごとに利用状況があったことを暗黙の前提に設計されていました。得られたメカニズムは、いくつかの使用に影響を与える、そしていくつかは全体の対話に影響を与える、効果を混合しました。
The current specifications define two usages, invite and subscribe. A dialog can share up to one invite usage and arbitrarily many subscribe usages.
現在の仕様は、二つの用法、招待し、購読を定義します。ダイアログには、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]ユーザーエージェントは-IDを呼び出し、登録要求のシリーズを横切ってのCSeqを増分再利用すべきであると述べているので（にタグおよびその例のいくつかのレジスタの応答に表示される）、いくつかの実装は、それかのようにREGISTERを処理していますダイアログにありました。しかし、RFC 3261を明示的にREGISTERがダイアログを作成しないことを呼び出します。 REGISTER要求のシリーズは、任意の利用状況やダイアログを作成しません。同様に、任意の使用またはダイアログを作成しない[4] PUBLISH。
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では、アリスはキャロルにボブから受信したコールを転送します。アリスとボブの間で対話（と招待ダイアログの使用）は200 OKラベルされたF1と一緒にいることになります。第2の使用（参照イベントへのサブスクリプション）は、NOTIFY標識F2を有することになります。サブスクリプションがF3ラベルNOTIFYトランザクションによって終了した場合、この第2の使用が終了します。ダイアログはまだF4ラベルBYEトランザクションまで続く1回の使用（招待用法）を、持っています。この時点で、ダイアログには、残りの用法を持っていないので、それは存在しなくなります。これらのメッセージのそれぞれの詳細は、図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>
メッセージの詳細（のみダイアログまたは使用状況の詳細を示すために簡略）F1 SIP / 2.0 200 OKのCall-ID：dialog1@bob.example.comのCSeq：100に招待<SIP：Alice@alice.example.com>;タグ= alicetag1 From：<SIP：Bob@bob.example.com>;タグ= bobtag1連絡先：<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>
F2は、SIPのNOTIFY：aliceinstance@alice.example.com SIP / 2.0イベント：dialog1@bob.example.comのCSeq：101にNOTIFY：コールID参照<SIP：Alice@alice.example.com>;タグ= alicetag1から：<SIP：Bob@bob.example.com>;タグ= bobtag1連絡先：<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
aliceinstance@alice.example.com SIP / 2.0イベント：F3は、SIPのNOTIFYサブスクリプションのステートを参照してください。終了し、その理由を= NORESOURCEコールID：dialog1@bob.example.comのCSeq：102に通知するために：<SIP：アリス@アリス。 example.com>;タグ= alicetag1から：<SIP：Bob@bob.example.com>;タグ= bobtag1連絡先：<SIP：bobinstance@bob.example.com>のContent-Type：メッセージ/ 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>
F4 BYE SIP：aliceinstance@alice.example.com SIP / 2.0のCall-ID：dialog1@bob.example.comのCSeq：103 BYE：<SIP：Alice@alice.example.com>;タグ= alicetag1から<SIP ：Bob@bob.example.com>;タグ= bobtag1連絡先：<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システムでは、人々はお互いを見て）アリスに加入しています。彼はアリスとダイアログですでにだからランデブーステップをスキップすることを決定し、そして彼の（少数の初期のSIMPLEクライアントはまさにこのように振る舞った）、そのダイアログ内SUBSCRIBE送信します。
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、であることになります。その第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は、それが最初の場所に存在することが原因とサブスクリプションは、今以上であっても、このダイアログの状態を維持する必要があります。アリスはF4でボブのサブスクリプションを終了することを決定したときに、第2の使用法は、（彼女はおそらく彼女が再びボブに加入する準備になるまで再サブスクライブするには、ボブの一部上の任意の試行を拒否するだろう）を終了します。これが最後の使用だったので、ダイアログも終了します。これらのメッセージの詳細については、図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>
メッセージの詳細（のみダイアログまたは使用状況の詳細を示すために簡略）F1 SIP NOTIFY：aliceinstance@alice.example.com SIP / 2.0イベント：プレゼンス購読ステート：アクティブと、有効期限が切れる= 600のCall-ID：alicecallid1@alice.example.comから：<SIP：Bob@bob.example.com>;タグ=へbobtag2：<SIP：Alice@alice.example.com>;タグ= alicetag2ののCSeq：連絡先をNOTIFY 100：<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>
bobinstance@bob.example.com SIP / 2.0イベント：プレゼンス購読ステート：F2 SIPのNOTIFY活性、有効期限が切れる= 1200のCall-ID：alicecallid1@alice.example.comに<SIP：Bob@bob.example.com> <一口：Alice@alice.example.com>;タグ= alicetag2ののCSeq：;から= bobtag2タグ500は、連絡先をNOTIFY：<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>
bobinstance@bob.example.com SIP / 2.0イベント：F3 SIPのSUBSCRIBE存在は有効期限：0のCall-ID：alicecallid1@alice.example.comに<SIP：Bob@bob.example.com>;からタグ= bobtag2。 <SIP：Alice@alice.example.com>;タグ= alicetag2用のCSeq：501はSUBSCRIBE問い合わせ：<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>
F4は、SIP NOTIFY：bobinstance@bob.example.comをSIP / 2.0イベント：プレゼンスサブスクリ - 状態：終了し、理由=非アクティブ化のCall-ID：alicecallid1@alice.example.comへ：<SIP：Bob@bob.example.com> <SIP：Alice@alice.example.com>;タグ= alicetag2用のCSeq：;より= bobtag2タグ502が接触NOTIFY <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.
ダイアログには、彼らの最初の使用とともに存在に入って来ます。彼らの最後の使用が破棄されたときのダイアログが終了します。用法を作成し、破壊したメッセージは、使用ごとに異なります。このセクションでは、これらのメッセージの高レベルの分類を提供します。セクションでは、REGISTER擬似ダイアログを探求しようとしません。
Created by: non-100 provisional responses to INVITE; 200 response to INVITE
作成者：INVITEに対する非100暫定応答。 INVITEに対する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
破壊：BYEへの200の応答。 、UPDATE、PRACK、INFO、またはBYEを招待する特定の障害応答。ダイアログとそのすべての用法を破壊するもの
Created by: 200 class responses to SUBSCRIBE; 200 class responses to REFER; NOTIFY requests
作成者：購読する200クラスの応答; 200クラスの応答は、参照すること。 NOTIFYリクエストを
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
破壊：NOTIFY-終了する200クラスの応答;要求タイムアウトを通知したりリフレッシュSUBSCRIBE。 NOTIFYまたは購読するには、特定の障害応答。リフレッシュなしの有効期限ネットワークの問題は、端末が到着からNOTIFY防ぐ場合。ダイアログとそのすべての用法を破壊するもの
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の例では、ダイアログが開始され、終了したとき、それはかなり明白である簡単な例を示しています。残念ながら、このような透明性が存在していない多くのシナリオがあります。 NOTIFY（F2）に対する応答が481であれば、例えば、図1に、それが何を意味しますか？単に参照するサブスクリプションを終了するか、それが全体のダイアログを破壊しないことにしていますか？このセクションでは、現在までに同定されている複数の用途で問題領域を探ります。
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.
今回の調査では、招待用法を確立し、ダイアログ内のサブスクライブの使用を検討してください。特に断りのない限り発行したクライアントは、サブスクライブの使用内NOTIFYとき、私たちは、それぞれの使用量に影響し、ダイアログを説明します（たとえば、参照してイベントにNOTIFYを発行する譲渡など）失敗応答を受け取ります。特に断りのない限りさらに、結論は任意の複数の用途に適用されます。この調査は、エラー応答を受信するクライアントの視点から書かれています。応答を発行するサーバーで、ダイアログや用法上の効果は同じです。
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はゴーン：
416 Unsupported URI Scheme:
416サポートされていないURIスキーム：
484 Address Incomplete:
不完全484の住所：
485 Ambiguous:
485あいまい：
604 Does Not Exist Anywhere:
604 Anywhereは存在しません：
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.
拒否されているのRequest-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は、状態が回復不能であると使用上のNOTIFYの送信を停止しなければならない知っています。任意のリフレッシュサブスクリプションは拒否されなければなりません。一般的に、これらのエラーは、ほとんどの使い方で影響します。リクエストが（それは未知の方法を使用し、または例えば、INVITE用法内部INFOだった）の使用に不可欠でなかった場合は、唯一のトランザクションは影響を受けます。
(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要求タイムアウト：5.2節で説明したように408を受け取るには、実際のトランザクションタイムアウトなどの用途およびダイアログの同じ効果を持つことになります。
(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は、リファラーのアイデンティティを提供します。この応答は、私たちの例のシナリオのようにNOTIFYに返却されることはありませんが、それが参照するために返されたときに、それだけでREFER要求自体に反対しています。
(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の効果は、最終的な応答の中で最も曖昧です。優れた使用回数に関係なく、全体のダイアログを破壊し、ここで推奨の意味を選択しているの実装、などがあります。のみを想定使用は実装の広い数で動作するように破壊されたそれらの展開の実装が可能になり、この明確化と今後。彼らが今そうであるように、ダイアログ内の他のすべての使用状況を破壊する既存の実装は推奨に従ってピアが他の用途で物事を行うにしようとすると、それらがすべてなくなるまで、この要素は、それらのそれぞれの481sを返すことを除いて、機能し続けます。ただし、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.
CANCELリクエストへの481応答が異なる扱いをする必要があります。キャンセルの場合は、481はUASが一致するトランザクションを見つけることができませんを意味します。 CANCELへの481応答は、CANCELトランザクションに影響します。 INVITEに関連付けられた使用には影響しません。
(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ループが検出されました：この応答は、ダイアログ中の異常です。 Record-Routeヘッダーフィールドが正しくダイアログの初期使用量を設定する際に必要プロキシによって構築した場合にのみ発生します、または場合、ダイアログ中のリクエストのフォークと（発生しません）マージ。このダイアログの状態を使用して、将来の要求も失敗します。
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.
(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とは異なり、回復は（依頼者は、それが最初の要求のために使用されるよりも、ダイアログ中のリクエストのマックス・フォワードのために小さな値を使用してのような奇妙な何かをしたと仮定して）マックス・フォワードを増やすことも可能です。要求が増加したマックス・転送してみましたされていない場合、エージェントは破棄ダイアログアクションに従ってください。
(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] NOTIFYしたサブスクリプションの使用が終了すると送信されていることを宣言します。この応答は、SUBSCRIBEとNOTIFYのコンテキストでのみ有効です。指定されていない他の方法には、この応答を受信し、未知の4xxとしてそれを治療するためにUACの動作は、合理的なやり方です。
(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
（13）500及び5xxの未認識の応答：応答はリトライ後ヘッダフィールド値が含まれている場合、サーバは、条件が一時的であると考え、そして要求が指示された間隔の後に再試行することができます。応答は、再試行の後ヘッダフィールド値が含まれていない場合、UAは、その選択した間隔の後に再試行するか、または正常使用を終了しようとすることを決定することができます。他の用途を終了するか否かは、アプリケーションに依存します。もし
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.
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不正なゲートウェイ：この応答は、ダイアログ中の異常です。 Record-Routeヘッダーフィールドが正しくダイアログの初期使用量を設定する際に必要プロキシによって構築された場合にのみ発生します。このダイアログの状態を使用して、将来の要求も失敗します。
(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サービスを使用できません：1として[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
[1] UACは、応答がダイアログ内で送信された要求のために受信されない場合（BYEを送信することによって）ダイアログを終了すべきであると述べています。この勧告は、招待用法の代わりに、ダイアログ全体に限定されている必要があります。 [5] NOTIFYのタイムアウトを削除することを述べて
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.
サブスクリプションが、それはない481以外の何かで失敗しSUBSCRIBEを。これらの文を考えると、リフレッシュは、ダイアログで発行されたSUBSCRIBEかどうかは不明である招待用法と共有して、それならばタイムアウトに使用方法やダイアログのいずれかを破壊します。
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が使用を招待することができますので、任意のは、UPDATE、PRACKは、ACKは、BYE、CANCEL、またはINFO要求はそれに属し、INVITE。使用（すなわち、特定のサブスクリプション）は、SUBSCRIBE、NOTIFY、及びREFER要求は、要求のイベントヘッダフィールドから決定することが可能に属します。 （擬似）内のREGISTER要求は、登録の使用に属し-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]によれば、「OPTIONS要求は、ダイアログ内で受信ダイアログの外側に構成したものと同じであり、そのダイアログ上の任意の影響を持っていない200 OK応答を生成します」。このため、オプションは任意の使用にも属していません。全体のダイアログを破壊し、5.1節と5.2節で述べたもののみ失敗は失敗したOPTIONS要求との対話を共有する用法上の任意の効果があります。
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.
MESSAGEリクエストはダイアログ内で落胆しています。実装は、（いくつかの実装がそのようにそれを使用しても、標準の勧告に対して、）MESSAGE要求のシーケンスを運ぶ目的のために使用を作成することが制限されています。既存のダイアログ内で発生失敗したメッセージは、失敗したOPTIONS要求としてダイアログとその用法についても同様の効果を持つことになります。
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.
未知のメソッドを持つミッドダイアログの要求は、使用して一致させることができません。サーバは失敗応答（おそらく501）を返します。ダイアログおよびクライアントまたはサーバのいずれかで、その用法への影響は失敗したOPTIONS要求のものと類似していなければなりません。
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.
UAS、UAC、または2つのエンドポイント間のすべてのメッセージを検査することによって使用して、ダイアログの状態を追跡する第三者として動作するとき用途へのメッセージに一致する（または全く使用がない決定）のためにこれらのガイドラインは、等しく適用されます。
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]).
それらが正常に処理されているときに、ターゲットリフレッシュリクエストはダイアログのリモートターゲットを更新します。現在定義されているターゲットリフレッシュ要求は、INVITE UPDATE、SUBSCRIBE、NOTIFY、及び指す[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.
リモートターゲットは、ダイアログ状態の一部です。ターゲットリフレッシュ要求がそれに影響を及ぼした場合は、そのダイアログを共有するすべての用途のためにそれに影響を与えます。サブスクリプションの場合と使用法を招待してダイアログを共有している、別の連絡先とのSUBSCRIBEリフレッシュを送信することは、ピアからreINVITEsは、異なる連絡先に行くことになります。
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.
それは、ターゲットリフレッシュ要求に200クラスの応答を送信した場合UASは、リモートターゲットを更新します。それは、ターゲットリフレッシュ要求に200クラスの応答を受信した場合、UACは、リモートターゲットを更新します。ここでも、ダイアログのリモートターゲットへの更新は、そのダイアログのすべての使用に影響を与えます。
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.
サブスクリプションと登録の用途は、（例えば、リフレッシュしてSUBSCRIBE）時間の経過とともに失効し、リフレッシュしなければなりません。この有効期限は、使用状態ではなく、対話状態です。複数のサブスクリプションは、ダイアログを共有している場合、それらのいずれかをリフレッシュすることは、他の有効期限には影響を与えません。
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 /サブスクリプションのステートとサブスクリプション終了：終了すると、そのダイアログを共有する招待の使用を終了しません。同様に、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.
残念ながら、現在、複数の用法を伴う転送などの既存のアプリケーションは、ありますので、「それをしない」の簡単な解決策は、いくつかの移行作業が必要になります。このセクションでは、これらの既存の複数の用途につながった圧力を見て、代替案を提案します。
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:
転送を実行する場合、譲渡人と譲受人は、現在、招待利用状況とそれらの間のダイアログ内のサブスクリプションの使用状況を共有しています。これは、招待の使用によって確立されたダイアログ内REFERリクエストを送信した結果です。実装は、これらの主要な問題により、この動作につながりました。
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.転送に関与する特定のエンドポイントに到達する新しいダイアログで参照することを確実にする方法はありませんでした。 INVITEとREFER間のプロキシルーティングでの実装や変更の詳細を含む多くの要因が、REFERが間違った場所に送信される可能性があります。既存のダイアログをダウンREFER送信すると、それはダイアログが確立されたと同じエンドポイントに着い確保しました。
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.既存のREFER REFERを招待し、使用者のダイアログに来たとき会合が何であったか、完全には明らかだった新しいダイアログ、に到着して使用状況を招待を関連付ける方法不明でした。
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.アウトオブダイアログ参照許可との懸念がありました。ほとんどの実装でREFERのための承認ポリシーは、（単に、「私はこのコールを置いたり答え」に基づいて、ほとんどの場合、ある）INVITEの認可ポリシーに便乗します。
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）のURI（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.
[8]のメカニズムは、この技術を使用する場合は、新しい要求が、それは我々が「1を含むと、おそらく多くのエンドポイントを、フォークすることを期待して任意のダイアログ外で送信され、問題1に対処するためにも使用することができる[11]に参加し、置き換え興味を持って再。この要求は、進行中のダイアログのダイアログ識別子をリストヘッダフィールドが含まれています。これらの識別子に一致するダイアログを保持する唯一のエンドポイントは、要求を受け入れます。他のエンドポイントは、要求がエラーで応答しますし、フォークした可能性があります。このメカニズムは、アウトオブダイアログのルーティングロジックは変更は、このような新しい要求が関心のダイアログを保持しているエンドポイントに到達していないことを要求した場合にのみ失敗し、合理的に堅牢です。
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.
問題1を解決するためにGRUUを使用する到達可能性側面が参加/置き換え、ターゲット対話メカニズムのアソシエーションと、他方のダイアログの態様と組み合わせることができます。アウトオブダイアログ送信REFER要求は、GRUUに向けて送信し、受信機が使用すべきコンテキストの一部として、既存のダイアログを識別することができます。ターゲット対話ヘッダフィールドはこのREFERダイアログをリストREFERに含めることができると関連しています。このダイアログを再利用せずに転送を達成するために使用することができる方法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において、アリスはボブが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)>
SIPのINVITE：bob@example.com SIP / 2.0のCall-ID：13jfdwer230jsdw@alice.example.comサポート：GRUU問い合わせ：<SIP：alice@example.com; GR = URN：UUID：（アリスのUAのビット）>
Message F2 carries Bob's GRUU to Alice.
メッセージF2はアリスにボブのGRUUを運びます。
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)>
SIPサポート/ 2.0 200 OK：GRUUへ：<SIP：bob@example.com>;タグ= totag1から：<SIP：alice@example.com>;タグ= fromtag1連絡先：<SIP：bob@example.com; GR = URN：UUID：（ボブのUAのビット）>
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.
ボブは、キャロルにアリスを転送しようとすることを決定したので、彼は保留にアリスを置き、キャロルにINVITEを送信します。キャロルとボブは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)>
carol@example.com SIP / 2.0がサポートされている：コールIDをGRUU：23rasdnfoa39i4jnasdf@bob.example.com問い合わせ：<; GR = URN bob@example.com：UUID：（ボブのUAのビット）SIP> SIPのINVITE
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)>
SIPサポート/ 2.0 200 OK：GRUUへ：<SIP：carol@example.com>;タグ= totag2から：<SIP：bob@example.com>;タグ= fromtag2のCall-ID：23rasdnfoa39i4jnasdf@bob.example.com問い合わせ<SIP：carol@example.com; GR = URN：UUID：（キャロルのUAのビット）>
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とは異なるコールIDであることことに注意してください。 （参照してください-Toヘッダー内の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.
アリスは、これはボブのある場所で、彼女はすでに持っているダイアログに関連付けられている参照することを決定するために、ターゲット対話ヘッダフィールド内の情報を使用しています。 「私はこの人と電話を持っていますか？」：アリスは言及彼女は、対話のために使用したのと同じ入場ポリシーを使用する立場になりました。彼女はボブが義務即時NOTIFY送信し、REFER受け入れ、メッセージF6でキャロルをINVITEに進みます。
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)>
SIP：carol@example.com;グラム= URN：UUID：（キャロルのUAのビット）\ / \ / | | V V SIP / 2.0コールIDをINVITE：4zsd9f234jasdfasn3jsad@alice.example.comは置き換え：23rasdnfoa39i4jnasdf@bob.example.com。タグ= totag2; = fromtag2がサポートからタグ：GRUU問い合わせ：<SIP：alice@example.com; GR = URN：UUID：（アリスのUAのビット）>
Carol accepts Alice's invitation to replace her dialog (invite usage) with Bob, and notifies him that the REFERenced INVITE succeeded with F7:
キャロルは、ボブと（使用状況を招待）彼女のダイアログを置き換えるために、アリスの招待を受諾し、参照をF7に成功したINVITEことを彼に通知します。
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
39fa99r0329493asdsf3n@bob.example.com連絡先：：<SIP：alice@example.com;グラム= URN：UUID：（アリス;：boaiidfjjereis@example.com SIP / 2.0サブスクリプションのステート：理由=コールIDをNORESOURCE終了一口NOTIFY UAのビット）>のContent-Type：メッセージ/ 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ミーティングの上に洗練されています。重要な貢献は、アダムローチ、アラン・ジョンストン、ベン・キャンベル、カレン・ジェニングス、ジョナサン・ローゼンバーグ、ポールKyzivat、ローハンマーイによって提供されました。複数使用ダイアログ・ハンドラを実装しながら、reSIProcateプロジェクトのメンバーも、その難しさや発見を共有しました。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[2]レヴィン、O.、RFC 4488、2006年5月 "セッション開始プロトコル（SIP）の抑制は、メソッドの暗黙の契約をREFER"。
[3] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
[3]バーガー、E.およびM.ドリー、 "Aセッション開始プロトコル（SIP）キーを押して刺激のためのイベントパッケージ（KPML）"、RFC 4730、2006年11月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[4]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）：SIPサーバの検索"、RFC 3263、2002年6月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] 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]マーイ、R.、ビッグス、B.、およびR.ディーンを、 "セッション開始プロトコル（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]ローゼンバーグ、J.、進歩、2006年6月に仕事 "セッション開始プロトコル（SIP）におけるグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
[10] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
、RFC 4538、2006年6月[10]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）におけるダイアログ識別介して要求承認"。
[11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[11]マーイ、R.とD.ペトリー、 "セッション開始プロトコル（SIP）は、 "" ヘッダ"、RFC 3911、2004年10月に参加しましょう。
Author's Address
著者のアドレス
Robert J. Sparks Estacado Systems
ロバート・J・スパークスシステムズEstacado
EMail: RjS@estacado.net
メールアドレス：RjS@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。