draft-ietf-sipping-race-examples-06.txt   rfc5407.txt 
sipping M. Hasebe Network Working Group M. Hasebe
Internet-Draft J. Koshiko Request for Comments: 5407 J. Koshiko
Intended status: BCP NTT-east Corporation BCP: 147 NTT-east Corporation
Expires: March 27, 2009 Y. Suzuki Category: Best Current Practice Y. Suzuki
NTT Corporation NTT Corporation
T. Yoshikawa T. Yoshikawa
NTT-east Corporation NTT-east Corporation
P. Kyzivat P. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
September 23, 2008 December 2008
Example calls flows of race conditions in the Session Initiation
Protocol (SIP)
draft-ietf-sipping-race-examples-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any Example Call Flows of Race Conditions in the
applicable patent or other IPR claims of which he or she is aware Session Initiation Protocol (SIP)
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet Best Current Practices for the
and may be updated, replaced, or obsoleted by other documents at any Internet Community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Distribution of this memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2008 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html. document authors. All rights reserved.
This Internet-Draft will expire on March 27, 2009. 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.
Abstract Abstract
This document gives examples call flows of race conditions in the This document gives example call flows of race conditions in the
Session Initiation Protocol (SIP). Race conditions are inherently Session Initiation Protocol (SIP). Race conditions are inherently
confusing and difficult to thwart; this document shows the best confusing and difficult to thwart; this document shows the best
practices to handle them. The elements in these call flows include practices to handle them. The elements in these call flows include
SIP User Agents and SIP Proxy Servers. Call flow diagrams and SIP User Agents and SIP Proxy Servers. Call flow diagrams and
message details are given. message details are given.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3
1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 4 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3
1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 5 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4
2. The Dialog State Machine for INVITE dialog usage . . . . . . . 6 2. The Dialog State Machine for INVITE Dialog Usage . . . . . . . 5
3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 11 3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Receiving message in the Moratorium State . . . . . . . . 12 3.1. Receiving Message in the Moratorium State . . . . . . . . 11
3.1.1. Callee receives Initial INVITE retransmission 3.1.1. Callee Receives Initial INVITE Retransmission
(Preparative state) while in the Moratorium state . . 12 (Preparative State) While in the Moratorium State . . 11
3.1.2. Callee receives CANCEL (Early state) when in 3.1.2. Callee Receives CANCEL (Early State) While in the
Moratorium state . . . . . . . . . . . . . . . . . . . 14 Moratorium State . . . . . . . . . . . . . . . . . . . 13
3.1.3. Callee receives BYE (Early state) while in the 3.1.3. Callee Receives BYE (Early State) While in the
Moratorium state . . . . . . . . . . . . . . . . . . . 16 Moratorium State . . . . . . . . . . . . . . . . . . . 15
3.1.4. Callee receives re-INVITE (Established state) 3.1.4. Callee Receives re-INVITE (Established State)
while in the Moratorium state (case 1) . . . . . . . . 18 While in the Moratorium State (Case 1) . . . . . . . . 17
3.1.5. Callee receives re-INVITE (Established state) 3.1.5. Callee Receives re-INVITE (Established State)
while in the Moratorium state (case 2) . . . . . . . . 23 While in the Moratorium State (Case 2) . . . . . . . . 22
3.1.6. Callee receives BYE (Established state) while in 3.1.6. Callee Receives BYE (Established State) While in
the Moratorium state . . . . . . . . . . . . . . . . . 27 the Moratorium State . . . . . . . . . . . . . . . . . 26
3.2. Receiving message in the Mortal State . . . . . . . . . . 29 3.2. Receiving Message in the Mortal State . . . . . . . . . . 28
3.2.1. UA receives BYE (Established state) while in the 3.2.1. UA Receives BYE (Established State) While in the
Mortal state . . . . . . . . . . . . . . . . . . . . . 30 Mortal State . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. UA receives re-INVITE (Established state) while in 3.2.2. UA Receives re-INVITE (Established State) While in
the Mortal state . . . . . . . . . . . . . . . . . . . 32 the Mortal State . . . . . . . . . . . . . . . . . . . 30
3.2.3. UA receives 200 OK for re-INVITE (Established 3.2.3. UA Receives 200 OK for re-INVITE (Established
state) while in the Mortal state . . . . . . . . . . . 34 State) While in the Mortal State . . . . . . . . . . . 32
3.2.4. Callee receives ACK (Moratorium state) while in 3.2.4. Callee Receives ACK (Moratorium State) While in
the Mortal state . . . . . . . . . . . . . . . . . . . 37 the Mortal State . . . . . . . . . . . . . . . . . . . 35
3.3. Other race conditions . . . . . . . . . . . . . . . . . . 38 3.3. Other Race Conditions . . . . . . . . . . . . . . . . . . 36
3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 38 3.3.1. Re-INVITE Crossover . . . . . . . . . . . . . . . . . 36
3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 44 3.3.2. UPDATE and re-INVITE Crossover . . . . . . . . . . . . 40
3.3.3. Receiving REFER (Established state) while in the 3.3.3. Receiving REFER (Established State) While in the
Mortal state . . . . . . . . . . . . . . . . . . . . . 48 Mortal State . . . . . . . . . . . . . . . . . . . . . 45
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 4. Security Considerations . . . . . . . . . . . . . . . . . . . 46
5. Security Considerations . . . . . . . . . . . . . . . . . . . 50 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.1. Normative References . . . . . . . . . . . . . . . . . . . 47
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50 6.2. Informative References . . . . . . . . . . . . . . . . . . 47
7.2. Informative References . . . . . . . . . . . . . . . . . . 51 Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 48
Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 51 Appendix B. BYE Request Overlapping with re-INVITE . . . . . . . 49
Appendix B. BYE request overlapping with re-INVITE . . . . . . . 53 Appendix C. UA's Behavior for CANCEL . . . . . . . . . . . . . . 52
Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 56 Appendix D. Notes on the Request in the Mortal State . . . . . . 54
Appendix D. Notes on the request in the Mortal state . . . . . . 58 Appendix E. Forking and Receiving New To Tags . . . . . . . . . . 54
Appendix E. Forking and receiving new To tags . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 65
1. Overview 1. Overview
The call flows shown in this document were developed in the design of The call flows shown in this document were developed in the design of
a SIP IP communications network. These examples are of race a SIP IP communications network. These examples are of race
conditions, which stem from transitions in dialog states; mainly conditions, which stem from transitions in dialog states -- mainly
transitions during session establishment after the sending of an transitions during session establishment after the sending of an
INVITE. INVITE.
When implementing SIP, various complex situations may arise. When implementing SIP, various complex situations may arise.
Therefore, it is helpful to provide implementors of the protocol with Therefore, it is helpful to provide implementors of the protocol with
examples of recommended terminal and server behavior. examples of recommended terminal and server behavior.
This document clarifies SIP UA behaviors when messages cross each This document clarifies SIP User Agent (UA) behaviors when messages
other as race conditions. By clarifying the operation under race cross each other as race conditions. By clarifying the operation
conditions, inconsistent interpretations between implementations are under race conditions, inconsistent interpretations between
avoided and interoperability is expected to be promoted. implementations are avoided and interoperability is expected to be
promoted.
It is the hope of the authors that this document will be useful for It is the hope of the authors that this document will be useful for
SIP implementors, designers, and protocol researchers and will help SIP implementors, designers, and protocol researchers and will help
them achieve the goal of a standard implementation of RFC 3261 [1]. them achieve the goal of a standard implementation of RFC 3261 [1].
These call flows are based on the version 2.0 of SIP defined in RFC These call flows are based on version 2.0 of SIP, defined in RFC 3261
3261 [1] with SDP usage as described in RFC 3264 [2]. [1], with SDP usage as described in RFC 3264 [2].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [3]. document are to be interpreted as described in BCP 14, RFC 2119 [3].
1.1. General Assumptions 1.1. General Assumptions
A number of architectural, network, and protocol assumptions underlie A number of architectural, network, and protocol assumptions underlie
the call flows in this document. Note that these assumptions are not the call flows in this document. Note that these assumptions are not
requirements. They are outlined in this section so that they may be requirements. They are outlined in this section so that they may be
skipping to change at page 5, line 7 skipping to change at page 4, line 7
1.2. Legend for Message Flows 1.2. Legend for Message Flows
Dashed lines (---) and slash lines (/, \) represent signaling Dashed lines (---) and slash lines (/, \) represent signaling
messages that are mandatory to the call scenario. (X) represents the messages that are mandatory to the call scenario. (X) represents the
crossover of signaling messages. (->x, x<-) indicate that the packet crossover of signaling messages. (->x, x<-) indicate that the packet
is lost. The arrow indicates the direction of message flow. Double is lost. The arrow indicates the direction of message flow. Double
dashed lines (===) represent media paths between network elements. dashed lines (===) represent media paths between network elements.
Messages are identified in the figures as F1, F2, etc. These numbers Messages are identified in the figures as F1, F2, etc. These numbers
are used for references to the message details that follow the are used for references to the message details that follow the
Figure. Comments in the message details are shown in the following figure. Comments in the message details are shown in the following
form: form:
/* Comments. */ /* Comments. */
1.3. SIP Protocol Assumptions 1.3. SIP Protocol Assumptions
This document does not prescribe the flows precisely as they are This document does not prescribe the flows precisely as they are
shown, but rather illustrates the principles for best practice. They shown, but rather illustrates the principles for best practice. They
are best practice usages (orderings, syntax, selection of features are best practice usages (orderings, syntax, selection of features
for the purpose, or handling of errors) of SIP methods, headers and for the purpose, or handling of errors) of SIP methods, headers, and
parameters. Note: The flows in this document must not be copied parameters. Note: The flows in this document must not be copied
as-is by implementors because additional annotations have been as-is by implementors because additional annotations have been
incorporated into this document for ease of explanation. To sum up, incorporated into this document for ease of explanation. To sum up,
the procedures described in this document represent well-reviewed the procedures described in this document represent well-reviewed
examples of SIP usage, which exemplify best common practice according examples of SIP usage, which exemplify best common practice according
to IETF consensus. to IETF consensus.
For reasons of simplicity in reading and editing the document, there For reasons of simplicity in reading and editing the document, there
are a number of differences between some of the examples and actual are a number of differences between some of the examples and actual
SIP messages. For instance, Call-IDs are often replicated, CSeq SIP messages. For instance, Call-IDs are often replicated, CSeq
often begins at 1, header fields are usually shown in the same order, often begins at 1, header fields are usually shown in the same order,
usually only the minimum required header field set is shown, and usually only the minimum required header field set is shown, and
other headers which would usually be included such as Accept, Allow, other headers that would usually be included, such as Accept, Allow,
etc. are not shown. etc., are not shown.
Actors: 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 Alice sip:alice@atlanta.example.com 192.0.2.101
User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201
User Agent Carol sip:carol@chicago.example.com 192.0.2.202 User Agent Carol sip:carol@chicago.example.com 192.0.2.202
Proxy Server ss.atlanta.example.com 192.0.2.111 Proxy Server ss.atlanta.example.com 192.0.2.111
The term "session" is used in this document in the same way it is The term "session" is used in this document in the same way it is
used in RFC 3261 [1] sections 13-15. (Which differs somewhat from 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 the definition of the term in RFC 3261). RFC 5057 [6] introduces
another term, "invite dialog usage", which is more precisely defined. another term, "invite dialog usage", which is more precisely defined.
The term "session" used herein is almost, but not quite, identical to The term "session" used herein is almost, but not quite, identical to
the term "invite dialog usage". The two have differing definitions the term "invite dialog usage". The two have differing definitions
of when the state ends -- the session ends earlier, when BYE is sent of when the state ends -- the session ends earlier, when BYE is sent
or received. or received.
2. The Dialog State Machine for INVITE dialog usage 2. The Dialog State Machine for INVITE Dialog Usage
Race conditions are generated when the dialog state of the receiving Race conditions are generated when the dialog state of the receiving
side differs from that of the sending side. side differs from that of the sending side.
For instance, a race condition occurs when a UAC (User Agent Client) 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) sends a CANCEL in the Early state while the UAS (User Agent Server)
is transitioning from the Early state to the Confirmed state by is transitioning from the Early state to the Confirmed state by
sending a 200 OK to an initial INVITE (indicated as "ini-INVITE" sending a 200 OK to an initial INVITE (indicated as "ini-INVITE"
hereafter). The DSM (dialog state machine) for the INVITE dialog hereafter). The DSM (dialog state machine) for the INVITE dialog
usage is presented as follows to help understanding of the UA's usage is presented as follows to help understanding of the UA's
behavior in race conditions. behavior in race conditions.
The DSM clarifies the UA's behavior by subdividing the dialog state The DSM clarifies the UA's behavior by subdividing the dialog state
shown in RFC 3261 [1] into various internal states. We call the shown in RFC 3261 [1] into various internal states. We call the
state before the establishment of a dialog the Preparative state. state before the establishment of a dialog the Preparative state.
The Confirmed state is subdivided into two substates, the Moratorium The Confirmed state is subdivided into two substates, the Moratorium
and the Established states, and the Terminated state is subdivided and the Established states, and the Terminated state is subdivided
into the Mortal and Morgue states. Messages which are the triggers into the Mortal and Morgue states. Messages that are the triggers
for the state transitions between these states are indicated with for the state transitions between these states are indicated with
arrows. In this figure, messages which are not related to state arrows. In this figure, messages that are not related to state
transition are omitted. transition are omitted.
Below are the DSMs, first for the caller and then for the callee. Below are the DSMs, first for the caller and then for the callee.
INV +-----------------------------------------------+ INV +-----------------------------------------------+
--->| Preparative | --->| Preparative |
+-----------------------------------------------+ +-----------------------------------------------+
| | | | | |
| 3xx-6xx | 1xx-tag | 2xx | 3xx-6xx | 1xx-tag | 2xx
| | | | | |
skipping to change at page 7, line 49 skipping to change at page 6, line 49
| | | | | | |<-C-+ | | | | | | |<-C-+
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | |
+------------------------+ +------------------+ +------------------------+ +------------------+
(r): indicates that only reception is allowed. (r): indicates that only reception is allowed.
Where (r) is not used as an indicator, "response" means Where (r) is not used as an indicator, "response" means
receive, and "request" means send. receive, and "request" means send.
(sr): indicates that both sending and reception are allowed. (sr): indicates that both sending and reception are allowed.
Figure 1: DSM for INVITE dialog usage (Caller) Figure 1: DSM for INVITE dialog usage (caller)
Figure 1 represents the caller's DSM for the INVITE dialog usage. 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 The caller MAY send a BYE in the Early state, even though this
behavior is not recommended. A BYE sent in the Early state behavior is not recommended. A BYE sent in the Early state
terminates the early dialog using a specific To tag. That is, when a 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 proxy is performing forking, the BYE is only able to terminate the
early dialog with a particular UA. If the caller wants to terminate 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 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 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 to the Early state to terminate a specific early dialog if this is the
caller's intent. Moreover, until the caller receives a final caller's intent. Moreover, until the caller receives a final
response and terminates the INVITE transaction, the caller MUST be response and terminates the INVITE transaction, the caller MUST be
prepared to establish a dialog by receiving a new response to the 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 INVITE even if it has already sent a CANCEL or BYE and terminated the
dialog (see Appendix A). dialog (see Appendix A).
INV +-----------------------------------------------+ INV +-----------------------------------------------+
--->| Preparative | --->| Preparative |
+-----------------------------------------------+ +-----------------------------------------------+
| | | | | |
skipping to change at page 9, line 47 skipping to change at page 8, line 47
| | Morgue | | | |Established| | | | Morgue | | | |Established| |
| | | | | | | | | | | | | | | |
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | |
+------------------------+ +------------------+ +------------------------+ +------------------+
(sr): indicates that both sending and reception are allowed. (sr): indicates that both sending and reception are allowed.
Where (sr) is not used as an indicator, "response" means send, Where (sr) is not used as an indicator, "response" means send,
and "request" means receive. and "request" means receive.
Figure 2: DSM for INVITE dialog usage (Callee) Figure 2: DSM for INVITE dialog usage (callee)
Figure 2 represents the callee's DSM for the INVITE dialog usage. Figure 2 represents the callee's DSM for the INVITE dialog usage.
The figure does not illustrate the state transition related to CANCEL The figure does not illustrate the state transition related to CANCEL
requests. A CANCEL request does not cause a dialog state transition. requests. A CANCEL request does not cause a dialog state transition.
However, the callee terminates the dialog and triggers the dialog However, the callee terminates the dialog and triggers the dialog
transition by sending 487 immediately after the reception of the transition by sending a 487 immediately after the reception of the
CANCEL. This behavior upon the reception of the CANCEL request is CANCEL. This behavior upon the reception of the CANCEL request is
further explained in Appendix C. further explained in Appendix C.
The UA's behavior in each state is as follows. The UA's behavior in each state is as follows.
Preparative (Pre): The Preparative state is in effect until the Preparative (Pre): The Preparative state is in effect until the
early dialog is established by sending or receiving a provisional early dialog is established by sending or receiving a provisional
response with a To tag after an ini-INVITE is sent or received. 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 The dialog does not yet exist in the Preparative state. If the UA
sends or receives a 2xx response, the dialog state transitions sends or receives a 2xx response, the dialog state transitions
from the Preparative to the Moratorium state, which is a substate from the Preparative state to the Moratorium state, which is a
of the Confirmed state. In addition, if UA sends or receives a substate of the Confirmed state. In addition, if the UA sends or
3xx-6xx response the dialog state transitions to the Morgue state receives a 3xx-6xx response, the dialog state transitions to the
which is a substate of the Terminated state. Sending an ACK for a Morgue state, which is a substate of the Terminated state.
3xx-6xx response and retransmissions of 3xx-6xx are not shown on Sending an ACK for a 3xx-6xx response and retransmissions of 3xx-
the DSMs because they are sent by the INVITE transaction. 6xx are not shown on the DSMs because they are sent by the INVITE
transaction.
Early (Ear): The early dialog is established by sending or receiving Early (Ear): The early dialog is established by sending or receiving
a provisional response except 100 Trying. The early dialog exists a provisional response except 100 Trying. The early dialog exists
even though the dialog does not exist in this state yet. The even though the dialog does not exist in this state yet. The
dialog state transitions from the Early to the Moratorium state, a dialog state transitions from the Early state to the Moratorium
substate of the Confirmed state, by sending or receiving a 2xx state, a substate of the Confirmed state, by sending or receiving
response. In addition, the dialog state transitions to the Morgue a 2xx response. In addition, the dialog state transitions to the
state, a substate of the Terminated state, by sending or receiving Morgue state, a substate of the Terminated state, by sending or
a 3xx-6xx response. Sending an ACK for a 3xx-6xx response and receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx
retransmissions of 3xx-6xx are not shown on this DSM because they response and retransmissions of 3xx-6xx are not shown on this DSM
are automatically processed on the transaction layer and don't because they are automatically processed on the transaction layer
influence the dialog state. The UAC may send a CANCEL in the and don't influence the dialog state. The UAC may send a CANCEL
Early state. The UAC may also send a BYE (although it is not in the Early state. The UAC may also send a BYE (although it is
recommended). The UAS may send a 1xx-6xx response. The sending not recommended). The UAS may send a 1xx-6xx response. The
or receiving of a CANCEL request does not have a direct influence sending or receiving of a CANCEL request does not have a direct
on the dialog state. The UA's behavior upon the reception of the influence on the dialog state. The UA's behavior upon the
CANCEL request is explained further in Appendix C. reception of the CANCEL request is explained further in Appendix
C.
Confirmed (Con): The sending or receiving of a 2xx final response Confirmed (Con): The sending or receiving of a 2xx final response
establishes a dialog. The dialog starts in this state. The establishes a dialog. The dialog starts in this state. The
Confirmed state transitions to the Mortal state, a substate of the Confirmed state transitions to the Mortal state, a substate of the
Terminated state, by sending or receiving a BYE request. The Terminated state, by sending or receiving a BYE request. The
Confirmed state has two substates, the Moratorium and the Confirmed state has two substates, the Moratorium and the
Established states, which are different with regard to the Established states, which are different with regard to the
messages that UAs are allowed to send. messages that UAs are allowed to send.
Moratorium (Mora): The Moratorium state is a substate of the Moratorium (Mora): The Moratorium state is a substate of the
Confirmed state and inherits its behavior. The Moratorium state Confirmed state and inherits its behavior. The Moratorium state
transitions to the Established state by sending or receiving an 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 ACK request. The UAC may send an ACK and the UAS may send a 2xx
final response. final response.
Established (Est): The Established state is a substate of the Established (Est): The Established state is a substate of the
Confirmed state and inherits its behavior. Both caller and callee Confirmed state and inherits its behavior. Both caller and callee
may send various messages which influence a dialog. The caller may send various messages that influence a dialog. The caller
supports the transmission of ACK to the retransmission of a 2xx supports the transmission of ACK to the retransmission of a 2xx
response to an ini-INVITE. response to an ini-INVITE.
Terminated (Ter): The Terminated state is subdivided into two Terminated (Ter): The Terminated state is subdivided into two
substates, the Mortal and Morgue states, to cover the behavior substates, the Mortal and Morgue states, to cover the behavior
when a dialog is being terminated. In this state, the UA holds when a dialog is being terminated. In this state, the UA holds
information about the dialog which is being terminated. information about the dialog that is being terminated.
Mortal (Mort): The caller and callee enter the Mortal state by Mortal (Mort): The caller and callee enter the Mortal state by
sending or receiving a BYE. The UA MUST NOT send any new requests sending or receiving a BYE. The UA MUST NOT send any new requests
within the dialog because there is no dialog. (Here the new 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 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 further explained in Appendix D below.) In the Mortal state, BYE
can be accepted, and the other messages in the INVITE dialog usage can be accepted, and the other messages in the INVITE dialog usage
are responded with an error. This addresses the case where a are responded to with an error. This addresses the case where a
caller and a callee exchange reports about the session when it is caller and a callee exchange reports about the session when it is
being terminated. Therefore the UA possesses dialog information being terminated. Therefore, the UA possesses dialog information
for internal processing but the dialog shouldn't be externally for internal processing but the dialog shouldn't be externally
visible. The UA stops managing its dialog state and changes it to visible. The UA stops managing its dialog state and changes it to
the Morgue state, when the BYE transaction is terminated. the Morgue state when the BYE transaction is terminated.
Morgue (Morg): The dialog no longer exists in this state. The Morgue (Morg): The dialog no longer exists in this state. The
sending or receiving of signaling which influences a dialog is not sending or receiving of signaling that influences a dialog is not
performed. (A dialog is literally terminated.) The caller and performed. (A dialog is literally terminated.) The caller and
callee enter the Morgue state via the termination of the BYE or callee enter the Morgue state via the termination of the BYE or
INVITE transaction. INVITE transaction.
3. Race Conditions 3. Race Conditions
This section details a race condition between two SIP UAs, Alice and This section details a race condition between two SIP UAs, Alice and
Bob. Alice (sip:alice@atlanta.example.com) and Bob Bob. Alice (sip:alice@atlanta.example.com) and Bob
(sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP- (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP-
enabled devices. Only significant signaling is illustrated. Dialog enabled devices. Only significant signaling is illustrated. Dialog
state transitions caused by the sending or receiving of SIP messages state transitions caused by the sending or receiving of SIP messages
are shown and race conditions are indicated by '*race*'. (For are shown, and race conditions are indicated by '*race*'. (For
abbreviations for the dialog state transitions, refer to Section 2.) abbreviations for the dialog state transitions, refer to Section 2.)
'*race*' indicates the moment when a race condition occurs. '*race*' indicates the moment when a race condition occurs.
Examples of race conditions are described below. Examples of race conditions are described below.
3.1. Receiving message in the Moratorium State 3.1. Receiving Message in the Moratorium State
This section shows some examples of call flow race conditions when This section shows some examples of call flow race conditions when
receiving messages from other states while in the Moratorium state. receiving messages from other states while in the Moratorium state.
3.1.1. Callee receives Initial INVITE retransmission (Preparative 3.1.1. Callee Receives Initial INVITE Retransmission (Preparative
state) while in the Moratorium state State) While in the Moratorium State
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
|------------------------------------>| |------------------------------------>|
Pre | 180 F2(Packet loss) | Pre Pre | 180 F2(Packet loss) | Pre
| x<-----------------------| | x<-----------------------|
| | Ear | | Ear
| ini-INVITE F4(=F1) 200 F3 | | ini-INVITE F4(=F1) 200 F3 |
|------------------ --------------| |------------------ --------------|
| \ / | Mora | \ / | Mora
| X | | X |
| / \ | | / \ |
|<----------------- ------------->| *race* |<----------------- ------------->| *race*
Mora | ACK F5 | Mora | ACK F5 |
|------------------------------------>| |------------------------------------>|
Est | | Est Est | | Est
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives a Preparative message while in the Moratorium state. receives a Preparative message while in the Moratorium state. All
All provisional responses to the initial INVITE (ini-INVITE F1) are provisional responses to the initial INVITE (ini-INVITE F1) are lost,
lost, and the UAC retransmits an ini-INVITE (F4). At the same time and the UAC retransmits an ini-INVITE (F4). At the same time as this
as this retransmission, the UAS generates a 200 OK (F3) to the ini- retransmission, the UAS generates a 200 OK (F3) to the ini-INVITE and
INVITE and terminates the INVITE server transaction, according to terminates the INVITE server transaction, according to Section
Section 13.3.1.4 of RFC 3261 [1]. 13.3.1.4 of RFC 3261 [1].
However, it is reported that terminating an INVITE server transaction However, it is reported that terminating an INVITE server transaction
when sending 200 OK is an essential correction to SIP [7]. when sending a 200 OK is an essential correction to SIP [7].
Therefore, the INVITE server transaction is not terminated by F3, and Therefore, the INVITE server transaction is not terminated by F3, and
the F4 MUST be handled properly as a retransmission. F4 MUST be handled properly as a retransmission.
In RFC 3261 [1], it is not specified whether UAS retransmits 200 to In RFC 3261 [1], it is not specified whether the UAS retransmits 200
the retransmission of ini-INVITE. Considering the retransmission of to the retransmission of ini-INVITE. Considering the retransmission
200 triggered by a timer (the TU keeps retransmitting 200 based on T1 of 200 triggered by a timer (the transaction user (TU) keeps
and T2 until it receives an ACK), according to Section 13.3.1.4 of retransmitting 200 based on T1 and T2 until it receives an ACK),
RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS according to Section 13.3.1.4 of RFC 3261 [1], it seems unnecessary
receives the retransmission of ini-INVITE. (For implementation, it to retransmit 200 when the UAS receives the retransmission of the
does not matter if the UAS sends the retransmission of 200, since the ini-INVITE. (For implementation, it does not matter if the UAS sends
200 does not cause any problem.) the retransmission of 200, since the 200 does not cause any problem.)
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
/* 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
skipping to change at page 14, line 5 skipping to change at page 13, line 5
/* F4 is a retransmission of F1. They are exactly the same 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 request. For UAs that have not dealt with the correction [7] (an
INVITE server transaction is terminated when sending 200 to INVITE server transaction is terminated when sending 200 to
INVITE), this request does not match the transaction as well as INVITE), this request does not match the transaction as well as
the dialog since it does not have a To tag. However, Bob must the dialog since it does not have a To tag. However, Bob must
recognize the retransmitted INVITE correctly, without treating it recognize the retransmitted INVITE correctly, without treating it
as a new INVITE. */ as a new INVITE. */
F5 ACK Alice -> Bob F5 ACK Alice -> Bob
3.1.2. Callee receives CANCEL (Early state) when in Moratorium state 3.1.2. Callee Receives CANCEL (Early State) While in the Moratorium
State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|----------------------------->| |----------------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<-----------------------------| |<-----------------------------|
Ear | | Ear Ear | | Ear
|CANCEL F3 200(INVITE) F4| |CANCEL F3 200(INVITE) F4|
|------------ -------------| |------------ -------------|
skipping to change at page 14, line 43 skipping to change at page 13, line 44
Mort | 200 F8 | Mort Mort | 200 F8 | Mort
|<-----------------------------| |<-----------------------------|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Early message, CANCEL, while in the Moratorium state. receives an Early message, CANCEL, while in the Moratorium state.
Alice sends a CANCEL and Bob sends a 200 OK response to the initial 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 INVITE message at the same time. As described in the previous
section, according to RFC 3261 [1], an INVITE server transaction is section, according to RFC 3261 [1], an INVITE server transaction is
supposed to be terminated by a 200 response, but this has been supposed to be terminated by a 200 response, but this has been
corrected in [7]. corrected in [7].
This section describes a case in which an INVITE server transaction This section describes a case in which an INVITE server transaction
is not terminated by a 200 response to the INVITE request. In this is not terminated by a 200 response to the INVITE request. In this
case, there is an INVITE transaction which the CANCEL request case, there is an INVITE transaction that the CANCEL request matches,
matches, so a 200 response to the request is sent. This 200 response so a 200 response to the request is sent. This 200 response simply
simply means that the next hop receives the CANCEL request means that the next hop receives the CANCEL request (successful
(Successful CANCEL (200) does not mean the INVITE was actually CANCEL (200) does not mean the INVITE was actually canceled). When a
canceled). When a UAS has not dealt with the correction [7], the UAC UAS has not dealt with the correction [7], the UAC MAY receive a 481
MAY receive a 481 response to the CANCEL since there is no response to the CANCEL since there is no transaction that the CANCEL
transaction which the CANCEL request matches. This 481 simply means request matches. This 481 simply means that there is no matching
that there is no matching INVITE server transaction and CANCEL is not INVITE server transaction and CANCEL is not sent to the next hop.
sent to the next hop. Regardless of the success/failure of the Regardless of the success/failure of the CANCEL, Alice checks the
CANCEL, Alice checks the final response to the INVITE, and if she final response to the INVITE, and if she receives 200 to the INVITE
receives 200 to the INVITE request she immediately sends a BYE and request she immediately sends a BYE and terminates the dialog. (See
terminates the dialog. (Section 15, RFC 3261 [1]) Section 15, RFC 3261 [1].)
From the time F1 is received by Bob until the time that F8 is sent by 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 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 an answer is received by Alice from Bob, there is the
that media may flow from Alice to Bob as well. However, once Alice possibility that media may flow from Alice to Bob as well. However,
has decided to cancel the call, she presumably will not send media, once Alice has decided to cancel the call, she presumably will not
so practically speaking the media stream will remain one way. send media, so practically speaking the media stream will remain one
way.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 CANCEL Alice -> Bob F3 CANCEL 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 OK (INVITE) Bob -> Alice
/* Alice receives a 200 to INVITE (F1) in the Moratorium state. /* Alice receives a 200 to INVITE (F1) in the Moratorium state.
Alice has the potential to send as well as receive media, but in 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. practice will not send because there is an intent to end the
*/ call. */
F5 200 OK (CANCEL) Bob -> Alice F5 200 OK (CANCEL) Bob -> Alice
/* 200 to CANCEL simply means that the CANCEL was received. The 200 /* 200 to CANCEL simply means that the CANCEL was received. The 200
response is sent, since this case assumes the correction [7] has response is sent, since this case assumes the correction [7] has
been made. If an INVITE server transaction is terminated been made. If an INVITE server transaction is terminated
according to the procedure stated in RFC 3261 [1], UAC MAY receive according to the procedure stated in RFC 3261 [1], the UAC MAY
a 481 response instead of 200. */ receive a 481 response instead of 200. */
F6 ACK Alice -> Bob F6 ACK Alice -> Bob
/* INVITE is successful, and the CANCEL becomes invalid. Bob /* INVITE is successful, and the CANCEL becomes invalid. Bob
establishes RTP streams. However, the next BYE request establishes RTP streams. However, the next BYE request
immediately terminates the dialog and session. */ immediately terminates the dialog and session. */
F7 BYE Alice -> Bob F7 BYE Alice -> Bob
F8 200 OK Bob -> Alice F8 200 OK Bob -> Alice
3.1.3. Callee receives BYE (Early state) while in the Moratorium state 3.1.3. Callee Receives BYE (Early State) While in the Moratorium State
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
|------------------------------->| |------------------------------->|
Pre | 180 F2 | Pre Pre | 180 F2 | Pre
|<-------------------------------| |<-------------------------------|
Ear | | Ear Ear | | Ear
| BYE F4 200(INVITE) F3| | BYE F4 200(INVITE) F3|
|------------- --------------| |------------- --------------|
skipping to change at page 16, line 46 skipping to change at page 15, line 44
| / \ | | | / \ | |
|<------------ ------------->| |<------------ ------------->|
| ^ | | | ^ | |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition that occurs when the UAS
receives an Early message, BYE, while in the Moratorium state. Alice 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 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 INVITE request at the same time. Bob receives the BYE in the
Confirmed dialog state although Alice sent the request in the Early Confirmed dialog state although Alice sent the request in the Early
state (As explained in Section 2 and Appendix A, this behavior is not state (as explained in Section 2 and Appendix A, this behavior is not
recommended). When a proxy is performing forking, the BYE is only recommended). When a proxy is performing forking, the BYE is only
able to terminate the early dialog with a particular UA. If the able to terminate the early dialog with a particular UA. If the
caller wants to terminate all early dialogs instead of only that with 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 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 not illegal to send BYE in the Early state to terminate a specific
early dialog if that is the caller's intent. early dialog if that is the caller's intent.
The BYE functions normally even if it is received after the INVITE The BYE functions normally even if it is received after the INVITE
transaction termination because BYE differs from CANCEL, and is sent transaction termination because BYE differs from CANCEL, and is sent
not to the request but to the dialog. Alice enters the Mortal state 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 on sending the BYE request, and remains Mortal until the Timer K
timeout occurs. In the Mortal state, the UAC does not establish a timeout occurs. In the Mortal state, the UAC does not establish a
session, even though it receives a 200 response to the INVITE. Even 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 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 transaction. The ACK is always sent to complete the three-way
handshake of the INVITE transaction (Further explained in Appendix D handshake of the INVITE transaction (further explained in Appendix D
below). below).
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK (ini-INVITE) Bob -> Alice F3 200 OK (ini-INVITE) Bob -> Alice
F4 BYE Alice -> Bob F4 BYE Alice -> Bob
/* Alice transitions to the Mortal state upon sending BYE. /* Alice transitions to the Mortal state upon sending BYE.
Therefore, after this, she does not begin a session even though Therefore, after this, she does not begin a session even though
she receives a 200 response with an answer. */ she receives a 200 response with an answer. */
F5 ACK Alice -> Bob F5 ACK Alice -> Bob
F6 200 OK (BYE) Bob -> Alice F6 200 OK (BYE) Bob -> Alice
3.1.4. Callee receives re-INVITE (Established state) while in the 3.1.4. Callee Receives re-INVITE (Established State) While in the
Moratorium state (case 1) Moratorium State (Case 1)
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE w/offer1 F1 | | ini-INVITE w/offer1 F1 |
|------------------------------->| |------------------------------->|
Pre | 180 F2 | Pre Pre | 180 F2 | Pre
|<-------------------------------| |<-------------------------------|
Ear | | Ear Ear | | Ear
| 200(ini-INV) w/answer1 F3 | | 200(ini-INV) w/answer1 F3 |
|<-------------------------------| |<-------------------------------|
skipping to change at page 18, line 39 skipping to change at page 17, line 39
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK (re-INV) F9 | Est | ACK (re-INV) F9 | Est
|------------------------------->| |------------------------------->|
| | | |
| | | |
This scenario illustrates the race condition which occurs when a UAS 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 in the Moratorium state receives a re-INVITE sent by a UAC in the
Established state. Established state.
The UAS receives a re-INVITE (with offer2) before receiving an ACK The UAS receives a re-INVITE (with offer2) before receiving an ACK
for ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) for the ini-INVITE (with offer1). The UAS sends a 200 OK (with
to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to answer2) to the re-INVITE (F8) because it has sent a 200 OK (with
the ini-INVITE (F3, F5) and the dialog has already been established. answer1) to the ini-INVITE (F3, F5) and the dialog has already been
(Because F5 is a retransmission of F3, SDP negotiation is not established. (Because F5 is a retransmission of F3, SDP negotiation
performed here.) is not performed here.)
As can be seen in Section 3.3.2 below, the 491 response seems to be 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 closely related to session establishment, even in cases other than
INVITE cross-over. This example recommends that 200 be sent instead INVITE crossover. This example recommends that 200 be sent instead
of 491 because it does not have an influence on the session. 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 However, a 491 response can also lead to the same outcome, so either
response can be used. response can be used.
Moreover, if UAS doesn't receive an ACK for a long time, it should Moreover, if the UAS doesn't receive an ACK for a long time, it
send a BYE and terminate the dialog. Note that ACK F7 has the same should send a BYE and terminate the dialog. Note that ACK F7 has the
CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]). same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261
The UA should not reject or drop the ACK on grounds of the CSeq [1]). The UA should not reject or drop the ACK on grounds of the
number. CSeq number.
Note: Implementation issues are outside the scope of this document, Note: Implementation issues are outside the scope of this document,
but this note provides a tip for avoiding race conditions of this but the following tip is provided for avoiding race conditions of
type. That is for the caller to delay sending re-INVITE F6 for some this type. The caller can delay sending re-INVITE F6 for some period
period of time (2 seconds, perhaps), after which the caller can of time (2 seconds, perhaps), after which the caller can reasonably
reasonably assume that its ACK has been received. Implementors can assume that its ACK has been received. Implementors can decouple the
decouple the actions of the user (e.g. pressing the hold button) from actions of the user (e.g., pressing the hold button) from the actions
the actions of the protocol (the sending of re-INVITE F6), so that of the protocol (the sending of re-INVITE F6), so that the UA can
the UA can behave like this. In this case, it is the implementor's behave like this. In this case, it is the implementor's choice as to
choice as to how long to wait. In most cases, such an implementation how long to wait. In most cases, such an implementation may be
may be useful to prevent the type of race condition shown in this useful to prevent the type of race condition shown in this section.
section. This document expresses no preference about whether or not This document expresses no preference about whether or not they
they should wait for an ACK to be delivered. After considering the should wait for an ACK to be delivered. After considering the impact
impact on users experience, implementors should decide whether to on user experience, implementors should decide whether or not to wait
wait for a while or not, because the user experience depends on the for a while, because the user experience depends on the
implementation and has no direct bearing on protocol behaviour. implementation and has no direct bearing on protocol behavior.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
skipping to change at page 21, line 4 skipping to change at page 19, line 47
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0 ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
/* The ACK request is lost. */
/* ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission) F5(=F3) 200 OK Bob -> Alice (retransmission)
/* UAS retransmits a 200 OK to the ini-INVITE since it has not /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */ received an ACK. */
F6 re-INVITE Alice -> Bob F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
skipping to change at page 21, line 39 skipping to change at page 20, line 35
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly 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 /* "(=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 an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous whether Via-branch of Via-branch value. Although it is ambiguous in RFC 3261 whether
ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's the Via-branch of ACK F7 differs from that of F4, it doesn't
behavior. */ affect the UAS's behavior. */
F8 200 OK (re-INVITE) Bob -> Alice F8 200 OK (re-INVITE) Bob -> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE CSeq: 2 INVITE
Content-Length: 143 Content-Length: 143
v=0 v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=- s=-
c=IN IP4 192.0.2.201 c=IN IP4 192.0.2.201
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=recvonly a=recvonly
F9 ACK (re-INVITE) Alice -> Bob F9 ACK (re-INVITE) Alice -> Bob
skipping to change at page 23, line 5 skipping to change at page 22, line 5
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK CSeq: 2 ACK
Content-Length: 0 Content-Length: 0
3.1.5. Callee receives re-INVITE (Established state) while in the 3.1.5. Callee Receives re-INVITE (Established State) While in the
Moratorium state (case 2) Moratorium State (Case 2)
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE (no offer) F1 | | ini-INVITE (no offer) F1 |
|------------------------------->| |------------------------------->|
Pre | 180 F2 | Pre Pre | 180 F2 | Pre
|<-------------------------------| |<-------------------------------|
Ear | | Ear Ear | | Ear
| 200(ini-INV) w/offer1 F3 | | 200(ini-INV) w/offer1 F3 |
|<-------------------------------| |<-------------------------------|
skipping to change at page 23, line 45 skipping to change at page 22, line 45
| | | |
| | | |
This scenario is basically the same as that of Section 3.1.4, but 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 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 contrast to the previous case, the offer in the 200 (F3) and the
offer in the re-INVITE (F6) collide with each other. offer in the re-INVITE (F6) collide with each other.
Bob sends a 491 to the re-INVITE (F6) since he is not able to 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: properly handle a new request until he receives an answer. (Note:
500 with Retry-After header may be returned, if the 491 response is 500 with a Retry-After header may be returned if the 491 response is
understood to indicate request collision. However, 491 is understood to indicate request collision. However, 491 is
recommended here because 500 applies to so many cases that it is recommended here because 500 applies to so many cases that it is
difficult to determine what the real problem was.) The same result difficult to determine what the real problem was.) The same result
will be reached if F6 is an UPDATE with offer. will be reached if F6 is an UPDATE with offer.
Note: As noted in Section 3.1.4, caller may delay sending a re-INVITE Note: As noted in Section 3.1.4, the caller may delay sending a re-
F6 for some period of time (2 seconds, perhaps), after which the INVITE F6 for some period of time (2 seconds, perhaps), after which
caller may reasonably assume that its ACK has been received, to the caller may reasonably assume that its ACK has been received, to
prevent this type of race condition. This document expresses no prevent this type of race condition. This document expresses no
preference about whether or not they should wait for an ACK to be preference about whether or not they should wait for an ACK to be
delivered. After considering the impact on users experience, delivered. After considering the impact on user experience,
implementors should decide whether to wait for a while or not, implementors should decide whether or not to wait for a while,
because the user experience depends on the implementation and has no because the user experience depends on the implementation and has no
direct bearing on protocol behaviour. direct bearing on protocol behavior.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp> Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Length: 0 Content-Length: 0
/* The request does not contain an offer. Detailed messages are /* The request does not contain an offer. Detailed messages are
shown for the sequence to illustrate offer and answer examples. shown for the sequence to illustrate offer and answer
*/ examples. */
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101 ;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
skipping to change at page 25, line 34 skipping to change at page 24, line 34
s=- s=-
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 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)
/* UAS retransmits a 200 OK to the ini-INVITE since it has not /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */ received an ACK. */
F6 re-INVITE Alice -> Bob F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
skipping to change at page 26, line 20 skipping to change at page 25, line 17
a=sendonly 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 /* A retransmission triggered by the reception of a retransmitted
200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in 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 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 necessarily equal in Via-branch value. Although it is ambiguous
whether Via-branch of ACK F7 differs from F4 in RFC3261, it in RFC 3261 whether the Via-branch of ACK F7 differs from that of
doesn't affect UAS's behavior. */ F4, it doesn't affect the UAS's behavior. */
F8 491 (re-INVITE) Bob -> Alice F8 491 (re-INVITE) 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 ACK (re-INVITE) Alice -> Bob
3.1.6. Callee receives BYE (Established state) while in the Moratorium 3.1.6. Callee Receives BYE (Established State) While in the Moratorium
state State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|-------------------------->| |-------------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<--------------------------| |<--------------------------|
Ear | | Ear Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
|<--------------------------| |<--------------------------|
skipping to change at page 27, line 41 skipping to change at page 26, line 41
| / \ | | / \ |
|<---------- ---------->| |<---------- ---------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Established message, BYE, while in the Moratorium receives an Established message, BYE, while in the Moratorium state.
state. An ACK request for a 200 OK response is lost (or delayed). An ACK request for a 200 OK response is lost (or delayed). Bob
Bob retransmits the 200 OK to the ini-INVITE, and at the same time retransmits the 200 OK to the ini-INVITE, and at the same time Alice
Alice sends a BYE request and terminates the session. Upon receipt sends a BYE request and terminates the session. Upon receipt of the
of retransmitted 200 OK Alice's UA might be inclined to reestablish retransmitted 200 OK, Alice's UA might be inclined to reestablish the
the session. But that is wrong - the session should not be session. But that is wrong -- the session should not be
reestablished when the dialog is in the Mortal state. Moreover, in 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 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 start a session again, for the same reason, if the UAS receives a
retransmitted ACK after receiving a BYE. retransmitted ACK after receiving a BYE.
Note: As noted in Section 3.1.4, implementation issues are outside Note: As noted in Section 3.1.4, implementation issues are outside
the scope of this document, but this note provides a tip for avoiding the scope of this document, but the following tip is provided for
race conditions of this type. That is for the caller to delay avoiding race conditions of this type. The caller can delay sending
sending BYE F6 for some period of time (2 seconds, perhaps), after BYE F6 for some period of time (2 seconds, perhaps), after which the
which the caller can reasonably assume that its ACK has been caller can reasonably assume that its ACK has been received.
received. Implementors can decouple the actions of the user (e.g. Implementors can decouple the actions of the user (e.g., hanging up)
hanging up) from the actions of the protocol (the sending of BYE F6), from the actions of the protocol (the sending of BYE F6), so that the
so that the UA can behave like this. In this case, it is the UA can behave like this. In this case, it is the implementor's
implementor's choice as to how long to wait. In most cases, such an choice as to how long to wait. In most cases, such an implementation
implementation may be useful to prevent the type of race condition may be useful to prevent the type of race condition shown in this
shown in this section. This document expresses no preference about section. This document expresses no preference about whether or not
whether or not they should wait for an ACK to be delivered. After they should wait for an ACK to be delivered. After considering the
considering the impact on users experience, implementors should impact on user experience, implementors should decide whether or not
decide whether to wait for a while or not, because the user to wait for a while, because the user experience depends on the
experience depends on the implementation and has no direct bearing on implementation and has no direct bearing on protocol behavior.
protocol behaviour.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
/* ACK request is lost. */ /* ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice F5(=F3) 200 OK Bob -> Alice
/* UAS retransmits a 200 OK to the ini-INVITE since it has not /* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */ received an ACK. */
F6 BYE Alice -> Bob F6 BYE Alice -> Bob
/* Bob retransmits a 200 OK and Alice sends a BYE at the same time. /* 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 Alice transitions to the Mortal state, so she does not begin a
session after this even though she receives a 200 response to the session after this even though she receives a 200 response to the
re-INVITE. */ 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 /* "(=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 is an ACK for F3. This doesn't mean that F4 and F7 must be equal
in Via-branch value. Although it is ambiguous whether Via-branch in Via-branch value. Although it is ambiguous in RFC 3261 whether
of ACK F7 differs from F4 in RFC3261, it doesn't affect UAS's the Via-branch of ACK F7 differs from that of F4, it doesn't
behavior. */ affect the UAS's behavior. */
F8 200 OK (BYE) Bob -> Alice F8 200 OK (BYE) Bob -> Alice
/* Bob sends a 200 OK to the BYE. */ /* Bob sends a 200 OK to the BYE. */
3.2. Receiving message in the Mortal State 3.2. Receiving Message in the Mortal State
This section shows some examples of call flow race conditions when This section shows some examples of call flow race conditions when
receiving messages from other states while in the Mortal state. receiving messages from other states while in the Mortal state.
3.2.1. UA receives BYE (Established state) while in the Mortal state 3.2.1. UA Receives BYE (Established State) While in the Mortal State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|----------------------->| |----------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<-----------------------| |<-----------------------|
Ear | | Ear Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
|<-----------------------| |<-----------------------|
skipping to change at page 30, line 41 skipping to change at page 29, line 4
| X | | X |
| / \ | | / \ |
|<-------- --------->| |<-------- --------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition that occurs when the UAS
This scenario illustrates the race condition which occurs when the receives an Established message, BYE, while in the Mortal state.
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 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. ended shortly after a BYE request is passed to a client transaction.
As shown in Section 2, the UA remains in the Mortal state. As shown in Section 2, the UA remains in the Mortal state.
UAs in the Mortal state return error responses to the requests that UAs in the Mortal state return error responses to the requests that
operate within a dialog or session, such as re-INVITE, UPDATE, or operate within a dialog or session, such as re-INVITE, UPDATE, or
REFER. However, the UA shall return 200 OK to the BYE taking the use REFER. However, the UA shall return a 200 OK to the BYE taking the
case into consideration where a caller and a callee exchange reports use case into consideration where a caller and a callee exchange
about the session when it is being terminated. (Since the dialogue reports about the session when it is being terminated. (Since the
and the session both terminate when a BYE is sent, the choice of dialog and the session both terminate when a BYE is sent, the choice
sending a 200 or an error response upon receiving a BYE while in the of sending a 200 or an error response upon receiving a BYE while in
Mortal state does not affect the resulting termination. Therefore, the Mortal state does not affect the resulting termination.
even though this example uses a 200 response, other responses can Therefore, even though this example uses a 200 response, other
also be used.) responses can also be used.)
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
skipping to change at page 31, line 36 skipping to change at page 30, line 4
F6 BYE Bob -> Alice F6 BYE Bob -> Alice
/* Bob has also transmitted a BYE simultaneously with Alice. Bob /* Bob has also transmitted a BYE simultaneously with Alice. Bob
terminates the session and the dialog. */ 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 /* Since the dialog is in the Moratorium state, Bob responds with a
200 to the BYE request. */ 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 /* Since Alice has transitioned from the Established state to the
Mortal state by sending a BYE, Alice responds with a 200 to the Mortal state by sending a BYE, Alice responds with a 200 to the
BYE request. */ BYE request. */
3.2.2. UA receives re-INVITE (Established state) while in the Mortal 3.2.2. UA Receives re-INVITE (Established State) While in the Mortal
state State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|----------------------->| |----------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<-----------------------| |<-----------------------|
Ear | | Ear Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
|<-----------------------| |<-----------------------|
skipping to change at page 32, line 44 skipping to change at page 30, line 49
| / \ ||Timer J | / \ ||Timer J
|<-------- --------->|| |<-------- --------->||
^| ACK (re-INV) F9 || ^| ACK (re-INV) F9 ||
||<-----------------------|| ||<-----------------------||
Timer K|| || Timer K|| ||
V| || V| ||
Morg | |V Morg | |V
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Established message, re-INVITE, while in the Mortal receives an Established message, re-INVITE, while in the Mortal
state. Bob sends a re-INVITE, and Alice sends a BYE at the same state. Bob sends a re-INVITE, and Alice sends a BYE at the same
time. The re-INVITE receives a 481 response, since the TU of Alice time. The re-INVITE receives a 481 response since the TU of Alice
has transitioned from the Established state to the Mortal state by has transitioned from the Established state to the Mortal state by
sending BYE. Bob sends an ACK for the 481 response, because the ACK 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 for error responses is handled by the transaction layer and, at the
point of receiving the 481 the INVITE client transaction still point of receiving the 481, the INVITE client transaction still
remains (even though the dialog has been terminated). remains (even though the dialog has been terminated).
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
skipping to change at page 34, line 5 skipping to change at page 32, line 5
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 /* Since Alice is in the Mortal state, she responds with a 481 to the
re-INVITE. */ re-INVITE. */
F9 ACK (re-INVITE) Bob -> Alice F9 ACK (re-INVITE) Bob -> Alice
/* ACK for an error response is handled by Bob's INVITE client /* ACK for an error response is handled by Bob's INVITE client
transaction. */ transaction. */
3.2.3. UA receives 200 OK for re-INVITE (Established state) while in 3.2.3. UA Receives 200 OK for re-INVITE (Established State) While in
the Mortal state the Mortal State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|----------------------->| |----------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<-----------------------| |<-----------------------|
Ear | | Ear Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
|<-----------------------| |<-----------------------|
skipping to change at page 34, line 45 skipping to change at page 32, line 45
| | / \ | | | / \ |
|<-------- --------->| |<-------- --------->|
| | ^ | | | ^ |
| | Timer K | | | | Timer K | |
| | V | | | V |
| | Timer J | Morg | | Timer J | Morg
| V | | V |
Morg | | Morg | |
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Established message, 200 to a re-INVITE, while in the receives an Established message, 200 to a re-INVITE, while in the
Mortal state. Bob sends a BYE immediately after sending a re-INVITE. Mortal state. Bob sends a BYE immediately after sending a re-INVITE.
(For example, in the case of a telephone application, it is possible (For example, in the case of a telephone application, it is possible
that a user hangs up the phone immediately after refreshing the 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 session.) Bob sends an ACK for a 200 response to INVITE while in the
Mortal state, completing the INVITE transaction. Mortal state, completing the INVITE transaction.
Note: As noted in Section 3.1.4, implementation issues are outside Note: As noted in Section 3.1.4, implementation issues are outside
the scope of this document, but this note provides a tip for avoiding the scope of this document, but the following tip is provided for
race conditions of this type. That is for the UAC to delay sending a avoiding race conditions of this type. The UAC can delay sending a
BYE F6 until the re-INVITE transaction F5 completes. Implementors BYE F6 until the re-INVITE transaction F5 completes. Implementors
can decouple the actions of the user (e.g. hanging up) from the 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 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 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 how long to wait. In most cases, such an implementation may be
useful in preventing the type of race condition described in this useful in preventing the type of race condition described in this
section. This document expresses no preference about whether or not section. This document expresses no preference about whether or not
they should wait for an ACK to be delivered. After considering the they should wait for an ACK to be delivered. After considering the
impact on users experience, implementors should decide whether to impact on user experience, implementors should decide whether or not
wait for a while or not, because the user experience depends on the to wait for a while, because the user experience depends on the
implementation and has no direct bearing on protocol behaviour. implementation and has no direct bearing on protocol behavior.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
skipping to change at page 37, line 5 skipping to change at page 35, line 5
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK CSeq: 2 ACK
Content-Length: 0 Content-Length: 0
/* Bob sends ACK in the Mortal state to complete the three-way /* Bob sends ACK in the Mortal state to complete the three-way
handshake of the INVITE transaction. */ handshake of the INVITE transaction. */
3.2.4. Callee receives ACK (Moratorium state) while in the Mortal state 3.2.4. Callee Receives ACK (Moratorium State) While in the Mortal State
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
|------------------------------->| |------------------------------->|
Pre | 180 F2 | Pre Pre | 180 F2 | Pre
|<-------------------------------| |<-------------------------------|
Ear | 200 F3 | Ear Ear | 200 F3 | Ear
|<-------------------------------| |<-------------------------------|
Mora | | Mora Mora | | Mora
skipping to change at page 37, line 32 skipping to change at page 35, line 32
Mort | 200 F6 | Mort | 200 F6 |
|------------------------------->| |------------------------------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| | V | | | V |
| | Timer J | Morg | | Timer J | Morg
| V | | V |
Morg | | Morg | |
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Established message, ACK to 200, while in the Mortal 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. 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 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 race condition. A session is not started when the ACK is received
because Bob has already terminated the session by sending a BYE. The because Bob has already terminated the session by sending a BYE. The
answer in the ACK request is just ignored. answer in the ACK request is just ignored.
Note: As noted in Section 3.1.4, implementation issues are outside Note: As noted in Section 3.1.4, implementation issues are outside
the scope of this document, but this note provides a tip for avoiding the scope of this document, but the following tip is provided for
race conditions of this type. Implementors can decouple the actions avoiding race conditions of this type. Implementors can decouple the
of the user (e.g. hanging up) from the actions of the protocol (the actions of the user (e.g., hanging up) from the actions of the
sending of BYE F5), so that the UA can behave like this. In this protocol (the sending of BYE F5), so that the UA can behave like
case, it is the implementor's choice as to how long to wait. In most this. In this case, it is the implementor's choice as to how long to
cases, such an implementation may be useful in preventing the type of wait. In most cases, such an implementation may be useful in
race condition described in this section. This document expresses no preventing the type of race condition described in this section.
preference about whether or not they should wait for an ACK to be This document expresses no preference about whether or not they
delivered. After considering the impact on users experience, should wait for an ACK to be delivered. After considering the impact
implementors should decide whether to wait for a while or not, on user experience, implementors should decide whether or not to wait
because the user experience depends on the implementation and has no for a while, because the user experience depends on the
direct bearing on protocol behaviour. implementation and has no direct bearing on protocol behavior.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
/* RTP streams are established between Alice and Bob */ /* RTP streams are established between Alice and Bob. */
F5 BYE Alice -> Bob F5 BYE 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. */
3.3. Other race conditions 3.3. Other Race Conditions
This section shows examples of race conditions that are not directly This section shows examples of race conditions that are not directly
related to dialog state transition. In SIP, processing functions are related to dialog state transition. In SIP, processing functions are
deployed in three layers, dialog, session, and transaction. They are deployed in three layers: dialog, session, and transaction. They are
related each other, but have to be treated separately. Section 17 of related to each other, but have to be treated separately. Section 17
RFC 3261 [1] details the processing of transactions. This draft has of RFC 3261 [1] details the processing of transactions. This
tried so far to clarify the processing on dialogs. This section document has tried so far to clarify the processing on dialogs. This
explains race conditions which are related to sessions established section explains race conditions that are related to sessions
with SIP. established with SIP.
3.3.1. Re-INVITE crossover 3.3.1. Re-INVITE Crossover
Alice Bob Alice Bob
| | | |
| INVITE F1 | | INVITE F1 |
|--------------------------->| |--------------------------->|
| 180 Ringing F2 | | 180 Ringing F2 |
|<---------------------------| |<---------------------------|
| 200 OK F3 | | 200 OK F3 |
|<---------------------------| |<---------------------------|
| ACK F4 | | ACK F4 |
skipping to change at page 39, line 45 skipping to change at page 37, line 41
| | | | | |
|re-INVITE F14(=F5) v | |re-INVITE F14(=F5) v |
|--------------------------->| |--------------------------->|
| 200 OK F15 | | 200 OK F15 |
|<---------------------------| |<---------------------------|
| ACK F16 | | ACK F16 |
|--------------------------->| |--------------------------->|
| | | |
| | | |
In this scenario, Alice and Bob send re-INVITE at the same time. 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 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 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 [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 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 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. 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID.
Therefore, each user agent must remember whether it has generated the Therefore, each User Agent must remember whether or not it has
Call-ID of the dialog or not, in case an INVITE may cross with generated the Call-ID of the dialog, in case an INVITE may cross with
another INVITE. another INVITE.
In this example, Alice's re-INVITE is for session modification and 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 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 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 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 the owner of Call-ID), the request would refresh and modify the
session at the same time. Then Bob would know that he would not need session at the same time. Then Bob would know that he does not need
to retry his re-INVITE to refresh the session. to retry his re-INVITE to refresh the session.
In another instance where two re-INVITEs for session modification, In another instance, where two re-INVITEs for session modification
cross over, retrying the same re-INVITE again after a 491 by the cross over, retrying the same re-INVITE again after a 491 by the
Call-ID owner (the UA which retries its re-INVITE after the other UA) 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 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 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 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 the firing of the timer may result in the situation where the video
is transmitted immediately after the holding of the audio. This is transmitted immediately after the holding of the audio. This
behavior is probably not intended by the users.) behavior is probably not intended by the users.)
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
skipping to change at page 43, line 4 skipping to change at page 40, line 34
Content-Length: 147 Content-Length: 147
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=- s=-
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE /* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
again after 2.1-4.0 seconds. */ again after 2.1-4.0 seconds. */
F15 200 OK Bob -> Alice F15 200 OK Bob -> Alice
F16 ACK Alice -> Bob F16 ACK Alice -> Bob
3.3.2. UPDATE and re-INVITE crossover 3.3.2. UPDATE and re-INVITE Crossover
Alice Bob Alice Bob
| | | |
| INVITE F1 | | INVITE F1 |
|--------------------------->| |--------------------------->|
| 180 Ringing F2 | | 180 Ringing F2 |
|<---------------------------| |<---------------------------|
| | | |
| 200 OK F3 | | 200 OK F3 |
|<---------------------------| |<---------------------------|
skipping to change at page 45, line 6 skipping to change at page 41, line 44
| | | | | |
| |2.1-4.0 sec | |2.1-4.0 sec
| | | | | |
| UPDATE F13 v | | UPDATE F13 v |
|--------------------------->| |--------------------------->|
| 200 OK F14 | | 200 OK F14 |
|<---------------------------| |<---------------------------|
| | | |
| | | |
In this scenario, the UPDATE contains an SDP offer, therefore the 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 UPDATE and re-INVITE are both responded to with 491 as in the case of
"re-INVITE crossover". When an UPDATE for session refresh which "re-INVITE crossover". When an UPDATE for session refresh that
doesn't contain a session description and a re-INVITE cross each 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 other, both requests succeed with 200 (491 means that a UA has a
pending request). The same is true for UPDATE crossover. In the pending request). The same is true for UPDATE crossover. In the
former case where either UPDATE contains a session description the former case where either UPDATE contains a session description, the
requests fail with 491, and in the latter cases succeed with 200. requests fail with 491; in the latter cases, they succeed with 200.
Note: Note: A 491 response is sent because an SDP offer is pending, and 491
A 491 response is sent because an SDP offer is pending, and 491 is is an error that is related to matters that impact the session
an error which is related to matters that impact the session
established by SIP. established by SIP.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
skipping to change at page 46, line 32 skipping to change at page 43, line 15
Content-Length: 133 Content-Length: 133
v=0 v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=- s=-
c=IN IP4 192.0.2.201 c=IN IP4 192.0.2.201
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
/* A case where a re-INVITE for a session refresh and a UPDATE for a /* This is a case where a re-INVITE for a session refresh and an
call hold are sent at the same time. */ UPDATE for a call hold are sent at the same time. */
F7 491 Request Pending (UPDATE) Bob -> Alice F7 491 Request Pending (UPDATE) 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 Request Pending (re-INVITE) Alice -> Bob
F9 ACK (re-INVITE) Alice -> Bob F9 ACK (re-INVITE) Alice -> Bob
F10 re-INVITE Bob -> Alice F10 re-INVITE Bob -> Alice
skipping to change at page 48, line 9 skipping to change at page 45, line 5
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends the UPDATE /* Since Alice is the owner of the Call-ID, Alice sends the UPDATE
again after 2.1-4.0 seconds. */ again after 2.1-4.0 seconds. */
F14 200 OK Bob -> Alice F14 200 OK Bob -> Alice
3.3.3. Receiving REFER (Established state) while in the Mortal state 3.3.3. Receiving REFER (Established State) While in the Mortal State
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
|----------------------->| |----------------------->|
Pre | 180 Ringing F2 | Pre Pre | 180 Ringing F2 | Pre
|<-----------------------| |<-----------------------|
Ear | | Ear Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
|<-----------------------| |<-----------------------|
skipping to change at page 48, line 46 skipping to change at page 45, line 42
| X | | | X | |
| / \ | | | / \ | |
|<-------- --------->| |<-------- --------->|
| ^ | | | ^ | |
| | Timer K | | | | Timer K | |
| V Timer J | | | V Timer J | |
Morg | V | Morg | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when the This scenario illustrates the race condition that occurs when the UAS
UAS receives an Established message, REFER, while in the Mortal receives an Established message, REFER, while in the Mortal state.
state. Bob sends a REFER, and Alice sends a BYE at the same time. Bob sends a REFER, and Alice sends a BYE at the same time. Bob sends
Bob sends the REFER in the same dialog. Alice's dialog state moves the REFER in the same dialog. Alice's dialog state moves to the
to the Mortal state at the point of sending BYE. In the Mortal Mortal state at the point of sending BYE. In the Mortal state, the
state, the UA possesses dialog information for an internal process UA possesses dialog information for an internal process but the
but the dialog shouldn't exist outwardly. Therefore, the UA sends an dialog shouldn't exist outwardly. Therefore, the UA sends an error
error response to the REFER, which is transmitted as a mid-dialog response to the REFER, which is transmitted as a mid-dialog request.
request. So Alice, in the Mortal state, sends an error response to So Alice, in the Mortal state, sends an error response to the REFER.
the REFER. However, Bob has already started the SUBSCRIBE usage with However, Bob has already started the SUBSCRIBE usage with REFER, so
REFER, so the dialog continues until the SUBSCRIBE usage terminates, the dialog continues until the SUBSCRIBE usage terminates, even
even though the INVITE dialog usage terminates by receiving BYE. though the INVITE dialog usage terminates by receiving BYE. Bob's
Bob's behavior in this case needs to follow the procedures in RFC behavior in this case needs to follow the procedures in RFC 5057 [6].
5057 [6].
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
skipping to change at page 50, line 4 skipping to change at page 46, line 34
/* Alice sends a BYE, and Bob sends a REFER at the same time. Bob /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob
sends the REFER on the INVITE dialog. The dialog state sends the REFER on the INVITE dialog. The dialog state
transitions to the Mortal state at the moment Alice sends the BYE, 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 but Bob doesn't know this until he receives the BYE. A race
condition occurs. */ condition occurs. */
F7 200 OK (BYE) Bob -> Alice F7 200 OK (BYE) Bob -> Alice
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. */
4. IANA Considerations
This document has no actions for IANA. /* Alice in the Mortal state sends a 481 to the REFER. */
5. Security Considerations 4. Security Considerations
This document contains clarifications of behavior specified in RFC This document contains clarifications of behavior specified in RFC
3261 [1], RFC 3264 [2] and RFC 3515 [4]. The security considerations 3261 [1], RFC 3264 [2], and RFC 3515 [4]. The security
of those documents continue to apply after the application of these considerations of those documents continue to apply after the
clarifications. application of these clarifications.
6. Acknowledgements 5. Acknowledgements
The authors would like to thank Robert Sparks, Dean Willis, Cullen The authors would like to thank Robert Sparks, Dean Willis, Cullen
Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro
Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro,
Kenichi Hiragi, Dale Worley, Vijay K. Gurbani and Anders Kristensen Kenichi Hiragi, Dale Worley, Vijay K. Gurbani, and Anders Kristensen
for their comments on this document. for their comments on this document.
7. References 6. References
7.1. Normative References 6.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
7.2. Informative References 6.2. Informative References
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", RFC 5057, November 2007. Protocol", RFC 5057, November 2007.
[7] Sparks, R., "Correct transaction handling for 200 responses to [7] Sparks, R., "Correct transaction handling for 200 responses to
Session Initiation Protocol INVITE requests", Session Initiation Protocol INVITE requests", Work in Progress,
draft-sparks-sip-invfix-02 (work in progress), July 2008. July 2008.
Appendix A. BYE in the Early Dialog Appendix A. BYE in the Early Dialog
This section, related to Section 3.1.3, explains why BYE is not 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 recommended in the Early state, illustrating a case in which a BYE in
the early dialog triggers confusion. the early dialog triggers confusion.
Alice Proxy Bob Carol Alice Proxy Bob Carol
| | | | | | | |
| INVITE F1 | | | | INVITE F1 | | |
skipping to change at page 52, line 45 skipping to change at page 48, line 51
| |------------------------>| | |------------------------>|
| | 200(B) F19 | | | 200(B) F19 |
| 200(B) F20 |<------------------------| | 200(B) F20 |<------------------------|
|<---------------| | |<---------------| |
| | | | | |
| | | | | |
Care is advised in sending BYE in the Early state when forking by a Care is advised in sending BYE in the Early state when forking by a
proxy is expected. In this example, the BYE request progresses proxy is expected. In this example, the BYE request progresses
normally, and it succeeds in correctly terminating the dialog with normally, and it succeeds in correctly terminating the dialog with
Bob. After Bob terminates the dialog by receiving the BYE, he sends a Bob. After Bob terminates the dialog by receiving the BYE, he sends
487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], a 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261
it is RECOMMENDED for the UAS to generate a 487 to any pending [1], it is RECOMMENDED for the UAS to generate a 487 to any pending
requests after receiving a BYE. In the example, Bob sends a 487 to 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 the ini-INVITE since he receives the BYE while the ini-INVITE is in
pending state. pending state.
However, Alice receives a final response to the INVITE (a 200 from However, Alice receives a final response to the INVITE (a 200 from
Carol) even though she has successfully terminated the dialog with Carol) even though she has successfully terminated the dialog with
Bob. This means that, regardless of the success/failure of the BYE in Bob. This means that, regardless of the success/failure of the BYE
the Early state, Alice MUST be prepared for the establishment of a in the Early state, Alice MUST be prepared for the establishment of a
new dialog until receiving the final response for the INVITE and new dialog until receiving the final response for the INVITE and
terminating the INVITE transaction. terminating the INVITE transaction.
It is not illegal to send a BYE in the Early state to terminate a 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. 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 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 carefully. CANCEL is appropriate when the goal is to abandon the
call attempt entirely. BYE is appropriate when the goal is to call attempt entirely. BYE is appropriate when the goal is to
abandon a particular early dialog while allowing the call to be abandon a particular early dialog while allowing the call to be
completed with other destinations. When using either BYE or CANCEL completed with other destinations. When using either BYE or CANCEL,
the UAC must be prepared for the possibility that a call may still be the UAC must be prepared for the possibility that a call may still be
established to one (or more) destinations. established to one or more destinations.
Appendix B. BYE request overlapping with re-INVITE Appendix B. BYE Request Overlapping with re-INVITE
UAC UAS UAC UAS
| | | |
The session has been already established The session has been already established
========================== ==========================
| re-INVITE F1 | | re-INVITE F1 |
|--------------------->| |--------------------->|
| BYE F2 | | BYE F2 |
|--------------------->| |--------------------->|
| 200(BYE) F3 | | 200(BYE) F3 |
skipping to change at page 54, line 4 skipping to change at page 50, line 9
is likely to cause confusion. is likely to cause confusion.
First of all, it is important not to confuse the behavior of the 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 transaction layer and that of the dialog layer. RFC 3261 [1] details
the transaction layer behavior. The dialog layer behavior is the transaction layer behavior. The dialog layer behavior is
explained in this document. It has to be noted that these two explained in this document. It has to be noted that these two
behaviors are independent of each other, even though both layers may behaviors are independent of each other, even though both layers may
be triggered to change their states by sending or receiving the same be triggered to change their states by sending or receiving the same
SIP messages. (A dialog can be terminated even though a transaction SIP messages. (A dialog can be terminated even though a transaction
still remains, and vice versa.) still remains, and vice versa.)
In the sequence above, there is no response to F1, and F2 (BYE) is 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 sent immediately after F1. (F1 is a mid-dialog request. If F1 was
ini-INVITE, BYE could not be sent before the UAC received a an ini-INVITE, BYE could not be sent before the UAC received a
provisional response to the request with a To tag). provisional response to the request with a To tag.)
Below is a figure which illustrates the UAC's dialog state and the Below is a figure that illustrates the UAC's dialog state and the
transaction state. transaction state.
BYE INV dialog UAC UAS BYE INV dialog UAC UAS
: | | : | |
: | | : | |
| | re-INVITE F1 | | | re-INVITE F1 |
o | |--------------------->| o | |--------------------->|
| | | BYE F2 | | | | BYE F2 |
o | (Mortal) |--------------------->| o | (Mortal) |--------------------->|
| | | | 200(BYE) F3 | | | | | 200(BYE) F3 |
skipping to change at page 54, line 35 skipping to change at page 50, line 41
| | | | ACK(INV) F6 | | | | | ACK(INV) F6 |
| | | |--------------------->| | | | |--------------------->|
| | | | | | | | | |
o | o | | o | o | |
| | | | | |
o | | o | |
| | | |
For the UAC, the INVITE client transaction begins at the point F1 is 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 sent. The UAC sends BYE (F2) immediately after F1. This is a
legitimate behavior. (Usually the usage of each SIP method is legitimate behavior. (Usually, the usage of each SIP method is
independent, for BYE and others. However, it should be noted that it 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 is prohibited to send a request with an SDP offer while the previous
offer is in progress.) offer is in progress.)
After that, F2 triggers the BYE client transaction. At the same After that, F2 triggers the BYE client transaction. At the same
time, the dialog state transitions to the Mortal state and then only time, the dialog state transitions to the Mortal state and then only
a BYE or a response to a BYE can be handled. a BYE or a response to a BYE can be handled.
It is permitted to send F4 (a retransmission of INVITE) in the Mortal It is permitted to send F4 (a retransmission of INVITE) in the Mortal
state, because the retransmission of F1 is handled by the transaction state because the retransmission of F1 is handled by the transaction
layer, and the INVITE transaction has not yet transitioned to the layer, and the INVITE transaction has not yet transitioned to the
Terminated state. As is mentioned above, the dialog and the Terminated state. As is mentioned above, the dialog and the
transaction behave independently each other. Therefore the transaction behave independently each other. Therefore, the
transaction handling has to be continued even though the dialog has transaction handling has to be continued even though the dialog has
moved to the Terminated state. moved to the Terminated state.
Note: As noted in Section 3.1.4, implementation issues are outside Note: As noted in Section 3.1.4, implementation issues are outside
the scope of this document, but this note provides a tip for avoiding the scope of this document, but the following tip is provided for
race conditions of this type. That is for the UAC to delay sending avoiding race conditions of this type. The UAC can delay sending BYE
BYE F2 until the re-INVITE transaction F1 completes. Implementors F2 until the re-INVITE transaction F1 completes. Implementors can
can decouple the actions of the user (e.g. hanging up) from the decouple the actions of the user (e.g., hanging up) from the actions
actions of the protocol (the sending of BYE F2), so that the UA can of the protocol (the sending of BYE F2), so that the UA can behave
behave like this. In this case, it is the implementor's choice as to like this. In this case, it is the implementor's choice as to how
how long to wait. In most cases, such an implementation may be long to wait. In most cases, such an implementation may be useful to
useful to prevent this case. This document expresses no preference prevent this case. This document expresses no preference about
about whether or not they should wait for an ACK to be delivered. whether or not they should wait for an ACK to be delivered. After
After considering the impact on users experience, implementors should considering the impact on user experience, implementors should decide
decide whether to wait for a while or not, because the user whether or not to wait for a while, because the user experience
experience depends on the implementation and has no direct bearing on depends on the implementation and has no direct bearing on protocol
protocol behaviour. behavior.
Next, the UAS's state is shown below. Next, the UAS's state is shown below.
UAC UAS dialog INV BYE UAC UAS dialog INV BYE
| | : | | :
| | : | | :
| re-INVITE F1 | | | re-INVITE F1 | |
|-------------->x | | |-------------->x | |
| BYE F2 | | | BYE F2 | |
|--------------------->| | o |--------------------->| | o
skipping to change at page 55, line 42 skipping to change at page 51, line 50
|--------------------->| | o | |--------------------->| | o |
| 4xx/5xx(INV) F5 | o | o | 4xx/5xx(INV) F5 | o | o
|<---------------------| | |<---------------------| |
| ACK(INV) F6 | | | ACK(INV) F6 | |
|--------------------->| |<-Start Timer I |--------------------->| |<-Start Timer I
| | | | | |
| | | | | |
| | o | | o
| | | |
For the UAS, it can be considered that packet the F1 is lost or For the UAS, it can be considered that packet F1 is lost or delayed
delayed (here the behavior is explained for the case that the UAS (here, the behavior is explained for the case that the UAS receives
receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE transaction
transaction for UAS, and simultaneously the dialog moves to the for the UAS, and simultaneously the dialog moves to the Mortal state.
Mortal state. Then, upon the reception of F4 the INVITE server Then, upon the reception of F4, the INVITE server transaction begins.
transaction begins. (It is permitted to start the INVITE server (It is permitted to start the INVITE server transaction in the Mortal
transaction in the Mortal state. The INVITE server transaction state. The INVITE server transaction begins to handle the received
begins to handle the received SIP request regardless of the dialog SIP request regardless of the dialog state.) The UAS's TU sends an
state.) The UAS's TU sends an appropriate error response for the F4 appropriate error response for the F4 INVITE, either 481 (because the
INVITE, either 481 (because the TU knows that the dialog which TU knows that the dialog that matches the INVITE is in the Terminated
matches the INVITE is in the Terminated state) or 500 (because the state) or 500 (because the re-sent F4 has an out-of-order CSeq). (It
re-sent F4 has an out-of-order CSeq). (It is mentioned above that is mentioned above that INVITE message F4 (and F1) is a mid-dialog
INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog request. Mid-dialog requests have a To tag. It should be noted that
requests have a To tag. It should be noted that the UAS's TU does the UAS's TU does not begin a new dialog upon the reception of INVITE
not begin a new dialog upon the reception of INVITE with a To tag.) with a To tag.)
Appendix C. UA's behavior for CANCEL Appendix C. UA's Behavior for CANCEL
This section explains the CANCEL behaviors which indirectly impact This section explains the CANCEL behaviors that indirectly impact the
the dialog state transition in the Early state. CANCEL does not have dialog state transition in the Early state. CANCEL does not have any
any influence on the UAC's dialog state. However, the request has a influence on the UAC's dialog state. However, the request has an
indirect influence on the dialog state transition because it has a indirect influence on the dialog state transition because it has a
significant effect on ini-INVITE. For the UAS the CANCEL request has significant effect on ini-INVITE. For the UAS, the CANCEL request
more direct effects on the dialog than the sending of a CANCEL by the has more direct effects on the dialog than on the sending of a CANCEL
UAC, because it can be a trigger to send the 487 response. Figure 3 by the UAC, because it can be a trigger to send the 487 response.
explains UAS's behavior in the Early state. This flow diagram is Figure 3 explains the UAS's behavior in the Early state. This flow
only an explanatory figure, and the actual dialog state transition is diagram is only an explanatory figure, and the actual dialog state
as illustrated in Figures 1 and 2. transition is as illustrated in Figures 1 and 2.
In the flow, full lines are related to dialog state transition, and In the flow, full lines are related to dialog state transition, and
dotted lines are involved with CANCEL. (r) represents the reception dotted lines are involved with CANCEL. (r) represents the reception
of signaling, and (s) means sending. There is no dialog state for of signaling, and (s) means sending. There is no dialog state for
CANCEL, but here the Cancelled state is handled virtually just 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 the ease of understanding of the UA's behavior when it sends and
receives CANCEL. receives CANCEL.
+-------------+ +-------------+
| Preparative |---+ | Preparative |---+
skipping to change at page 57, line 39 skipping to change at page 53, line 39
+------------+ +------------+
| Terminated | | Terminated |
+------------+ +------------+
Figure 3: CANCEL flow diagram for UAS Figure 3: CANCEL flow diagram for UAS
There are two behaviors for the UAS depending on the state when it There are two behaviors for the UAS depending on the state when it
receives a CANCEL. receives a CANCEL.
The first behavior is when the UAS receives a CANCEL in the Early 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, state. In this case, the UAS immediately sends a 487 for the INVITE,
and the dialog transitions to the Terminated state. and the dialog transitions to the Terminated state.
The other is the case in which the UAS receives a CANCEL while in the 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 Confirmed state. In this case, the dialog state transition does not
occur because UAS has already sent a final response to the INVITE to occur, because the UAS has already sent a final response to the
which the CANCEL is targeted. (Note that, because of the UAC's INVITE to which the CANCEL is targeted. (Note that, because of the
behavior, a UAS that receives a CANCEL in the Confirmed state can UAC's behavior, a UAS that receives a CANCEL in the Confirmed state
expect to receive a BYE immediately and move to the Terminated state. can expect to receive a BYE immediately and move to the Terminated
However, the UAS's state does not transition until it actually state. However, the UAS's state does not transition until it
receives a BYE.) actually receives a BYE.)
Appendix D. Notes on the request in the Mortal state Appendix D. Notes on the Request in the Mortal State
This section describes the UA's behavior in the Mortal state, which This section describes the UA's behavior in the Mortal state, which
needs careful attention. Note that every transaction completes needs careful attention. Note that every transaction completes
independently of others, following the principle of RFC 3261 [1]. independently of others, following the principle of RFC 3261 [1].
In the Mortal state, only a BYE can be accepted, and the other 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. messages in the INVITE dialog usage are responded to with an error.
However, sending of ACK and the authentication procedure for BYE are However, sending of ACK and the authentication procedure for BYE are
conducted in this state. (The handling of messages concerning conducted in this state. (The handling of messages concerning
multiple dialog usages is out of the scope of this document. Refer multiple dialog usages is out of the scope of this document. Refer
to RFC 5057 [6] for further information.) to RFC 5057 [6] for further information.)
ACK for error responses is handled by the transaction layer, so the ACK for error responses is handled by the transaction layer, so the
handling is not related to the dialog state. Unlike the ACK for handling is not related to the dialog state. Unlike the ACK for
error responses, ACK for 2xx responses is a request newly generated 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 by a TU. However, the ACK for 2xx and the ACK for error responses
are both a part of the INVITE transaction, even though their handling are both part of the INVITE transaction, even though their handling
differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE
transaction is completed by the three-way handshake, which includes transaction is completed by the three-way handshake, which includes
ACK, even in the Mortal state. ACK, even in the Mortal state.
Considering actual implementation, the UA needs to keep the INVITE Considering actual implementation, the UA needs to keep the INVITE
dialog usage until the Mortal state finishes, so that it is able to 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 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 is received in the Mortal state, the duration of the INVITE dialog
usage will be extended to 64*T1 seconds after the receiving of the usage will be extended to 64*T1 seconds after the receipt of the 2xx,
2xx, to cope with the possible 2xx retransmission. (The duration of to cope with the possible 2xx retransmission. (The duration of the
the 2xx retransmission is 64*T1, so the UA needs to be prepared to 2xx retransmission is 64*T1, so the UA needs to be prepared to handle
handle the retransmission for this duration.) However, the UA shall the retransmission for this duration.) However, the UA shall send an
send an error response to other requests, since the INVITE dialog error response to other requests, since the INVITE dialog usage in
usage in the Mortal state is kept only for the sending of ACK for the Mortal state is kept only for the sending of ACK for 2xx.
2xx.
The BYE authentication procedure shall be processed in the Mortal The BYE authentication procedure shall be processed in the Mortal
state. When authentication is requested by a 401 or 407 response, state. When authentication is requested by a 401 or 407 response,
UAC resends BYE with appropriate credentials. Also the UAS handles the UAC resends BYE with appropriate credentials. Also, the UAS
the retransmission of the BYE for which it requested authentication. handles the retransmission of the BYE for which it requested
authentication.
Appendix E. Forking and receiving new To tags Appendix E. Forking and Receiving New To Tags
This section details the behavior of the TU when it receives multiple This section details the behavior of the TU when it receives multiple
responses with a different To tag to ini-INVITE. responses with different To tags to the ini-INVITE.
When an INVITE is forked inside a SIP network, there is a possibility When an INVITE is forked inside a SIP network, there is a possibility
that the TU receives multiple responses to the ini-INVITE with that the TU receives multiple responses to the ini-INVITE with
differing To tags (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. differing To tags (see Sections 12.1, 13.1, 13.2.2.4, 16.7, 19.3,
etc., of RFC 3261 [1]). If the TU receives multiple 1xx responses
of RFC 3261 [1]). If the TU receives multiple 1xx responses with with different To tags, the original DSM forks and a new DSM instance
different To tags, the original DSM forks and a new DSM instance is is created. As a consequence, multiple early dialogs are generated.
created. As a consequence multiple early dialogs are generated.
If one of the multiple early dialogs receives a 2xx response, it If one of the multiple early dialogs receives a 2xx response, it
naturally transitions to the Confirmed state. No DSM state naturally transitions to the Confirmed state. No DSM state
transition occurs for the other early dialogs, and their sessions transition occurs for the other early dialogs, and their sessions
(early media) terminate. The TU of the UAC terminates the INVITE (early media) terminate. The TU of the UAC terminates the INVITE
transaction after 64*T1 seconds starting at the point of receiving transaction after 64*T1 seconds, starting at the point of receiving
the first 2xx response. Moreover, all mortal early dialogs which do the first 2xx response. Moreover, all mortal early dialogs that do
not transition to the Established state are terminated (See Section 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 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 early dialog that the UA will terminate when another early dialog is
confirmed. confirmed.
Below is an example sequence in which two 180 responses with Below is an example sequence in which two 180 responses with
different To tags are received, and then a 200 response for one of different To tags are received, and then a 200 response for one of
the early dialogs (dialog A) is received. Dotted lines (..) in the the early dialogs (dialog A) is received. Dotted lines (..) in the
sequences are auxiliary lines to represent the influence on dialog B. sequences are auxiliary lines to represent the influence on dialog B.
UAC UAC
dialog(A) | INVITE F1 dialog(A) | INVITE F1
skipping to change at page 60, line 4 skipping to change at page 56, line 32
| | |(13.2.2.4 of RFC 3261 [1]) | | |(13.2.2.4 of RFC 3261 [1])
| | | | | | | |
| | | | | | | |
| | V | | | V |
o..........|.(terminate INVITE transaction) o..........|.(terminate INVITE transaction)
terminated | | terminated | |
dialog(B) | | dialog(B) | |
| | | |
Figure 4: Receiving 1xx responses with different To tags Figure 4: Receiving 1xx responses with different To tags
The figure above shows the DSM inside a SIP TU. Triggered by the The figure above shows the DSM inside a SIP TU. Triggered by the
reception of a provisional response with a different To tag (F4 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. 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, 64*T1 seconds later, dialog A receives a 200 OK response. Dialog B,
which does not transition to the Established state, terminates. which does not transition to the Established state, terminates.
Next, the behavior of a TU which receives multiple 2xx responses with Next, the behavior of a TU that receives multiple 2xx responses with
different To tags is explained. When a mortal early dialog, which different To tags is explained. When a mortal early dialog that did
did not match the first 2xx response that the TU received, receives not match the first 2xx response that the TU received receives
another 2xx response which matches its To tag before the 64*T1 INVITE another 2xx response that matches its To tag before the 64*T1 INVITE
transaction timeout, its DSM transitions to the Confirmed state. transaction timeout, its DSM transitions to the Confirmed state.
However, the session on the mortal early dialog is terminated when 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 the TU receives the first 2xx to establish a dialog, so no session is
established for the mortal early dialog. Therefore, when the mortal established for the mortal early dialog. Therefore, when the mortal
early dialog receives a 2xx response, the TU sends an ACK and, early dialog receives a 2xx response, the TU sends an ACK and,
immediately after, the TU usually sends a BYE to terminate the DSM. immediately after, the TU usually sends a BYE to terminate the DSM.
(In special cases, e.g. if a UA intends to establish multiple (In special cases, e.g., if a UA intends to establish multiple
dialogs, the TU may not send the BYE.) dialogs, the TU may not send the BYE.)
The handling of the second early dialog after receiving the 200 for 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 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 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 useful action and not the only valid one. Some devices might want to
handle things differently. For instance, a conference focus that has handle things differently. For instance, a conference focus that has
sent out an INVITE that forks may want to accept and mix all the 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. dialogs it gets. In that case, no early dialog is treated as mortal.
Below is an example sequence in which two 180 responses with a 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 different To tag are received and then a 200 response for each of the
skipping to change at page 61, line 41 skipping to change at page 58, line 4
V | | | V | | |
Morg o | | Morg o | |
| | | |
Figure 5: Receiving 1xx and 2xx responses with different To tags Figure 5: Receiving 1xx and 2xx responses with different To tags
Below is an example sequence when a TU receives multiple 200 Below is an example sequence when a TU receives multiple 200
responses with different To tags before the 64*T1 timeout of the responses with different To tags before the 64*T1 timeout of the
INVITE transaction in the absence of a provisional response. Even INVITE transaction in the absence of a provisional response. Even
though a TU does not receive a provisional response, the TU needs to though a TU does not receive a provisional response, the TU needs to
process the 2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In 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 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 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 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.) establish multiple dialogs, the TU may not send the BYE.)
UAC UAC
dialog(A) | INVITE F1 dialog(A) | INVITE F1
Pre o |-----------------------> Pre o |----------------------->
| | 100 F2 | | 100 F2
| |<----------------------- | |<-----------------------
| | 180(To tag=A) F3 | | 180(To tag=A) F3
Ear | |<----------------------- Ear | |<-----------------------
| | | |
| | 200(A) F4 | | 200(A) F4
Mora |..........|<----------------------- Mora |..........|<-----------------------
skipping to change at page 62, line 39 skipping to change at page 58, line 45
V | | | V | | |
Morg o | | Morg o | |
| | | |
Figure 6: Receiving 2xx responses with different To tags Figure 6: Receiving 2xx responses with different To tags
Below is an example sequence in which the option tag 100rel (RFC 3262 Below is an example sequence in which the option tag 100rel (RFC 3262
[5]) is required by a 180. [5]) is required by a 180.
If a forking proxy supports 100rel, it transparently transmits to the If a forking proxy supports 100rel, it transparently transmits to the
UAC a provisional response which contains a Require header with the UAC a provisional response that contains a Require header with the
value of 100rel. Upon receiving a provisional response with 100rel, value of 100rel. Upon receiving a provisional response with 100rel,
the UAC establishes the early dialog (B) and sends PRACK. (Here, the UAC establishes the early dialog (B) and sends PRACK (Provisional
also, every transaction completes independently of others.) Response Acknowledgement). (Here, also, every transaction completes
independently of others.)
As in Figure 4, the early dialog (B) terminates at the same time the 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 INVITE transaction terminates. In the case where a proxy does not
support 100rel, the provisional response will be handled in the usual support 100rel, the provisional response will be handled in the usual
way (a provisional response with 100rel is discarded by the proxy, way (a provisional response with 100rel is discarded by the proxy,
not to be transmitted to the UAC). not to be transmitted to the UAC).
UAC UAC
dialog(A) | INVITE F1 dialog(A) | INVITE F1
Pre o |-------------------------> Pre o |------------------------->
| | 100 F2 | | 100 F2
skipping to change at page 63, line 45 skipping to change at page 60, line 13
when using the mechanism for reliable provisional responses (100rel) when using the mechanism for reliable provisional responses (100rel)
Authors' Addresses Authors' Addresses
Miki Hasebe Miki Hasebe
NTT-east Corporation NTT-east Corporation
19-2 Nishi-shinjuku 3-chome 19-2 Nishi-shinjuku 3-chome
Shinjuku-ku, Tokyo 163-8019 Shinjuku-ku, Tokyo 163-8019
JP JP
Email: hasebe.miki@east.ntt.co.jp EMail: hasebe.miki@east.ntt.co.jp
Jun Koshiko Jun Koshiko
NTT-east Corporation NTT-east Corporation
19-2 Nishi-shinjuku 3-chome 19-2 Nishi-shinjuku 3-chome
Shinjuku-ku, Tokyo 163-8019 Shinjuku-ku, Tokyo 163-8019
JP JP
Email: j.koshiko@east.ntt.co.jp EMail: j.koshiko@east.ntt.co.jp
Yasushi Suzuki Yasushi Suzuki
NTT Corporation NTT Corporation
9-11, Midori-cho 3-Chome 9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
JP JP
Email: suzuki.yasushi@lab.ntt.co.jp EMail: suzuki.yasushi@lab.ntt.co.jp
Tomoyuki Yoshikawa Tomoyuki Yoshikawa
NTT-east Corporation NTT-east Corporation
19-2 Nishi-shinjuku 3-chome 19-2 Nishi-shinjuku 3-chome
Shinjuku-ku, Tokyo 163-8019 Shinjuku-ku, Tokyo 163-8019
JP JP
Email: tomoyuki.yoshikawa@east.ntt.co.jp EMail: tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat Paul H. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
US US
Email: pkyzivat@cisco.com EMail: pkyzivat@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 167 change blocks. 
460 lines changed or deleted 446 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/