Network Working Group M. Hasebe
Request for Comments: 5407 J. Koshiko
BCP: 147 NTT-east Corporation
Category: Best Current Practice Y. Suzuki
NTT Corporation
T. Yoshikawa
NTT-east Corporation
P. Kyzivat
Cisco Systems, Inc.
December 2008
Network Working Group M. Hasebe
Request for Comments: 5407 J. Koshiko
BCP: 147 NTT-east Corporation
Category: Best Current Practice Y. Suzuki
NTT Corporation
T. Yoshikawa
NTT-east Corporation
P. Kyzivat
Cisco Systems, Inc.
December 2008
Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中竞争条件的示例调用流
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2008 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given.
本文档给出了会话启动协议（SIP）中竞争条件的示例调用流。种族状况本身就令人困惑，难以阻挠；本文档展示了处理这些问题的最佳实践。这些调用流中的元素包括SIP用户代理和SIP代理服务器。给出了呼叫流程图和消息细节。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3
1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3
1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4
2. The Dialog State Machine for INVITE Dialog Usage . . . . . . . 5
3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Receiving Message in the Moratorium State . . . . . . . . 11
3.1.1. Callee Receives Initial INVITE Retransmission
(Preparative State) While in the Moratorium State . . 11
3.1.2. Callee Receives CANCEL (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 13
3.1.3. Callee Receives BYE (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 15
3.1.4. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 1) . . . . . . . . 17
3.1.5. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 2) . . . . . . . . 22
3.1.6. Callee Receives BYE (Established State) While in
the Moratorium State . . . . . . . . . . . . . . . . . 26
3.2. Receiving Message in the Mortal State . . . . . . . . . . 28
3.2.1. UA Receives BYE (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. UA Receives re-INVITE (Established State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 30
3.2.3. UA Receives 200 OK for re-INVITE (Established
State) While in the Mortal State . . . . . . . . . . . 32
3.2.4. Callee Receives ACK (Moratorium State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 35
3.3. Other Race Conditions . . . . . . . . . . . . . . . . . . 36
3.3.1. Re-INVITE Crossover . . . . . . . . . . . . . . . . . 36
3.3.2. UPDATE and re-INVITE Crossover . . . . . . . . . . . . 40
3.3.3. Receiving REFER (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 45
4. Security Considerations . . . . . . . . . . . . . . . . . . . 46
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. Normative References . . . . . . . . . . . . . . . . . . . 47
6.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 48
Appendix B. BYE Request Overlapping with re-INVITE . . . . . . . 49
Appendix C. UA's Behavior for CANCEL . . . . . . . . . . . . . . 52
Appendix D. Notes on the Request in the Mortal State . . . . . . 54
Appendix E. Forking and Receiving New To Tags . . . . . . . . . . 54
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3
1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3
1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4
2. The Dialog State Machine for INVITE Dialog Usage . . . . . . . 5
3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Receiving Message in the Moratorium State . . . . . . . . 11
3.1.1. Callee Receives Initial INVITE Retransmission
(Preparative State) While in the Moratorium State . . 11
3.1.2. Callee Receives CANCEL (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 13
3.1.3. Callee Receives BYE (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 15
3.1.4. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 1) . . . . . . . . 17
3.1.5. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 2) . . . . . . . . 22
3.1.6. Callee Receives BYE (Established State) While in
the Moratorium State . . . . . . . . . . . . . . . . . 26
3.2. Receiving Message in the Mortal State . . . . . . . . . . 28
3.2.1. UA Receives BYE (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. UA Receives re-INVITE (Established State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 30
3.2.3. UA Receives 200 OK for re-INVITE (Established
State) While in the Mortal State . . . . . . . . . . . 32
3.2.4. Callee Receives ACK (Moratorium State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 35
3.3. Other Race Conditions . . . . . . . . . . . . . . . . . . 36
3.3.1. Re-INVITE Crossover . . . . . . . . . . . . . . . . . 36
3.3.2. UPDATE and re-INVITE Crossover . . . . . . . . . . . . 40
3.3.3. Receiving REFER (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 45
4. Security Considerations . . . . . . . . . . . . . . . . . . . 46
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. Normative References . . . . . . . . . . . . . . . . . . . 47
6.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 48
Appendix B. BYE Request Overlapping with re-INVITE . . . . . . . 49
Appendix C. UA's Behavior for CANCEL . . . . . . . . . . . . . . 52
Appendix D. Notes on the Request in the Mortal State . . . . . . 54
Appendix E. Forking and Receiving New To Tags . . . . . . . . . . 54
The call flows shown in this document were developed in the design of a SIP IP communications network. These examples are of race conditions, which stem from transitions in dialog states -- mainly transitions during session establishment after the sending of an INVITE.
本文档中显示的呼叫流是在SIP IP通信网络的设计中开发的。这些例子是竞争条件的例子，它源于对话框状态中的转换——主要是在发送邀请后的会话建立期间的转换。
When implementing SIP, various complex situations may arise. Therefore, it is helpful to provide implementors of the protocol with examples of recommended terminal and server behavior.
在实施SIP时，可能会出现各种复杂情况。因此，向协议的实现者提供推荐的终端和服务器行为的示例是很有帮助的。
This document clarifies SIP User Agent (UA) behaviors when messages cross each other as race conditions. By clarifying the operation under race conditions, inconsistent interpretations between implementations are avoided and interoperability is expected to be promoted.
本文档阐明了当消息作为竞争条件相互交叉时SIP用户代理（UA）的行为。通过澄清竞争条件下的操作，可以避免实现之间不一致的解释，并有望促进互操作性。
It is the hope of the authors that this document will be useful for SIP implementors, designers, and protocol researchers and will help them achieve the goal of a standard implementation of RFC 3261 [1].
作者希望本文档对SIP实现人员、设计者和协议研究人员有用，并帮助他们实现RFC 3261[1]的标准实现目标。
These call flows are based on version 2.0 of SIP, defined in RFC 3261 [1], with SDP usage as described in RFC 3264 [2].
这些调用流基于RFC 3261[1]中定义的SIP版本2.0，SDP使用如RFC 3264[2]中所述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。
A number of architectural, network, and protocol assumptions underlie the call flows in this document. Note that these assumptions are not requirements. They are outlined in this section so that they may be taken into consideration and help understanding of the call flow examples.
本文档中的调用流基于许多体系结构、网络和协议假设。请注意，这些假设不是要求。本节对它们进行了概述，以便考虑它们并帮助理解调用流示例。
These flows do not assume specific underlying transport protocols such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for details of the transport issues for SIP.
These flows do not assume specific underlying transport protocols such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for details of the transport issues for SIP.translate error, please retry
Dashed lines (---) and slash lines (/, \) represent signaling
messages that are mandatory to the call scenario. (X) represents the
crossover of signaling messages. (->x, x<-) indicate that the packet
is lost. The arrow indicates the direction of message flow. Double
dashed lines (===) represent media paths between network elements.
Dashed lines (---) and slash lines (/, \) represent signaling
messages that are mandatory to the call scenario. (X) represents the
crossover of signaling messages. (->x, x<-) indicate that the packet
is lost. The arrow indicates the direction of message flow. Double
dashed lines (===) represent media paths between network elements.
Messages are identified in the figures as F1, F2, etc. These numbers are used for references to the message details that follow the figure. Comments in the message details are shown in the following form:
图中的消息标识为F1、F2等。这些数字用于参考图后的消息详细信息。消息详细信息中的注释如下所示：
/* Comments. */
/* Comments. */
This document does not prescribe the flows precisely as they are shown, but rather illustrates the principles for best practice. They are best practice usages (orderings, syntax, selection of features for the purpose, or handling of errors) of SIP methods, headers, and parameters. Note: The flows in this document must not be copied as-is by implementors because additional annotations have been incorporated into this document for ease of explanation. To sum up, the procedures described in this document represent well-reviewed examples of SIP usage, which exemplify best common practice according to IETF consensus.
本文件并未精确规定所示的流程，而是说明了最佳实践的原则。它们是SIP方法、头和参数的最佳实践用法（顺序、语法、为此目的选择的功能或错误处理）。注意：本文档中的流不能按原样由实现者复制，因为为了便于解释，本文档中已包含其他注释。综上所述，本文件中描述的程序代表了经过充分审查的SIP使用示例，根据IETF共识，这些示例体现了最佳通用实践。
For reasons of simplicity in reading and editing the document, there are a number of differences between some of the examples and actual SIP messages. For instance, Call-IDs are often replicated, CSeq often begins at 1, header fields are usually shown in the same order, usually only the minimum required header field set is shown, and other headers that would usually be included, such as Accept, Allow, etc., are not shown.
出于阅读和编辑文档的简单性，一些示例与实际SIP消息之间存在许多差异。例如，调用ID通常被复制，CSeq通常从1开始，报头字段通常以相同的顺序显示，通常只显示所需的最小报头字段集，而不显示通常包含的其他报头，如Accept、Allow等。
Actors:
演员：
Element Display Name URI IP Address
------- ------------ --- ----------
Element Display Name URI IP Address
------- ------------ --- ----------
User Agent Alice sip:alice@atlanta.example.com 192.0.2.101
User Agent Bob sip:bob@biloxi.example.com 192.0.2.201
User Agent Carol sip:carol@chicago.example.com 192.0.2.202
Proxy Server ss.atlanta.example.com 192.0.2.111
User Agent Alice sip:alice@atlanta.example.com 192.0.2.101
User Agent Bob sip:bob@biloxi.example.com 192.0.2.201
User Agent Carol sip:carol@chicago.example.com 192.0.2.202
Proxy Server ss.atlanta.example.com 192.0.2.111
The term "session" is used in this document in the same way it is used in Sections 13-15 of RFC 3261 [1] (which differs somewhat from the definition of the term in RFC 3261). RFC 5057 [6] introduces another term, "invite dialog usage", which is more precisely defined. The term "session" used herein is almost, but not quite, identical to the term "invite dialog usage". The two have differing definitions of when the state ends -- the session ends earlier, when BYE is sent or received.
本文件中使用术语“会话”的方式与RFC 3261[1]第13-15节中使用的方式相同（这与RFC 3261中的术语定义有所不同）。RFC 5057[6]引入了另一个术语“邀请对话框使用”，其定义更为精确。这里使用的术语“会话”与术语“邀请对话用法”几乎相同，但并不完全相同。对于状态何时结束，两者有不同的定义——会话在发送或接收BYE时提前结束。
Race conditions are generated when the dialog state of the receiving side differs from that of the sending side.
当接收端的对话框状态与发送端的对话框状态不同时，将生成竞争条件。
For instance, a race condition occurs when a UAC (User Agent Client) sends a CANCEL in the Early state while the UAS (User Agent Server) is transitioning from the Early state to the Confirmed state by sending a 200 OK to an initial INVITE (indicated as "ini-INVITE" hereafter). The DSM (dialog state machine) for the INVITE dialog usage is presented as follows to help understanding of the UA's behavior in race conditions.
例如，当UAC（用户代理客户端）在早期状态下发送取消，而UAS（用户代理服务器）通过向初始邀请发送200 OK（在下文中表示为“ini INVITE”）从早期状态转换为确认状态时，竞赛条件发生。INVITE对话框使用的DSM（对话框状态机）如下所示，以帮助理解UA在竞争条件下的行为。
The DSM clarifies the UA's behavior by subdividing the dialog state shown in RFC 3261 [1] into various internal states. We call the state before the establishment of a dialog the Preparative state. The Confirmed state is subdivided into two substates, the Moratorium and the Established states, and the Terminated state is subdivided into the Mortal and Morgue states. Messages that are the triggers for the state transitions between these states are indicated with arrows. In this figure, messages that are not related to state transition are omitted.
DSM通过将RFC 3261[1]中所示的对话状态细分为各种内部状态来澄清UA的行为。我们把建立对话之前的状态称为准备状态。确认状态细分为两个亚状态，暂停状态和已建立状态，终止状态细分为死亡状态和停尸状态。作为这些状态之间状态转换触发器的消息用箭头表示。在此图中，省略了与状态转换无关的消息。
Below are the DSMs, first for the caller and then for the callee.
以下是DSM，首先针对呼叫者，然后针对被呼叫者。
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| | 1xx-tag |
| V w/new tag |
| +-----------------+ [new DSM] |
| 3xx-6xx | | | (new DSM |
+<--------| Early | | instance |
| | |<--+ created) |
| +-----------------+ |
| | | | 2xx w/new tag
| | BYE | 2xx | [new DSM]
| | +------------>+<-+ | (new DSM
| | | | instance
+-----C------------C-----+ +-----------C------+ | created)
| | Terminated | | | Confirmed | | |
| | +<----C---------| | | |
| | | | BYE(sr) | | | |
| | V | | V | |
| 2xx | +-----------+ | | +-----------+ | |
| +---C--| |---C-+ | | | | |
| | | | Mortal | | | BYE(r)| | Moratorium|<-C--+
| +---C->| |<--C-+ | | | |
| ACK | +-----------+ | | +-----------+ |
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | |--C-+
| | Morgue | | | |Established| | | 2xx,ACK
| | | | | | |<-C-+
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| | 1xx-tag |
| V w/new tag |
| +-----------------+ [new DSM] |
| 3xx-6xx | | | (new DSM |
+<--------| Early | | instance |
| | |<--+ created) |
| +-----------------+ |
| | | | 2xx w/new tag
| | BYE | 2xx | [new DSM]
| | +------------>+<-+ | (new DSM
| | | | instance
+-----C------------C-----+ +-----------C------+ | created)
| | Terminated | | | Confirmed | | |
| | +<----C---------| | | |
| | | | BYE(sr) | | | |
| | V | | V | |
| 2xx | +-----------+ | | +-----------+ | |
| +---C--| |---C-+ | | | | |
| | | | Mortal | | | BYE(r)| | Moratorium|<-C--+
| +---C->| |<--C-+ | | | |
| ACK | +-----------+ | | +-----------+ |
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | |--C-+
| | Morgue | | | |Established| | | 2xx,ACK
| | | | | | |<-C-+
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(r): indicates that only reception is allowed. Where (r) is not used as an indicator, "response" means receive, and "request" means send. (sr): indicates that both sending and reception are allowed.
（r） ：表示只允许接收。其中（r）未用作指示符，“响应”表示接收，“请求”表示发送。（sr）：表示同时允许发送和接收。
Figure 1: DSM for INVITE dialog usage (caller)
图1:INVITE对话框使用的DSM（调用者）
Figure 1 represents the caller's DSM for the INVITE dialog usage. The caller MAY send a BYE in the Early state, even though this behavior is not recommended. A BYE sent in the Early state terminates the early dialog using a specific To tag. That is, when a proxy is performing forking, the BYE is only able to terminate the early dialog with a particular UA. If the caller wants to terminate all early dialogs instead of that with a particular UA, it needs to send CANCEL, not BYE. However, it is not illegal to send BYE in the Early state to terminate a specific early dialog if this is the caller's intent. Moreover, until the caller receives a final response and terminates the INVITE transaction, the caller MUST be prepared to establish a dialog by receiving a new response to the INVITE even if it has already sent a CANCEL or BYE and terminated the dialog (see Appendix A).
图1显示了调用方对INVITE对话框使用的DSM。呼叫方可能在早期状态下发送BYE，即使不建议这样做。在早期状态下发送的BYE使用特定的To标记终止早期对话框。也就是说，当代理执行分叉时，BYE只能终止与特定UA的早期对话。如果调用方希望终止所有早期对话，而不是与特定UA的对话，则需要发送CANCEL，而不是BYE。但是，如果这是调用方的意图，则在早期状态下发送BYE以终止特定的早期对话并不违法。此外，在调用者收到最终响应并终止INVITE事务之前，调用者必须准备好通过接收对INVITE的新响应来建立对话，即使它已经发送了CANCEL或BYE并终止了对话（参见附录a）。
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| V |
| +------------------+ |
| 3xx-6xx | | |
+<--------| Early | |
| | | |
| +------------------+ |
| | | |
| |BYE/487(INV) | 2xx |
| | +------------>+<-+
| | |
+-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | |
| | +<----C---------| | |
| | | | BYE(sr) | | |
| | V | | V |
| | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+
| | | Mortal | | | BYE | | Moratorium| | | 2xx
| | | |<--C-+ | | |<-C-+ if ACK not
| | +------------+ | | +-----------+ | received
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | | |
| | Morgue | | | |Established| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| V |
| +------------------+ |
| 3xx-6xx | | |
+<--------| Early | |
| | | |
| +------------------+ |
| | | |
| |BYE/487(INV) | 2xx |
| | +------------>+<-+
| | |
+-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | |
| | +<----C---------| | |
| | | | BYE(sr) | | |
| | V | | V |
| | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+
| | | Mortal | | | BYE | | Moratorium| | | 2xx
| | | |<--C-+ | | |<-C-+ if ACK not
| | +------------+ | | +-----------+ | received
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | | |
| | Morgue | | | |Established| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(sr): indicates that both sending and reception are allowed. Where (sr) is not used as an indicator, "response" means send, and "request" means receive.
（sr）：表示同时允许发送和接收。如果（sr）未用作指示器，“响应”表示发送，“请求”表示接收。
Figure 2: DSM for INVITE dialog usage (callee)
图2:INVITE对话框使用的DSM（被调用方）
Figure 2 represents the callee's DSM for the INVITE dialog usage. The figure does not illustrate the state transition related to CANCEL requests. A CANCEL request does not cause a dialog state transition. However, the callee terminates the dialog and triggers the dialog
图2显示了被调用方在INVITE对话框中的DSM用法。该图未说明与取消请求相关的状态转换。取消请求不会导致对话框状态转换。但是，被调用方终止对话框并触发对话框
transition by sending a 487 immediately after the reception of the CANCEL. This behavior upon the reception of the CANCEL request is further explained in Appendix C.
接收到取消后立即发送487进行转换。附录C进一步解释了接收到取消请求时的这种行为。
The UA's behavior in each state is as follows.
UA在每个州的行为如下所示。
Preparative (Pre): The Preparative state is in effect until the early dialog is established by sending or receiving a provisional response with a To tag after an ini-INVITE is sent or received. The dialog does not yet exist in the Preparative state. If the UA sends or receives a 2xx response, the dialog state transitions from the Preparative state to the Moratorium state, which is a substate of the Confirmed state. In addition, if the UA sends or receives a 3xx-6xx response, the dialog state transitions to the Morgue state, which is a substate of the Terminated state. Sending an ACK for a 3xx-6xx response and retransmissions of 3xx-6xx are not shown on the DSMs because they are sent by the INVITE transaction.
Preparative（Pre）：在发送或接收ini INVITE后，通过发送或接收带有To标记的临时响应来建立早期对话框之前，准备状态一直有效。对话框尚未处于准备状态。如果UA发送或接收2xx响应，对话状态将从准备状态转换为暂停状态，这是确认状态的子状态。此外，如果UA发送或接收3xx-6xx响应，对话状态将转换为Morgue状态，这是终止状态的子状态。发送3xx-6xx响应的ACK和3xx-6xx的重传未显示在DSMs上，因为它们是由INVITE事务发送的。
Early (Ear): The early dialog is established by sending or receiving a provisional response except 100 Trying. The early dialog exists even though the dialog does not exist in this state yet. The dialog state transitions from the Early state to the Moratorium state, a substate of the Confirmed state, by sending or receiving a 2xx response. In addition, the dialog state transitions to the Morgue state, a substate of the Terminated state, by sending or receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx response and retransmissions of 3xx-6xx are not shown on this DSM because they are automatically processed on the transaction layer and don't influence the dialog state. The UAC may send a CANCEL in the Early state. The UAC may also send a BYE (although it is not recommended). The UAS may send a 1xx-6xx response. The sending or receiving of a CANCEL request does not have a direct influence on the dialog state. The UA's behavior upon the reception of the CANCEL request is explained further in Appendix C.
Early（Ear）：通过发送或接收临时响应（100次尝试除外）来建立Early对话框。早期对话框存在，即使该对话框尚未处于此状态。通过发送或接收2xx响应，对话框状态从早期状态转换为暂停状态（已确认状态的子状态）。此外，通过发送或接收3xx-6xx响应，对话框状态转换为Morgue状态，即终止状态的子状态。发送3xx-6xx响应的ACK和3xx-6xx的重传未显示在此DSM上，因为它们在事务层上自动处理，不会影响对话框状态。UAC可以在早期状态下发送取消。UAC也可以发送BYE（尽管不推荐）。UAS可能会发送1xx-6xx响应。发送或接收取消请求对对话框状态没有直接影响。UA在收到取消请求时的行为在附录C中作了进一步解释。
Confirmed (Con): The sending or receiving of a 2xx final response establishes a dialog. The dialog starts in this state. The Confirmed state transitions to the Mortal state, a substate of the Terminated state, by sending or receiving a BYE request. The Confirmed state has two substates, the Moratorium and the Established states, which are different with regard to the messages that UAs are allowed to send.
确认（Con）：发送或接收2xx最终响应将建立一个对话框。对话框在此状态下启动。通过发送或接收BYE请求，确认状态转换为正常状态，即终止状态的子状态。确认状态有两个子状态，暂停状态和已建立状态，这两个状态在允许UAs发送的消息方面是不同的。
Moratorium (Mora): The Moratorium state is a substate of the Confirmed state and inherits its behavior. The Moratorium state transitions to the Established state by sending or receiving an ACK request. The UAC may send an ACK and the UAS may send a 2xx final response.
暂停（Mora）：暂停状态是已确认状态的子状态，并继承其行为。暂停状态通过发送或接收ACK请求转换为已建立状态。UAC可以发送ACK，UAS可以发送2xx最终响应。
Established (Est): The Established state is a substate of the Confirmed state and inherits its behavior. Both caller and callee may send various messages that influence a dialog. The caller supports the transmission of ACK to the retransmission of a 2xx response to an ini-INVITE.
已建立（Est）：已建立状态是已确认状态的子状态，并继承其行为。调用者和被调用者都可能发送影响对话的各种消息。调用者支持将ACK传输到ini INVITE的2xx响应的重传。
Terminated (Ter): The Terminated state is subdivided into two substates, the Mortal and Morgue states, to cover the behavior when a dialog is being terminated. In this state, the UA holds information about the dialog that is being terminated.
终止（Ter）：终止状态细分为两个子状态，即凡人状态和停尸状态，以涵盖对话框终止时的行为。在此状态下，UA保存有关正在终止的对话框的信息。
Mortal (Mort): The caller and callee enter the Mortal state by sending or receiving a BYE. The UA MUST NOT send any new requests within the dialog because there is no dialog. (Here, the new requests do not include ACK for 2xx and BYE for 401 or 407, as further explained in Appendix D below.) In the Mortal state, BYE can be accepted, and the other messages in the INVITE dialog usage are responded to with an error. This addresses the case where a caller and a callee exchange reports about the session when it is being terminated. Therefore, the UA possesses dialog information for internal processing but the dialog shouldn't be externally visible. The UA stops managing its dialog state and changes it to the Morgue state when the BYE transaction is terminated.
凡人（Mort）：呼叫者和被呼叫者通过发送或接收BYE进入凡人状态。UA不得在对话框内发送任何新请求，因为没有对话框。（此处，新请求不包括2xx的ACK和401或407的BYE，如下文附录D所述。）在正常状态下，BYE可以被接受，并且INVITE对话框使用中的其他消息会被错误响应。这解决了调用方和被调用方交换在会话终止时报告会话的情况。因此，UA拥有用于内部处理的对话框信息，但该对话框不应在外部可见。UA停止管理其对话状态，并在BYE事务终止时将其更改为停尸房状态。
Morgue (Morg): The dialog no longer exists in this state. The sending or receiving of signaling that influences a dialog is not performed. (A dialog is literally terminated.) The caller and callee enter the Morgue state via the termination of the BYE or INVITE transaction.
停尸房（Morg）：对话框在此状态下不再存在。不执行影响对话的信令的发送或接收。（一个对话框字面上被终止。）呼叫者和被呼叫者通过终止BYE或INVITE事务进入停尸房状态。
This section details a race condition between two SIP UAs, Alice and Bob. Alice (sip:alice@atlanta.example.com) and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP-enabled devices. Only significant signaling is illustrated. Dialog state transitions caused by the sending or receiving of SIP messages are shown, and race conditions are indicated by '*race*'. (For abbreviations for the dialog state transitions, refer to Section 2.) '*race*' indicates the moment when a race condition occurs.
本节详细介绍两个SIP UAs Alice和Bob之间的竞争条件。艾丽斯（sip:alice@atlanta.example.com)及鲍伯(sip:bob@biloxi.example.com)假定为SIP电话或支持SIP的设备。仅说明了重要的信号。显示由发送或接收SIP消息引起的对话框状态转换，竞态条件由“*race*”表示。（有关对话框状态转换的缩写，请参阅第2节。）“*race*”表示出现竞争条件的时刻。
Examples of race conditions are described below.
竞态条件的示例如下所述。
This section shows some examples of call flow race conditions when receiving messages from other states while in the Moratorium state.
本节展示了在暂停状态下从其他状态接收消息时调用流竞争条件的一些示例。
3.1.1. Callee Receives Initial INVITE Retransmission (Preparative State) While in the Moratorium State
3.1.1. 被叫方在暂停状态下接收初始邀请重传（准备状态）
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------------>|
Pre | 180 F2(Packet loss) | Pre
| x<-----------------------|
| | Ear
| ini-INVITE F4(=F1) 200 F3 |
|------------------ --------------|
| \ / | Mora
| X |
| / \ |
|<----------------- ------------->| *race*
Mora | ACK F5 |
|------------------------------------>|
Est | | Est
| |
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------------>|
Pre | 180 F2(Packet loss) | Pre
| x<-----------------------|
| | Ear
| ini-INVITE F4(=F1) 200 F3 |
|------------------ --------------|
| \ / | Mora
| X |
| / \ |
|<----------------- ------------->| *race*
Mora | ACK F5 |
|------------------------------------>|
Est | | Est
| |
This scenario illustrates the race condition that occurs when the UAS receives a Preparative message while in the Moratorium state. All provisional responses to the initial INVITE (ini-INVITE F1) are lost, and the UAC retransmits an ini-INVITE (F4). At the same time as this retransmission, the UAS generates a 200 OK (F3) to the ini-INVITE and terminates the INVITE server transaction, according to Section 13.3.1.4 of RFC 3261 [1].
此场景说明了当UAS在暂停状态下收到准备消息时发生的竞争条件。对初始邀请（ini INVITE F1）的所有临时响应将丢失，UAC将重新传输ini INVITE（F4）。根据RFC 3261[1]第13.3.1.4节，在重新传输的同时，UAS生成ini INVITE的200 OK（F3）并终止INVITE服务器事务。
However, it is reported that terminating an INVITE server transaction when sending a 200 OK is an essential correction to SIP [7]. Therefore, the INVITE server transaction is not terminated by F3, and F4 MUST be handled properly as a retransmission.
然而，据报道，在发送200 OK时终止INVITE服务器事务是对SIP的一个基本更正[7]。因此，邀请服务器事务不会被F3终止，F4必须作为重传正确处理。
In RFC 3261 [1], it is not specified whether the UAS retransmits 200 to the retransmission of ini-INVITE. Considering the retransmission of 200 triggered by a timer (the transaction user (TU) keeps retransmitting 200 based on T1 and T2 until it receives an ACK), according to Section 13.3.1.4 of RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS receives the retransmission of the ini-INVITE. (For implementation, it does not matter if the UAS sends the retransmission of 200, since the 200 does not cause any problem.)
在RFC 3261[1]中，未指定UAS是否将200重传给ini INVITE的重传。根据RFC 3261[1]第13.3.1.4节，考虑到由定时器触发的200的重传（事务用户（TU）根据T1和T2继续重传200，直到收到ACK为止），当UAS收到ini INVITE的重传时，似乎没有必要重传200。（对于实现，UAS是否发送200的重传并不重要，因为200不会引起任何问题。）
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
/* 180 response is lost and does not reach Alice. */
/* 180 response is lost and does not reach Alice. */
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
/* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server
transaction is terminated at this point. However, this has been
reported as an essential correction to SIP, and the UAS MUST
correctly recognize the ini-INVITE (F4) as a retransmission. */
/* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server
transaction is terminated at this point. However, this has been
reported as an essential correction to SIP, and the UAS MUST
correctly recognize the ini-INVITE (F4) as a retransmission. */
F4 INVITE (retransmission) Alice -> Bob
F4邀请（重传）Alice->Bob
/* F4 is a retransmission of F1. They are exactly the same INVITE
request. For UAs that have not dealt with the correction [7] (an
INVITE server transaction is terminated when sending 200 to
INVITE), this request does not match the transaction as well as
the dialog since it does not have a To tag. However, Bob must
recognize the retransmitted INVITE correctly, without treating it
as a new INVITE. */
/* F4 is a retransmission of F1. They are exactly the same INVITE
request. For UAs that have not dealt with the correction [7] (an
INVITE server transaction is terminated when sending 200 to
INVITE), this request does not match the transaction as well as
the dialog since it does not have a To tag. However, Bob must
recognize the retransmitted INVITE correctly, without treating it
as a new INVITE. */
F5 ACK Alice -> Bob
F5确认爱丽丝->鲍勃
3.1.2. Callee Receives CANCEL (Early State) While in the Moratorium State
3.1.2. 被叫方在暂停状态下接收取消（早期状态）
State Alice Bob State
| |
| INVITE F1 |
|----------------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------------|
Ear | | Ear
|CANCEL F3 200(INVITE) F4|
|------------ -------------|
| \ / | Mora
| X |
| / \ |
|<----------- ------------>| *race*
Mora | |
| ACK F6 200(CANCEL) F5|
|------------ -------------|
Est | \ / |
| X |
| / \ |
|<----------- ------------>|
| | Est
| One Way RTP Media |
| (Two Way RTP Media possible) |
|<=============================|
| BYE F7 |
|----------------------------->|
Mort | 200 F8 | Mort
|<-----------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
State Alice Bob State
| |
| INVITE F1 |
|----------------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------------|
Ear | | Ear
|CANCEL F3 200(INVITE) F4|
|------------ -------------|
| \ / | Mora
| X |
| / \ |
|<----------- ------------>| *race*
Mora | |
| ACK F6 200(CANCEL) F5|
|------------ -------------|
Est | \ / |
| X |
| / \ |
|<----------- ------------>|
| | Est
| One Way RTP Media |
| (Two Way RTP Media possible) |
|<=============================|
| BYE F7 |
|----------------------------->|
Mort | 200 F8 | Mort
|<-----------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Early message, CANCEL, while in the Moratorium state. Alice sends a CANCEL, and Bob sends a 200 OK response to the initial INVITE message at the same time. As described in the previous section, according to RFC 3261 [1], an INVITE server transaction is supposed to be terminated by a 200 response, but this has been corrected in [7].
此场景说明了UAS在暂停状态下收到早期消息CANCEL时发生的竞态情况。Alice发送一个CANCEL，Bob同时向初始INVITE消息发送一个200OK响应。如前一节所述，根据RFC 3261[1]，INVITE服务器事务应通过200响应终止，但这已在[7]中更正。
This section describes a case in which an INVITE server transaction is not terminated by a 200 response to the INVITE request. In this case, there is an INVITE transaction that the CANCEL request matches, so a 200 response to the request is sent. This 200 response simply means that the next hop receives the CANCEL request (successful CANCEL (200) does not mean the INVITE was actually canceled). When a UAS has not dealt with the correction [7], the UAC MAY receive a 481 response to the CANCEL since there is no transaction that the CANCEL request matches. This 481 simply means that there is no matching INVITE server transaction and CANCEL is not sent to the next hop. Regardless of the success/failure of the CANCEL, Alice checks the final response to the INVITE, and if she receives 200 to the INVITE request she immediately sends a BYE and terminates the dialog. (See Section 15, RFC 3261 [1].)
本节描述了INVITE服务器事务没有被INVITE请求的200响应终止的情况。在这种情况下，有一个INVITE事务与CANCEL请求相匹配，因此会发送一个200请求响应。这个200响应仅仅意味着下一个跃点接收到取消请求（成功取消（200）并不意味着邀请实际上被取消）。当UAS未处理更正[7]时，UAC可能会收到481对取消的响应，因为没有与取消请求匹配的事务。这481仅仅意味着没有匹配的INVITE服务器事务，取消不会发送到下一个跃点。不管取消是否成功，Alice都会检查对邀请的最终响应，如果收到邀请请求的200，她会立即发送“再见”并终止对话框。（见RFC 3261[1]第15节）
From the time F1 is received by Bob until the time that F8 is sent by Bob, media may be flowing one way from Bob to Alice. From the time that an answer is received by Alice from Bob, there is the possibility that media may flow from Alice to Bob as well. However, once Alice has decided to cancel the call, she presumably will not send media, so practically speaking the media stream will remain one way.
从Bob接收F1到Bob发送F8，媒体可能从Bob单向流向Alice。从Alice收到Bob的答复时起，媒体也有可能从Alice流向Bob。然而，一旦Alice决定取消通话，她大概不会发送媒体，因此实际上，媒体流仍然是一种方式。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 CANCEL Alice -> Bob
F3取消Alice->Bob
/* Alice sends a CANCEL in the Early state. */
/* Alice sends a CANCEL in the Early state. */
F4 200 OK (INVITE) Bob -> Alice
F4 200确定（邀请）Bob->Alice
/* Alice receives a 200 to INVITE (F1) in the Moratorium state.
Alice has the potential to send as well as receive media, but in
practice will not send because there is an intent to end the
call. */
/* Alice receives a 200 to INVITE (F1) in the Moratorium state.
Alice has the potential to send as well as receive media, but in
practice will not send because there is an intent to end the
call. */
F5 200 OK (CANCEL) Bob -> Alice
F5 200确定（取消）Bob->Alice
/* 200 to CANCEL simply means that the CANCEL was received. The 200
response is sent, since this case assumes the correction [7] has
been made. If an INVITE server transaction is terminated
according to the procedure stated in RFC 3261 [1], the UAC MAY
receive a 481 response instead of 200. */
/* 200 to CANCEL simply means that the CANCEL was received. The 200
response is sent, since this case assumes the correction [7] has
been made. If an INVITE server transaction is terminated
according to the procedure stated in RFC 3261 [1], the UAC MAY
receive a 481 response instead of 200. */
F6 ACK Alice -> Bob
F6确认Alice->Bob
/* INVITE is successful, and the CANCEL becomes invalid. Bob
establishes RTP streams. However, the next BYE request
immediately terminates the dialog and session. */
/* INVITE is successful, and the CANCEL becomes invalid. Bob
establishes RTP streams. However, the next BYE request
immediately terminates the dialog and session. */
F7 BYE Alice -> Bob
F7再见Alice->Bob
F8 200 OK Bob -> Alice
F8 200 OK Bob->Alice
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| BYE F4 200(INVITE) F3|
|------------- --------------|
Mort | \ / | Mora
| X |
| / \ |
|<------------ ------------->| *race*
| | Mort
| ACK F5 200(BYE) F6 |
|------------- --------------|
| \ / ^ |
| X | |
| / \ | |
|<------------ ------------->|
| ^ | |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| BYE F4 200(INVITE) F3|
|------------- --------------|
Mort | \ / | Mora
| X |
| / \ |
|<------------ ------------->| *race*
| | Mort
| ACK F5 200(BYE) F6 |
|------------- --------------|
| \ / ^ |
| X | |
| / \ | |
|<------------ ------------->|
| ^ | |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Early message, BYE, while in the Moratorium state. Alice sends a BYE in the Early state, and Bob sends a 200 OK to the initial INVITE request at the same time. Bob receives the BYE in the Confirmed dialog state although Alice sent the request in the Early state (as explained in Section 2 and Appendix A, this behavior is not recommended). When a proxy is performing forking, the BYE is only able to terminate the early dialog with a particular UA. If the
此场景说明了当UAS在暂停状态下收到早期消息BYE时发生的竞态情况。Alice在早期状态下发送BYE，Bob同时向初始邀请请求发送200 OK。Bob在确认对话框状态下接收BYE，尽管Alice在早期状态下发送了请求（如第2节和附录A所述，不建议采用这种行为）。当代理执行分叉时，BYE只能终止与特定UA的早期对话。如果
caller wants to terminate all early dialogs instead of only that with a particular UA, it needs to send CANCEL, not BYE. However, it is not illegal to send BYE in the Early state to terminate a specific early dialog if that is the caller's intent.
调用者希望终止所有早期对话，而不仅仅是特定UA的对话，它需要发送CANCEL，而不是BYE。但是，如果是调用方的意图，在早期状态下发送BYE以终止特定的早期对话并不违法。
The BYE functions normally even if it is received after the INVITE transaction termination because BYE differs from CANCEL, and is sent not to the request but to the dialog. Alice enters the Mortal state on sending the BYE request, and remains Mortal until the Timer K timeout occurs. In the Mortal state, the UAC does not establish a session even though it receives a 200 response to the INVITE. Even so, the UAC sends an ACK to 200 in order to complete the INVITE transaction. The ACK is always sent to complete the three-way handshake of the INVITE transaction (further explained in Appendix D below).
BYE正常工作，即使它是在INVITE事务终止后收到的，因为BYE不同于CANCEL，并且不是发送到请求，而是发送到对话框。Alice在发送BYE请求时进入凡人状态，并在计时器K超时发生之前保持凡人状态。在凡人状态下，UAC不会建立会话，即使它收到200条对邀请的响应。即便如此，UAC还是会向200发送一个ACK，以完成INVITE事务。ACK总是被发送来完成INVITE事务的三方握手（下面的附录D将进一步解释）。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK (ini-INVITE) Bob -> Alice
F3 200 OK（ini邀请）Bob->Alice
F4 BYE Alice -> Bob
F4再见爱丽丝->鲍勃
/* Alice transitions to the Mortal state upon sending BYE.
Therefore, after this, she does not begin a session even though
she receives a 200 response with an answer. */
/* Alice transitions to the Mortal state upon sending BYE.
Therefore, after this, she does not begin a session even though
she receives a 200 response with an answer. */
F5 ACK Alice -> Bob
F5确认爱丽丝->鲍勃
F6 200 OK (BYE) Bob -> Alice
F6 200好（再见）鲍勃->爱丽丝
3.1.4. Callee Receives re-INVITE (Established State) While in the Moratorium State (Case 1)
3.1.4. 被呼叫方在暂停状态（案例1）下接收重新邀请（已建立状态）
State Alice Bob State
| |
| ini-INVITE w/offer1 F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/answer1 F3 |
|<-------------------------------|
Mora | ACK F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/answer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| *race*
| 200(re-INV) F8|
| ACK F7(=F4) w/answer2 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
State Alice Bob State
| |
| ini-INVITE w/offer1 F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/answer1 F3 |
|<-------------------------------|
Mora | ACK F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/answer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| *race*
| 200(re-INV) F8|
| ACK F7(=F4) w/answer2 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
This scenario illustrates the race condition that occurs when a UAS in the Moratorium state receives a re-INVITE sent by a UAC in the Established state.
此场景说明了处于暂停状态的UAS接收到处于已建立状态的UAC发送的重新邀请时发生的竞争条件。
The UAS receives a re-INVITE (with offer2) before receiving an ACK for the ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to the ini-INVITE (F3, F5) and the dialog has already been established. (Because F5 is a retransmission of F3, SDP negotiation is not performed here.)
UAS在收到ini邀请（与offer1）的确认之前，会收到重新邀请（与offer2）。UAS向重新邀请（F8）发送200 OK（带应答器2），因为它已向ini邀请（F3，F5）发送200 OK（带应答器1），并且对话框已建立。（因为F5是F3的重传，所以这里不执行SDP协商。）
As can be seen in Section 3.3.2 below, the 491 response seems to be closely related to session establishment, even in cases other than INVITE crossover. This example recommends that 200 be sent instead
如下文第3.3.2节所示，491响应似乎与会话建立密切相关，即使在邀请交叉以外的情况下也是如此。此示例建议改为发送200
of 491 because it does not have an influence on the session. However, a 491 response can also lead to the same outcome, so either response can be used.
因为它对会话没有影响。然而，491响应也可能导致相同的结果，因此可以使用任何一种响应。
Moreover, if the UAS doesn't receive an ACK for a long time, it should send a BYE and terminate the dialog. Note that ACK F7 has the same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261 [1]). The UA should not reject or drop the ACK on grounds of the CSeq number.
此外，如果UAS长时间没有收到ACK，它应该发送BYE并终止对话。注意，ACK F7与ini INVITE F1具有相同的CSeq编号（见RFC 3261[1]第13.2.2.4节）。UA不得以CSeq编号为理由拒绝或丢弃ACK。
Note: Implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The caller can delay sending re-INVITE F6 for some period of time (2 seconds, perhaps), after which the caller can reasonably assume that its ACK has been received. Implementors can decouple the actions of the user (e.g., pressing the hold button) from the actions of the protocol (the sending of re-INVITE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent the type of race condition shown in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注意：实现问题不在本文档的范围内，但提供以下提示是为了避免这种类型的竞争条件。调用者可以将重新邀请F6的发送延迟一段时间（可能是2秒），之后调用者可以合理地假设其ACK已被接收。实现者可以将用户的操作（例如，按下保持按钮）与协议的操作（发送重新邀请F6）分离，以便UA可以这样做。在这种情况下，等待多长时间是实现者的选择。在大多数情况下，这样的实现可能有助于防止本节所示的竞争条件类型。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 137
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 137
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Detailed messages are shown for the sequence to illustrate the
offer and answer examples. */
/* Detailed messages are shown for the sequence to illustrate the
offer and answer examples. */
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 133
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 133
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0
呼叫ID:3848276298220188511@atlanta.example.comCSeq:1确认内容长度：0
/* The ACK request is lost. */
/* The ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5(=F3) 200 OK Bob -> Alice (retransmission)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
F6重新邀请Alice->Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
F7(=F4) ACK Alice -> Bob (retransmission)
F7(=F4) ACK Alice -> Bob (retransmission)
/* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
/* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
F8 200 OK (re-INVITE) Bob -> Alice
F8 200确定（重新邀请）Bob->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 143
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 143
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
F9 ACK (re-INVITE) Alice -> Bob
F9确认（重新邀请）Alice->Bob
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
3.1.5. Callee Receives re-INVITE (Established State) While in the Moratorium State (Case 2)
3.1.5. 被呼叫方在暂停状态下接收重新邀请（已建立状态）（情况2）
State Alice Bob State
| |
| ini-INVITE (no offer) F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/offer1 F3 |
|<-------------------------------|
Mora | ACK w/answer1 F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/offer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK F7(=F4) 491(re-INV) F8|
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
State Alice Bob State
| |
| ini-INVITE (no offer) F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/offer1 F3 |
|<-------------------------------|
Mora | ACK w/answer1 F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/offer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK F7(=F4) 491(re-INV) F8|
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
This scenario is basically the same as that of Section 3.1.4, but differs in sending an offer in the 200 and an answer in the ACK. In contrast to the previous case, the offer in the 200 (F3) and the offer in the re-INVITE (F6) collide with each other.
该场景基本上与第3.1.4节相同，但不同之处在于在200中发送要约，在ACK中发送答复。与前一种情况相反，200（F3）中的报价和重新邀请（F6）中的报价相互冲突。
Bob sends a 491 to the re-INVITE (F6) since he is not able to properly handle a new request until he receives an answer. (Note: 500 with a Retry-After header may be returned if the 491 response is understood to indicate request collision. However, 491 is recommended here because 500 applies to so many cases that it is difficult to determine what the real problem was.) The same result will be reached if F6 is an UPDATE with offer.
Bob向重新邀请（F6）发送491，因为在收到答复之前，他无法正确处理新请求。（注意：如果491响应被理解为指示请求冲突，则可能会返回500和Retry After标头。但是，这里建议使用491，因为500适用于太多的情况，因此很难确定真正的问题是什么。）如果F6是带有offer的更新，则会得到相同的结果。
Note: As noted in Section 3.1.4, the caller may delay sending a re-INVITE F6 for some period of time (2 seconds, perhaps), after which the caller may reasonably assume that its ACK has been received, to prevent this type of race condition. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：如第3.1.4节所述，调用者可能会延迟发送重新邀请F6一段时间（可能2秒），之后调用者可能会合理地假设已经收到其ACK，以防止此类竞争条件。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Length: 0
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Length: 0
/* The request does not contain an offer. Detailed messages are
shown for the sequence to illustrate offer and answer
examples. */
/* The request does not contain an offer. Detailed messages are
shown for the sequence to illustrate offer and answer
examples. */
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 133
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201
v=0 o=IP4 client.biloxi.example.com中的bob 2890844527 2890844527 s=-c=IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* An offer is made in 200. */
/* An offer is made in 200. */
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Type: application/sdp
Content-Length: 137
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Type: application/sdp
Content-Length: 137
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* The request contains an answer, but the request is lost. */
/* The request contains an answer, but the request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5(=F3) 200 OK Bob -> Alice (retransmission)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
F6重新邀请Alice->Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101
v=0 o=IP4 client.atlanta.example.com中的alice 2890844526 2890844527 IP4 192.0.2.101中的s=-c=
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* The request contains an offer. */
/* The request contains an offer. */
F7(=F4) ACK Alice -> Bob (retransmission)
F7(=F4) ACK Alice -> Bob (retransmission)
/* A retransmission triggered by the reception of a retransmitted
200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
that it is an ACK for F3. This doesn't mean that F4 and F7 are
necessarily equal in Via-branch value. Although it is ambiguous
in RFC 3261 whether the Via-branch of ACK F7 differs from that of
F4, it doesn't affect the UAS's behavior. */
/* A retransmission triggered by the reception of a retransmitted
200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
that it is an ACK for F3. This doesn't mean that F4 and F7 are
necessarily equal in Via-branch value. Although it is ambiguous
in RFC 3261 whether the Via-branch of ACK F7 differs from that of
F4, it doesn't affect the UAS's behavior. */
F8 491 (re-INVITE) Bob -> Alice
F8 491（重新邀请）Bob->Alice
/* Bob sends 491 (Request Pending), since Bob has a pending
offer. */
/* Bob sends 491 (Request Pending), since Bob has a pending
offer. */
F9 ACK (re-INVITE) Alice -> Bob
F9确认（重新邀请）Alice->Bob
3.1.6. Callee Receives BYE (Established State) While in the Moratorium State
3.1.6. 被呼叫方在暂停状态下接收BYE（已建立状态）
State Alice Bob State
| |
| INVITE F1 |
|-------------------------->|
Pre | 180 Ringing F2 | Pre
|<--------------------------|
Ear | | Ear
| 200 OK F3 |
|<--------------------------|
Mora | ACK F4(packet loss) | Mora
|--------------->x |
Est | Both Way RTP Media |
|<=========================>|
| BYE F6 200 F5(=F3)|
|----------- -----------|
Mort | \ / |
| X |
| / \ |
|<---------- ---------->| *race*
|ACK F7(=F4) 200(BYE) F8| Mort
|----------- -----------|
| \ / |
| X |
| / \ |
|<---------- ---------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
State Alice Bob State
| |
| INVITE F1 |
|-------------------------->|
Pre | 180 Ringing F2 | Pre
|<--------------------------|
Ear | | Ear
| 200 OK F3 |
|<--------------------------|
Mora | ACK F4(packet loss) | Mora
|--------------->x |
Est | Both Way RTP Media |
|<=========================>|
| BYE F6 200 F5(=F3)|
|----------- -----------|
Mort | \ / |
| X |
| / \ |
|<---------- ---------->| *race*
|ACK F7(=F4) 200(BYE) F8| Mort
|----------- -----------|
| \ / |
| X |
| / \ |
|<---------- ---------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, BYE, while in the Moratorium state. An ACK request for a 200 OK response is lost (or delayed). Bob retransmits the 200 OK to the ini-INVITE, and at the same time Alice sends a BYE request and terminates the session. Upon receipt of the retransmitted 200 OK, Alice's UA might be inclined to reestablish the session. But that is wrong -- the session should not be reestablished when the dialog is in the Mortal state. Moreover, in the case where the UAS sends an offer in a 200 OK, the UAS should not start a session again, for the same reason, if the UAS receives a retransmitted ACK after receiving a BYE.
此场景说明了当UAS在暂停状态下收到已建立的消息BYE时发生的竞态情况。200 OK响应的ACK请求丢失（或延迟）。Bob将200 OK重新传输到ini INVITE，同时Alice发送BYE请求并终止会话。在收到重新传输的200 OK后，Alice的UA可能倾向于重新建立会话。但这是错误的——当对话处于死亡状态时，不应重新建立会话。此外，在UAS以200 OK发送要约的情况下，如果UAS在接收到BYE之后接收到重传的ACK，则出于相同的原因，UAS不应再次启动会话。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The caller can delay sending BYE F6 for some period of time (2 seconds, perhaps), after which the caller can reasonably assume that its ACK has been received. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent the type of race condition shown in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：如第3.1.4节所述，实施问题不在本文件范围内，但提供以下提示是为了避免这种类型的竞争条件。调用者可以将BYE F6发送延迟一段时间（可能是2秒），之后调用者可以合理地假设其ACK已被接收。实现者可以将用户的操作（例如挂断）与协议的操作（BYE F6的发送）解耦，以便UA可以这样做。在这种情况下，等待多长时间是实现者的选择。在大多数情况下，这样的实现可能有助于防止本节所示的竞争条件类型。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
/* ACK request is lost. */
/* ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice
F5(=F3) 200 OK Bob -> Alice
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 BYE Alice -> Bob
F6再见Alice->Bob
/* Bob retransmits a 200 OK and Alice sends a BYE at the same time.
Alice transitions to the Mortal state, so she does not begin a
session after this even though she receives a 200 response to the
re-INVITE. */
/* Bob retransmits a 200 OK and Alice sends a BYE at the same time.
Alice transitions to the Mortal state, so she does not begin a
session after this even though she receives a 200 response to the
re-INVITE. */
F7(=F4) ACK Alice -> Bob
F7(=F4) ACK Alice -> Bob
/* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it
is an ACK for F3. This doesn't mean that F4 and F7 must be equal
in Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
/* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it
is an ACK for F3. This doesn't mean that F4 and F7 must be equal
in Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
F8 200 OK (BYE) Bob -> Alice
F8 200好（再见）鲍勃->爱丽丝
/* Bob sends a 200 OK to the BYE. */
/* Bob sends a 200 OK to the BYE. */
This section shows some examples of call flow race conditions when receiving messages from other states while in the Mortal state.
本节显示了在正常状态下从其他状态接收消息时呼叫流竞争条件的一些示例。
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 BYE F6 |
|--------- ----------|
Mort | \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
| |
| 200 F8 200 F7 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 BYE F6 |
|--------- ----------|
Mort | \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
| |
| 200 F8 200 F7 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, BYE, while in the Mortal state. Alice and Bob send a BYE at the same time. A dialog and session are ended shortly after a BYE request is passed to a client transaction. As shown in Section 2, the UA remains in the Mortal state.
此场景说明了当UAS在致命状态下收到已建立的消息BYE时发生的竞态情况。爱丽丝和鲍勃同时道别。对话和会话在BYE请求传递给客户端事务后不久结束。如第2节所示，UA仍处于死亡状态。
UAs in the Mortal state return error responses to the requests that operate within a dialog or session, such as re-INVITE, UPDATE, or REFER. However, the UA shall return a 200 OK to the BYE taking the use case into consideration where a caller and a callee exchange reports about the session when it is being terminated. (Since the dialog and the session both terminate when a BYE is sent, the choice of sending a 200 or an error response upon receiving a BYE while in the Mortal state does not affect the resulting termination. Therefore, even though this example uses a 200 response, other responses can also be used.)
处于致命状态的UAs会对在对话框或会话中运行的请求（如重新邀请、更新或引用）返回错误响应。然而，UA应将200 OK返回给BYE，并考虑到当会话终止时呼叫者和被呼叫者交换有关会话的报告的用例。（由于对话框和会话都在发送BYE时终止，因此在正常状态下接收BYE时选择发送200或错误响应不会影响最终的终止。因此，即使本例使用200响应，也可以使用其他响应。）
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 BYE Alice -> Bob
F5再见Alice->Bob
/* The session is terminated at the moment Alice sends a BYE. The
dialog still exists then, but it is certain to be terminated in a
short period of time. The dialog is completely terminated when
the timeout of the BYE request occurs. */
/* The session is terminated at the moment Alice sends a BYE. The
dialog still exists then, but it is certain to be terminated in a
short period of time. The dialog is completely terminated when
the timeout of the BYE request occurs. */
F6 BYE Bob -> Alice
F6再见Bob->Alice
/* Bob has also transmitted a BYE simultaneously with Alice. Bob
terminates the session and the dialog. */
/* Bob has also transmitted a BYE simultaneously with Alice. Bob
terminates the session and the dialog. */
F7 200 OK Bob -> Alice
F7 200 OK Bob->Alice
/* Since the dialog is in the Moratorium state, Bob responds with a
200 to the BYE request. */
/* Since the dialog is in the Moratorium state, Bob responds with a
200 to the BYE request. */
F8 200 OK Alice -> Bob
F8 200 OK Alice->Bob
/* Since Alice has transitioned from the Established state to the
Mortal state by sending a BYE, Alice responds with a 200 to the
BYE request. */
/* Since Alice has transitioned from the Established state to the
Mortal state by sending a BYE, Alice responds with a 200 to the
BYE request. */
3.2.2. UA Receives re-INVITE (Established State) While in the Mortal State
3.2.2. UA在死亡状态下收到重新邀请（已建立状态）
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 re-INVITE F6|
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (re-INV) (BYE) |
|--------- ----------|
| \ / |^
| X ||
| / \ ||Timer J
|<-------- --------->||
^| ACK (re-INV) F9 ||
||<-----------------------||
Timer K|| ||
V| ||
Morg | |V
| | Morg
| |
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 re-INVITE F6|
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (re-INV) (BYE) |
|--------- ----------|
| \ / |^
| X ||
| / \ ||Timer J
|<-------- --------->||
^| ACK (re-INV) F9 ||
||<-----------------------||
Timer K|| ||
V| ||
Morg | |V
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, re-INVITE, while in the Mortal state. Bob sends a re-INVITE, and Alice sends a BYE at the same
此场景说明了当UAS在致命状态下接收到已建立的消息re-INVITE时发生的竞争条件。鲍勃发出了重新邀请，爱丽丝同时也发出了再见
time. The re-INVITE receives a 481 response since the TU of Alice has transitioned from the Established state to the Mortal state by sending BYE. Bob sends an ACK for the 481 response because the ACK for error responses is handled by the transaction layer and, at the point of receiving the 481, the INVITE client transaction still remains (even though the dialog has been terminated).
时间重新邀请收到481响应，因为Alice的TU已通过发送BYE从已建立状态过渡到必死状态。Bob为481响应发送ACK，因为错误响应的ACK由事务层处理，并且在接收481时，INVITE client事务仍然保留（即使对话框已终止）。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 BYE Alice -> Bob
F5再见Alice->Bob
/* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */
/* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */
F6 re-INVITE Bob -> Alice
F6重新邀请Bob->Alice
/* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
The dialog state transitions to the Mortal state at the moment
Alice sends the BYE, but Bob does not know this until he receives
the BYE. Therefore, the dialog is in the Terminated state from
Alice's point of view, but in the Confirmed state from Bob's point
of view. A race condition occurs. */
/* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
The dialog state transitions to the Mortal state at the moment
Alice sends the BYE, but Bob does not know this until he receives
the BYE. Therefore, the dialog is in the Terminated state from
Alice's point of view, but in the Confirmed state from Bob's point
of view. A race condition occurs. */
F7 200 OK (BYE) Bob -> Alice
F7 200好（再见）鲍勃->爱丽丝
F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
/* Since Alice is in the Mortal state, she responds with a 481 to the
re-INVITE. */
/* Since Alice is in the Mortal state, she responds with a 481 to the
re-INVITE. */
F9 ACK (re-INVITE) Bob -> Alice
F9确认（重新邀请）Bob->Alice
/* ACK for an error response is handled by Bob's INVITE client
transaction. */
/* ACK for an error response is handled by Bob's INVITE client
transaction. */
3.2.3. UA Receives 200 OK for re-INVITE (Established State) While in the Mortal State
3.2.3. UA在凡人状态下收到200 OK重新邀请（已建立状态）
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| re-INVITE F5 |
|<-----------------------|
| 200 F7 BYE F6 |
|--------- ----------|
| \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
Mort | 200 F8 ACK F9 |
| (BYE) (re-INV) |
|--------- ----------|
| ^ \ / |
| | X |
| | / \ |
|<-------- --------->|
| | ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| re-INVITE F5 |
|<-----------------------|
| 200 F7 BYE F6 |
|--------- ----------|
| \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
Mort | 200 F8 ACK F9 |
| (BYE) (re-INV) |
|--------- ----------|
| ^ \ / |
| | X |
| | / \ |
|<-------- --------->|
| | ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, 200 to a re-INVITE, while in the Mortal state. Bob sends a BYE immediately after sending a re-INVITE. (For example, in the case of a telephone application, it is possible that a user hangs up the phone immediately after refreshing the session.) Bob sends an ACK for a 200 response to INVITE while in the Mortal state, completing the INVITE transaction.
此场景说明了当UAS接收到已建立的消息时发生的竞态条件，200到一个重新邀请，同时处于死亡状态。Bob在发送重新邀请后立即发送再见。（例如，在电话应用程序的情况下，用户有可能在刷新会话后立即挂断电话。）Bob在正常状态下发送200个INVITE响应的ACK，完成INVITE事务。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The UAC can delay sending a BYE F6 until the re-INVITE transaction F5 completes. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful in preventing the type of race condition described in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：如第3.1.4节所述，实施问题不在本文件范围内，但提供以下提示是为了避免这种类型的竞争条件。UAC可以延迟发送BYE F6，直到重新邀请事务F5完成。实现者可以将用户的操作（例如挂断）与协议的操作（BYE F6的发送）解耦，以便UA可以这样做。在这种情况下，等待多长时间是实现者的选择。在大多数情况下，这种实现可能有助于防止本节中描述的竞争条件类型。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 re-INVITE Bob -> Alice
F5重新邀请Bob->Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal
state. */
/* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal
state. */
F6 BYE Bob -> Alice
F6再见Bob->Alice
/* Bob sends BYE immediately after sending the re-INVITE. Bob
terminates the session and transitions from the Established state
to the Mortal state. */
/* Bob sends BYE immediately after sending the re-INVITE. Bob
terminates the session and transitions from the Established state
to the Mortal state. */
F7 200 OK (re-INVITE) Alice -> Bob
F7 200确定（重新邀请）Alice->Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7
;received=192.0.2.201
Require: timer
Session-Expires: 300;refresher=uac
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7
;received=192.0.2.201
Require: timer
Session-Expires: 300;refresher=uac
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
A race condition occurs. */
/* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
A race condition occurs. */
F8 200 OK (BYE) Alice -> Bob
F8 200好（再见）爱丽丝->鲍勃
F9 ACK (re-INVITE) Bob -> Alice
F9确认（重新邀请）Bob->Alice
ACK sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
ACK sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
/* Bob sends ACK in the Mortal state to complete the three-way
handshake of the INVITE transaction. */
/* Bob sends ACK in the Mortal state to complete the three-way
handshake of the INVITE transaction. */
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | 200 F3 | Ear
|<-------------------------------|
Mora | | Mora
| ACK F4 BYE F5 |
|------------- --------------|
Est | \ / | Mort
| X |
| / \ |
|<------------ ------------->| *race*
Mort | 200 F6 |
|------------------------------->|
| ^ ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | 200 F3 | Ear
|<-------------------------------|
Mora | | Mora
| ACK F4 BYE F5 |
|------------- --------------|
Est | \ / | Mort
| X |
| / \ |
|<------------ ------------->| *race*
Mort | 200 F6 |
|------------------------------->|
| ^ ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, ACK to 200, while in the Mortal state. Alice sends an ACK and Bob sends a BYE at the same time. When the offer is in a 2xx, and the answer is in an ACK, there is a race condition. A session is not started when the ACK is received because Bob has already terminated the session by sending a BYE. The answer in the ACK request is just ignored.
此场景说明了当UAS在致命状态下收到已建立的消息ACK to 200时发生的竞态情况。Alice发送了一个ACK，Bob同时发送了一个BYE。当报价在2xx中，且答案在ACK中时，存在竞争条件。当收到ACK时，会话不会启动，因为Bob已经通过发送BYE终止了会话。ACK请求中的答案被忽略。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F5), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful in preventing the type of race condition described in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：如第3.1.4节所述，实施问题不在本文件范围内，但提供以下提示是为了避免这种类型的竞争条件。实现者可以将用户的操作（例如挂断）与协议的操作（BYE F5的发送）分离，以便UA可以这样做。在这种情况下，等待多长时间是实现者的选择。在大多数情况下，这种实现可能有助于防止本节中描述的竞争条件类型。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
/* RTP streams are established between Alice and Bob. */
/* RTP streams are established between Alice and Bob. */
F5 BYE Alice -> Bob
F5再见Alice->Bob
F6 200 OK Bob -> Alice
F6 200 OK Bob->Alice
/* Alice sends a BYE and terminates the session and dialog. */
/* Alice sends a BYE and terminates the session and dialog. */
This section shows examples of race conditions that are not directly related to dialog state transition. In SIP, processing functions are deployed in three layers: dialog, session, and transaction. They are related to each other, but have to be treated separately. Section 17 of RFC 3261 [1] details the processing of transactions. This document has tried so far to clarify the processing on dialogs. This section explains race conditions that are related to sessions established with SIP.
本节显示与对话框状态转换不直接相关的竞争条件示例。在SIP中，处理功能部署在三个层中：对话框、会话和事务。它们彼此相关，但必须分开处理。RFC 3261[1]第17节详细说明了交易的处理。到目前为止，本文档试图澄清对话框的处理过程。本节解释与使用SIP建立的会话相关的竞争条件。
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
|re-INVITE F5 re-INVITE F6 |
|------------ -------------|
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
|re-INVITE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ ACK F10|
|--|--------- ----|--------|
| | \ / | |
| | X | |
| | / \ | |
|<-|---------- ---|------->|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F11(=F6) |
|<------------------|--------|
| 200 OK F12 | |
|-------------------|------->|
| ACK F13 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
|re-INVITE F14(=F5) v |
|--------------------------->|
| 200 OK F15 |
|<---------------------------|
| ACK F16 |
|--------------------------->|
| |
| |
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ ACK F10|
|--|--------- ----|--------|
| | \ / | |
| | X | |
| | / \ | |
|<-|---------- ---|------->|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F11(=F6) |
|<------------------|--------|
| 200 OK F12 | |
|-------------------|------->|
| ACK F13 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
|re-INVITE F14(=F5) v |
|--------------------------->|
| 200 OK F15 |
|<---------------------------|
| ACK F16 |
|--------------------------->|
| |
| |
In this scenario, Alice and Bob send re-INVITEs at the same time. When two re-INVITEs cross in the same dialog, they are retried, each after a different interval, according to Section 14.1 of RFC 3261 [1]. When Alice sends the re-INVITE and it crosses with Bob's, the re-INVITE will be retried after 2.1-4.0 seconds because she owns the Call-ID (she generated it). Bob will retry his INVITE again after 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID.
在此场景中，Alice和Bob同时发送重新邀请。根据RFC 3261[1]第14.1节，当两个重新邀请在同一对话框中交叉时，将在不同的间隔后重试。当Alice发送重新邀请并且它与Bob的交叉时，重新邀请将在2.1-4.0秒后重试，因为她拥有呼叫ID（她生成了它）。Bob将在0.0-2.0秒后再次重试他的邀请，因为Bob不是Call-ID的所有者。
Therefore, each User Agent must remember whether or not it has generated the Call-ID of the dialog, in case an INVITE may cross with another INVITE.
因此，每个用户代理必须记住是否已生成对话框的调用ID，以防一个邀请与另一个邀请交叉。
In this example, Alice's re-INVITE is for session modification and Bob's re-INVITE is for session refresh. In this case, after the 491 responses, Bob retries the re-INVITE for session refresh earlier than Alice. If Alice was to retry her re-INVITE (that is, if she was not the owner of Call-ID), the request would refresh and modify the session at the same time. Then Bob would know that he does not need to retry his re-INVITE to refresh the session.
在本例中，Alice的重新邀请用于会话修改，Bob的重新邀请用于会话刷新。在本例中，在491个响应之后，Bob在Alice之前重试会话刷新的重新邀请。如果Alice要重试她的重新邀请（即，如果她不是呼叫ID的所有者），则请求将同时刷新和修改会话。这样，Bob就知道他不需要重试他的重新邀请来刷新会话。
In another instance, where two re-INVITEs for session modification cross over, retrying the same re-INVITE again after a 491 by the Call-ID owner (the UA that retries its re-INVITE after the other UA) may result in unintended behavior, so the UA must decide if the retry of the re-INVITE is necessary. (For example, when a call hold and an addition of video media cross over, mere retry of the re-INVITE at the firing of the timer may result in the situation where the video is transmitted immediately after the holding of the audio. This behavior is probably not intended by the users.)
在另一个实例中，当会话修改的两个重新邀请交叉时，呼叫ID所有者（在另一个UA之后重试其重新邀请的UA）在491之后再次重试相同的重新邀请可能会导致非预期行为，因此UA必须决定是否有必要重试重新邀请。（例如，当呼叫保持和视频媒体的添加交叉时，仅在定时器触发时重试重新邀请可能会导致在音频保持后立即传输视频的情况。用户可能并不打算这样做。）
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 re-INVITE Alice -> Bob
F5重新邀请Alice->Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Some detailed messages are shown for the sequence to illustrate
what sort of INVITE requests crossed over each other. */
/* Some detailed messages are shown for the sequence to illustrate
what sort of INVITE requests crossed over each other. */
F6 re-INVITE Bob -> Alice
F6重新邀请Bob->Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* A re-INVITE request for a session refresh and another for a call
hold are sent at the same time. */
/* A re-INVITE request for a session refresh and another for a call
hold are sent at the same time. */
F7 491 Request Pending Bob -> Alice
F7 491请求挂起Bob->Alice
/* Since a re-INVITE is in progress, a 491 response is returned. */
/* Since a re-INVITE is in progress, a 491 response is returned. */
F8 491 Request Pending Alice -> Bob
F8 491请求挂起Alice->Bob
F9 ACK (INVITE) Alice -> Bob
F9确认（邀请）Alice->Bob
F10 ACK (INVITE) Bob -> Alice
F10确认（邀请）Bob->Alice
F11 re-INVITE Bob -> Alice
F11重新邀请Bob->Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 133
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201
v=0 o=IP4 client.biloxi.example.com中的bob 2890844527 2890844527 s=-c=IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
again after 0.0-2.0 seconds. */
/* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
again after 0.0-2.0 seconds. */
F12 200 OK Alice -> Bob
F12 200 OK Alice->Bob
F13 ACK Bob -> Alice
F13确认鲍勃->爱丽丝
F14 re-INVITE Alice -> Bob
F14重新邀请Alice->Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 INVITE
Content-Length: 147
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 INVITE
Content-Length: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
again after 2.1-4.0 seconds. */
/* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
again after 2.1-4.0 seconds. */
F15 200 OK Bob -> Alice
F15 200 OK Bob->Alice
F16 ACK Alice -> Bob
F16确认爱丽丝->鲍勃
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
| UPDATE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
| (re-INVITE) (UPDATE) |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ |
|<-|----------------|--------|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F10 | |
|<------------------|--------|
| 200 OK F11 | |
|-------------------|------->|
| ACK F12 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
| UPDATE F13 v |
|--------------------------->|
| 200 OK F14 |
|<---------------------------|
| |
| |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
| UPDATE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
| (re-INVITE) (UPDATE) |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ |
|<-|----------------|--------|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F10 | |
|<------------------|--------|
| 200 OK F11 | |
|-------------------|------->|
| ACK F12 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
| UPDATE F13 v |
|--------------------------->|
| 200 OK F14 |
|<---------------------------|
| |
| |
In this scenario, the UPDATE contains an SDP offer; therefore, the UPDATE and re-INVITE are both responded to with 491 as in the case of "re-INVITE crossover". When an UPDATE for session refresh that doesn't contain a session description and a re-INVITE cross each other, both requests succeed with 200 (491 means that a UA has a pending request). The same is true for UPDATE crossover. In the former case where either UPDATE contains a session description, the requests fail with 491; in the latter cases, they succeed with 200.
在此场景中，更新包含SDP报价；因此，更新和重新邀请都以491响应，就像“重新邀请交叉”的情况一样。当不包含会话描述和重新邀请的会话刷新更新相互交叉时，两个请求都以200成功（491表示UA有一个挂起的请求）。更新交叉也是如此。在前一种情况下，其中任一更新包含会话描述，请求以491失败；在后一种情况下，他们以200美元成功。
Note: A 491 response is sent because an SDP offer is pending, and 491 is an error that is related to matters that impact the session established by SIP.
注意：发送491响应是因为SDP提供处于挂起状态，而491是一个与影响SIP建立的会话的事项相关的错误。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 UPDATE Alice -> Bob
F5更新Alice->Bob
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 UPDATE
Content-Length: 147
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 UPDATE
Content-Length: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Some detailed messages are shown for the sequence to illustrate
messages crossing over each other. */
/* Some detailed messages are shown for the sequence to illustrate
messages crossing over each other. */
F6 re-INVITE Bob -> Alice
F6重新邀请Bob->Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 133
Content-Type: application/sdp
Content-Length: 133
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* This is a case where a re-INVITE for a session refresh and an
UPDATE for a call hold are sent at the same time. */
/* This is a case where a re-INVITE for a session refresh and an
UPDATE for a call hold are sent at the same time. */
F7 491 Request Pending (UPDATE) Bob -> Alice
F7 491请求挂起（更新）Bob->Alice
/* Since a re-INVITE is in process, a 491 response is returned. */
/* Since a re-INVITE is in process, a 491 response is returned. */
F8 491 Request Pending (re-INVITE) Alice -> Bob
F8 491请求挂起（重新邀请）Alice->Bob
F9 ACK (re-INVITE) Alice -> Bob
F9确认（重新邀请）Alice->Bob
F10 re-INVITE Bob -> Alice
F10重新邀请Bob->Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 133
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 133
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
again after 0.0-2.0 seconds. */
/* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
again after 0.0-2.0 seconds. */
F11 200 OK Alice -> Bob
F11 200 OK Alice->Bob
F12 ACK Bob -> Alice
F12确认鲍勃->爱丽丝
F13 UPDATE Alice -> Bob
F13更新Alice->Bob
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 UPDATE
Content-Length: 147
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 UPDATE
Content-Length: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends the UPDATE
again after 2.1-4.0 seconds. */
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends the UPDATE
again after 2.1-4.0 seconds. */
F14 200 OK Bob -> Alice
F14 200 OK Bob->Alice
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 REFER F6 |
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (REFER) (BYE) |
|--------- ----------|
| \ / ^ |
| X | |
| / \ | |
|<-------- --------->|
| ^ | |
| | Timer K | |
| V Timer J | |
Morg | V |
| | Morg
| |
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 REFER F6 |
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (REFER) (BYE) |
|--------- ----------|
| \ / ^ |
| X | |
| / \ | |
|<-------- --------->|
| ^ | |
| | Timer K | |
| V Timer J | |
Morg | V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, REFER, while in the Mortal state. Bob sends a REFER, and Alice sends a BYE at the same time. Bob sends the REFER in the same dialog. Alice's dialog state moves to the Mortal state at the point of sending BYE. In the Mortal state, the UA possesses dialog information for an internal process but the dialog shouldn't exist outwardly. Therefore, the UA sends an error response to the REFER, which is transmitted as a mid-dialog request. So Alice, in the Mortal state, sends an error response to the REFER. However, Bob has already started the SUBSCRIBE usage with REFER, so
此场景说明了当UAS在非正常状态下收到已建立的消息REFER时发生的竞态情况。鲍勃发了一封推荐信，爱丽丝同时发了一封再见信。Bob在同一对话框中发送refere。Alice的对话状态在发送“再见”时移到“死亡”状态。在正常状态下，UA拥有内部进程的对话信息，但对话不应该存在于外部。因此，UA向REFER发送错误响应，作为mid对话请求发送。因此，处于死亡状态的Alice向Reference发送错误响应。但是，Bob已经开始使用REFER订阅，所以
the dialog continues until the SUBSCRIBE usage terminates, even though the INVITE dialog usage terminates by receiving BYE. Bob's behavior in this case needs to follow the procedures in RFC 5057 [6].
该对话框将继续，直到订阅使用终止，即使INVITE对话框使用通过接收BYE终止。在这种情况下，Bob的行为需要遵循RFC 5057[6]中的程序。
Message Details
消息详细信息
F1 INVITE Alice -> Bob
F1邀请Alice->Bob
F2 180 Ringing Bob -> Alice
F2 180响铃鲍勃->爱丽丝
F3 200 OK Bob -> Alice
F3 200 OK Bob->Alice
F4 ACK Alice -> Bob
F4确认爱丽丝->鲍勃
F5 BYE Alice -> Bob
F5再见Alice->Bob
/* Alice sends a BYE request and terminates the session, and
transitions from the Confirmed state to the Terminated state. */
/* Alice sends a BYE request and terminates the session, and
transitions from the Confirmed state to the Terminated state. */
F6 REFER Bob -> Alice
F6参考Bob->Alice
/* Alice sends a BYE, and Bob sends a REFER at the same time. Bob
sends the REFER on the INVITE dialog. The dialog state
transitions to the Mortal state at the moment Alice sends the BYE,
but Bob doesn't know this until he receives the BYE. A race
condition occurs. */
/* Alice sends a BYE, and Bob sends a REFER at the same time. Bob
sends the REFER on the INVITE dialog. The dialog state
transitions to the Mortal state at the moment Alice sends the BYE,
but Bob doesn't know this until he receives the BYE. A race
condition occurs. */
F7 200 OK (BYE) Bob -> Alice
F7 200好（再见）鲍勃->爱丽丝
F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
/* Alice in the Mortal state sends a 481 to the REFER. */
/* Alice in the Mortal state sends a 481 to the REFER. */
This document contains clarifications of behavior specified in RFC 3261 [1], RFC 3264 [2], and RFC 3515 [4]. The security considerations of those documents continue to apply after the application of these clarifications.
本文件包含对RFC 3261[1]、RFC 3264[2]和RFC 3515[4]中规定的行为的澄清。在适用这些澄清之后，这些文件的安全考虑继续适用。
The authors would like to thank Robert Sparks, Dean Willis, Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, Kenichi Hiragi, Dale Worley, Vijay K. Gurbani, and Anders Kristensen for their comments on this document.
作者要感谢罗伯特·斯帕克斯、迪安·威利斯、卡伦·詹宁斯、詹姆斯·M·波尔克、冈萨洛·卡马里洛、小谷健一、清水昭弘、木下幸男、稻垣靖一、纪道光忠孝、平井健一、戴尔·沃利、维杰·K·古巴尼和安德斯·克里斯滕森对本文件的评论。
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[2] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[6] Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，2007年11月。
[7] Sparks, R., "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Work in Progress, July 2008.
[7] Sparks，R.“会话启动协议邀请请求的200个响应的正确事务处理”，正在进行的工作，2008年7月。
This section, related to Section 3.1.3, explains why BYE is not recommended in the Early state, illustrating a case in which a BYE in the early dialog triggers confusion.
本节与第3.1.3节相关，解释了为什么在早期状态下不建议使用BYE，说明了早期对话框中的BYE会引发混淆的情况。
Alice Proxy Bob Carol
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |----------------->| |
|<---------------| 180(To tag=A) F4 | |
| 180(A) F5 |<-----------------| |
|<---------------| | |
| | INVITE(Fork) F6 |
| |------------------------>|
| | 100 F7 |
| BYE(A) F8 |<------------------------|
|--------------->| BYE(A) F9 | |
| |----------------->| |
| | 200(A,BYE) F10 | |
| 200(A,BYE) F11 |<-----------------| |
|<---------------| 487(A,INV) F12 | |
| |<-----------------| |
| | ACK(A) F13 | |
| |----------------->| |
| | | |
| | |
| | 200(To tag=B) F13 |
| 200(B) F14 |<------------------------|
|<---------------| |
| ACK(B) F15 | |
|--------------->| ACK(B) F16 |
| |------------------------>|
| BYE(B) F17 | |
|--------------->| BYE(B) F18 |
| |------------------------>|
| | 200(B) F19 |
| 200(B) F20 |<------------------------|
|<---------------| |
| | |
| | |
Alice Proxy Bob Carol
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |----------------->| |
|<---------------| 180(To tag=A) F4 | |
| 180(A) F5 |<-----------------| |
|<---------------| | |
| | INVITE(Fork) F6 |
| |------------------------>|
| | 100 F7 |
| BYE(A) F8 |<------------------------|
|--------------->| BYE(A) F9 | |
| |----------------->| |
| | 200(A,BYE) F10 | |
| 200(A,BYE) F11 |<-----------------| |
|<---------------| 487(A,INV) F12 | |
| |<-----------------| |
| | ACK(A) F13 | |
| |----------------->| |
| | | |
| | |
| | 200(To tag=B) F13 |
| 200(B) F14 |<------------------------|
|<---------------| |
| ACK(B) F15 | |
|--------------->| ACK(B) F16 |
| |------------------------>|
| BYE(B) F17 | |
|--------------->| BYE(B) F18 |
| |------------------------>|
| | 200(B) F19 |
| 200(B) F20 |<------------------------|
|<---------------| |
| | |
| | |
Care is advised in sending BYE in the Early state when forking by a proxy is expected. In this example, the BYE request progresses normally, and it succeeds in correctly terminating the dialog with Bob. After Bob terminates the dialog by receiving the BYE, he sends a 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261
当需要代理进行分叉时，建议在早期状态下发送BYE。在本例中，BYE请求正常进行，并成功地正确终止与Bob的对话。在Bob通过接收BYE终止对话后，他向ini INVITE发送一个487。根据RFC 3261第15.1.2节
[1], it is RECOMMENDED for the UAS to generate a 487 to any pending requests after receiving a BYE. In this example, Bob sends a 487 to the ini-INVITE since he receives the BYE while the ini-INVITE is in pending state.
[1] ，建议UAS在收到BYE后对任何未决请求生成487。在本例中，Bob向ini邀请发送487，因为他在ini邀请处于挂起状态时收到BYE。
However, Alice receives a final response to the INVITE (a 200 from Carol) even though she has successfully terminated the dialog with Bob. This means that, regardless of the success/failure of the BYE in the Early state, Alice MUST be prepared for the establishment of a new dialog until receiving the final response for the INVITE and terminating the INVITE transaction.
然而，Alice收到了对邀请的最后回复（Carol发来的200），尽管她已经成功地终止了与Bob的对话。这意味着，无论BYE在早期状态中是否成功/失败，Alice都必须为建立新对话框做好准备，直到收到INVITE的最终响应并终止INVITE事务。
It is not illegal to send a BYE in the Early state to terminate a specific early dialog -- it may satisfy the intent of some callers. However, the choice of BYE or CANCEL in the Early state must be made carefully. CANCEL is appropriate when the goal is to abandon the call attempt entirely. BYE is appropriate when the goal is to abandon a particular early dialog while allowing the call to be completed with other destinations. When using either BYE or CANCEL, the UAC must be prepared for the possibility that a call may still be established to one or more destinations.
在早期状态下发送BYE以终止特定的早期对话并不违法——这可能满足某些调用者的意图。但是，在早期状态中，必须小心选择“再见”或“取消”。当目标是完全放弃呼叫尝试时，取消是合适的。当目标是放弃特定的早期对话，同时允许通过其他目的地完成呼叫时，BYE是合适的。使用BYE或CANCEL时，UAC必须做好准备，以防仍有可能建立到一个或多个目的地的呼叫。
UAC UAS
| |
The session has been already established
==========================
| re-INVITE F1 |
|--------------------->|
| BYE F2 |
|--------------------->|
| 200(BYE) F3 |
|<---------------------|
| INVITE F4(=F1) |
|--------------------->|
| |
| |
UAC UAS
| |
The session has been already established
==========================
| re-INVITE F1 |
|--------------------->|
| BYE F2 |
|--------------------->|
| 200(BYE) F3 |
|<---------------------|
| INVITE F4(=F1) |
|--------------------->|
| |
| |
This case could look similar to the one in Section 3.2.3. However, it is not a race condition. This case describes the behavior when there is no response to the INVITE for some reason. The appendix explains the behavior in this case and its rationale, since this case is likely to cause confusion.
这种情况可能与第3.2.3节中的情况类似。然而，这不是一个比赛条件。本例描述了由于某种原因对邀请没有响应时的行为。附录解释了本案例中的行为及其理由，因为本案例可能会引起混淆。
First of all, it is important not to confuse the behavior of the transaction layer and that of the dialog layer. RFC 3261 [1] details the transaction layer behavior. The dialog layer behavior is
首先，重要的是不要混淆事务层和对话框层的行为。RFC 3261[1]详细说明了事务层的行为。对话框图层行为为
explained in this document. It has to be noted that these two behaviors are independent of each other, even though both layers may be triggered to change their states by sending or receiving the same SIP messages. (A dialog can be terminated even though a transaction still remains, and vice versa.)
本文件对此进行了解释。必须注意的是，这两种行为彼此独立，即使两个层都可以通过发送或接收相同的SIP消息来触发以改变其状态。（即使事务仍然存在，也可以终止对话框，反之亦然。）
In the sequence above, there is no response to F1, and F2 (BYE) is sent immediately after F1. (F1 is a mid-dialog request. If F1 was an ini-INVITE, BYE could not be sent before the UAC received a provisional response to the request with a To tag.)
在上面的序列中，没有对F1的响应，F2（BYE）在F1之后立即发送。（F1是中间对话请求。如果F1是ini邀请，则在UAC收到带有to标记的请求临时响应之前，无法发送BYE。）
Below is a figure that illustrates the UAC's dialog state and the transaction state.
下图显示了UAC的对话框状态和事务状态。
BYE INV dialog UAC UAS
: | |
: | |
| | re-INVITE F1 |
o | |--------------------->|
| | | BYE F2 |
o | (Mortal) |--------------------->|
| | | | 200(BYE) F3 |
| | | |<---------------------|
| | | | INVITE F4(=F1) |
| | | |--------------------->|
| | | | 481(INV) F5 |
| | | |<---------------------|
| | | | ACK(INV) F6 |
| | | |--------------------->|
| | | | |
o | o | |
| | |
o | |
| |
BYE INV dialog UAC UAS
: | |
: | |
| | re-INVITE F1 |
o | |--------------------->|
| | | BYE F2 |
o | (Mortal) |--------------------->|
| | | | 200(BYE) F3 |
| | | |<---------------------|
| | | | INVITE F4(=F1) |
| | | |--------------------->|
| | | | 481(INV) F5 |
| | | |<---------------------|
| | | | ACK(INV) F6 |
| | | |--------------------->|
| | | | |
o | o | |
| | |
o | |
| |
For the UAC, the INVITE client transaction begins at the point F1 is sent. The UAC sends BYE (F2) immediately after F1. This is a legitimate behavior. (Usually, the usage of each SIP method is independent, for BYE and others. However, it should be noted that it is prohibited to send a request with an SDP offer while the previous offer is in progress.)
对于UAC，INVITE client事务从发送点F1开始。UAC在F1之后立即发送BYE（F2）。这是合法的行为。（通常，对于BYE和其他方法，每个SIP方法的使用都是独立的。但是，应该注意的是，禁止在前一个提供过程中发送带有SDP提供的请求。）
After that, F2 triggers the BYE client transaction. At the same time, the dialog state transitions to the Mortal state and then only a BYE or a response to a BYE can be handled.
之后，F2触发BYE客户端事务。同时，对话框状态转换为正常状态，然后只能处理BYE或对BYE的响应。
It is permitted to send F4 (a retransmission of INVITE) in the Mortal state because the retransmission of F1 is handled by the transaction layer, and the INVITE transaction has not yet transitioned to the Terminated state. As is mentioned above, the dialog and the transaction behave independently each other. Therefore, the transaction handling has to be continued even though the dialog has moved to the Terminated state.
允许在正常状态下发送F4（INVITE的重传），因为F1的重传由事务层处理，并且INVITE事务尚未转换到终止状态。如上所述，对话框和事务的行为彼此独立。因此，即使对话框已移动到终止状态，也必须继续事务处理。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The UAC can delay sending BYE F2 until the re-INVITE transaction F1 completes. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F2), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent this case. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：如第3.1.4节所述，实施问题不在本文件范围内，但提供以下提示是为了避免这种类型的竞争条件。UAC可以延迟发送BYE F2，直到重新邀请事务F1完成。实现者可以将用户的动作（例如挂断）与协议的动作（发送BYE F2）分离，以便UA可以这样做。在这种情况下，等待多长时间是实现者的选择。在大多数情况下，这种实现可能有助于防止这种情况。本文档不表示他们是否应该等待ACK的传递。在考虑对用户体验的影响后，实现者应该决定是否等待一段时间，因为用户体验取决于实现，与协议行为没有直接关系。
Next, the UAS's state is shown below.
接下来，UAS的状态如下所示。
UAC UAS dialog INV BYE
| | :
| | :
| re-INVITE F1 | |
|-------------->x | |
| BYE F2 | |
|--------------------->| | o
| 200(BYE) F3 | (Mortal) |
|<---------------------| | |<-Start Timer J
| INVITE F4(=F1) | | |
|--------------------->| | o |
| 4xx/5xx(INV) F5 | o | o
|<---------------------| |
| ACK(INV) F6 | |
|--------------------->| |<-Start Timer I
| | |
| | |
| | o
| |
UAC UAS dialog INV BYE
| | :
| | :
| re-INVITE F1 | |
|-------------->x | |
| BYE F2 | |
|--------------------->| | o
| 200(BYE) F3 | (Mortal) |
|<---------------------| | |<-Start Timer J
| INVITE F4(=F1) | | |
|--------------------->| | o |
| 4xx/5xx(INV) F5 | o | o
|<---------------------| |
| ACK(INV) F6 | |
|--------------------->| |<-Start Timer I
| | |
| | |
| | o
| |
For the UAS, it can be considered that packet F1 is lost or delayed (here, the behavior is explained for the case that the UAS receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE transaction
对于UAS，可以认为数据包F1丢失或延迟（这里，针对UAS在F1 INVITE之前接收F2 BYE的情况解释该行为）。因此，F2触发BYE事务
for the UAS, and simultaneously the dialog moves to the Mortal state. Then, upon the reception of F4, the INVITE server transaction begins. (It is permitted to start the INVITE server transaction in the Mortal state. The INVITE server transaction begins to handle the received SIP request regardless of the dialog state.) The UAS's TU sends an appropriate error response for the F4 INVITE, either 481 (because the TU knows that the dialog that matches the INVITE is in the Terminated state) or 500 (because the re-sent F4 has an out-of-order CSeq). (It is mentioned above that INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog requests have a To tag. It should be noted that the UAS's TU does not begin a new dialog upon the reception of INVITE with a To tag.)
对于UAS，对话框同时移动到死亡状态。然后，在接收到F4之后，邀请服务器事务开始。（允许在正常状态下启动INVITE服务器事务。INVITE服务器事务开始处理收到的SIP请求，而不管对话状态如何。）UAS的TU为F4 INVITE发送一个适当的错误响应，即481（因为TU知道与INVITE匹配的对话处于终止状态）或500（因为重新发送的F4具有顺序错误的CSeq）。（如上所述，INVITE消息F4（和F1）是一个中间对话请求。中间对话请求有一个To标记。需要注意的是，UAS的TU在收到带有To标记的INVITE后不会开始新的对话。）
This section explains the CANCEL behaviors that indirectly impact the dialog state transition in the Early state. CANCEL does not have any influence on the UAC's dialog state. However, the request has an indirect influence on the dialog state transition because it has a significant effect on ini-INVITE. For the UAS, the CANCEL request has more direct effects on the dialog than on the sending of a CANCEL by the UAC, because it can be a trigger to send the 487 response. Figure 3 explains the UAS's behavior in the Early state. This flow diagram is only an explanatory figure, and the actual dialog state transition is as illustrated in Figures 1 and 2.
本节解释在早期状态下间接影响对话框状态转换的取消行为。取消对UAC的对话框状态没有任何影响。但是，请求对对话框状态转换有间接影响，因为它对ini INVITE有显著影响。对于UAS，取消请求对对话框的直接影响大于UAC发送取消的直接影响，因为它可能是发送487响应的触发器。图3解释了UAS在早期状态下的行为。这个流程图只是一个解释图，实际的对话框状态转换如图1和图2所示。
In the flow, full lines are related to dialog state transition, and dotted lines are involved with CANCEL. (r) represents the reception of signaling, and (s) means sending. There is no dialog state for CANCEL, but here the Cancelled state is handled virtually just for the ease of understanding of the UA's behavior when it sends and receives CANCEL.
在流程中，实线与对话框状态转换相关，虚线与取消相关。（r） 表示信号的接收，表示发送。取消没有对话框状态，但这里处理取消状态实际上只是为了便于理解UA发送和接收取消时的行为。
+-------------+
| Preparative |---+
+-------------+ |
: | 1xx(s) |
: V |
: +-------+ | 2xx(s)
: | Early |-----+------+
: +-------+ |
: : V
: : +-----------+
: : | Confirmed |<...
:.....: +-----------+ :
: | : :
: BYE(r)| : :
: CANCEL(r) | :.......:
V | CANCEL(r)
............. |
: Cancelled : |
:...........: |
| 487(s) |
| |
+--------------------+
|
V
+------------+
| Terminated |
+------------+
+-------------+
| Preparative |---+
+-------------+ |
: | 1xx(s) |
: V |
: +-------+ | 2xx(s)
: | Early |-----+------+
: +-------+ |
: : V
: : +-----------+
: : | Confirmed |<...
:.....: +-----------+ :
: | : :
: BYE(r)| : :
: CANCEL(r) | :.......:
V | CANCEL(r)
............. |
: Cancelled : |
:...........: |
| 487(s) |
| |
+--------------------+
|
V
+------------+
| Terminated |
+------------+
Figure 3: CANCEL flow diagram for UAS
图3:UAS的取消流程图
There are two behaviors for the UAS depending on the state when it receives a CANCEL.
UAS有两种行为，具体取决于收到取消通知时的状态。
The first behavior is when the UAS receives a CANCEL in the Early state. In this case, the UAS immediately sends a 487 for the INVITE, and the dialog transitions to the Terminated state.
第一个行为是UAS在早期状态下接收到取消。在这种情况下，UAS立即为INVITE发送487，对话框转换为终止状态。
The other is the case in which the UAS receives a CANCEL while in the Confirmed state. In this case, the dialog state transition does not occur, because the UAS has already sent a final response to the INVITE to which the CANCEL is targeted. (Note that, because of the UAC's behavior, a UAS that receives a CANCEL in the Confirmed state can expect to receive a BYE immediately and move to the Terminated state. However, the UAS's state does not transition until it actually receives a BYE.)
另一种情况是UAS在确认状态下收到取消。在这种情况下，不会发生对话框状态转换，因为UAS已经向取消目标的INVITE发送了最终响应。（请注意，由于UAC的行为，在确认状态下收到取消的UAS可以期望立即收到BYE并移动到终止状态。但是，UAS的状态在实际收到BYE之前不会转换。）
This section describes the UA's behavior in the Mortal state, which needs careful attention. Note that every transaction completes independently of others, following the principle of RFC 3261 [1].
本节描述UA在凡人状态下的行为，需要仔细注意。请注意，按照RFC 3261[1]的原则，每个事务独立于其他事务完成。
In the Mortal state, only a BYE can be accepted, and the other messages in the INVITE dialog usage are responded to with an error. However, sending of ACK and the authentication procedure for BYE are conducted in this state. (The handling of messages concerning multiple dialog usages is out of the scope of this document. Refer to RFC 5057 [6] for further information.)
在正常状态下，只能接受BYE，而INVITE对话框使用中的其他消息将以错误响应。然而，在该状态下进行ACK的发送和BYE的认证过程。（有关多个对话框用法的消息处理不在本文档范围内。有关更多信息，请参阅RFC 5057[6]）
ACK for error responses is handled by the transaction layer, so the handling is not related to the dialog state. Unlike the ACK for error responses, ACK for 2xx responses is a request newly generated by a TU. However, the ACK for 2xx and the ACK for error responses are both part of the INVITE transaction, even though their handling differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE transaction is completed by the three-way handshake, which includes ACK, even in the Mortal state.
错误响应的ACK由事务层处理，因此处理与对话框状态无关。与错误响应的确认不同，2xx响应的确认是TU新生成的请求。然而，2xx的确认和错误响应的确认都是INVITE事务的一部分，即使它们的处理不同（第17.1.1.1节，RFC 3261[1]）。因此，INVITE事务通过三方握手完成，其中包括ACK，即使在非正常状态下也是如此。
Considering actual implementation, the UA needs to keep the INVITE dialog usage until the Mortal state finishes, so that it is able to send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE is received in the Mortal state, the duration of the INVITE dialog usage will be extended to 64*T1 seconds after the receipt of the 2xx, to cope with the possible 2xx retransmission. (The duration of the 2xx retransmission is 64*T1, so the UA needs to be prepared to handle the retransmission for this duration.) However, the UA shall send an error response to other requests, since the INVITE dialog usage in the Mortal state is kept only for the sending of ACK for 2xx.
考虑到实际实现，UA需要保持INVITE对话框的使用，直到正常状态结束，以便能够在正常状态下发送2xx响应的ACK。如果在正常状态下收到2xx to INVITE，则在收到2xx后，INVITE对话框的使用时间将延长到64*T1秒，以应对可能的2xx重传。（2xx重传的持续时间为64*T1，因此UA需要准备在此持续时间内处理重传。）但是，UA应向其他请求发送错误响应，因为在正常状态下，INVITE对话框的使用仅用于发送2xx的ACK。
The BYE authentication procedure shall be processed in the Mortal state. When authentication is requested by a 401 or 407 response, the UAC resends BYE with appropriate credentials. Also, the UAS handles the retransmission of the BYE for which it requested authentication.
BYE认证程序应在正常状态下处理。当401或407响应请求身份验证时，UAC使用适当的凭据重新发送BYE。此外，UAS处理其请求认证的BYE的重传。
This section details the behavior of the TU when it receives multiple responses with different To tags to the ini-INVITE.
本节详细介绍了TU在收到多个响应时的行为，这些响应对ini INVITE具有不同的To标记。
When an INVITE is forked inside a SIP network, there is a possibility that the TU receives multiple responses to the ini-INVITE with differing To tags (see Sections 12.1, 13.1, 13.2.2.4, 16.7, 19.3,
当INVITE在SIP网络内分叉时，TU可能会收到对ini INVITE的多个响应，这些响应带有不同的to标签（参见第12.1、13.1、13.2.2.4、16.7、19.3节，
etc., of RFC 3261 [1]). If the TU receives multiple 1xx responses with different To tags, the original DSM forks and a new DSM instance is created. As a consequence, multiple early dialogs are generated.
RFC 3261[1]中的等。如果TU收到多个带有不同To标记的1xx响应，则原始DSM分叉，并创建一个新的DSM实例。因此，会生成多个早期对话框。
If one of the multiple early dialogs receives a 2xx response, it naturally transitions to the Confirmed state. No DSM state transition occurs for the other early dialogs, and their sessions (early media) terminate. The TU of the UAC terminates the INVITE transaction after 64*T1 seconds, starting at the point of receiving the first 2xx response. Moreover, all mortal early dialogs that do not transition to the Established state are terminated (see Section 13.2.2.4 of RFC 3261 [1]). By "mortal early dialog", we mean any early dialog that the UA will terminate when another early dialog is confirmed.
如果多个早期对话框中的一个收到2xx响应，它将自然转换为确认状态。其他早期对话框未发生DSM状态转换，其会话（早期媒体）终止。UAC的TU在64*T1秒后终止INVITE事务，从接收第一个2xx响应开始。此外，所有未过渡到已建立状态的正常早期对话均被终止（见RFC 3261[1]第13.2.2.4节）。“凡人早期对话”是指UA在确认另一个早期对话时终止的任何早期对话。
Below is an example sequence in which two 180 responses with different To tags are received, and then a 200 response for one of the early dialogs (dialog A) is received. Dotted lines (..) in the sequences are auxiliary lines to represent the influence on dialog B.
下面是一个示例序列，其中接收到两个带有不同To标记的180响应，然后接收一个早期对话框（对话框a）的200响应。序列中的虚线（..）是表示对对话框B的影响的辅助线。
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
dialog(B) | |
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-------------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-------------------------
early | | ^ | ACK(A) F6
media | Est | | |------------------------->
| | | |
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
dialog(B) | |
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-------------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-------------------------
early | | ^ | ACK(A) F6
media | Est | | |------------------------->
| | | |
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
Figure 4: Receiving 1xx responses with different To tags
图4：接收具有不同To标记的1xx响应
The figure above shows the DSM inside a SIP TU. Triggered by the reception of a provisional response with a different To tag (F4 180(To tag=B)), the DSM forks and the early dialog B is generated. 64*T1 seconds later, dialog A receives a 200 OK response. Dialog B, which does not transition to the Established state, terminates.
上图显示了SIP TU内的DSM。由接收到具有不同To标签（F4 180（To tag=B））的临时响应触发，DSM分叉并生成早期对话框B。64*T1秒后，对话框A收到200 OK响应。对话框B不会转换到已建立的状态，因此终止。
Next, the behavior of a TU that receives multiple 2xx responses with different To tags is explained. When a mortal early dialog that did not match the first 2xx response that the TU received receives another 2xx response that matches its To tag before the 64*T1 INVITE transaction timeout, its DSM transitions to the Confirmed state. However, the session on the mortal early dialog is terminated when the TU receives the first 2xx to establish a dialog, so no session is established for the mortal early dialog. Therefore, when the mortal early dialog receives a 2xx response, the TU sends an ACK and, immediately after, the TU usually sends a BYE to terminate the DSM. (In special cases, e.g., if a UA intends to establish multiple dialogs, the TU may not send the BYE.)
接下来，解释接收多个带有不同To标记的2xx响应的TU的行为。如果在64*T1 INVITE事务超时之前，与TU收到的第一个2xx响应不匹配的正常早期对话框收到另一个与其To标记匹配的2xx响应，则其DSM将转换为确认状态。但是，当TU收到第一个2xx以建立对话时，凡人早期对话上的会话终止，因此没有为凡人早期对话建立会话。因此，当凡人早期对话收到2xx响应时，TU发送ACK，紧接着，TU通常发送BYE以终止DSM。（在特殊情况下，例如，如果UA打算建立多个对话，则TU可能不会发送BYE。）
The handling of the second early dialog after receiving the 200 for the first dialog is quite appropriate for a typical device, such as a phone. It is important to note that what is being shown is a typical useful action and not the only valid one. Some devices might want to handle things differently. For instance, a conference focus that has sent out an INVITE that forks may want to accept and mix all the dialogs it gets. In that case, no early dialog is treated as mortal.
在接收到第一个对话框的200之后处理第二个早期对话框非常适合于典型的设备，例如电话。需要注意的是，所显示的是一个典型的有用操作，而不是唯一有效的操作。有些设备可能希望以不同的方式处理问题。例如，一个发出邀请的会议焦点，forks可能想要接受并混合它得到的所有对话框。在这种情况下，任何早期对话都不会被视为致命的。
Below is an example sequence in which two 180 responses with a different To tag are received and then a 200 response for each of the early dialogs is received.
下面是一个示例序列，其中接收两个带有不同To标记的180响应，然后接收每个早期对话框的200响应。
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
dialog(B) Ear | |<-----------------------
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-----------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-----------------------
early | | ^ | ACK(A) F6
media | Est | | |----------------------->
| | |64*T1 |
| | | | 200(B) F7
Mora |..........|.|........|<-----------------------
| | | | ACK(B) F8
Est |..........|.|........|----------------------->
| | | | BYE(B) F9
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F10
| | | | |<-----------------------
|Timer K | | |
| | | V |
| | | (terminate INVITE transaction)
V | | |
Morg o | |
| |
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
dialog(B) Ear | |<-----------------------
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-----------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-----------------------
early | | ^ | ACK(A) F6
media | Est | | |----------------------->
| | |64*T1 |
| | | | 200(B) F7
Mora |..........|.|........|<-----------------------
| | | | ACK(B) F8
Est |..........|.|........|----------------------->
| | | | BYE(B) F9
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F10
| | | | |<-----------------------
|Timer K | | |
| | | V |
| | | (terminate INVITE transaction)
V | | |
Morg o | |
| |
Figure 5: Receiving 1xx and 2xx responses with different To tags
图5：接收具有不同To标签的1xx和2xx响应
Below is an example sequence when a TU receives multiple 200 responses with different To tags before the 64*T1 timeout of the INVITE transaction in the absence of a provisional response. Even though a TU does not receive a provisional response, the TU needs to
下面是一个示例序列，在没有临时响应的情况下，TU在INVITE事务的64*T1超时之前接收到多个带有不同To标记的200个响应。即使TU没有收到临时响应，TU也需要
process the 2xx responses (see Section 13.2.2.4 of RFC 3261 [1]). In that case, the DSM state is forked at the Confirmed state, and then the TU sends an ACK for the 2xx response and, immediately after, the TU usually sends a BYE. (In special cases, e.g., if a UA intends to establish multiple dialogs, the TU may not send the BYE.)
处理2xx响应（见RFC 3261[1]第13.2.2.4节）。在这种情况下，DSM状态在确认状态下分叉，然后TU发送2xx响应的ACK，紧接着，TU通常发送BYE。（在特殊情况下，例如，如果UA打算建立多个对话，则TU可能不会发送BYE。）
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
Ear | |<-----------------------
| |
| | 200(A) F4
Mora |..........|<-----------------------
| ^ | ACK(A) F5
Est | | |----------------------->
| | |
dialog(B) | |64*T1 |
forked new DSM | | | 200(To tag=B) F6
Mora o..........|.|........|<-----------------------
| | | | ACK(B) F7
Est |..........|.|........|----------------------->
| | | | BYE(B) F8
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F9
| | | | |<-----------------------
| | | V |
|Timer K | (terminate INVITE transaction)
| | | |
V | | |
Morg o | |
| |
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
Ear | |<-----------------------
| |
| | 200(A) F4
Mora |..........|<-----------------------
| ^ | ACK(A) F5
Est | | |----------------------->
| | |
dialog(B) | |64*T1 |
forked new DSM | | | 200(To tag=B) F6
Mora o..........|.|........|<-----------------------
| | | | ACK(B) F7
Est |..........|.|........|----------------------->
| | | | BYE(B) F8
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F9
| | | | |<-----------------------
| | | V |
|Timer K | (terminate INVITE transaction)
| | | |
V | | |
Morg o | |
| |
Figure 6: Receiving 2xx responses with different To tags
图6：使用不同的To标签接收2xx响应
Below is an example sequence in which the option tag 100rel (RFC 3262 [5]) is required by a 180.
下面是一个示例序列，其中180需要选项标签100rel（RFC 3262[5]）。
If a forking proxy supports 100rel, it transparently transmits to the UAC a provisional response that contains a Require header with the value of 100rel. Upon receiving a provisional response with 100rel, the UAC establishes the early dialog (B) and sends PRACK (Provisional Response Acknowledgement). (Here, also, every transaction completes independently of others.)
如果分叉代理支持100rel，它将透明地向UAC传输一个临时响应，该响应包含一个值为100rel的Require头。收到100rel的临时响应后，UAC建立早期对话框（B）并发送PRACK（临时响应确认）。（在这里，每笔交易都是独立完成的。）
As in Figure 4, the early dialog (B) terminates at the same time the INVITE transaction terminates. In the case where a proxy does not support 100rel, the provisional response will be handled in the usual way (a provisional response with 100rel is discarded by the proxy, not to be transmitted to the UAC).
如图4所示，早期对话框（B）在INVITE事务终止的同时终止。在代理不支持100rel的情况下，临时响应将以通常的方式处理（带有100rel的临时响应将被代理丢弃，不会传输到UAC）。
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
| | 200(A) F4
Mora |..........|<-------------------------
| ^ | ACK(A) F5
Est | | |------------------------->
dialog(B) | | |
forked new DSM | | | 180(To tag=B) w/100rel F6
Ear o..........|.|........|<-------------------------
| | | | PRACK(B) F7
| | | |------------------------->
| | | | 200(B,PRACK) F8
| | | |<-------------------------
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
| | 200(A) F4
Mora |..........|<-------------------------
| ^ | ACK(A) F5
Est | | |------------------------->
dialog(B) | | |
forked new DSM | | | 180(To tag=B) w/100rel F6
Ear o..........|.|........|<-------------------------
| | | | PRACK(B) F7
| | | |------------------------->
| | | | 200(B,PRACK) F8
| | | |<-------------------------
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
Figure 7: Receiving 1xx responses with different To tags when using the mechanism for reliable provisional responses (100rel)
图7：使用可靠临时响应机制（100rel）时，接收具有不同To标签的1xx响应
Authors' Addresses
作者地址
Miki Hasebe NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
三木早本NTT东公司19-2西新宿3-chome新宿，东京163-8019 JP
EMail: hasebe.miki@east.ntt.co.jp
EMail: hasebe.miki@east.ntt.co.jp
Jun Koshiko NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
日本新界东株式会社东京西新宿3-chome新宿19-2 163-8019 JP
EMail: j.koshiko@east.ntt.co.jp
EMail: j.koshiko@east.ntt.co.jp
Yasushi Suzuki NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 JP
靖国铃木NTT株式会社9-11，日本东京武藏寺3-Chome Midori cho 180-8585 JP
EMail: suzuki.yasushi@lab.ntt.co.jp
EMail: suzuki.yasushi@lab.ntt.co.jp
Tomoyuki Yoshikawa NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
吉川智之NTT东公司19-2西新宿3-chome新宿，东京163-8019 JP
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
Paul H.Kyzivat Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号01719
EMail: pkyzivat@cisco.com
EMail: pkyzivat@cisco.com