draft-ietf-sipping-race-examples-04.txt   draft-ietf-sipping-race-examples-05.txt 
sipping M. Hasebe sipping M. Hasebe
Internet-Draft J. Koshiko Internet-Draft J. Koshiko
Intended status: Best Current Y. Suzuki Intended status: Best Current NTT-east Corporation
Practice T. Yoshikawa Practice Y. Suzuki
Expires: March 1, 2008 NTT-east Corporation Expires: August 21, 2008 NTT Corporation
T. Yoshikawa
NTT-east Corporation
P. Kyzivat P. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
August 29, 2007 February 18, 2008
Examples call flow in race condition on Session Initiation Protocol Example calls flows of race conditions in the Session Initiation
draft-ietf-sipping-race-examples-04 Protocol (SIP)
draft-ietf-sipping-race-examples-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 1, 2008. This Internet-Draft will expire on August 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document gives examples of the Session Initiation Protocol (SIP) This document gives examples call flows of race conditions in the
call flows in race condition. Call flows in race condition are Session Initiation Protocol (SIP). Race conditions are inherently
confusing, and this document shows the best practice to handle them. confusing and difficult to thwart; this document shows the best
The elements in these call flows include SIP User Agents and SIP practices to handle them. The elements in these call flows include
Proxies. Call flow diagrams and message details are shown. SIP User Agents and SIP Proxy Servers. Call flow diagrams and
message details are given.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4
1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 4
1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 5
2. The Dialog State Machine for INVITE dialog usage . . . . . . . 4 2. The Dialog State Machine for INVITE dialog usage . . . . . . . 6
3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10 3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Receiving message in the Moratorium State . . . . . . . . 11 3.1. Receiving message in the Moratorium State . . . . . . . . 12
3.1.1. Receiving Initial INVITE retransmission 3.1.1. Receiving Initial INVITE retransmission
(Preparative state) in Moratorium state . . . . . . . 11 (Preparative state) while in the Moratorium state . . 12
3.1.2. Receiving CANCEL (Early state) in Moratorium state . . 13 3.1.2. Receiving CANCEL (Early state) when in Moratorium
3.1.3. Receiving BYE (Early state) in Moratorium state . . . 15 state . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4. Receiving re-INVITE (Established state) in 3.1.3. Receiving BYE (Early state) while in the
Moratorium state (case 1) . . . . . . . . . . . . . . 17 Moratorium state . . . . . . . . . . . . . . . . . . . 16
3.1.5. Receiving re-INVITE (Established state) in 3.1.4. Receiving re-INVITE (Established state) while in
Moratorium state (case 2) . . . . . . . . . . . . . . 22 the Moratorium state (case 1) . . . . . . . . . . . . 18
3.1.6. Receiving BYE (Established state) in Moratorium 3.1.5. Receiving re-INVITE (Established state) while in
state . . . . . . . . . . . . . . . . . . . . . . . . 26 the Moratorium state (case 2) . . . . . . . . . . . . 23
3.2. Receiving message in the Mortal State . . . . . . . . . . 28 3.1.6. Receiving BYE (Established state) while in the
3.2.1. Receiving BYE (Establish state) in Mortal state . . . 28 Moratorium state . . . . . . . . . . . . . . . . . . . 27
3.2.2. Receiving re-INVITE (Establish state) in Mortal 3.2. Receiving message in the Mortal State . . . . . . . . . . 29
state . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.1. Receiving BYE (Established state) while in the
Mortal state . . . . . . . . . . . . . . . . . . . . . 29
3.2.2. Receiving re-INVITE (Established state) while in
the Mortal state . . . . . . . . . . . . . . . . . . . 32
3.2.3. Receiving 200 OK for re-INVITE (Established state) 3.2.3. Receiving 200 OK for re-INVITE (Established state)
in Mortal state . . . . . . . . . . . . . . . . . . . 33 while in the Mortal state . . . . . . . . . . . . . . 34
3.2.4. Receiving ACK (Moratorium state) in Mortal state . . . 36 3.2.4. Receiving ACK (Moratorium state) while in the
3.3. Other race conditions . . . . . . . . . . . . . . . . . . 37 Mortal state . . . . . . . . . . . . . . . . . . . . . 37
3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 37 3.3. Other race conditions . . . . . . . . . . . . . . . . . . 38
3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 43 3.3.1. Re-INVITE crossover . . . . . . . . . . . . . . . . . 38
3.3.3. Receiving REFER (Establish state) in Mortal state . . 47 3.3.2. UPDATE and re-INVITE crossover . . . . . . . . . . . . 44
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 3.3.3. Receiving REFER (Established state) while in the
5. Security Considerations . . . . . . . . . . . . . . . . . . . 49 Mortal state . . . . . . . . . . . . . . . . . . . . . 48
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 49 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 49 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . 49 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . 51 7.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 54 Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 50
Appendix D. Notes on the request in Mortal state . . . . . . . . 55 Appendix B. BYE request overlapping with re-INVITE . . . . . . . 52
Appendix E. Forking and receiving new To tags . . . . . . . . . . 56 Appendix C. UA's behavior for CANCEL . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Appendix D. Notes on the request in the Mortal state . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . . . 62 Appendix E. Forking and receiving new To tags . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 64
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
condition, which stems from the dialog state transition mainly conditions, which stem from transitions in dialog states; mainly
established by INVITE. transitions during session establishment after the sending of an
INVITE.
When implementing SIP, various complex situations may arise. When implementing SIP, various complex situations may arise.
Therefore, it will be helpful to provide implementors of the protocol Therefore, it is helpful to provide implementors of the protocol with
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 UA behaviors when messages cross each
other as race conditions. By clarifying operation under race other as race conditions. By clarifying the operation under race
conditions, inconsistent interpretations between implementations are conditions, inconsistent interpretations between implementations are
avoided and interoperability is expected to be promoted. 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 the version 2.0 of SIP defined in RFC
3261 [1] with SDP usage described in RFC 3264 [2]. 3261 [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 architecture, 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
taken into consideration and help understanding the call flow taken into consideration and help understanding of the call flow
examples. examples.
These flows do not assume specific underlying transport protocols These flows do not assume specific underlying transport protocols
such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for
details on the transport issues for SIP. details of the transport issues for SIP.
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 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 error) 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 as parameters. Note: The flows in this document must not be copied
they are by implementors because additional characteristics were as-is by implementors because additional annotations have been
incorporated into the 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 are best common practice according to examples of SIP usage, which exemplify best common practice according
IETF consensus. to IETF consensus.
For simplicity in reading and editing the document, there are a For reasons of simplicity in reading and editing the document, there
number of differences between some of the examples and actual SIP are a number of differences between some of the examples and actual
messages. For instance, Call-IDs are often repeated, CSeq often SIP messages. For instance, Call-IDs are often replicated, CSeq
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 which 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
used in RFC 3261 [1] sections 13-15. (Which differs somewhat from
the definition of the term in RFC 3261.) RFC 5057 [6] introduces
another term, "invite dialog usage", which is more precisely defined.
The term "session" used herein is almost, but not quite, identical to
the term "invite dialog usage". The two have differing definitions
of when the state ends -- the session ends earlier, when BYE is sent
or received.
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 UAC (User Agent Client) For instance, a race condition occurs when a UAC (User Agent Client)
sends a CANCEL in the Early state while UAS (User Agent Server) is sends a CANCEL in the Early state while the UAS (User Agent Server)
transiting from the Early state to the Confirmed state by sending a is transitioning from the Early state to the Confirmed state by
200 OK to initial INVITE (indicated as "ini-INVITE" hereafter). The sending a 200 OK to an initial INVITE (indicated as "ini-INVITE"
DSM (dialog state machine) for the INVITE dialog usage is presented hereafter). The DSM (dialog state machine) for the INVITE dialog
as follows to help understanding UA's behavior in race conditions. usage is presented as follows to help understanding of the UA's
behavior in race conditions.
The DSM clarifies UA's behavior by subdividing the dialog state shown The DSM clarifies the UA's behavior by subdividing the dialog state
in RFC 3261 [1] into some internal states. We call the state before shown in RFC 3261 [1] into various internal states. We call the
a dialog establishment the Preparative state. The Confirmed state is state before the establishment of a dialog the Preparative state.
subdivided into two substates, the Moratorium and Established states, The Confirmed state is subdivided into two substates, the Moratorium
and the Terminated state is subdivided into the Mortal and Morgue and the Established states, and the Terminated state is subdivided
states. Messages which are the triggers of the state transitions into the Mortal and Morgue states. Messages which are the triggers
between these states are indicated with arrows. In this figure, for the state transitions between these states are indicated with
messages which are not related to state transition are omitted. arrows. In this figure, messages which are not related to state
transition are omitted.
Below are the DSMs for UAC and UAS respectively. 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
| | | | | |
| | 1xx-tag | | | 1xx-tag |
| V w/new tag | | V w/new tag |
| +-----------------+ [new DSM] | | +-----------------+ [new DSM] |
skipping to change at page 6, line 44 skipping to change at page 7, line 44
| | | | | | | | | | | | | |
| V V | | V | | V V | | V |
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | |--C-+ | | | | | | |--C-+
| | Morgue | | | |Established| | | 2xx,ACK | | Morgue | | | |Established| | | 2xx,ACK
| | | | | | |<-C-+ | | | | | | |<-C-+
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | |
+------------------------+ +------------------+ +------------------------+ +------------------+
(r): indicates only reception is allowed. (r): indicates that only reception is allowed.
Where (r) is not indicated, response means receive, request Where (r) is not used as an indicator, "response" means
means send. receive, and "request" means send.
(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.
Caller MAY send a BYE in the Early state, even though this behavior The caller MAY send a BYE in the Early state, even though this
is NOT RECOMMENDED. The BYE sent in the Early state terminates the behavior is NOT RECOMMENDED. A BYE sent in the Early state
early dialog with a specific To tag. That is, when a proxy is terminates the early dialog using a specific To tag. That is, when a
performing forking, the BYE is only able to terminate the early proxy is performing forking, the BYE is only able to terminate the
dialog with a particular UA. If caller wants to terminate all early early dialog with a particular UA. If the caller wants to terminate
dialogs instead of that with a particular UA, it needs to send all early dialogs instead of that with a particular UA, it needs to
CANCEL, not BYE. However, it is not illegal to send BYE in the Early send CANCEL, not BYE. However, it is not illegal to send BYE in the
state to terminate a specific early dialog according to the caller's Early state to terminate a specific early dialog if this is to the
intent. Moreover, until caller receives a final response and caller's intent. Moreover, until the caller receives a final
terminates the INVITE transaction, the caller MUST be prepared to response and terminates the INVITE transaction, the caller MUST be
establish a dialog by receiving a new response to the INVITE even prepared to establish a dialog by receiving a new response to the
though it had sent a CANCEL or BYE and terminated the dialog (see INVITE even if it has already sent a CANCEL or BYE and terminated the
Appendix A). dialog (see Appendix A).
INV +-----------------------------------------------+ INV +-----------------------------------------------+
--->| Preparative | --->| Preparative |
+-----------------------------------------------+ +-----------------------------------------------+
| | | | | |
| 3xx-6xx | 1xx-tag | 2xx | 3xx-6xx | 1xx-tag | 2xx
| | | | | |
| V | | V |
| +------------------+ | | +------------------+ |
| 3xx-6xx | | | | 3xx-6xx | | |
skipping to change at page 8, line 44 skipping to change at page 9, line 44
| V V | | V | | V V | | V |
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | | | | | | | | | |
| | 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 indicated, response means send, Where (sr) is not used as an indicator, "response" means send,
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 callee's DSM for the INVITE dialog usage. The Figure 2 represents the callee's DSM for the INVITE dialog usage.
figure does not illustrate the state transition related to CANCEL The figure does not illustrate the state transition related to CANCEL
request. 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 487 immediately after the reception of the
CANCEL. Considering this, the behavior upon the reception of the CANCEL. This behavior upon the reception of the CANCEL request is
CANCEL request is further explained in Appendix C. further explained in Appendix C.
Following are UA's behaviors in each state. The UA's behavior in each state is as follows.
Preparative (Pre): The Preparative state is a state until the early Preparative (Pre): The Preparative state is in effect until the
dialog is established by sending or receiving a provisional early dialog is established by sending or receiving a provisional
response with To tag after an ini-INVITE is sent or received. The response with a To tag after an ini-INVITE is sent or received.
dialog has not existed yet in the Preparative state. If UA sends The dialog does not yet exist in the Preparative state. If the UA
or receives a 2xx response, the dialog state transit from the sends or receives a 2xx response, the dialog state transitions
Preparative to the Moratorium state which is a substate of the from the Preparative to the Moratorium state, which is a substate
Confirmed state. In addition, if UA sends or receives a 3xx-6xx of the Confirmed state. In addition, if UA sends or receives a
response the dialog state transit to the Morgue state which is a 3xx-6xx response the dialog state transitions to the Morgue state
substate of the Terminated state. Sending an ACK for a 3xx-6xx which is a substate of the Terminated state. Sending an ACK for a
response and retransmissions of 3xx-6xx are not expressed on the 3xx-6xx response and retransmissions of 3xx-6xx are not shown on
DSMs because they are sent by the INVITE transaction. 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 with To tag. The early dialog exists a provisional response except 100 Trying. The early dialog exists
though the dialog does not exist in this state yet. The dialog even though the dialog does not exist in this state yet. The
state transits from the Early to Moratorium state, a substate of dialog state transitions from the Early to the Moratorium state, a
the Confirmed state, by sending or receiving a 2xx response. In substate of the Confirmed state, by sending or receiving a 2xx
addition, the dialog state transits to the Morgue state, a response. In addition, the dialog state transitions to the Morgue
substate of the Terminated state, by sending or receiving a 3xx- state, a substate of the Terminated state, by sending or receiving
6xx response. Sending an ACK for a 3xx-6xx response and a 3xx-6xx response. Sending an ACK for a 3xx-6xx response and
retransmissions of 3xx-6xx are not expressed on this DSM because retransmissions of 3xx-6xx are not shown on this DSM because they
they are automatically processed on transaction layer and don't are automatically processed on the transaction layer and don't
influence the dialog state. UAC may send CANCEL in the Early influence the dialog state. The UAC may send a CANCEL in the
state. UAC may send BYE (although it is not recommended). UAS Early state. The UAC may also send a BYE (although it is not
may send a 1xx-6xx response. Sending or receiving of a CANCEL recommended). The UAS may send a 1xx-6xx response. The sending
request does not have direct influences on dialog state. The UA's or receiving of a CANCEL request does not have a direct influence
behavior upon the reception of the CANCEL request is further on the dialog state. The UA's behavior upon the reception of the
explained in Appendix C. CANCEL request is explained further in Appendix C.
Confirmed (Con): Sending or receiving of a 2xx final response Confirmed (Con): The sending or receiving of a 2xx final response
establishes a dialog. Dialog exists in this state. The Confirmed establishes a dialog. The dialog starts in this state. The
state transits to the Mortal state, a substate of the Terminated Confirmed state transitions to the Mortal state, a substate of the
state, by sending or receiving a BYE request. The Confirmed state Terminated state, by sending or receiving a BYE request. The
has two substates, the Moratorium and Established state, which are Confirmed state has two substates, the Moratorium and the
different in messages UAs are allowed to send. Established states, which are different with regard to the
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 the behavior of the superstate. The Confirmed state and inherits its behavior. The Moratorium state
Moratorium state transits to the Established state by sending or transitions to the Established state by sending or receiving an
receiving an ACK request. UAC may send ACK and 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 the behavior of superstate. Both Confirmed state and inherits its behavior. Both caller and callee
caller and callee may send various messages which influence a may send various messages which influence a dialog. The caller
dialog. Caller supports the transmission of ACK in response to supports the transmission of ACK to the retransmission of a 2xx
retransmission of a 2xx response to an ini-INVITE. response to an ini-INVITE.
Terminated (Ter): The Terminated state is divided 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, UAs hold when a dialog is being terminated. In this state, the UA holds
information about the dialog which is being terminated. information about the dialog which is being terminated.
Mortal (Mort): Caller and callee enter the Mortal state by sending Mortal (Mort): The caller and callee enter the Mortal state by
or receiving a BYE. UA MUST NOT send any new requests within the sending or receiving a BYE. The UA MUST NOT send any new requests
dialog because there is no dialog. (Here the new requests do not within the dialog because there is no dialog. (Here the new
include ACK for 2xx and BYE for 401 or 407 as further explained in requests do not include ACK for 2xx and BYE for 401 or 407 as
Appendix D below.) In this state, only BYE or its response can be further explained in Appendix D below.) In the Mortal state, BYE
handled, and no other messages can be received. This addresses can be accepted, and the other messages in the INVITE dialog usage
the case where BYE is sent by both a caller and a callee to are responded with an error. This addresses the case where BYE is
exchange reports about the session when it is being terminated. sent by both a caller and a callee to exchange reports about the
Therefore the UA possesses dialog information for internal session when it is being terminated. Therefore the UA possesses
processing but the dialog shouldn't be externally visible. The UA dialog information for internal processing but the dialog
stops managing its dialog state and changes it to the Morgue shouldn't be externally visible. The UA stops managing its dialog
state, when the BYE transaction is terminated. state and changes it to the Morgue state, when the BYE transaction
is terminated.
Morgue (Morg): The dialog no longer exists in this state. Sending Morgue (Morg): The dialog no longer exists in this state. The
or receiving of signaling which influences a dialog is not sending or receiving of signaling which influences a dialog is not
performed. (A dialog is literally terminated.) Caller and callee performed. (A dialog is literally terminated.) The caller and
enter the Morgue state via the termination of the BYE or INVITE callee enter the Morgue state via the termination of the BYE or
transaction. INVITE transaction.
3. Race Conditions 3. Race Conditions
This section details 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 sending or receiving of SIP messages as state transitions caused by the sending or receiving of SIP messages
well as '*race*', which indicates race condition, are shown. (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 shown 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 in race condition when This section shows some examples of call flow race conditions when
receiving the message from other states in the Moratorium state. receiving messages from other states while in the Moratorium state.
3.1.1. Receiving Initial INVITE retransmission (Preparative state) in 3.1.1. Receiving Initial INVITE retransmission (Preparative state)
Moratorium 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 UAS This scenario illustrates the race condition which occurs when the
receives a Preparative message in the Moratorium state. All UAS receives a Preparative message while in the Moratorium state.
provisional responses to the initial INVITE (ini-INVITE F1) are lost, All provisional responses to the initial INVITE (ini-INVITE F1) are
and UAC retransmits an ini-INVITE (F4). At the same time as lost, and the UAC retransmits an ini-INVITE (F4). At the same time
retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it as this retransmission, the UAS generates a 200 OK (F3) to the ini-
terminates an INVITE server transaction, according to Section INVITE and terminates the INVITE server transaction, according to
13.3.1.4 of RFC 3261 [1]. Section 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
by 200 OK is a SIP bug. (http://bugs.sipit.net, #769) Therefore, the when sending 200 OK is a SIP bug. (http://bugs.sipit.net, #769)
INVITE server transaction is not terminated at F3, and the F4 MUST be Therefore, the INVITE server transaction is not terminated by F3, and
properly handled as a retransmission. (UAs that do not deal with the F4 MUST be handled properly as a retransmission. (UAs that do
this bug still need to recognize the dialog relying on its From tag not deal with this bug still need to recognize the dialog by relying
and Call-ID, and the retransmitted request relying on the CSeq header on its From tag and Call-ID, and the retransmitted request by relying
field value even though it does not match the transaction.) on the CSeq header field value even though it does not match the
transaction.)
In RFC 3261 [1], it is not specified whether UAS retransmits 200 to In RFC 3261 [1], it is not specified whether UAS retransmits 200 to
the retransmission of ini-INVITE. Considering the retransmission of the retransmission of ini-INVITE. Considering the retransmission of
200 triggered by timer (TU keeps retransmitting 200 based on T1 and 200 triggered by a timer (the TU keeps retransmitting 200 based on T1
T2 until it receives an ACK), according to Section 13.3.1.4 of RFC and T2 until it receives an ACK), according to Section 13.3.1.4 of
3261 [1], it seems unnecessary to retransmit 200 when the UAS RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS
receives the retransmission of ini-INVITE. (For implementation, it receives the retransmission of ini-INVITE. (For implementation, it
does not matter if the UAS sends the retransmission of 200, since the does not matter if the UAS sends the retransmission of 200, since the
200 does not cause any problem.) 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
/* According to Section 13.3.1.4 of RFC 3261 [1], an INVITE server /* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server
transaction is terminated at this point. However, this has been transaction is terminated at this point. However, this has been
reported as a SIP bug, and the UAS MUST correctly recognize the reported as a SIP bug, and the UAS MUST correctly recognize the
ini-INVITE (F4) as a retransmission. */ ini-INVITE (F4) as a retransmission. */
F4 INVITE (retransmission) Alice -> Bob F4 INVITE (retransmission) Alice -> Bob
/* 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 do not deal with the bug reported in #769 (an request. For UAs that have not dealt with bug report #769 (an
INVITE server transaction is terminated by 200 to INVITE), this INVITE server transaction is terminated when sending 200 to
request does not match the transaction as well as the dialog since INVITE), this request does not match the transaction as well as
it does not have a To tag. However, Bob have to recognize the the dialog since it does not have a To tag. However, Bob must
retransmitted INVITE correctly, without treating it as a new recognize the retransmitted INVITE correctly, without treating it
INVITE. */ as a new INVITE. */
F5 ACK Alice -> Bob F5 ACK Alice -> Bob
3.1.2. Receiving CANCEL (Early state) in Moratorium state 3.1.2. Receiving CANCEL (Early state) when in 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 13, line 43 skipping to change at page 14, line 43
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 UAS This scenario illustrates the race condition which occurs when the
receives an Early message, CANCEL, in the Moratorium state. Alice UAS receives an Early message, CANCEL, while in the Moratorium state.
sends a CANCEL and Bob sends a 200 OK response to the initial INVITE Alice sends a CANCEL and Bob sends a 200 OK response to the initial
message at the same time. As described in the previous section, INVITE message at the same time. As described in the previous
according to RFC 3261 [1], an INVITE server transaction is supposed section, according to RFC 3261 [1], an INVITE server transaction is
to be terminated by a 200 response, but this has been reported as a supposed to be terminated by a 200 response, but this has been
bug #769. reported as bug #769.
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 which the CANCEL request
matches, so a 200 response is sent to the request. This 200 response matches, so a 200 response to the request is sent. This 200 response
simply means that the next hop received the CANCEL request simply means that the next hop receives the CANCEL request
(Successful CANCEL (200) does not mean an INVITE failure). When UAS (Successful CANCEL (200) does not mean an INVITE failure). When a
does not deal with #769, UAC MAY receive a 481 response for CANCEL UAS has not dealt with bug #769, the UAC MAY receive a 481 response
since there is no transaction which the CANCEL request matches. This to the CANCEL since there is no transaction which the CANCEL request
481 simply means that there is no matching INVITE server transaction matches. This 481 simply means that there is no matching INVITE
and CANCEL is not sent to the next hop. Regardless of the success/ server transaction and CANCEL is not sent to the next hop.
failure of the CANCEL, Alice checks the final response to INVITE, and Regardless of the success/failure of the CANCEL, Alice checks the
if she receives 200 to the INVITE request she immediately sends a BYE final response to the INVITE, and if she receives 200 to the INVITE
and terminates the dialog. (Section 15, RFC 3261 [1]) request she immediately sends a BYE and terminates the dialog.
(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 possibility
that media may flow from Alice to Bob as well. However, once Alice that media may flow from Alice to Bob as well. However, once Alice
has decided to cancel the call, she presumably will not send media, has decided to cancel the call, she presumably will not send media,
so practically speaking the media stream will remain one way. so practically speaking the media stream will remain one way.
Message Details Message Details
skipping to change at page 14, line 43 skipping to change at page 15, line 44
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 document deals with the bug reported response is sent, since this case assumes the fix to bug #769 has
in #769. When an INVITE server transaction is terminated as the been made. If an INVITE server transaction is terminated
procedure stated in RFC 3261 [1], UAC MAY receive 481 response according to the procedure stated in RFC 3261 [1], UAC MAY receive
instead of 200. */ 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. Receiving BYE (Early state) in Moratorium state 3.1.3. Receiving 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 15, line 45 skipping to change at page 16, line 47
|<------------ ------------->| |<------------ ------------->|
| ^ | | | ^ | |
| | 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 which occurs when UAS
receives an Early message, BYE, in the Moratorium state. Alice sends receives an Early message, BYE, while in the Moratorium state. Alice
a BYE in the Early state and Bob sends a 200 OK response to the sends a BYE in the Early state and Bob sends a 200 OK to the initial
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 though 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 caller able to terminate the early dialog with a particular UA. If the
wants to terminate all early dialogs instead of that with a caller wants to terminate all early dialogs instead of only that with
particular UA, it needs to send CANCEL, not BYE. However, it is not a particular UA, it needs to send CANCEL, not BYE. However, it is
illegal to send BYE in the Early state to terminate a specific early not illegal to send BYE in the Early state to terminate a specific
dialog according to 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 gets into the Mortal not to the request but to the dialog. Alice enters the Mortal state
state on sending the BYE request, and remains Mortal until Timer K on sending the BYE request, and remains Mortal until the Timer K
timeout occurs. In the Mortal state, 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 INVITE. Even so, session, even though it receives a 200 response to the INVITE. Even
the UAC sends an ACK to 200 for the completion of INVITE transaction. so, the UAC sends an ACK to 200 in order to complete of the INVITE
The ACK is always sent to complete the three-way handshake of INVITE transaction. The ACK is always sent to complete the three-way
transaction (Further explained in Appendix D below). handshake of the INVITE transaction (Further explained in Appendix D
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 transits to the Mortal state upon sending BYE. Therefore, /* Alice transitions to the Mortal state upon sending BYE.
after this, she does not begin a session even though she receives Therefore, after this, she does not begin a session even though
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. Receiving re-INVITE (Established state) in Moratorium state 3.1.4. Receiving re-INVITE (Established state) while in the Moratorium
(case 1) 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 17, line 39 skipping to change at page 18, line 39
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK (re-INV) F9 | Est | ACK (re-INV) F9 | Est
|------------------------------->| |------------------------------->|
| | | |
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when the
receives re-INVITE request sent from the Established state, in the UAS receives a re-INVITE request sent from the Established state,
Moratorium state. while in the Moratorium state.
UAS receives a re-INVITE (w/offer2) before receiving an ACK for ini- The UAS receives a re-INVITE (w/offer2) before receiving an ACK for
INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the re-INVITE ini-INVITE (w/offer1). The UAS sends a 200 OK (w/answer2) to the re-
(F8) because it has sent a 200 OK (w/answer1) to the ini-INVITE (F3, INVITE (F8) because it has sent a 200 OK (w/answer1) to the ini-
F5) and the dialog has already been established. (Because F5 is a INVITE (F3, F5) and the dialog has already been established.
retransmission of F3, SDP negotiation is not performed here.) (Because F5 is a retransmission of F3, SDP negotiation is not
performed here.)
If a 200 OK to the ini-INVITE has an offer and the answer is in the If a 200 OK to the ini-INVITE contains an offer and the answer is in
ACK, it is recommended that UA return a 491 to the re-INVITE (refer the ACK, it is recommended that the UA return a 491 to the re-INVITE
to Section 3.1.5). (Note: 500 with Retry-After header may be (refer to Section 3.1.5). (Note: 500 with a Retry-After header may
returned, if the 491 response is understood to indicate request be returned, if the 491 response is understood to indicate request
collision. However, 491 is recommended here because 500 applies to collision. However, 491 is recommended here because 500 applies to
so many cases that it is difficult to determine what the real problem so many cases that it is difficult to determine what the real problem
was.) As it can be seen in Section 3.3.2 below, the 491 response was.) As can be seen in Section 3.3.2 below, the 491 response seems
seems to be closely related to session establishment, even in cases to be closely related to session establishment, even in cases other
other than INVITE cross-over. This example recommends 200 be sent than INVITE cross-over. This example recommends that 200 be sent
instead of 491 because it does not have influence on session. instead of 491 because it does not have an influence on the session.
However, a 491 response can also lead to the same outcome, so the However, a 491 response can also lead to the same outcome, so either
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 UAS doesn't receive an ACK for a long time, it should
send a BYE and terminate the dialog. Note that ACK F7 has the same send a BYE and terminate the dialog. Note that ACK F7 has the same
CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]). CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261 [1]).
The UA should not reject or drop the ACK on grounds of CSeq number. The UA should not reject or drop the ACK on grounds of the CSeq
number.
Note: There is a hint for implementation to avoid the race conditions Note: Here is a hint for implementors to avoid race conditions of
of this type. That is for the caller to delay sending re-INVITE F6 this type. That is for the caller to delay sending re-INVITE F6 for
for some period of time (2 seconds, perhaps), from which the caller some period of time (2 seconds, perhaps), after which the caller can
is reasonably able to assume that its ACK has been received. reasonably assume that its ACK has been received. Implementors can
Implementors can decouple the actions of the user (e.g. pressing the decouple the actions of the user (e.g. pressing the hold button) from
hold button) from the actions of the protocol (the sending of re- the actions of the protocol (the sending of re-INVITE F6), so that
INVITE F6), so that the UA can behave as such. In this case, it is the UA can behave like this. In this case, it is the implementor's
dependent on the implementor's choice as to how long it waits. In choice as to how long to wait. In most cases, such an implementation
most cases, such implementation may be useful to prevent a type of may be useful to prevent the type of race condition shown in this
race condition shown in this section. section.
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 19, line 4 skipping to change at page 20, line 6
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 137 Content-Length: 137
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844526 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
/* Detailed messages are shown for the sequence to illustrate offer
and answer examples. */ /* Detailed messages are shown for the sequence to illustrate the
offer and answer examples. */
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
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
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
skipping to change at page 20, line 35 skipping to change at page 21, line 38
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
F7(=F4) ACK Alice -> Bob (retransmission) F7(=F4) ACK Alice -> Bob (retransmission)
/* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous whether Via-branch of
ACK F7 differs from F4 in RFC3261, it doesn't affect 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
skipping to change at page 22, line 5 skipping to change at page 23, 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. Receiving re-INVITE (Established state) in Moratorium state 3.1.5. Receiving re-INVITE (Established state) while in the Moratorium
(case 2) 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 22, line 39 skipping to change at page 23, line 39
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK (re-INV) F9 | Est | ACK (re-INV) F9 | Est
|------------------------------->| |------------------------------->|
| | | |
| | | |
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 200 and an answer in ACK. Different differs in sending an offer in the 200 and an answer in the ACK. In
to the previous case, the offer in the 200 (F3) and the offer in the contrast to the previous case, the offer in the 200 (F3) and the
re-INVITE (F6) collide with each other. offer in the re-INVITE (F6) collide with each other.
Bob sends 491 to re-INVITE (F6) since he is not able to properly Bob sends a 491 to the re-INVITE (F6) since he is not able to
handle a new request until he receives an answer. (Note: 500 with properly handle a new request until he receives an answer. (Note:
Retry-After header may be returned, if the 491 response is understood 500 with Retry-After header may be returned, if the 491 response is
to indicate request collision. However, 491 is recommended here understood to indicate request collision. However, 491 is
because 500 applies to so many cases that it is difficult to recommended here because 500 applies to so many cases that it is
determine what the real problem was.) Even if F6 is UPDATE with difficult to determine what the real problem was.) The same result
offer, it will reach the same result. will be reached if F6 is an UPDATE with offer.
Note: As noted in Section 3.1.4, it may be useful for the caller to Note: As noted in Section 3.1.4, it may be useful for the caller to
delay sending re-INVITE F6 for some period of time (2 seconds, delay sending a re-INVITE F6 for some period of time (2 seconds,
perhaps), from which the caller is reasonably able to assume that its perhaps), after which the caller may reasonably assume that its ACK
ACK has been received, to prevent a type of race condition shown in has been received, to prevent this type of race condition.
this section.
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 25, line 13 skipping to change at page 26, line 13
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
/* 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. */ 200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
that it is an ACK for F3. This doesn't mean that F4 and F7 are
necessarily equal in Via-branch value. Although it is ambiguous
whether Via-branch of ACK F7 differs from F4 in RFC3261, it
doesn't affect 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. Receiving BYE (Established state) in Moratorium state 3.1.6. Receiving BYE (Established 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
| 200 OK F3 | | 200 OK F3 |
|<--------------------------| |<--------------------------|
skipping to change at page 26, line 40 skipping to change at page 27, line 40
| / \ | | / \ |
|<---------- ---------->| |<---------- ---------->|
| ^ ^ | | ^ ^ |
| | 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 which occurs when the
receives an Established message, BYE, in the Moratorium state. An UAS receives an Established message, BYE, while in the Moratorium
ACK request for a 200 OK response is lost (or delayed). Immediately state. An ACK request for a 200 OK response is lost (or delayed).
after Bob retransmits the 200 OK to ini-INVITE, and Alice sends a BYE Bob retransmits the 200 OK to the ini-INVITE, and at the same time
request at the same time. Depending on the implementation of a SIP Alice sends a BYE request and terminates the session. Upon receipt
UA, Alice may start a session again by the reception of the of retransmitted 200 OK Alice's UA might be inclined to reestablish
retransmitted 200 OK with SDP since she has already terminated a the session. But that is wrong - the session should not be
session by sending a BYE. In that case, when UAC receives a reestablished when the dialog is in the Mortal state. Moreover, in
retransmitted 200 OK after sending a BYE, a session should not be the case where the UAS sends an offer in a 200 OK, the UAS should not
started again since the session which is not associated with dialog start a session again, for the same reason, if the UAS receives a
still remains. Moreover, in the case where UAS sends an offer in a retransmitted ACK after receiving a BYE.
200 OK, UAS should not start a session again for the same reason if
UAS receives a retransmitted ACK after receiving a BYE.
Note: As noted in Section 3.1.4, there is a hint for implementation Note: As noted in Section 3.1.4, there is a hint for implementors to
to avoid the race conditions of this type. That is for the caller to avoid race conditions of this type. That is for the caller to delay
delay sending BYE F6 for some period of time (2 seconds, perhaps), sending BYE F6 for some period of time (2 seconds, perhaps), after
from which the caller is reasonably able to assume that its ACK has which the caller can reasonably assume that its ACK has been
been received. Implementors can decouple the actions of the user received. Implementors can decouple the actions of the user (e.g.
(e.g. hanging up) from the actions of the protocol (the sending of hanging up) from the actions of the protocol (the sending of BYE F6),
BYE F6), so that the UA can behave as such. In this case, it is so that the UA can behave like this. In this case, it is the
dependent on the implementor's choice as to how long it waits. In implementor's choice as to how long to wait. In most cases, such an
most cases, such implementation may be useful to prevent a type of implementation may be useful to prevent the type of race condition
race condition shown in this section. shown in this section.
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 27, line 36 skipping to change at page 28, line 34
/* 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 /* 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 transits 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
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
of ACK F7 differs from F4 in RFC3261, it doesn't affect 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 in race condition when This section shows some examples of call flow race conditions when
receiving the message from other states in the Mortal state. receiving messages from other states while in the Mortal state.
3.2.1. Receiving BYE (Establish state) in Mortal state 3.2.1. Receiving 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 28, line 48 skipping to change at page 29, line 50
| / \ | | / \ |
|<-------- --------->| |<-------- --------->|
| ^ ^ | | ^ ^ |
| | 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 which occurs when the
receives an Established message, BYE, in the Mortal state. Alice and UAS receives an Established message, BYE, while in the Mortal state.
Bob send a BYE at the same time. A dialog and session are ended Alice and Bob send a BYE at the same time. A dialog and session are
shortly after a BYE request is passed to a client transaction. As ended shortly after a BYE request is passed to a client transaction.
shown in Section 2, 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 dialog or session, such as re-INVITE, UPDATE, or REFER. operate within a dialog or session, such as re-INVITE, UPDATE, or
However, UA shall return 200 OK to the BYE taking the use case into REFER. However, the UA shall return 200 OK to the BYE taking the use
consideration where BYE request is sent by both a caller and a callee case into consideration where a BYE request is sent by both a caller
to exchange reports about the session when it is being terminated. and a callee to exchange reports about the session when it is being
(Since the dialogue and the session both terminate when a BYE is terminated. (Since the dialogue and the session both terminate when
sent, the choice of sending 200 or an error response upon receiving a BYE is sent, the choice of sending a 200 or an error response upon
BYE in the Mortal state does not affect the resulting termination. receiving a BYE while in the Mortal state does not affect the
Therefore, even though this example uses a 200 response, other resulting termination. Therefore, even though this example uses a
responses can also be used.) 200 response, other 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 30, line 9 skipping to change at page 31, line 9
/* 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 transited from the Established state to the Mortal /* Since Alice has transitioned from the Established state to the
state by sending BYE, Alice responds with a 200 to the BYE Mortal state by sending a BYE, Alice responds with a 200 to the
request. */ BYE request. */
3.2.2. Receiving re-INVITE (Establish state) in Mortal state 3.2.2. Receiving re-INVITE (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 31, line 43 skipping to change at page 32, line 44
| / \ ||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 UAS This scenario illustrates the race condition which occurs when the
receives an Established message, re-INVITE, in the Mortal state. Bob UAS receives an Established message, re-INVITE, while in the Mortal
sends a re-INVITE, and Alice sends a BYE at the same time. The re- state. Bob sends a re-INVITE, and Alice sends a BYE at the same
INVITE is responded by a 481, since the TU of Alice has transited time. The re-INVITE receives a 481 response, since the TU of Alice
from the Established state to the Mortal state by sending BYE. Bob has transitioned from the Established state to the Mortal state by
sends ACK for the 481 response, because the ACK for error responses sending BYE. Bob sends an ACK for the 481 response, because the ACK
is handled by the transaction layer and at the point of receiving the for error responses is handled by the transaction layer and at the
481 the INVITE client transaction still remains (even though the point of receiving the 481 the INVITE client transaction still
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
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
F5 BYE Alice -> Bob F5 BYE Alice -> Bob
/* Alice sends a BYE and terminates the session, and transits from /* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */ the Established state to the Mortal state. */
F6 re-INVITE Bob -> Alice F6 re-INVITE Bob -> Alice
/* Alice sends a BYE, and Bob sends a re-INVITE at the same time. /* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
The dialog state transits to the Mortal state at the moment Alice The dialog state transitions to the Mortal state at the moment
sends the BYE, but Bob does not know it until he receives the BYE. Alice sends the BYE, but Bob does not know this until he receives
Therefore, the dialog is in the Terminated state from Alice's the BYE. Therefore, the dialog is in the Terminated state from
point of view, but it is the Confirmed state from Bob's point of Alice's point of view, but in the Confirmed state from Bob's point
view. A race condition occurs. */ of view. A race condition occurs. */
F7 200 OK (BYE) Bob -> Alice F7 200 OK (BYE) Bob -> Alice
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. Receiving 200 OK for re-INVITE (Established state) in Mortal 3.2.3. Receiving 200 OK for re-INVITE (Established state) while in the
state 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 33, line 45 skipping to change at page 34, 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 UAS This scenario illustrates the race condition which occurs when the
receives an Established message, 200 to re-INVITE, in the Mortal UAS receives an Established message, 200 to a re-INVITE, while in the
state. Bob sends a BYE immediately after sending a re-INVITE. (A Mortal state. Bob sends a BYE immediately after sending a re-INVITE.
user is not conscious that refresher sends re-INVITE automatically. (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 places a receiver immediately after refresher.) Bob session.) Bob sends an ACK for a 200 response to INVITE while in the
sends ACK for a 200 response to INVITE in the Mortal state, so that Mortal state, completing the INVITE transaction.
he completes the INVITE transaction.
Note: As noted in Section 3.1.4, there is a hint for implementation Note: As noted in Section 3.1.4, there is a hint for implementators
to avoid the race conditions of this type. That is for the UAC to to avoid race conditions of this type. That is for the UAC to delay
delay sending BYE F6 until re-INVITE F5 transaction completes. sending a BYE F6 until the re-INVITE transaction F5 completes.
Implementors can decouple the actions of the user (e.g. hanging up) Implementors can decouple the actions of the user (e.g. hanging up)
from the actions of the protocol (the sending of BYE F6), so that the from the actions of the protocol (the sending of BYE F6), so that the
UA can behave as such. In this case, it is dependent on the UA can behave like this. In this case, it is the implementor's
implementor's choice as to how long it waits. In most cases, such choice as to how long to wait. In most cases, such an implementation
implementation may be useful to prevent a type of race condition may be useful in preventing the type of race condition described in
shown in this section. this section.
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 35, line 5 skipping to change at page 36, line 5
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
/* Some detailed messages are shown for the sequence to illustrate /* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal that the re-INVITE is handled in the usual manner in the Mortal
state. */ state. */
F6 BYE Bob -> Alice F6 BYE Bob -> Alice
/* Bob sends BYE immediately after sending the re-INVITE. Bob /* Bob sends BYE immediately after sending the re-INVITE. Bob
terminates the session and transits from the Established state to terminates the session and transitions from the Established state
the Mortal state. */ to the Mortal state. */
F7 200 OK (re-INVITE) Alice -> Bob F7 200 OK (re-INVITE) Alice -> Bob
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7
;received=192.0.2.201 ;received=192.0.2.201
Require: timer Require: timer
Session-Expires: 300;refresher=uac Session-Expires: 300;refresher=uac
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
skipping to change at page 36, line 5 skipping to change at page 37, 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. Receiving ACK (Moratorium state) in Mortal state 3.2.4. Receiving 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 36, line 32 skipping to change at page 37, 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 UAS This scenario illustrates the race condition which occurs when the
receives an Established message, ACK to 200, in the Mortal state. UAS receives an Established message, ACK to 200, while in the Mortal
Alice sends an ACK and Bob sends a BYE at the same time. When the state. Alice sends an ACK and Bob sends a BYE at the same time.
offer is in a 2xx, and the answer is in an ACK, this example is in a When the offer is in a 2xx, and the answer is in an ACK, there is a
race condition. The session is not started by receiving the ACK race condition. A session is not started when the ACK is received
because Bob has already terminated the session by sending the BYE. because Bob has already terminated the session by sending a BYE. The
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, there is a hint for implementation Note: As noted in Section 3.1.4, there is a hint for implementors to
to avoid the race conditions of this type. Implementors can decouple avoid race conditions of this type. Implementors can decouple the
the actions of the user (e.g. hanging up) from the actions of the actions of the user (e.g. hanging up) from the actions of the
protocol (the sending of BYE F5), so that the UA can behave as such. protocol (the sending of BYE F5), so that the UA can behave like
In this case, it is dependent on the implementor's choice as to how this. In this case, it is the implementor's choice as to how long to
long it waits. In most cases, such implementation may be useful to wait. In most cases, such an implementation may be useful in
prevent a type of race condition shown in this section. preventing the type of race condition described in this section.
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 the examples in race condition that are not This section shows examples of race conditions that are not directly
directly related to the dialog state transition. In SIP, processing related to dialog state transition. In SIP, processing functions are
functions are deployed in three layers, dialog, session, and deployed in three layers, dialog, session, and transaction. They are
transaction. There are related each other, but have to be treated related each other, but have to be treated separately. Section 17 of
separately. Section 17 of RFC 3261 [1] details the processing on RFC 3261 [1] details the processing of transactions. This draft has
transactions. This draft has tried so far to clarify the processing tried so far to clarify the processing on dialogs. This section
on dialogs. This section explains race conditions which are related explains race conditions which are related to sessions established
to sessions established by SIP. 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 |
skipping to change at page 38, line 41 skipping to change at page 39, 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-INVITE at the same time.
When two re-INVITEs cross in the same dialog, they resend re-INVITEs When two re-INVITEs cross in the same dialog, they are retried, each
after different interval for each, according to Section 14.1, of RFC after a different interval, according to Section 14.1, of RFC 3261
3261 [1]. When Alice sends the re-INVITE and it crosses, the re- [1]. When Alice sends the re-INVITE and it crosses with Bob's, the
INVITE will be sent again 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 send an 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 it has generated the
Call-ID of the dialog or not, in case an INVITE may cross with Call-ID of the dialog or not, 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 retransmits the re-INVITE for session refresh earlier responses, Bob retransmits the re-INVITE for session refresh earlier
than Alice. If Alice was to retransmit her re-INVITE (that is, if than Alice. If Alice was to retransmit her re-INVITE (that is, if
she was not the owner of Call-ID), the request would refresh and she was not the owner of Call-ID), the request would refresh and
modify the session at the same time. Then Bob would know that he modify the session at the same time. Then Bob would know that he
would not need to retransmit his re-INVITE to refresh the session. would not need to retransmit 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, retransmitting the same re-INVITE again after 491 by the cross over, retransmitting the same re-INVITE again after a 491 by
Call-ID owner (the UA which retransmits its re-INVITE after the other the Call-ID owner (the UA which retransmits its re-INVITE after the
UA) may result in a behavior different from what the user originally other UA) may result in unintended behavior, so the UA must decide if
intended to, so the UA needs to decide if the retransmission of the the retransmission of the re-INVITE is necessary. (For example, when
re-INVITE is necessary. (For example, when a call hold and an a call hold and an addition of video media cross over, mere
addition of video media cross over, mere retransmission of the re- retransmission of the re-INVITE at the firing of the timer may result
INVITE at the firing of the timer may result in the situation where in the situation where the video is transmitted immediately after the
the video is transmitted immediately after the holding of the audio. holding of the audio. This behavior is probably not intended by the
This behavior is probably not intended by the users.) users.)
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 40, line 25 skipping to change at page 41, line 25
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac Session-Expires: 300;refresher=uac
Supported: timer Supported: timer
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: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
/* A re-INVITE request for a session refresh and that for a call hold /* A re-INVITE request for a session refresh and another for a call
are sent at the same time. */ hold are sent at the same time. */
F7 491 Request Pending Bob -> Alice F7 491 Request Pending Bob -> Alice
/* Since a re-INVITE is in progress, a 491 response is returned. */ /* Since a re-INVITE is in progress, a 491 response is returned. */
F8 491 Request Pending Alice -> Bob F8 491 Request Pending Alice -> Bob
F9 ACK (INVITE) Alice -> Bob F9 ACK (INVITE) Alice -> Bob
F10 ACK (INVITE) Bob -> Alice F10 ACK (INVITE) Bob -> Alice
skipping to change at page 44, line 7 skipping to change at page 45, line 7
| |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 responded with 491 as in the case of "re- UPDATE and re-INVITE are both responded to with 491 as in the case of
INVITE crossover". When an UPDATE for refresher which doesn't "re-INVITE crossover". When an UPDATE for session refresh which
contain a session description and a re-INVITE crossed each other, doesn't contain a session description and a re-INVITE cross each
both requests succeed with 200 (491 means that UA have a pending other, both requests succeed with 200 (491 means that a UA has a
request). Moreover, the same is equally true for UPDATE crossover. pending request). The same is true for UPDATE crossover. In the
In the former case where either UPDATE contains a session description former case where either UPDATE contains a session description the
the requests fail with 491, and in the latter cases succeed with 200. requests fail with 491, and in the latter cases succeed with 200.
Note: Note:
A 491 response is sent because SDP offer is pending, and 491 is an A 491 response is sent because an SDP offer is pending, and 491 is
error which is related to matters that behave on 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 45, line 8 skipping to change at page 46, line 8
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
/* Some detailed messages are shown for the sequence to illustrate /* Some detailed messages are shown for the sequence to illustrate
the example messages crossed over each other. */ messages crossing over each other. */
F6 re-INVITE Bob -> Alice F6 re-INVITE Bob -> Alice
INVITE sip:alice@client.atlanta.example.com SIP/2.0 INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7
Session-Expires: 300;refresher=uac Session-Expires: 300;refresher=uac
Supported: timer Supported: timer
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: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
/* A case where a re-INVITE for a session refresh and a UPDATE for a /* A case where a re-INVITE for a session refresh and a UPDATE for a
call hold are sent at the same time. */ 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 are 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
INVITE sip:alice@client.atlanta.example.com SIP/2.0 INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
Session-Expires: 300;refresher=uac Session-Expires: 300;refresher=uac
skipping to change at page 46, line 12 skipping to change at page 47, line 12
Content-Type: application/sdp Content-Type: application/sdp
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
/* Since Bob is not the owner of Call-ID, Bob sends an INVITE again /* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
after 0.0-2.0 seconds. */ again after 0.0-2.0 seconds. */
F11 200 OK Alice -> Bob F11 200 OK Alice -> Bob
F12 ACK Bob -> Alice F12 ACK Bob -> Alice
F13 UPDATE Alice -> Bob F13 UPDATE Alice -> Bob
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 UPDATE 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
skipping to change at page 47, line 5 skipping to change at page 48, line 5
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 (Establish state) in 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 47, line 42 skipping to change at page 48, 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 UAS This scenario illustrates the race condition which occurs when the
receives an Established message, REFER, in the Mortal state. Bob UAS receives an Established message, REFER, while in the Mortal
sends a REFER, and Alice sends a BYE at the same time. Bob sends the state. Bob sends a REFER, and Alice sends a BYE at the same time.
REFER in the same dialog. Alice's dialog state moves to the Mortal Bob sends the REFER in the same dialog. Alice's dialog state moves
state at the point of sending BYE. In the Mortal state, UA possesses to the Mortal state at the point of sending BYE. In the Mortal
dialog information for internal process but dialog shouldn't exist state, the UA possesses dialog information for an internal process
outwardly. Therefore, UA sends an error response to a REFER which is but the dialog shouldn't exist outwardly. Therefore, the UA sends an
transmitted as a mid-dialog request. So, Alice in the Mortal state error response to the REFER, which is transmitted as a mid-dialog
sends an error response to the REFER. However, Bob has already request. So Alice, in the Mortal state, sends an error response to
started the SUBSCRIBE usage with REFER, so the dialog continues until the REFER. However, Bob has already started the SUBSCRIBE usage with
the SUBSCRIBE usage terminates, even though the INVITE dialog usage REFER, so the dialog continues until the SUBSCRIBE usage terminates,
terminates by receiving BYE. Bob's behavior in this case needs to even though the INVITE dialog usage terminates by receiving BYE.
follow the procedure in I-D.ietf-sipping-dialogusage [6]. (For Bob's behavior in this case needs to follow the procedures in RFC
handling of dialogs with multiple usages see I-D.ietf-sipping- 5057 [6].
dialogusage [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
F5 BYE Alice -> Bob F5 BYE Alice -> Bob
/* Alice sends a BYE request and terminates the session, and transits /* Alice sends a BYE request and terminates the session, and
from the Confirmed state to Terminated state. */ transitions from the Confirmed state to the Terminated state. */
F6 REFER Bob -> Alice F6 REFER Bob -> Alice
/* 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 transits sends the REFER on the INVITE dialog. The dialog state
to the Mortal state at the moment Alice sends the BYE, but Bob transitions to the Mortal state at the moment Alice sends the BYE,
doesn't know it until he receives the BYE. A race condition but Bob doesn't know this until he receives the BYE. A race
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. */ /* Alice in the Mortal state sends a 481 to the REFER. */
4. IANA Considerations 4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 49, line 25 skipping to change at page 50, line 25
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 7. References
7.1. Normative References 7.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. Scooler, "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
the 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] Sparks, R. and H. Schulzrinne, "Reliability of Provisional [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
7.2. Informative References 7.2. Informative References
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation [6] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", I-D draft-ietf-sipping-dialogusage-06 (work in Protocol", RFC 5057, November 2007.
progress), February 2007.
Appendix A. BYE on 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 the case in which 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 | | |
|--------------->| INVITE F2 | | |--------------->| INVITE F2 | |
| 100 F3 |----------------->| | | 100 F3 |----------------->| |
|<---------------| 180(To tag=A) F4 | | |<---------------| 180(To tag=A) F4 | |
| 180(A) F5 |<-----------------| | | 180(A) F5 |<-----------------| |
|<---------------| | | |<---------------| | |
skipping to change at page 50, line 47 skipping to change at page 51, line 46
| |------------------------>| | |------------------------>|
| | 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 Bob. After Bob terminates the dialog by receiving the BYE, he sends a
487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1], 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261 [1],
it is RECOMMENDED for UAS to generate 487 to any pending requests it is RECOMMENDED for the UAS to generate a 487 to any pending
after receiving BYE. In the example, Bob sends 487 to ini-INVITE requests after receiving a BYE. In the example, Bob sends a 487 to
since he receives BYE while the ini-INVITE is in pending state. the ini-INVITE since he receives the BYE while the ini-INVITE is in
pending state.
However, Alice receives a final response to INVITE (a 200 from Carol) However, Alice receives a final response to the INVITE (a 200 from
even though she has successfully terminated the dialog with Bob. This Carol) even though she has successfully terminated the dialog with
means that, regardless of the success/failure of the BYE in the Early Bob. This means that, regardless of the success/failure of the BYE in
state, Alice MUST be prepared for the establishment of a new dialog the Early state, Alice MUST be prepared for the establishment of a
until receiving the final response for the INVITE and terminating the new dialog until receiving the final response for the INVITE and
INVITE transaction. terminating the INVITE transaction.
It is not illegal to send 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 according to the caller's intent. However, the specific early dialog - it may satisfy the intent of some callers.
choice of BYE or CANCEL in the Early state must be made carefully. However, the choice of BYE or CANCEL in the Early state must be made
CANCEL is appropriate when the goal is to abandon the call attempt carefully. CANCEL is appropriate when the goal is to abandon the
entirely. BYE is appropriate when the goal is to abandon a call attempt entirely. BYE is appropriate when the goal is to
particular early dialog while allowing the call to be completed with abandon a particular early dialog while allowing the call to be
other destinations. When using either BYE or CANCEL the UAC must be completed with other destinations. When using either BYE or CANCEL
prepared for the possibility that a call may still be established to the UAC must be prepared for the possibility that a call may still be
one (or more) destinations. established to one (or more) destinations.
Appendix B. BYE request overlapped on 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 |
|<---------------------| |<---------------------|
| INVITE F4(=F1) | | INVITE F4(=F1) |
|--------------------->| |--------------------->|
| | | |
| | | |
This case could look similar to the one in Section 3.2.3. However, This case could look similar to the one in Section 3.2.3. However,
it is not a race condition. This case describes the behavior where it is not a race condition. This case describes the behavior when
there is no response for INVITE for some reasons. The appendix there is no response to the INVITE for some reason. The appendix
explains the behavior in such case and its rationale behind, since explains the behavior in this case and its rationale, since this case
this case 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 behaviors explained in this document. It has to be noted that these two
are independent of each other, even though the both layers change behaviors are independent of each other, even though both layers may
their states triggered by sending or receiving of the same SIP be triggered to change their states by sending or receiving the same
messages (A dialog can be terminated even though a transaction still SIP messages. (A dialog can be terminated even though a transaction
remain, and vice versa). still remains, and vice versa.)
In the sequence above, there is no response for 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 sent immediately after F1 (F1 is a mid-dialog request. If F1 was an
ini-INVITE, BYE could not be sent before UAC received a provisional ini-INVITE, BYE could not be sent before the UAC received a
response to the request with To tag). provisional response to the request with a To tag).
Below is a figure which illustrates UAC's dialog state and Below is a figure which 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 52, line 35 skipping to change at page 53, line 35
| | | | 481(INV) F5 | | | | | 481(INV) F5 |
| | | |<---------------------| | | | |<---------------------|
| | | | ACK(INV) F6 | | | | | ACK(INV) F6 |
| | | |--------------------->| | | | |--------------------->|
| | | | | | | | | |
o | o | | o | o | |
| | | | | |
o | | o | |
| | | |
For 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 transits to the Mortal state and then only a time, the dialog state transitions to the Mortal state and then only
BYE or its response 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 transited to the layer, and the INVITE transaction has not yet transitioned to the
Terminated state. As it 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 moved transaction handling has to be continued even though the dialog has
to the Terminated state. moved to the Terminated state.
Note: As noted in Section 3.1.4, there is a hint for implementation Note: As noted in Section 3.1.4, there is a hint for implementation
to avoid this case. That is for the UAC to delay sending BYE F2 to avoid this case. That is for the UAC to delay sending BYE F2
until re-INVITE F1 transaction completes. Implementors can decouple until the re-INVITE transaction F1 completes. Implementors can
the actions of the user (e.g. hanging up) from the actions of the decouple the actions of the user (e.g. hanging up) from the actions
protocol (the sending of BYE F2), so that the UA can behave as such. of the protocol (the sending of BYE F2), so that the UA can behave
In this case, it is dependent on the implementor's choice as to how like this. In this case, it is the implementor's choice as to how
long it waits. In most cases, such implementation may be useful to long to wait. In most cases, such an implementation may be useful to
prevent this case. prevent this case.
Next, 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
| 200(BYE) F3 | (Mortal) | | 200(BYE) F3 | (Mortal) |
|<---------------------| | |<-Start Timer J |<---------------------| | |<-Start Timer J
skipping to change at page 53, line 37 skipping to change at page 54, line 37
|--------------------->| | 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 UAS, it can be regarded that F1 packet is lost or delayed (Here For the UAS, it can be considered that packet the F1 is lost or
the behavior is explained for the case UAS receives F2 BYE before F1 delayed (here the behavior is explained for the case that the UAS
INVITE). Therefore, F2 triggers the BYE transaction for UAS, and receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE
simultaneously the dialog moves to the Mortal state. Then, upon the transaction for UAS, and simultaneously the dialog moves to the
reception of F4 the INVITE server transaction begins. (It is allowed Mortal state. Then, upon the reception of F4 the INVITE server
to start the INVITE server transaction in the Mortal state. The transaction begins. (It is permitted to start the INVITE server
INVITE server transaction begins to handle received SIP request transaction in the Mortal state. The INVITE server transaction
regardless of the dialog state.) UAS's TU sends an appropriate error begins to handle the received SIP request regardless of the dialog
response for F4 INVITE, either 481 (because the TU knows that the state.) The UAS's TU sends an appropriate error response for the F4
dialog which matches to the INVITE is in the Terminated state) or 500 INVITE, either 481 (because the TU knows that the dialog which
(because the re-sent F4 has an out-of-order CSeq). (It is mentioned matches the INVITE is in the Terminated state) or 500 (because the
above that F4 (and F1) INVITE is a mid-dialog request. Mid-dialog re-sent F4 has an out-of-order CSeq). (It is mentioned above that
requests have a To tag. It should be noted that UAS's TU does not INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog
begin a new dialog upon the reception of INVITE with a To tag.) requests have a To tag. It should be noted that the UAS's TU does
not begin a new dialog upon the reception of INVITE with a To tag.)
Appendix C. UA's behavior for CANCEL Appendix C. UA's behavior for CANCEL
This section explains the CANCEL behaviors which indirectly involve This section explains the CANCEL behaviors which indirectly impact
in the dialog state transition in the Early state. CANCEL does not the dialog state transition in the Early state. CANCEL does not have
have any influence on UAC's dialog state. However, the request has any influence on the UAC's dialog state. However, the request has a
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 UAS the CANCEL request has significant effect on ini-INVITE. For the UAS the CANCEL request has
more direct effects on the dialog than the sending of CANCEL by UAC, more direct effects on the dialog than the sending of a CANCEL by the
because they can be a trigger to send the 487 response. Figure 3 UAC, because it can be a trigger to send the 487 response. Figure 3
explains UAS's behavior in the Early state. This flow diagram is explains UAS's behavior in the Early state. This flow diagram is
only an explanatory figure, and the actual dialog state transition is only an explanatory figure, and the actual dialog state transition is
as illustrated in Figure 1 and 2. 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 virtually handled 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.
Below, UAS's flow is explained.
+-------------+ +-------------+
| Preparative |---+ | Preparative |---+
+-------------+ | +-------------+ |
: | 1xx(s) | : | 1xx(s) |
: V | : V |
: +-------+ | 2xx(s) : +-------+ | 2xx(s)
: | Early |-----+------+ : | Early |-----+------+
: +-------+ | : +-------+ |
: : V : : V
: : +-----------+ : : +-----------+
skipping to change at page 55, line 6 skipping to change at page 56, line 33
:...........: | :...........: |
| 487(s) | | 487(s) |
| | | |
+--------------------+ +--------------------+
| |
V V
+------------+ +------------+
| Terminated | | Terminated |
+------------+ +------------+
Figure 3. CANCEL flow diagram for UAS Figure 3: CANCEL flow diagram for UAS
There are two behaviors for UAS depending on the state when it There are two behaviors for the UAS depending on the state when it
receives CANCEL. receives a CANCEL.
One is when UAS receives CANCEL in the Early states. In this case The first behavior is when the UAS receives a CANCEL in the Early
the UAS immediately sends 487 for the INVITE, and the dialog transits state. In this case the UAS immediately sends a 487 for the INVITE,
to the Terminated state. and the dialog transitions to the Terminated state.
The other is the case in which UAS receives CANCEL in the Confirmed The other is the case in which the UAS receives a CANCEL while in the
state. In this case the dialog state transition does not occur Confirmed state. In this case the dialog state transition does not
because UAS has already sent a final response to the INVITE to which occur because UAS has already sent a final response to the INVITE to
the CANCEL is targeted. (Note that, because of UAC's behavior, a UAS which the CANCEL is targeted. (Note that, because of the UAC's
that receives a CANCEL in the Confirmed state can expect to receive a behavior, a UAS that receives a CANCEL in the Confirmed state can
BYE immediately and move to the Terminated state. However, the UAS's expect to receive a BYE immediately and move to the Terminated state.
state does not transit until it actually receives BYE.) However, the UAS's state does not transition until it actually
receives a BYE.)
Appendix D. Notes on the request in Mortal state Appendix D. Notes on the request in the Mortal state
This section describes UA's behavior in the Mortal state which needs This section describes the UA's behavior in the Mortal state, which
careful attention. Note that every transaction completes independent needs careful attention. Note that every transaction completes
of others, following the principle of RFC 3261 [1]. independently of others, following the principle of RFC 3261 [1].
In the Mortal state, BYE can be accepted, and the other messages in In the Mortal state, only a BYE can be accepted, and the other
the INVITE dialog usage are responded with an error. However, messages in the INVITE dialog usage are responded to with an error.
sending of ACK and the authentication procedure for BYE are conducted However, sending of ACK and the authentication procedure for BYE are
in this state. (The handling of messages concerning multiple dialog conducted in this state. (The handling of messages concerning
usages is out of the scope of this document. Refer to I-D.ietf- multiple dialog usages is out of the scope of this document. Refer
sipping-dialogusage [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 TU. However, the ACK for 2xx and the ACK for error responses are by a TU. However, the ACK for 2xx and the ACK for error responses
both a part of the INVITE transaction, even though their handling are both a 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, UA needs to keep the INVITE dialog Considering actual implementation, the UA needs to keep the INVITE
usage until the Mortal state finishes, so that it is able to send ACK dialog usage until the Mortal state finishes, so that it is able to
for a 2xx response in the Mortal state. If a 2xx to INVITE is send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE
received in the Mortal state, the duration of the INVITE dialog usage is received in the Mortal state, the duration of the INVITE dialog
will be extended to 64*T1 seconds after the receiving of the 2xx, to usage will be extended to 64*T1 seconds after the receiving of the
cope with the possible 2xx retransmission. (The duration of the 2xx 2xx, to cope with the possible 2xx retransmission. (The duration of
retransmission is 64*T1, so the UA need to be prepared to handle the the 2xx retransmission is 64*T1, so the UA needs to be prepared to
retransmission for this duration.) However, the UA shall send error handle the retransmission for this duration.) However, the UA shall
response to other requests, since the INVITE dialog usage in the send an error response to other requests, since the INVITE dialog
Mortal state is kept only for the sending of ACK for 2xx. usage in the Mortal state is kept only for the sending of ACK for
2xx.
BYE authentication procedure shall be processed in the Mortal state. The BYE authentication procedure shall be processed in the Mortal
When authentication is requested by 401 or 407 response, UAC resends state. When authentication is requested by a 401 or 407 response,
BYE with appropriate credentials. Also UAS handles the UAC resends BYE with appropriate credentials. Also the UAS handles
retransmission of the BYE which it requested authentication itself. 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 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 a different To tag to 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 with a different To tag to that the TU receives multiple responses to the ini-INVITE with
ini-INVITE (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. of RFC differing To tags (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc.
3261 [1]). If the TU receives multiple 1xx responses with a
different To tag, the original DSM forks and a new DSM instance is of RFC 3261 [1]). If the TU receives multiple 1xx responses with
different To tags, the original DSM forks and a new DSM instance is
created. As a consequence multiple early dialogs are generated. 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 transits to the Confirmed state. No DSM state transition naturally transitions to the Confirmed state. No DSM state
occurs for the other early dialogs, and their sessions (early media) transition occurs for the other early dialogs, and their sessions
terminate. The TU of the UAC terminates the INVITE transaction after (early media) terminate. The TU of the UAC terminates the INVITE
64*T1 seconds starting at the point of receiving the first 2xx transaction after 64*T1 seconds starting at the point of receiving
response. Moreover, all mortal early dialogs which do not transit to the first 2xx response. Moreover, all mortal early dialogs which do
the Established state are terminated (See Section 13.2.2.4 of RFC not transition to the Established state are terminated (See Section
3261 [1]). By "mortal early dialog" we mean any early dialog that 13.2.2.4 of RFC 3261 [1]). By "mortal early dialog" we mean any
the UA will terminate when another early dialog is confirmed. early dialog that the UA will terminate when another early dialog is
confirmed.
Below is an example sequence in which two 180 responses with a Below is an example sequence in which two 180 responses with
different To tag are received, and then a 200 response for one of the different To tags are received, and then a 200 response for one of
early dialogs (dialog A) is received. Dotted lines (..) in sequences the early dialogs (dialog A) is received. Dotted lines (..) in the
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
Pre o |-------------------------> Pre o |------------------------->
| | 100 F2 | | 100 F2
| |<------------------------- | |<-------------------------
| | 180(To tag=A) F3 | | 180(To tag=A) F3
Ear | |<------------------------- Ear | |<-------------------------
dialog(B) | | dialog(B) | |
forked new DSM | | 180(To tag=B) F4 forked new DSM | | 180(To tag=B) F4
skipping to change at page 57, line 31 skipping to change at page 58, line 51
| | |64*T1 | | | |64*T1 |
| | |(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)), DSM forks and the early dialog B is generated. After 180(To tag=B)), the DSM forks and the early dialog B is generated.
64*T1 seconds after the dialog A receives 200 OK response, the dialog 64*T1 seconds later dialog A receives a 200 OK response. Dialog B,
B, which does not transit 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 which receives multiple 2xx responses with
a different To tag is explained. When a mortal early dialog, which different To tags is explained. When a mortal early dialog, which
did not match the first 2xx response the TU received, receives did not match the first 2xx response that the TU received, receives
another 2xx response which matches its To tag before 64*T1 INVITE another 2xx response which matches its To tag before the 64*T1 INVITE
transaction timeout, its DSM state transits 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 send 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 DSM. (In immediately after, the TU usually sends a BYE to terminate the DSM.
special cases, e.g. a UA intends to establish multiple dialogs, the (In special cases, e.g. if a UA intends to establish multiple
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 phone. It is important to note that what is being shown is a typical
typically useful action and not the only valid one. Some devices useful action and not the only valid one. Some devices might want to
might want to handle things differently. For instance, a conference handle things differently. For instance, a conference focus that has
focus that has sent out an INVITE that forks may want to accept and sent out an INVITE that forks may want to accept and mix all the
mix all the dialogs it gets. In that case, no early dialog is dialogs it gets. In that case, no early dialog is treated as mortal.
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
early dialogs is received. early dialogs is received.
UAC UAC
dialog(A) | INVITE F1 dialog(A) | INVITE F1
Pre o |-----------------------> Pre o |----------------------->
| | 100 F2 | | 100 F2
| |<----------------------- | |<-----------------------
skipping to change at page 58, line 46 skipping to change at page 60, line 35
Mort |..........|.|........|-----------------------> Mort |..........|.|........|----------------------->
^ | | | | 200(B) F10 ^ | | | | 200(B) F10
| | | | |<----------------------- | | | | |<-----------------------
|Timer K | | | |Timer K | | |
| | | V | | | | V |
| | | (terminate INVITE transaction) | | | (terminate INVITE transaction)
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 a different To tag before 64*T1 timeout of the INVITE responses with different To tags before the 64*T1 timeout of the
transaction in the absence of a provisional response. Even though a INVITE transaction in the absence of a provisional response. Even
TU does not receive provisional response, the TU needs to process the though a TU does not receive a provisional response, the TU needs to
2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In that case, process the 2xx responses (See Section 13.2.2.4 of RFC 3261 [1]). In
the DSM state is forked at the Confirmed state, and then the TU sends that case, the DSM state is forked at the Confirmed state, and then
an ACK for the 2xx response and, immediately after, the TU usually the TU sends an ACK for the 2xx response and, immediately after, the
sends a BYE. (In special cases, e.g. a UA intends to establish TU usually sends a BYE. (In special cases, e.g. if a UA intends to
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 59, line 39 skipping to change at page 61, line 33
Mort |..........|.|........|-----------------------> Mort |..........|.|........|----------------------->
^ | | | | 200(B) F9 ^ | | | | 200(B) F9
| | | | |<----------------------- | | | | |<-----------------------
| | | V | | | | V |
|Timer K | (terminate INVITE transaction) |Timer K | (terminate INVITE transaction)
| | | | | | | |
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 which 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. (Here,
also, every transaction completes independent of others.) also, every transaction completes independently of others.)
As 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 60, line 37 skipping to change at page 62, line 34
| | |(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 7. Receiving 1xx responses with different To tags when using Figure 7: Receiving 1xx responses with different To tags
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-east Corporation NTT Corporation
19-2 Nishi-shinjuku 3-chome 9-11, Midori-cho 3-Chome
Shinjuku-ku, Tokyo 163-8019 Musashino-shi, Tokyo 180-8585
JP JP
Email: suzuki.yasushi@east.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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 165 change blocks. 
622 lines changed or deleted 665 lines changed or added

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