Network Working Group R. Sparks
Request for Comments: 5057 Estacado Systems
Category: Informational November 2007
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
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
SIP中有几种方法可以建立对话。这样做时，它们还可以在该对话框中的端点之间建立关联。这种关联在开发人员社区中被称为“对话用法”，已有一段时间了。使用INVITE请求启动的对话框具有INVITE用法。通过订阅启动的对话框
request has a subscribe usage. A dialog initiated with a REFER request has a subscribe usage.
请求具有订阅用法。使用REFER请求启动的对话框具有subscribe用法。
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请求建立的对话框中发出的REFER或SUBSCRIBE。对话框中的多个引用创建多个订阅，每个订阅都是共享公共对话框状态的新对话框用法。（请注意，使用[2]中指定的订阅抑制机制发出的任何引用都不会产生新的用法。）类似地，使用INVITE建立的对话框中的端点可能会订阅其对等方的按键标记语言（KPML）[3]，然后发出引用，从而导致三种对话框用法共享公共对话框状态。
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
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的许多使用管理方面（如身份验证）最初都是在隐式假设下设计的，即每个对话框有一个使用。产生的机制有多种效果，有些影响使用，有些影响整个对话框。
The current specifications define two usages, invite and subscribe. A dialog can share up to one invite usage and arbitrarily many subscribe usages.
当前的规范定义了两种用法，invite和subscribe。一个对话框最多可以共享一个invite用法和任意多个subscribe用法。
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（在一些示例中，to标记出现在寄存器响应中），所以一些实现将寄存器视为在对话框中。然而，RFC3261显式地调用寄存器不创建对话框。一系列注册请求不会创建任何用法或对话框。类似地，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中，Alice将从Bob接到的电话转接给Carol。Alice和Bob之间的一个对话框（以及一个邀请对话框用法）出现了，200 OK标记为F1。第二种用法（订阅事件引用）与标记为F2的NOTIFY一起出现。当订阅被标记为F3的NOTIFY事务终止时，第二次使用结束。对话框仍然有一种用法（invite用法），这种用法一直持续到标记为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- ------------>|---------------->| . |
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>
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>
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
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正常
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
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中，Alice同意Bob的存在。为简单起见，假设Bob和Alice都从其端点而不是状态服务器为其状态提供服务。为了关注要点，图中省略了Alice发现Bob端点的任何会合信号。
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).
Bob也对Alice的状态感兴趣，所以他订阅了Alice（在大多数部署的状态/即时通讯系统中，人们互相观看）。他决定跳过集合步骤，因为他已经在与Alice的对话中，并在该对话中发送他的订阅（一些早期的简单客户端就是这样做的）。
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的订阅。它的第二个用法从F2开始，它建立了Bob对Alice的订阅。这两个订阅是独立的-它们有不同的过期时间，但它们共享所有对话框状态。
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
当Alice决定在F3退订时，第一次使用结束。Bob订阅了Alice，因此对话框仍然存在。Alice的UA必须保持此对话框状态，即使最初导致它存在的订阅现在已结束。第二种用法在Alice决定终止Bob的
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.
在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- -->|<-------------------|
| |
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>
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>
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>
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>
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个对BYE的回复；邀请、更新、恶作剧、信息或拜拜的某些失败响应；任何破坏对话框及其所有用法的东西
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
在本次调查中，考虑使用邀请使用的对话框内的订阅使用。除非另有说明，否则我们将讨论在subscribe用法中发出NOTIFY的客户端收到失败响应（例如受让方发出NOTIFY to event refer）时对每个用法和对话框的影响。此外，除非另有说明，否则结论适用于任意多种用途。本调查是从客户接受调查的角度编写的
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响应：重定向mid对话框在SIP中没有得到很好的理解，但它的任何效果都会对整个对话框及其所有用法产生同等的影响。在我们的示例场景中，订阅和invite使用都将通过这个响应重定向。
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或更高的故障响应，有三种常见的方式可以影响事务、使用和对话框状态。
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 | | |
+----------------------+----------------+-----------------+
+----------------------+----------------+-----------------+
| 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 | |
+---------+---------------------------------+-------------+-------+
| 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 | |
+---------+---------------------------------+-------------+-------+
| 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不存在于任何地方：
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知道该情况是不可恢复的，应该停止发送有关使用情况的NOTIFY。应拒绝任何刷新订阅。通常，这些错误最多会影响使用。如果请求不是用法的一部分（例如，它使用了未知方法，或者是INVITE用法中的一个信息），则只有事务会受到影响。
(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提供referer标识：这个响应不会像我们的示例场景中那样返回给NOTIFY，但是当它返回给referer时，它只反对referer请求本身。
(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响应进行不同的处理。对于CANCEL，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故障切换期间，在发送请求的元素处存在边缘条件，其中请求有效地从客户端分叉到多个目的地。如果RFC 3263确定的下一个潜在位置没有立即响应，则某些实现会非常迅速地尝试下一个潜在位置，从而增加进入该边缘条件的风险。在任何情况下，当客户端向多个端点发送相同的请求时，它必须准备好接收来自每个分支的响应（并且应该选择“最佳”响应，以遵循与分叉代理相同的准则）。在这种特殊的竞争条件下，如果多个分支响应，除了一个分支外，其他所有分支都很可能返回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不同，恢复可能通过增加最大转发数实现（假设请求者做了一些奇怪的事情，比如在中间对话请求中使用比初始请求中使用的最大转发数更小的值）。如果未使用增加的最大转发尝试请求，则代理应遵循销毁对话框操作。
(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]声明发送通知的订阅使用被终止。此响应仅在SUBSCRIBE和NOTIFY上下文中有效。未指定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
（13） 500和5xx无法识别的响应：如果响应包含头字段值Retry After，则服务器认为该条件是临时的，并且可以在指定的时间间隔后重试请求。如果响应不包含头字段值后重试，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坏网关：此响应是异常的mid对话。只有当设置对话框初始使用时涉及的代理不正确地构造了“记录路由头”字段时，才会发生这种情况。将来使用此对话框状态的请求也将失败。
(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响应一样，错误是对该事务的投诉，而不是对使用的投诉。由于此响应发生在已确定用途的上下文中（因此存在一个对话框），因此路由集已经形成，RFC3263逻辑已经耗尽了尝试备用服务器（如[1]中建议的）的任何机会。
(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响应代码表示收件人用户的某些信息，而不是发出的请求。此最终用户表示不愿意沟通。如果响应包含Retry After标头字段值，则用户表示愿意稍后进行通信，并且可以在指定的间隔后重试请求。此用法以及共享对话框的任何其他用法不受影响。如果响应不包含头字段值后重试，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] 声明通知的超时将删除
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以外的任何东西失败的订阅都不会失败。考虑到这些语句，不清楚在与invite用法共享的对话框中发出的刷新订阅是否会破坏用法或对话框超时。
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).
通常，事务超时应该只影响事务发生时的使用情况。共享对话框的其他用途不应受到影响。在由于总传输失败而导致超时的最坏情况下，可能需要多条失败的消息来删除对话框中的所有用法（每个用法至少一条）。
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.
有些mid对话框消息从不属于任何用途。如果它们超时，则对对话框或其用法没有影响。
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).
对于许多mid对话请求，识别它们所属的用法是显而易见的。一个对话框最多可以有一个邀请用法，因此任何邀请、更新、PRACK、确认、取消、再见或信息请求都属于该对话框。订阅、通知和引用请求所属的用法（即特定订阅）可以从请求的事件头字段中确定。（伪）对话框中的注册请求属于注册用途。（如前所述，实现没有将注册用法与其他用法混用，因此本文档没有探讨这种不良行为的后果）。
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对话框请求无法与用法匹配。服务器将返回故障响应（可能是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.
当作为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.
订阅和注册使用会随着时间的推移而过期，必须刷新（例如，使用刷新订阅）。此过期是使用状态，而不是对话框状态。如果多个订阅共享一个对话框，则刷新其中一个订阅不会影响其他订阅的过期。
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:terminated的订阅不会终止共享其对话框的邀请使用情况。同样，用BYE结束invite使用不会终止任何活动事件：引用在该对话框上建立的订阅。
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] 定义一种机制，通过该机制，一种用法可以替换另一种用法。例如，它可用于在有人值守的转移过程中关联转移目标所涉及的两个对话框。它是使用术语“dialog”编写的，但其目的只是影响其目标对话框的invite使用。该对话框中的任何其他用法都不受影响。对于某些应用程序，其他用法可能不再有意义，应用程序也可能终止它们。
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对话框的新应用程序或功能时，不需要端点构造多个用途来参与应用程序或使用功能。在设计端点时，尽可能最好地解决现有的多个使用场景。在这些场景之外，如果对等方试图在对话框中创建第二个用法，请拒绝它。
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.
不幸的是，现有的应用程序（如transfer）目前需要多种用途，因此“不要这样做”的简单解决方案需要一些过渡工作。本节着眼于导致这些现有多种用途的压力，并提出替代方案。
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:
执行转让时，转让人和受让人当前在他们之间的对话框中共享邀请使用和订阅使用。这是在invite用户建立的对话框中发送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被发送到错误的位置。将引用向下发送到现有对话框可确保它到达与建立对话框相同的端点。
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. 目前还不清楚如何将现有的invite用法与新对话框中出现的reference关联起来，当reference出现在invite用法对话框中时，这种关联是什么。
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（GROUS）[9]是专门为解决问题1而定义的，它提供了一个将到达一个特定用户代理的URI。创建目标对话框标题字段[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.
联接[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
使用GRUU解决问题1的可达性方面可以与连接/替换和目标对话框机制的其他对话框方面相结合。从对话框发送的REFER请求可以发送到GRUU，并将现有对话框标识为接收方应该使用的上下文的一部分。目标对话框标题字段可以包含在“引用”中，其中列出了与此引用关联的对话框。图5示意了如何使用它在不重用对话框的情况下实现传输。为简单起见，example.com上的图表和消息详细信息不显示服务器
that will be involved in routing the GRUU. Refer to [9] for those details.
这将涉及GRUU的路由。有关这些详细信息，请参阅[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 | |
|------------------------------->| |
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 |
| |<-----------------------------|
| | |
| 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消息中，Alice邀请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)>
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)>
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.
鲍勃决定试着把艾丽丝转给卡罗尔，所以他让艾丽丝暂缓，并向卡罗尔发出邀请。Carol和Bob协商GRUU支持，类似于F1和F2中发生的情况。
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)>
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)>
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将爱丽丝介绍给她。请注意，refererefereURI是Carol的GRUU，它位于与消息F1不同的调用ID上。（为了本文档的可读性，refere-ref头中的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)>
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.
Alice使用Target Dialog header字段中的信息来确定此引用与她与Bob之间已经存在的对话框相关联。Alice现在可以使用她在对话中使用的相同的准入政策：“我和此人有电话吗？”。她接受了推荐，向Bob发送了强制性的即时通知，并继续用消息F6邀请Carol。
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;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:
Carol接受Alice的邀请，用Bob替换她的对话框（邀请用法），并通知他引用的邀请已成功，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
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正常
Bob then ends his invite usages with both Alice and Carol using BYEs.
然后，Bob用Alice和Carol用“是”来结束他的“邀请”用法。
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项目的成员还分享了他们在实现多用途对话框处理程序时遇到的困难和发现。
[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：会话启动协议”，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.和M.Dolly，“按键刺激（KPML）的会话启动协议（SIP）事件包”，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）-特定事件通知”，RFC3265，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服务器”，RFC3263，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 38912004年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）URI（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）”加入“头”，RFC 3911，2004年10月。
Author's Address
作者地址
Robert J. Sparks Estacado Systems
Robert J.Sparks Estacado系统公司
EMail: RjS@estacado.net
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.