draft-ietf-sipping-race-examples-01.txt   draft-ietf-sipping-race-examples-02.txt 
Internet Engineering Task Force M. HASEBE Internet Engineering Task Force M. HASEBE
Internet-Draft J. KOSHIKO Internet-Draft J. KOSHIKO
Expires: Sep 6, 2007 Y. SUZUKI Intended status: Best Current Practice Y. SUZUKI
T. YOSHIKAWA Expires: Dec 30, 2007 T. YOSHIKAWA
NTT-East NTT-East
P. Kyzivat P. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
Mar 5th, 2007 Jun 30th, 2007
Examples call flow in race condition on Session Initiation Protocol Examples call flow in race condition on Session Initiation Protocol
draft-ietf-sipping-race-examples-01.txt draft-ietf-sipping-race-examples-02.txt
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 38
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 September 1, 2007. This Internet-Draft will expire on December 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document gives examples of the Session Initiation Protocol (SIP) This document gives examples of the Session Initiation Protocol (SIP)
call flows in race condition. Call flows in race condition are call flows in race condition. Call flows in race condition are
confusing, and this document shows the best practice to handle confusing, and this document shows the best practice to handle them.
them. The elements in these call flows include SIP User Agents The elements in these call flows include SIP User Agents and SIP
and SIP Proxies. Call flow diagrams and message details are shown. Proxies. Call flow diagrams and message details are shown.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . .3 1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . .3
1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . .3 1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . .3
1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . .3 1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . .3
2. The Dialog State Machine for INVITE dialog usage . . . . . . . .4 2. The Dialog State Machine for INVITE dialog usage . . . . . . . .4
3. Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . .10 3. Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . .9
3.1 Receiving message in the Moratorium State. . . . . . . . . .10 3.1 Receiving message in the Moratorium State. . . . . . . . . .9
3.1.1 Receiving Initial INVITE retransmission(Trying state). .10 3.1.1 Receiving Initial INVITE retransmission. . . . . . . . .10
3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . .12 3.1.2 Receiving CANCEL(Early state). . . . . . . . . . . . . .11
3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .14 3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .13
3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .15 3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .15
3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .19 3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .19
3.1.6 Receiving BYE (Established state). . . . . . . . . . . .24 3.1.6 Receiving BYE (Established state). . . . . . . . . . . .22
3.2 Receiving message in the Mortal State. . . . . . . . . . . .24 3.2 Receiving message in the Mortal State. . . . . . . . . . . .24
3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .25 3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .24
3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .27 3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .26
3.2.3 Receiving 200OK for re-INVITE(Established state) . . . .30 3.2.3 Receiving 200 OK for re-INVITE(Established state). . . .28
3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .32 3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .31
3.3 Other race conditions. . . . . . . . . . . . . . . . . . . .34 3.3 Other race conditions. . . . . . . . . . . . . . . . . . . .32
3.3.1 Re-INVITE crossover. . . . . . . . . . . . . . . . . . .34 3.3.1 Re-INVITE crossover. . . . . . . . . . . . . . . . . . .32
3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .38 3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .36
3.3.3 Receiving REFER(Established state) . . . . . . . . . . .42 3.3.3 Receiving REFER(Established state) . . . . . . . . . . .40
Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .44 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . .42
Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .45 5. Security Considerations. . . . . . . . . . . . . . . . . . . . .42
Appendix C. UA's behaviour for CANCEL . . . . . . . . . . . . . . .47 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .42
Appendix D. Notes on the request in Mortal state. . . . . . . . . .49 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Appendix E. Forking and receiving new To-tags . . . . . . . . . . .50 7.1 Normative References . . . . . . . . . . . . . . . . . . . .42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 7.2 Informative References . . . . . . . . . . . . . . . . . . .42
Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .43
Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .44
Appendix C. UA's behavior for CANCEL. . . . . . . . . . . . . . . .46
Appendix D. Notes on the request in Mortal state. . . . . . . . . .48
Appendix E. Forking and receiving new To tags . . . . . . . . . . .49
Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .53 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .53
Intellectual Property Statement . . . . . . . . . . . . . . . . . .54 Intellectual Property and Copyright Statements. . . . . . . . . . .54
Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . .55
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . .55
Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . . . .55
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 condition, which stems from the dialog state transition mainly
established by INVITE. established by 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 Therefore, it will be helpful to provide implementors of the protocol
protocol with examples of recommended terminal and server behavior. with 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 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 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 [4]. 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 architecture, 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 taken into consideration and help understanding the call flow
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 on the transport issues for SIP.
1.2 Legend for Message Flows 1.2 Legend for Message Flows
Dashed lines (---) and slash lines (/,\) represent signaling messages Dashed lines (---) and slash lines (/, \) represent signaling
that are mandatory to the call scenario. (X) represents crossover of messages that are mandatory to the call scenario. (X) represents
signaling messages. (->x,x<-) indicate that the packet is lost. crossover of signaling messages. (->x, x<-) indicate that the packet
The arrow indicate the direction of message flow. Double dashed is lost. The arrow indicates the direction of message flow. Double
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. Figure.
Comments in the message details are shown in the following form: Comments in the message details are shown in the following 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. shown, but rather illustrates the principles for best practice.
skipping to change at page 3, line 49 skipping to change at page 4, line 4
are used for references to the message details that follow the are used for references to the message details that follow the
Figure. Figure.
Comments in the message details are shown in the following form: Comments in the message details are shown in the following 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. shown, but rather illustrates the principles for best practice.
They are best practice usages (orderings, syntax, selection of They are best practice usages (orderings, syntax, selection of
features for the purpose, or handling of error) of SIP methods, features for the purpose, or handling of error) of SIP methods,
headers and parameters. NOTE: The flows in this document must not headers and parameters. Note: The flows in this document must not
be copied as they are by implementors because additional be copied as they are by implementors because additional
characteristics were incorporated into the document for ease of characteristics were incorporated into the document for ease of
explanation. To sum up, the procedures described in this document explanation. To sum up, the procedures described in this document
represent well-reviewed examples of SIP usage, which are best common represent well-reviewed examples of SIP usage, which are best common
practice according to IETF consensus. practice according to IETF consensus.
For simplicity in reading and editing the document, there are a For simplicity in reading and editing the document, there are a
number of differences between some of the examples and actual SIP number of differences between some of the examples and actual SIP
messages. For instance, Call-IDs are often repeated, CSeq often messages. For instance, Call-IDs are often repeated, CSeq often
begins at 1, header fields are usually shown in the same order, 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
skipping to change at page 4, line 33 skipping to change at page 4, line 36
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
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 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 UAS (User Agent Server) is
transiting from the Early state to the Confirmed state by sending a transiting from the Early state to the Confirmed state by sending a
200 OK to ini-INVITE. 200 OK to initial INVITE (indicated as "ini-INVITE" hereafter).
The DSM (dialog state machine) for the INVITE dialog usage is The DSM (dialog state machine) for the INVITE dialog usage is
presented as follows to help understanding UA's behavior in race presented as follows to help understanding UA's behavior in race
conditions. conditions.
The DSM clarifies UA's behavior by subdividing some internal states
shown in the FSM (Finite State Machine) for dialog state of the The DSM clarifies UA's behavior by subdividing the dialog state shown
dialog-package [7], without changing the states of the dialog, in RFC 3261 [1] into some internal states. We call the state before
"early", "confirmed", and "terminated" shown in RFC3261 [1]. a dialog establishment the Preparative state. The Confirmed state is
The Preparative state is put before the Early state, which includes subdivided into two substates, the Moratorium and Established states,
the Trying and Proceeding states. The Confirmed state is subdivided and the Terminated state is subdivided into the Mortal and Morgue
into two substates, the Moratorium and Established states and the states. Messages which are the triggers of the state transitions
Terminated state is subdivided into the Mortal and Morgue states. between these states are indicated with arrows. In this figure,
Messages which are the triggers of the state transitions between messages which are not related to state transition are omitted.
these states are indicated with 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 for UAC and UAS respectively.
+-----------------------------------------------+ INV +-----------------------------------------------+
| Preparative | --->| Preparative |
| +----------+ +--------------+ |
| | | 100 | |-----C-+
| | Trying |---------->| Proceeding | | | 100
| | | | |<----C-+
| +----------+ +--------------+ |
| |
+-----------------------------------------------+ +-----------------------------------------------+
| | | | | |
| 3xx-6xx | 1xx-tag | 2xx | 3xx-6xx | 1xx-tag | 2xx
| | | | | |
| V | | | 1xx-tag |
| +------------------+ | | V w/new tag |
| 3xx-6xx | |--+ 1xx-tag | | +-----------------+ [new DSM] |
+<--------| Early | | w/new tag | | 3xx-6xx | | | (new DSM |
| | |<-+ (new DSM | +<--------| Early | | instance |
| +------------------+ instance | | | |<--+ created) |
| | | created) | | +-----------------+ |
| | BYE | 2xx | | | | | 2xx w/new tag
| | +------------>+<-+ | | BYE | 2xx | [new DSM]
| | | | | +------------>+<-+ | (new DSM
+-----C------------C-----+ +-----------C------+ | | | | instance
| | Terminated | | | Confirmed | | +-----C------------C-----+ +-----------C------+ | created)
| | +<----C---------| | | | | Terminated | | | Confirmed | | |
| | | | BYE | | | | | +<----C---------| | | |
| | V | | V | | | | | BYE(sr) | | | |
| | +------------+ | | +-----------+ | | | V | | V | |
| | | |---C-+ | | |--C-+ 2xx | 2xx | +-----------+ | | +-----------+ | |
| | | Mortal | | | BYE(r)| | Moratorium| | | w/new tag | +---C--| |---C-+ | | | | |
| | | |<--C-+ | | |<-C-+ (new DSM | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+
| | +------------+ | | +-----------+ | instance | +---C->| |<--C-+ | | | |
| | | | | | | created) | ACK | +-----------+ | | +-----------+ |
| | | | | | |
| | | Timeout | | | ACK | | | | Timeout | | | ACK |
| | | (Timer K) | | | | | | | | | | |
| V V | | V | | V V | | V |
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | | | | | | | | |--C-+
| | Morgue | | | |Established| | | | Morgue | | | |Established| | | 2xx,ACK
| | | | | | | | | | | | | | |<-C-+
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | |
+------------------------+ +------------------+ +------------------------+ +------------------+
(r): indicates only reception is allowed. (r): indicates only reception is allowed.
Where (r) is not indicated, response means receive, request Where (r) is not indicated, response means receive, request
means send. means send.
Figure 1. DSM for INVITE dialog usage (UAC) Figure 1. DSM for INVITE dialog usage (Caller)
Figure 1 represents the UAC's DSM for the INVITE dialog usage. UAC
MAY send a BYE in the Early state, even though this behavior is Figure 1 represents the caller's DSM for the INVITE dialog usage.
NOT RECOMMENDED. The BYE sent in the Early state terminates the Caller MAY send a BYE in the Early state, even though this behavior
Early dialog with a specific To-tag. That is, when a proxy is is NOT RECOMMENDED. The BYE sent in the Early state terminates the
performing forking, the BYE is only able to terminate the Early early dialog with a specific To tag. That is, when a proxy is
dialog with a particular UA. If UAC wants to terminate all Early performing forking, the BYE is only able to terminate the early
dialog with a particular UA. If caller wants to terminate all early
dialogs instead of that with a particular UA, it needs to send dialogs instead of that with a particular UA, it needs to send
CANCEL, not BYE. Moreover, until UAC receives a final response and CANCEL, not BYE. However, it is not illegal to send BYE in the Early
terminates the INVITE transaction, the UAC MUST be prepared to state to terminate a specific early dialog according to the caller's
intent. Moreover, until caller receives a final response and
terminates the INVITE transaction, the caller MUST be prepared to
establish a dialog by receiving a new response to the INVITE even establish a dialog by receiving a new response to the INVITE even
though it had sent a BYE and terminated the dialog (see Appendix A). though it had sent a CANCEL or BYE and terminated the dialog (see
Appendix A).
+-----------------------------------------------+ INV +-----------------------------------------------+
| Preparative | --->| Preparative |
| +----------+ +--------------+ |
| | | 100 | |-----C-+
| | Trying |---------->| Proceeding | | | 100
| | | | |<----C-+
| +----------+ +--------------+ |
| |
+-----------------------------------------------+ +-----------------------------------------------+
| | | | | |
| 3xx-6xx | 1xx-tag | 2xx | 3xx-6xx | 1xx-tag | 2xx
| | | | | |
| V | | V |
| +------------------+ | | +------------------+ |
| 3xx-6xx | |--+ | | 3xx-6xx | | |
+<--------| Early | | 1xx-tag | +<--------| Early | |
| | |<-+ | | | | |
| +------------------+ | | +------------------+ |
| | | | | | | |
| | BYE | 2xx | | | BYE | 2xx |
| | +------------>+<-+ | | +------------>+<-+
| | | | | |
+-----C------------C-----+ +-----------C------+ +-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | | | | Terminated | | | Confirmed | |
| | +<----C---------| | | | | +<----C---------| | |
| | | | BYE(sr) | | | | | | | BYE(sr) | | |
| | V | | V | | | V | | V |
| | +------------+ | | +-----------+ | | | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+ | | | |---C-+ | | |--C-+
| | | Mortal | | | BYE | | Moratorium| | | 2xx | | | Mortal | | | BYE | | Moratorium| | | 2xx
| | | |<--C-+ | | |<-C-+ | | | |<--C-+ | | |<-C-+ if ACK not
| | +------------+ | | +-----------+ | | | +------------+ | | +-----------+ | received
| | | | | | | | | | | | | |
| | | Timeout | | | ACK | | | | Timeout | | | ACK |
| | | (Timer J) | | | | | | | | | | |
| 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 indicated, response means send,
request means receive. request means receive.
Figure 2. DSM for INVITE dialog usage (UAS) Figure 2. DSM for INVITE dialog usage (Callee)
Figure 2 represents UAS's DSM for the INVITE dialog usage.
Figure 2 represents callee's DSM for the INVITE dialog usage.
The figure does not illustrate the state transition related to The figure does not illustrate the state transition related to
CANCEL request. CANCEL request does not cause a dialog state CANCEL request. CANCEL request does not cause a dialog state
transition. However, the UAS terminates the dialog and triggers the transition. However, the callee terminates the dialog and triggers
dialog transition by sending 487 immediately after the reception of the dialog transition by sending 487 immediately after the reception
the CANCEL. Considering this, the behavior upon the reception of the of the CANCEL. Considering this, the behavior upon the reception of
CANCEL request is further explained in the Appendix C. the CANCEL request is further explained in Appendix C.
Following are UA's behaviors in each state. Following are UA's behaviors in each state.
Preparative (Pre): The Preparative state is a state until the Preparative (Pre): The Preparative state is a state until the
Early dialog is established by sending and receiving a early dialog is established by sending or receiving a
provisional response with To-tag after an ini-INVITE is sent provisional response with To tag after an ini-INVITE is sent or
and received. The dialog has not existed yet in the received. The dialog has not existed yet in the Preparative
Preparative state. The dialog state transits from the state. If UA sends or receives a 2xx response, the dialog
Preparative to the Early by sending or receiving a provisional state transit from the Preparative to the Moratorium state
response with To-tag. Moreover, if UA sends or receives a 2xx
response, the dialog state transit to the Moratorium state
which is a substate of the Confirmed state. which is a substate of the Confirmed state.
In addition, if UA sends or receives a 3xx-6xx response the In addition, if UA sends or receives a 3xx-6xx response the
dialog state transit to the Morgue state which is a substate of dialog state transit to the Morgue state which is a substate of
the Terminated state. Sending an ACK for a 3xx-6xx response the Terminated state. Sending an ACK for a 3xx-6xx response
and retransmissions of 3xx-6xx are not expressed on this DSM and retransmissions of 3xx-6xx are not expressed on the DSMs
because they are sent by the INVITE transaction. because they are sent by the INVITE transaction.
Trying (Try): The Trying state is a substate of the Preparative
state and inherits the behavior of the superstate. The Trying
state is started by sending and receiving of an ini-INVITE.
It transits to the Proceeding state by sending or receiving a
1xx (usually 100 trying) without To-tag. UAC may retransmit an
INVITE on transaction layer and must not send a CANCEL request.
UAS may send a 1xx-6xx response.
Proceeding (Pro): The Proceeding state is a substate of the
Preparative state and inherits the behavior of the superstate.
Dialog becomes the Proceeding state if a dialog in the Trying
state sends or receives a 1xx without To-tag (usually 100
trying). UAC may send CANCEL, and UAS may send a 1xx-6xx
response in the Proceeding state.
Early (Ear): The early dialog is established by sending or Early (Ear): The early dialog is established by sending or
receiving a provisional response with To-tag. The early dialog receiving a provisional response with To tag. The early dialog
exists though the dialog does not existed in this state yet. exists though the dialog does not exist in this state yet.
The dialog state transits from the Early to Moratorium state, a The dialog state transits from the Early to Moratorium state, a
substate of the Confirmed state, by sending or receiving a 2xx substate of the Confirmed state, by sending or receiving a 2xx
response. In addition, the dialog state transits to the Morgue response. In addition, the dialog state transits to the Morgue
state, a substate of the Terminated state, by sending and state, a substate of the Terminated state, by sending or
receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx
response and retransmissions of 3xx-6xx are not expressed on response and retransmissions of 3xx-6xx are not expressed on
this DSM because they are automatically processed on this DSM because they are automatically processed on
transaction layer and don't influence the dialog state. UAC transaction layer and don't influence the dialog state. UAC
may send CANCEL in the Early state. UAC may send BYE may send CANCEL in the Early state. UAC may send BYE
(although it is not recommended). UAS may send a 1xx-6xx (although it is not recommended). UAS may send a 1xx-6xx
response. Sending or receiving of a CANCEL request does not response. Sending or receiving of a CANCEL request does not
have direct influences on dialog state. The UA's behavior upon have direct influences on dialog state. The UA's behavior upon
the reception of the CANCEL request is further explained in the the reception of the CANCEL request is further explained in
Appendix C. Appendix C.
Confirmed (Con): Sending or receiving of a 2xx final response Confirmed (Con): Sending or receiving of a 2xx final response
establishes a dialog. Dialog exists in this state. The BYE establishes a dialog. Dialog exists in this state. The
request the changes state from the Confirmed to Mortal state, Confirmed state transits to the Mortal state, a substate of the
a substate of the Terminated state. The Confirmed has two Terminated state, by sending or receiving a BYE request. The
substates, the Moratorium and Established state, which are Confirmed state has two substates, the Moratorium and
different in messages UAs are allowed to send. Established state, which are different in messages 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. Confirmed state and inherits the behavior of the superstate.
The Moratorium state transits to the Established state by The Moratorium state transits to the Established state by
sending or receiving an ACK request. UAC may send ACK and UAS sending or receiving an ACK request. UAC may send ACK and UAS
may send a 2xx final response. may send a 2xx 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 the behavior of superstate. Both
caller and callee may send various messages which influences a caller and callee may send various messages which influence a
dialog. Caller supports the transmission of ACK for a dialog. Caller supports the transmission of ACK in response to
retransmission of a 2xx response to an ini-INVITE. retransmission of a 2xx response to an ini-INVITE.
Terminated (Ter): The Terminated state is divided into two Terminated (Ter): The Terminated state is divided 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, UAs hold
information about the dialog which is being terminated. The information about the dialog which is being terminated.
Confirmed state transits to the Mortal state, a substate of the
Terminated state, by sending or receiving a BYE request.
Mortal (Mort): Caller and callee becomes Mortal state by sending Mortal (Mort): Caller and callee enter the Mortal state by sending
or receiving a BYE. UA MUST NOT send any new requests since or receiving a BYE. UA MUST NOT send any new requests within
there is no dialog. (Here the new requests do not include ACK the dialog because there is no dialog. (Here the new requests
for 2xx and BYE for 401 or 407 as further explained in the do not include ACK for 2xx and BYE for 401 or 407 as further
Appendix D below.) explained in Appendix D below.)
In this state, only BYE or its response can be handled, and no In this state, only BYE or its response can be handled, and no
other messages can be received. This is because the use case other messages can be received. This addresses the case where
is taken into consideration that BYE is sent by both a caller BYE is sent by both a caller and a callee to exchange reports
and a callee to exchange reports about the session when it is about the session when it is being terminated. Therefore the
being terminated. Therefore, UA possesses dialog information UA possesses dialog information for internal processing but the
for internal process but dialog shouldn't exist outwardly. The dialog shouldn't be externally visible. The UA stops managing
UA stops managing its dialog state and changes it to the Morgue its dialog state and changes it to the Morgue state, when the
state, when the BYE transaction is finished by timer BYE transaction is terminated.
(Timer F or Timer K for UAC. Timer J for UAS).
Morgue (Morg): Dialog does not exist any more in this state. Morgue (Morg): The dialog no longer exists in this state.
Sending or receiving of a signal which influences a dialog is Sending or receiving of signaling which influences a dialog is
not performed. (A dialog is literally terminated.) not performed. (A dialog is literally terminated.)
Caller and callee enter the Morgue state via the termination of
the BYE or INVITE transaction.
3. Race conditions 3. Race conditions
This section details race condition between two SIP UAs, Alice and This section details 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:bob@biloxi.example.com) are assumed to be SIP phones or
SIP-enabled devices. SIP-enabled devices. Only significant signaling is illustrated.
Only significant signals are illustrated. Dialog state transitions Dialog state transitions caused by sending or receiving of SIP
caused by sending and receiving of SIP messages as well as '*race*', messages as well as '*race*', which indicates race condition, are
which indicates race condition are shown. (For abbreviations for shown. (For abbreviations for the dialog state transitions, refer to
the dialog state transitions, refer to Chapter 2.) 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 shown 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 This section shows some examples of call flow in race condition when
when receiving the message from other states in the Moratorium state. receiving the message from other states in the Moratorium state.
3.1.1 Receiving Initial INVITE retransmission (Trying state) 3.1.1 Receiving Initial INVITE retransmission (Preparative state)
in Moratorium state in 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(=F1) F4 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 UAS
receives a Preparative message in the Moratorium state. All receives a Preparative message in the Moratorium state. All
provisional responses to the initial INVITE (ini-INVITE F1) are lost, provisional responses to the initial INVITE (ini-INVITE F1) are lost,
and UAC retransmits an ini-INVITE (F4). At the same time as and UAC retransmits an ini-INVITE (F4). At the same time as
retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it
terminate an INVITE server transaction, according to Section 13.3.1.4 terminates an INVITE server transaction, according to Section
of RFC3261 [1]. 13.3.1.4 of RFC 3261 [1].
However, it is reported that terminating an INVITE server transaction However, it is reported that terminating an INVITE server transaction
by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769) by 200 OK is a SIP bug. (http://bugs.sipit.net/, #769)
Therefore, the INVITE server transaction is not terminated at F3, and Therefore, the INVITE server transaction is not terminated at F3, and
the F4 MUST be properly handled as a retransmission. the F4 MUST be properly handled as a retransmission.
(UAs that do not deal with this bug still need to recognize the (UAs that do not deal with this bug still need to recognize the
dialog relying on its From-tag and Call-ID, and the retransmitted dialog relying on its From tag and Call-ID, and the retransmitted
request relying on the CSeq header field value even though it does request relying on the CSeq header field value even though it does
not match the transaction.) not match the transaction.)
In RFC3261 [1], it is not specified whether UAS retransmits 200 to In RFC3261 [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 200 triggered by timer (TU keeps retransmitting 200 based on T1 and
and T2 until it receives an ACK), according to Section 13.3.1.4 of T2 until it receives an ACK), according to Section 13.3.1.4 of RFC
RFC3261 [1], it seems unnecessary to retransmit 200 when the UAS 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 13.3.1.4 of RFC3261, an INVITE server transaction
is terminated at this point. However, this has been reported as a /* According to 13.3.1.4 of RFC 3261, an INVITE server transaction is
SIP bug, and the UAS MUST correctly recognize the ini-INVITE (F4) as terminated at this point. However, this has been reported as a
a retransmission. */ SIP bug, and the UAS MUST correctly recognize the 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 do not deal with the bug reported in #769 (an
INVITE server transaction is terminated by 200 to INVITE), this INVITE server transaction is terminated by 200 to INVITE), this
request does not match the transaction as well as the dialog request does not match the transaction as well as the dialog
since it does not have a To-tag. since it does not have a To tag.
However, Bob have to recognize the retransmitted INVITE correctly, However, Bob have to recognize the retransmitted INVITE correctly,
without treating it as a new INVITE. */ without treating it as a new INVITE. */
F5 ACK Alice -> Bob F5 ACK Alice -> Bob
3.1.2 Receiving CANCEL (Proceeding or Early state) 3.1.2 Receiving CANCEL (Early state)
in Moratorium state 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|
|------------ -------------| |------------ -------------|
| \ / | Mora | \ / | Mora
| X | | X |
| / \ | | / \ |
|<----------- ------------>| *race* |<----------- ------------>| *race*
Mora | | Mora | |
| ACK F6 200(CANCEL) F5| | ACK F6 200(CANCEL) F5|
|------------ -------------| |------------ -------------|
Est | \ / | Est | \ / |
skipping to change at page 12, line 51 skipping to change at page 12, line 28
| | 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, CANCEL, in the Moratorium state. Alice receives an Early message, CANCEL, in the Moratorium state. Alice
sends a CANCEL and Bob sends a 200 OK response to the initial INVITE sends a CANCEL and Bob sends a 200 OK response to the initial INVITE
message at the same time. As described in the previous section, message at the same time. As described in the previous section,
according to RFC3261, an INVITE server transaction is supposed to be according to RFC3261, an INVITE server transaction is supposed to be
terminated by a 200 response, but this has been reported as a bug terminated by a 200 response, but this has been reported as a bug
#769. #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 response to the CANCEL request. In this case, is not terminated by a 200 response to the INVITE request. In this
there is an INVITE transaction which the CANCEL request matches, so a case, there is an INVITE transaction which the CANCEL request
200 response is sent to the request. This 200 response simply means matches, so a 200 response is sent to the request. This 200 response
that the next hop received the CANCEL request (Successful CANCEL simply means that the next hop received the CANCEL request
(200) does not mean an INVITE failure). When UAS does not deal with (Successful CANCEL (200) does not mean an INVITE failure). When UAS
#769, UAC MAY receive a 481 response for CANCEL since there is no does not deal with #769, UAC MAY receive a 481 response for CANCEL
transaction which the CANCEL request matches. This 481 simply means since there is no transaction which the CANCEL request matches. This
that there is no matching INVITE server transaction and CANCEL is not 481 simply means that there is no matching INVITE server transaction
sent to the next hop. and CANCEL is not sent to the next hop.
Regardless of the success/failure of the CANCEL, Alice checks the Regardless of the success/failure of the CANCEL, Alice checks the
final response to INVITE, and if she receives 200 to the INVITE final response to INVITE, and if she receives 200 to the INVITE
request she immediately sends a BYE and terminates a dialog. request she immediately sends a BYE and terminates the dialog.
(Section 15, RFC3261 [1]) (Section 15, RFC3261 [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
than 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
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
skipping to change at page 13, line 29 skipping to change at page 13, line 12
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
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 CANCEL Alice -> Bob F3 CANCEL Alice -> Bob
/* Alice sends a CANCEL in the Early state. */ /* Alice sends a CANCEL in the Early state. */
F4 200 OK (INVITE) Bob -> Alice F4 200 OK (INVITE) Bob -> Alice
/* Alice receives a 200 to INVITE (F1) in the Moratorium state. /* Alice receives a 200 to INVITE (F1) in the Moratorium state.
Alice has the potential to send as well as receive media, Alice has the potential to send as well as receive media, but in
but in practice will not send because there is an intent practice will not send because there is an intent to end the
to end the call. */ call. */
F5 200 OK (CANCEL) Bob -> Alice F5 200 OK (CANCEL) Bob -> Alice
/* 200 to CANCEL simply means that the CANCEL was received. /* 200 to CANCEL simply means that the CANCEL was received.
The 200 response is sent, since this document deals with the The 200 response is sent, since this document deals with the bug
bug reported in #769. When an INVITE server transaction is reported in #769. When an INVITE server transaction is terminated
terminated as the procedure stated in RFC3261, UAC MAY receive as the procedure stated in RFC 3261, UAC MAY receive 481 response
481 response instead of 200. */ 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. establishes RTP streams.
However, the next BYE request immediately terminates However, the next BYE request immediately terminates the dialog
the dialog and session. */ 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) 3.1.3 Receiving BYE (Early state)
in Moratorium state in Moratorium state
State Alice Bob State State Alice Bob State
| | | |
skipping to change at page 14, line 41 skipping to change at page 14, line 27
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, in the Moratorium state. Alice sends
a BYE in the Early state and Bob sends a 200 OK response to the a BYE in the Early state and Bob sends a 200 OK response to the
initial INVITE request at the same time. Bob receives the BYE in the initial 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 though Alice sent the request in the Early
state (As explained in Section 2, this behavior is NOT RECOMMENDED). state (As explained in Section 2 and Appendix A, this behavior is NOT
RECOMMENDED). When a proxy is performing forking, the BYE is only
able to terminate the early dialog with a particular UA. If caller
wants to terminate all early dialogs instead of that with a
particular UA, it needs to send CANCEL, not BYE. However, it is not
illegal to send BYE in the Early state to terminate a specific early
dialog according to 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 gets into the Mortal
state on receiving the BYE response, and remains Mortal until the state on sending the BYE request, and remains Mortal until the
Timer K timeout occurs. In the Mortal state, UAC does not establish Timer K timeout occurs. In the Mortal state, UAC does not establish
a session, even though it receives a 200 response to INVITE. Even a session, even though it receives a 200 response to INVITE. Even
so, the UAC sends an ACK to 200 for the completion of INVITE so, the UAC sends an ACK to 200 for the completion of INVITE
transaction. The ACK is always sent to complete the three-way transaction. The ACK is always sent to complete the three-way
handshake of INVITE transaction (Further explained in the Appendix D handshake of INVITE transaction (Further explained in Appendix D
below). below).
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK (ini-INVITE) Bob -> Alice F3 200 OK (ini-INVITE) Bob -> Alice
F4 BYE Alice -> Bob F4 BYE Alice -> Bob
/* Alice transits to the Mortal state upon sending BYE. /* Alice transits to the Mortal state upon sending BYE.
Therefore, after this, she does not begin a session even Therefore, after this, she does not begin a session even though
though she receives a 200 response with an answer. */ she receives a 200 response with an answer. */
F5 ACK Alice -> Bob F5 ACK Alice -> Bob
F6 200 OK (BYE) Bob -> Alice F6 200 OK (BYE) Bob -> Alice
3.1.4 Receiving re-INVITE (Established state) 3.1.4 Receiving re-INVITE (Established state)
in Moratorium state (case 1) in Moratorium state (case 1)
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE w/offer1 F1 | | ini-INVITE w/offer1 F1 |
|------------------------------->| |------------------------------->|
Pre | 180 F2 | Pre Pre | 180 F2 | Pre
|<-------------------------------| |<-------------------------------|
Ear | | Ear Ear | | Ear
| 200(ini-INV) w/answer1 F3 | | 200(ini-INV) w/answer1 F3 |
|<-------------------------------| |<-------------------------------|
Mora | ACK F4(packet loss) | Mora Mora | ACK F4(packet loss) | Mora
|-------------------->x | |-------------------->x |
Est | | Est | |
| re-INVITE F6 200(=F3) F5 | | re-INVITE F6 200 F5(=F3) |
| w/offer2 w/answer1 | | w/offer2 w/answer1 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| *race* |<------------ ------------->| *race*
| 200(re-INV) F8| | 200(re-INV) F8|
| ACK(=F4) F7 w/answer2 | | ACK F7(=F4) w/answer2 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK 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 UAS
receives re-INVITE request sent from the Established state, in the receives re-INVITE request sent from the Established state, in the
Moratorium state. Moratorium state.
UAS receives a re-INVITE (w/offer2) before receiving an ACK for UAS receives a re-INVITE (w/offer2) before receiving an ACK for
ini-INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the ini-INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the
re-INVITE (F8) because it has sent a 200 OK (w/answer1) to the re-INVITE (F8) because it has sent a 200 OK (w/answer1) to the
ini-INVITE (F3, F5) and the dialog has already been established. ini-INVITE (F3, F5) and the dialog has already been established.
(Because F5 is a retransmission of F3, SDP negotiation is not (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 performed here.)
answer is in the ACK, UA should return by a 491 to the
re-INVITE (refer to 3.1.5). As it can be seen in Section 3.3.2 If a 200 OK to the ini-INVITE has an offer and the answer is in the
below, the 491 response seems to be closely related to session ACK, it is recommended that UA return a 491 to the re-INVITE (refer
establishment, even in cases other than INVITE cross-over. This to 3.1.5). (Note: 500 with Retry-After header may be returned, if
example recommends 200 be sent instead of 491 because it does not the 491 response is understood to indicate request collision.
have influence on session. However, a 491 response can also lead to However, 491 is recommended here because 500 applies to so many cases
the same outcome, so the either response can be used. that it is difficult to determine what the real problem was.)
Moreover, if UAS doesn't receive an ACK for a long time, As it can be seen in Section 3.3.2 below, the 491 response seems to
it should send a BYE and terminate the dialog. be closely related to session establishment, even in cases other than
INVITE cross-over. This example recommends 200 be sent instead of
491 because it does not have influence on session. However, a 491
response can also lead to the same outcome, so the either response
can be used.
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
CSeq number as ini-INVITE F1 (See Section 13.2.2.4 of RFC 3261).
The UA should not reject or drop the ACK on grounds of CSeq number.
Note: There is a hint for implementation to avoid the race conditions
of this type. That is for the caller to delay sending re-INVITE F6
for some period of time (2 seconds, perhaps), from which the caller
is reasonably able to assume that its ACK has been received.
Implementors can decouple the actions of the user (e.g. pressing the
hold button) from the actions of the protocol (the sending of
re-INVITE F6), so the UA can behave as such. In this case, it is
dependent on the implementor's choice how long it waits. In most
cases, such implementation may be useful to prevent a type of race
condition shown in 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 16, line 51 skipping to change at page 17, line 17
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
/* ini-INVITE contains an offer. */ /* Detailed messages are shown for the sequence to illustrate 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
Contact: <sip:bob@client.biloxi.example.com;transport=udp> Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0 Content-Length: 0
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101 ;received=192.0.2.101
skipping to change at page 17, line 37 skipping to change at page 18, line 4
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
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0 ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
/* ACK request is lost. */ /* ACK request is lost. */
F5 200 OK (=F3) Bob -> Alice (retransmission)
F5(=F3) 200 OK Bob -> Alice (retransmission)
/* 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 re-INVITE Alice -> Bob F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 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: 147 Content-Length: 147
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=- s=-
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly a=sendonly
F7 ACK (=F4) Alice -> Bob (retransmission) F7(=F4) ACK Alice -> Bob (retransmission)
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=z9hG4bK74bf9.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE CSeq: 2 INVITE
Content-Length: 143 Content-Length: 143
v=0 v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=- s=-
c=IN IP4 192.0.2.201 c=IN IP4 192.0.2.201
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=recvonly a=recvonly
F9 ACK Alice -> Bob
F9 ACK (re-INVITE) Alice -> Bob
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=z9hG4bK230f2.1 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) 3.1.5 Receiving re-INVITE (Established state)
in Moratorium state (case 2) in Moratorium state (case 2)
skipping to change at page 19, line 30 skipping to change at page 19, line 43
| 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 |
|<-------------------------------| |<-------------------------------|
Mora | ACK w/answer1 F4(packet loss) | Mora Mora | ACK w/answer1 F4(packet loss) | Mora
|-------------------->x | |-------------------->x |
Est | | Est | |
| re-INVITE F6 200(=F3) F5 | | re-INVITE F6 200 F5(=F3) |
| w/offer2 w/offer1 | | w/offer2 w/offer1 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK(=F4) F7 491(re-INV) F8| | ACK F7(=F4) 491(re-INV) F8|
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK 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 200 and an answer in ACK. Different
to the previous case, the offer in the 200 (F3) and the offer in the to the previous case, the offer in the 200 (F3) and the offer in the
re-INVITE (F6) collide with each other. re-INVITE (F6) collide with each other.
Bob sends 491 to re-INVITE (F6) since he is not able to properly Bob sends 491 to re-INVITE (F6) since he is not able to properly
handle a new request until he receives an answer. Even if F6 is handle a new request until he receives an answer. (Note: 500 with
UPDATE with offer, it will reach the same result. Retry-After header may be returned, if the 491 response is understood
to indicate request collision. However, 491 is recommended here
because 500 applies to so many cases that it is difficult to
determine what the real problem was.)
Even if F6 is UPDATE with offer, it will reach the same result.
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,
perhaps), from which the caller is reasonably able to assume that its
ACK has been received, to prevent a type of race condition shown in
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>
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp> Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Length: 0 Content-Length: 0
/* The request does not contain an offer. */ /* The request does not contain an offer. Detailed messages are
shown for the sequence to illustrate offer and answer
examples. */
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101 ;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp> Contact: <sip:bob@client.biloxi.example.com;transport=udp>
skipping to change at page 20, line 48 skipping to change at page 21, line 25
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
/* An offer is made in 200 */ /* An offer is made in 200. */
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0 ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK CSeq: 1 ACK
Content-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
/* The request contains an answer, but the request is lost. */ /* The request contains an answer, but the request is lost. */
F5 200 OK (=F3) Bob -> Alice (retransmission) F5(=F3) 200 OK Bob -> Alice (retransmission)
/* 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 re-INVITE Alice -> Bob F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 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: 147 Content-Length: 147
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=- s=-
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly a=sendonly
/* The request contains an offer. */ /* The request contains an offer. */
F7 ACK (=F4) 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. */
F8 491 (re-INVITE) Bob -> Alice F8 491 (re-INVITE) Bob -> Alice
/* Bob sends 491 (Request Pending), since Bob has a pending /* Bob sends 491 (Request Pending), since Bob has a pending
offer. */ offer. */
F9 ACK Alice -> Bob F9 ACK (re-INVITE) Alice -> Bob
3.1.6 Receiving BYE (Established state) 3.1.6 Receiving BYE (Established state)
in Moratorium state 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
| 200 OK F3 | | 200 OK F3 |
|<--------------------------| |<--------------------------|
Mora | ACK F4(packet loss) | Mora Mora | ACK F4(packet loss) | Mora
|--------------->x | |--------------->x |
Est | Both Way RTP Media | Est | Both Way RTP Media |
|<=========================>| |<=========================>|
| BYE F6 200(=F3) F5| | BYE F6 200 F5(=F3)|
|----------- -----------| |----------- -----------|
Mort | \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
|<---------- ---------->| *race* |<---------- ---------->| *race*
|ACK(=F4) F7 200(BYE) F8| Mort |ACK F7(=F4) 200(BYE) F8| Mort
|----------- -----------| |----------- -----------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<---------- ---------->| |<---------- ---------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
skipping to change at page 23, line 18 skipping to change at page 23, line 45
sends a BYE request at the same time. Depending on the sends a BYE request at the same time. Depending on the
implementation of a SIP UA, Alice may start a session again by the implementation of a SIP UA, Alice may start a session again by the
reception of the retransmitted 200 OK with SDP since she has already reception of the retransmitted 200 OK with SDP since she has already
terminated a session by sending a BYE. In that case, when UAC terminated a session by sending a BYE. In that case, when UAC
receives a retransmitted 200 OK after sending a BYE, a session should receives a retransmitted 200 OK after sending a BYE, a session should
not be started again since the session which is not associated with not be started again since the session which is not associated with
dialog still remains. Moreover, in the case where UAS sends an offer dialog still remains. Moreover, in the case where UAS sends an offer
in a 200 OK , UAS should not start a session again for the same in a 200 OK , UAS should not start a session again for the same
reason if UAS receives a retransmitted ACK after receiving a BYE. 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
to avoid the race conditions of this type. That is for the caller to
delay sending BYE F6 for some period of time (2 seconds, perhaps),
from which the caller is reasonably able to assume that its ACK has
been received. Implementors can decouple the actions of the user
(e.g. hanging up) from the actions of the protocol (the sending of
BYE F6), so the UA can behave as such. In this case, it is dependent
on the implementor's choice how long it waits. In most cases, such
implementation may be useful to prevent a type of race condition
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
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* ACK request is lost. */ /* ACK request is lost. */
F5 200 OK (retransmission) Bob -> Alice F5(=F3) 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 133
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* 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
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* 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 transits to the Mortal state, so she does not begin a
session after this even though she receives a 200 response to session after this even though she receives a 200 response to
the re-INVITE. */ the re-INVITE. */
F7 ACK(=F4) Alice -> Bob F7(=F4) ACK Alice -> Bob
F8 200 OK (BYE) Bob -> Alice F8 200 OK (BYE) Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* 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 This section shows some examples of call flow in race condition
when receiving the message from other states in the Mortal state. when receiving the message from other states in the Mortal state.
3.2.1 Receiving BYE (Establish state) 3.2.1 Receiving BYE (Establish state)
in Mortal state in Mortal state
State Alice Bob 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 |
|<-----------------------| |<-----------------------|
Mora | ACK F4 | Mora Mora | ACK F4 | Mora
|----------------------->| |----------------------->|
skipping to change at page 25, line 45 skipping to change at page 25, line 37
| ^ ^ | | ^ ^ |
| | 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 Established message, BYE, in the Mortal state. receives an Established message, BYE, in the Mortal state.
Alice and Bob send a BYE at the same time. A dialog and session is Alice and Bob send a BYE at the same time. A dialog and session are
ended shortly after a BYE request is passed to a client transaction. ended shortly after a BYE request is passed to a client transaction.
As shown in Section 2, UA remains in the Mortal state. As shown in Section 2, 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 dialog or session, such as re-INVITE, UPDATE, or REFER.
However, UA shall return 200 OK to the BYE taking the use case into However, UA shall return 200 OK to the BYE taking the use case into
consideration where BYE request is sent by both a caller and a callee consideration where BYE request is sent by both a caller and a callee
to exchange reports about the session when it is being terminated. to exchange reports about the session when it is being terminated.
(Since the dialogue and the session both terminate when a BYE is (Since the dialogue and the session both terminate when a BYE is
sent, the choice of sending 200 or an error response upon receiving sent, the choice of sending 200 or an error response upon receiving
BYE in the Mortal state does not affect the resulting termination. BYE in the Mortal state does not affect the resulting termination.
Therefore, even though this example uses a 200 response, other Therefore, even though this example uses a 200 response, other
responses can also be used.) responses can also be used.)
skipping to change at page 26, line 21 skipping to change at page 26, line 16
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
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* The session is terminated at the moment Alice sends a BYE. /* The session is terminated at the moment Alice sends a BYE.
The dialog still exists then, but it is certain to be terminated The dialog still exists then, but it is certain to be terminated
in a short period of time. The dialog is completely in a short period of time. The dialog is completely
terminated when the timeout of the BYE request occurs. */ terminated when the timeout of the BYE request occurs. */
F6 BYE Bob -> Alice F6 BYE Bob -> Alice
BYE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
/* Bob has also transmitted a BYE simultaneously with Alice. /* Bob has also transmitted a BYE simultaneously with Alice.
Bob terminates the session and the dialog. */ Bob terminates the session and the dialog. */
F7 200 OK Bob -> Alice F7 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
;received=192.0.2.201
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Since the dialog is in the Moratorium state, Bob responds with /* Since the dialog is in the Moratorium state, Bob responds with
a 200 to the BYE request. */ a 200 to the BYE request. */
F8 200 OK Alice -> Bob F8 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 BYE
Content-Length: 0
/* Since Alice has transited from the Established state to the Mortal /* Since Alice has transited from the Established state to the Mortal
state by sending BYE, Alice responds with a 200 to the BYE state by sending BYE, Alice responds with a 200 to the BYE
request. */ request. */
3.2.2 Receiving re-INVITE (Establish state) 3.2.2 Receiving re-INVITE (Establish state)
in Mortal state in Mortal state
State Alice Bob 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 |
|<-----------------------| |<-----------------------|
Mora | ACK F4 | Mora Mora | ACK F4 | Mora
|----------------------->| |----------------------->|
skipping to change at page 28, line 8 skipping to change at page 27, line 15
|<======================>| |<======================>|
| | | |
| BYE F5 re-INVITE F6| | BYE F5 re-INVITE F6|
|--------- ----------| |--------- ----------|
Mort | \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
*race* |<-------- --------->| *race* |<-------- --------->|
| | Mort | | Mort
| 481 F8 200 F7 | | 481 F8 200 F7 |
| (re-INV) (BYE) |
|--------- ----------| |--------- ----------|
| \ / |^ | \ / |^
| X || | X ||
| / \ ||Timer J | / \ ||Timer J
|<-------- --------->|| |<-------- --------->||
^| ACK 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 UAS
receives an Established message, re-INVITE, in the Mortal state. receives an Established message, re-INVITE, in the Mortal state.
Bob sends a re-INVITE, and Alice sends a BYE at the same time. Bob sends a re-INVITE, and Alice sends a BYE at the same time.
The re-INVITE is responded by a 481, since the TU of Alice has The re-INVITE is responded by a 481, since the TU of Alice has
transited from the Established state to the Mortal state by sending transited from the Established state to the Mortal state by sending
skipping to change at page 28, line 44 skipping to change at page 27, line 51
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
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Alice sends a BYE and terminates the session, and transits from /* Alice sends a BYE and terminates the session, and transits 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
INVITE sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
Session-Expires: 300;refresher=uac
Supported: timer
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* 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 The dialog state transits to the Mortal state at the moment
Alice sends the BYE, but Bob does not know it until he receives Alice sends the BYE, but Bob does not know it until he receives
the BYE. Therefore, the dialog is in the Terminated state from the BYE. Therefore, the dialog is in the Terminated state from
Alice's point of view, but it is the Confirmed state Alice's point of view, but it is the Confirmed state
from Bob's point of view. A race condition occurs. */ from Bob's point of view. A race condition occurs. */
F7 200 OK Bob -> Alice F7 200 OK (BYE) Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
;received=192.0.2.201
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
F8 481 Call/Transaction Does Not Exist Alice -> Bob F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
SIP/2.0 481 Call/Transaction Does Not Exist
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.201
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* 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 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 200OK for re-INVITE (Established state) 3.2.3 Receiving 200OK for re-INVITE (Established state)
in Mortal state in Mortal state
State Alice Bob 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 |
|<-----------------------| |<-----------------------|
Mora | ACK F4 | Mora Mora | ACK F4 | Mora
|----------------------->| |----------------------->|
skipping to change at page 30, line 38 skipping to change at page 29, line 6
| | | |
| re-INVITE F5 | | re-INVITE F5 |
|<-----------------------| |<-----------------------|
| 200 F7 BYE F6 | | 200 F7 BYE F6 |
|--------- ----------| |--------- ----------|
| \ / | Mort | \ / | Mort
| X | | X |
| / \ | | / \ |
|<-------- --------->| *race* |<-------- --------->| *race*
Mort | 200 F8 ACK F9 | Mort | 200 F8 ACK F9 |
| (BYE) (re-INV) |
|--------- ----------| |--------- ----------|
| ^ \ / | | ^ \ / |
| | X | | | X |
| | / \ | | | / \ |
|<-------- --------->| |<-------- --------->|
| | ^ | | | ^ |
| | Timer K | | | | Timer K | |
| | V | | | V |
| | Timer J | Morg | | Timer J | Morg
| V | | V |
skipping to change at page 31, line 14 skipping to change at page 29, line 30
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when UAS
receives an Established message, 200 to re-INVITE, in the Mortal receives an Established message, 200 to re-INVITE, in the Mortal
state. Bob sends a BYE immediately after sending a re-INVITE. state. Bob sends a BYE immediately after sending a re-INVITE.
(A user is not conscious that refresher sends re-INVITE (A user is not conscious that refresher sends re-INVITE
automatically. For example, in the case of a telephone application, automatically. For example, in the case of a telephone application,
it is possible that a user places a receiver immediately after it is possible that a user places a receiver immediately after
refresher.) refresher.)
Bob sends ACK for a 200 response to INVITE in the Mortal state, so Bob sends ACK for a 200 response to INVITE in the Mortal state, so
that he completes the INVITE transaction. that he completes the INVITE transaction.
Note: As noted in Section 3.1.4, there is a hint for implementation
to avoid the race conditions of this type. That is for the UAC to
delay sending BYE F6 until re-INVITE F5 transaction completes.
Implementors can decouple the actions of the user (e.g. hanging up)
from the actions of the protocol (the sending of BYE F6), so the UA
can behave as such. In this case, it is dependent on the
implementor's choice how long it waits. In most cases, such
implementation may be useful to prevent a type of race condition
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
F5 re-INVITE Bob -> Alice F5 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=z9hG4bKnashds7 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
F6 BYE Bob -> Alice /* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal
state. */
BYE sip:alice@client.atlanta.example.com SIP/2.0 F6 BYE Bob -> Alice
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Bob sends BYE immediately after sending the re-INVITE. /* Bob sends BYE immediately after sending the re-INVITE.
Bob terminates the session and transits from the Established Bob terminates the session and transits from the Established
state to the Mortal state. */ 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=z9hG4bKnashds7 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7
;received=192.0.2.201 ;received=192.0.2.201
Require: timer
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
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Content-Length: 0 Content-Length: 0
/* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE. /* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
A race condition occurs. */ A race condition occurs. */
F8 200 OK (BYE) Alice -> Bob F8 200 OK (BYE) Alice -> Bob
SIP/2.0 200 OK F9 ACK (re-INVITE) Bob -> Alice
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8
;received=192.0.2.201 ACK sip:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 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 BYE CSeq: 2 ACK
Content-Length: 0 Content-Length: 0
F9 ACK Bob -> Alice
/* 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) 3.2.4 Receiving ACK (Moratorium state)
in Mortal state in Mortal state
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
|------------------------------->| |------------------------------->|
skipping to change at page 33, line 24 skipping to change at page 31, line 45
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when UAS
receives an Established message, ACK to 200, in the Mortal state. receives an Established message, ACK to 200, in the Mortal state.
Alice sends an ACK and Bob sends a BYE at the same time. When the Alice sends an ACK and Bob sends a BYE at the same time. When the
offer is in a 2xx, and the answer is in an ACK, this example is in offer is in a 2xx, and the answer is in an ACK, this example is in
a race condition. The session is not started by receiving the ACK a race condition. The session is not started by receiving the ACK
because Bob has already terminated the session by sending the BYE. because Bob has already terminated the session by sending the BYE.
The answer in the ACK request is just ignored. The answer in the ACK request is just ignored.
Note: As noted in Section 3.1.4, there is a hint for implementation
to avoid the race conditions of this type. Implementors can decouple
the actions of the user (e.g. hanging up) from the actions of the
protocol (the sending of BYE F5), so the UA can behave as such. In
this case, it is dependent on the implementor's choice how long it
waits. In most cases, such implementation may be useful to prevent a
type of race condition shown in this section.
Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between Alice and Bob */ /* RTP streams are established between Alice and Bob */
F5 BYE Alice -> Bob F5 BYE Alice -> Bob
BYE sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
/* Alice sends a BYE and terminates the session and dialog. */
F6 200 OK Bob -> Alice F6 200 OK Bob -> Alice
SIP/2.0 200 OK /* Alice sends a BYE and terminates the session and dialog. */
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
;received=192.0.2.201
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
3.3 Other race conditions 3.3 Other race conditions
This section shows the examples in race condition that are not This section shows the examples in race condition that are not
directly related to the dialog state transition. Here explains directly related to the dialog state transition. In SIP, processing
the way to handle the race condition generated when UAs treat functions are deployed in three layers, dialog, session, and
"What is established by SIP", which has some relation to dialog. transaction. There are related each other, but have to be treated
separately. Section 17 of RFC 3261 [1] details the processing on
transactions. This draft has tried so far to clarify the processing
on dialogs. This section explains race conditions which are related
to sessions established by SIP.
3.3.1 Re-INVITE crossover 3.3.1 Re-INVITE crossover
Alice Bob Alice Bob
| | | |
| INVITE F1 | | INVITE F1 |
|--------------------------->| |--------------------------->|
| 180 Ringing F2 | | 180 Ringing F2 |
|<---------------------------| |<---------------------------|
| |
| 200 OK F3 | | 200 OK F3 |
|<---------------------------| |<---------------------------|
| ACK F4 | | ACK F4 |
|--------------------------->| |--------------------------->|
| Both Way RTP Media | | Both Way RTP Media |
|<==========================>| |<==========================>|
| | | |
|re-INVITE F5 re-INVITE F6 | |re-INVITE F5 re-INVITE F6 |
|------------ -------------| |------------ -------------|
| \ / | | \ / |
skipping to change at page 35, line 17 skipping to change at page 33, line 21
|<----------- ------------>| |<----------- ------------>|
| ^ ACK F9 ^ ACK F10| | ^ ACK F9 ^ ACK F10|
|--|--------- ----|--------| |--|--------- ----|--------|
| | \ / | | | | \ / | |
| | X | | | | X | |
| | / \ | | | | / \ | |
|<-|---------- ---|------->| |<-|---------- ---|------->|
| | | | | | | |
| |0-2.0 sec | | | |0-2.0 sec | |
| | | | | | | |
| v re-INVITE(=F6) F11 | | v re-INVITE F11(=F6) |
|<------------------|--------| |<------------------|--------|
| 200 OK F12 | | | 200 OK F12 | |
|-------------------|------->| |-------------------|------->|
| ACK F13 | | | ACK F13 | |
|<------------------|--------| |<------------------|--------|
| | | | | |
| |2.1-4.0 sec | |2.1-4.0 sec
| | | | | |
|re-INVITE(=F5) F14 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 resend re-INVITEs
after different interval for each, according to Section 14.1, of after different interval for each, according to Section 14.1, of
RFC3261 [1]. When Alice sends the re-INVITE and it crosses, the RFC3261 [1]. When Alice sends the re-INVITE and it crosses, the
re-INVITE will be sent again after 2.1-4.0 seconds because she owns re-INVITE will be sent again after 2.1-4.0 seconds because she owns
the Call-ID (she generated it). Bob will send an INVITE again after the Call-ID (she generated it). Bob will send an 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 Bob's re-INVITE is for session refresh. In this case, after In this example, Alice's re-INVITE is for session modification and
the 491 responses, Bob retransmits the re-INVITE for session refresh Bob's re-INVITE is for session refresh. In this case, after the 491
earlier than Alice. If Alice was to retransmit her re-INVITE (that responses, Bob retransmits the re-INVITE for session refresh earlier
is, if she was not the owner of Call-ID), the request would refresh than Alice. If Alice was to retransmit her re-INVITE (that is, if
and modify the session at the same time. Then Bob would know that she was not the owner of Call-ID), the request would refresh and
he would not need to retransmit his re-INVITE to refresh the session. 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.
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 491 by the
Call-ID owner (the UA which retransmits its re-INVITE after the Call-ID owner (the UA which retransmits its re-INVITE after the other
other UA) may result in a behavior different from what the user UA) may result in a behavior different from what the user originally
originally intended to, so the UA needs to decide if the intended to, so the UA needs to decide if the retransmission of the
retransmission of the re-INVITE is necessary. re-INVITE is necessary.
(For example, when a call hold and an addition of video media cross (For example, when a call hold and an addition of video media cross
over, mere retransmission of the re-INVITE at the firing of the timer over, mere retransmission of the re-INVITE at the firing of the timer
may result in the situation where the video is transmitted may result in the situation where the video is transmitted
immediately after the holding of the audio. This behavior is immediately after the holding of the audio. This behavior is
probably not intended by the users.) probably not intended by the users.)
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
skipping to change at page 36, line 45 skipping to change at page 34, line 51
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
/* re-INVITE for session modification (a=sendrecv -> sendonly). */ /* Some detailed messages are shown for the sequence to illustrate
what sort of INVITE requests crossed over each other. */
F6 re-INVITE Bob -> Alice F6 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=z9hG4bKnashds7 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 re-INVITE request for a session refresh and that for a call hold
a call hold are sent at the same time. */ 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
F11 re-INVITE Bob -> Alice F11 re-INVITE Bob -> Alice
skipping to change at page 37, line 27 skipping to change at page 35, line 33
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
F11 re-INVITE Bob -> Alice F11 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=z9hG4bKnashds7.1 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
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: 2 INVITE CSeq: 2 INVITE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 133 Content-Length: 133
skipping to change at page 38, line 4 skipping to change at page 36, line 9
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 the Call-ID, he sends a re-INVITE /* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
again after 0.0-2.0 seconds. */ again after 0.0-2.0 seconds. */
F12 200 OK Alice -> Bob F12 200 OK Alice -> Bob
F13 ACK Bob -> Alice F13 ACK Bob -> Alice
F14 re-INVITE Alice -> Bob F14 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 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: 3 INVITE CSeq: 3 INVITE
Content-Length: 147 Content-Length: 147
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=- s=-
skipping to change at page 39, line 7 skipping to change at page 37, line 13
| Both Way RTP Media | | Both Way RTP Media |
|<==========================>| |<==========================>|
| | | |
| UPDATE F5 re-INVITE F6 | | UPDATE F5 re-INVITE F6 |
|------------ -------------| |------------ -------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<----------- ------------>| |<----------- ------------>|
| 491 F8 491 F7 | | 491 F8 491 F7 |
| (re-INVITE) (UPDATE) |
|------------ -------------| |------------ -------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<----------- ------------>| |<----------- ------------>|
| ^ ACK F9 ^ | | ^ ACK F9 ^ |
|<-|----------------|--------| |<-|----------------|--------|
| | | | | | | |
| |0-2.0 sec | | | |0-2.0 sec | |
| | | | | | | |
skipping to change at page 39, line 43 skipping to change at page 37, line 50
In this scenario, the UPDATE contains a SDP offer, therefore the In this scenario, the UPDATE contains a SDP offer, therefore the
UPDATE and re-INVITE are responded with 491 as in the case of UPDATE and re-INVITE are responded with 491 as in the case of
"re-INVITE crossover". When an UPDATE for refresher which doesn't "re-INVITE crossover". When an UPDATE for refresher which doesn't
contain a session description and a re-INVITE crossed each other, contain a session description and a re-INVITE crossed each other,
both requests succeed with 200 (491 means that UA have a pending both requests succeed with 200 (491 means that UA have a pending
request). Moreover, the same is equally true for UPDATE crossover. request). Moreover, the same is equally true for UPDATE crossover.
In the former case where either UPDATE contains a session description In the former case where either UPDATE contains a session description
the requests fail with 491, and in the latter cases succeed with 200. the requests fail with 491, and in the latter cases succeed with 200.
Editor's Note: Editor's Note:
A 491 response is considered as a result that UA judged the A 491 response is sent because SDP offer is pending, and 491 is an
effectiveness of request to "What is established by SIP". error which is related to matters that behave on the session
Therefore, it is considered that 491 will be used in all the established by SIP.
requests that demand operation to "What is 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
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
F5 UPDATE Alice -> Bob F5 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=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
skipping to change at page 40, line 30 skipping to change at page 38, line 35
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
the example messages crossed 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=z9hG4bKnashds7 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 re-INVITE for /* A case where a re-INVITE for a session refresh and a UPDATE for a
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 Bob -> Alice
/* Since a re-INVITE is in process, a 491 response are returned. */ /* Since a re-INVITE is in process, a 491 response are returned. */
F8 491 Request Pending 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=z9hG4bKnashds7.1 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
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: 2 INVITE CSeq: 2 INVITE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 133 Content-Length: 133
skipping to change at page 41, line 36 skipping to change at page 39, line 44
/* Since Bob is not the owner of Call-ID, Bob sends an INVITE again /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again
after 0.0-2.0 seconds. */ 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=z9hG4bK74bf9.1 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: 3 UPDATE CSeq: 3 UPDATE
Content-Length: 147 Content-Length: 147
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=- s=-
skipping to change at page 42, line 34 skipping to change at page 40, line 42
|<======================>| |<======================>|
| | | |
| BYE F5 REFER F6 | | BYE F5 REFER F6 |
|--------- ----------| |--------- ----------|
Mort | \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
*race* |<-------- --------->| *race* |<-------- --------->|
| | Mort | | Mort
| 481 F8 200 F7 | | 481 F8 200 F7 |
| (REFER) (BYE) |
|--------- ----------| |--------- ----------|
| \ / ^ | | \ / ^ |
| X | | | X | |
| / \ | | | / \ | |
|<-------- --------->| |<-------- --------->|
| ^ | | | ^ | |
| | 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 UAS
receives an Established message, REFER, in the Mortal state. receives an Established message, REFER, in the Mortal state.
Bob sends a REFER, and Alice sends a BYE at the same time. Bob Bob sends a REFER, and Alice sends a BYE at the same time. Bob send
send the REFER in the same dialog. Alice sends an error response the REFER in the same dialog. Alice's dialog state moves to the
to the requests which operates the session, such as REFER, because Mortal state at the point of sending BYE. In the Mortal state, UA
by sending the BYE, Alice had terminated the session which would possesses dialog information for internal process but dialog
have corresponded to the REFER. For handling of dialogs with shouldn't exist outwardly. Therefore, UA sends an error response to
multiple usages, as can be seen in the use of REFER method, a REFER which is transmitted as a mid-dialog request. So, Alice in
see the draft on dialog usage [8]. the Mortal state sends an error response to the REFER.
However, Bob has already started the SUBSCRIBE usage with REFER, so
the dialog continues until the SUBSCRIBE usage terminates, even
though the INVITE dialog usage terminates by receiving BYE. Bob's
behavior in this case needs to follow the procedure in the dialog
usage draft [6]. (For handling of dialogs with multiple usages see
the dialog usage draft [6].)
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob F4 ACK Alice -> Bob
skipping to change at page 43, line 22 skipping to change at page 41, line 33
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 transits
from the Confirmed state to Terminated state. */ from the Confirmed state to Terminated state. */
F6 REFER Bob -> Alice F6 REFER Bob -> Alice
REFER sip:alice@client.atlanta.example.com SIP/2.0 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 sends the REFER on the INVITE dialog. The dialog state transits
Max-Forwards: 70 to the Mortal state at the moment Alice sends the BYE, but Bob
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 doesn't know it until he receives the BYE. A race condition
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl occurs. */
Call-ID: 3848276298220188511@atlanta.example.com
Refer-To: sip:carol@cleveland.example.org
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
CSeq: 1 REFER
Content-Length: 0
/* Alice sends a BYE, and Bob sends a REFER at the same time. F7 200 OK (BYE) Bob -> Alice
Bob sends the REFER on the INVITE dialog.
The dialog state transits to the Mortal state at the moment
Alice sends the BYE, but Bob doesn't know it until he receives
the BYE. A race condition occurs. */
F7 200 OK Bob -> Alice F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
F8 481 Call/Transaction Does Not Exist Alice -> Bob /* Alice in the Mortal state sends a 481 to the REFER. */
/* Since Alice has terminated the session, she responds with a 481
to the REFER. */ 4. IANA Considerations
This document has no actions for IANA.
5. Security Considerations
This document contains clarifications of behavior specified in RFCs
3261 [1], 3264 [2], and 3515 [4]. The security considerations of
those documents continue to apply after the application of these
clarifications.
6. Acknowledgements
The authors would like to thank Robert Sparks, Dean Willis,
Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami,
Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki,
Tadaatsu Kidokoro, Kenichi Hiragi, Dale Worley, Vijay K. Gurbani
and Anders Kristensen for their comments on this document.
7. References
7.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
7.2 Informative References
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", draft-ietf-sipping-dialogusage-06 (work in progress),
February 16, 2007.
Appendix A - BYE on the Early Dialog Appendix A - BYE on 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 recommended in the Early state, illustrating the case in which BYE in
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=1) F4 | | |<---------------| 180(To tag=A) F4 | |
| 180(1) F5 |<-----------------| | | 180(A) F5 |<-----------------| |
|<---------------| | | |<---------------| | |
| | INVITE(Fork) F6 | | | INVITE(Fork) F6 |
| |------------------------>| | |------------------------>|
| | 100 F7 | | | 100 F7 |
| BYE(1) F8 |<------------------------| | BYE(A) F8 |<------------------------|
|--------------->| BYE(1) F9 | | |--------------->| BYE(A) F9 | |
| |----------------->| | | |----------------->| |
| | 200(1) F10 | | | | 200(A,BYE) F10 | |
| 200(1) F11 |<-----------------| | | 200(A,BYE) F11 |<-----------------| |
|<---------------| 487(1) F12 | | |<---------------| 487(A,INV) F12 | |
| |<-----------------| | | |<-----------------| |
| | ACK(1) F13 | | | | ACK(A) F13 | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| | | | | |
| | 200(To-tag=2) F13 | | | 200(To tag=B) F13 |
| 200(2) F14 |<------------------------| | 200(B) F14 |<------------------------|
|<---------------| | |<---------------| |
| ACK(2) F15 | | | ACK(B) F15 | |
|--------------->| ACK(2) F16 | |--------------->| ACK(B) F16 |
| |------------------------>| | |------------------------>|
| BYE(2) F17 | | | BYE(B) F17 | |
|--------------->| BYE(2) F18 | |--------------->| BYE(B) F18 |
| |------------------------>| | |------------------------>|
| | 200(2) F19 | | | 200(B) F19 |
| 200(2) 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
487 to the ini-INVITE. According to Section 15.1.2 of RFC3261 [1], 487 to the ini-INVITE. According to Section 15.1.2 of RFC3261 [1],
it is RECOMMENDED for UAS to generate 487 to any pending requests it is RECOMMENDED for UAS to generate 487 to any pending requests
after receiving BYE. In the example, Bob sends 487 to ini-INVITE after receiving BYE. In the example, Bob sends 487 to ini-INVITE
since he receives BYE while the ini-INVITE is in pending state. since he receives 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 INVITE (a 200 from Carol)
even though she has successfully terminated the dialog with Bob. This even though she has successfully terminated the dialog with Bob.
means that, regardless of the success/failure of the BYE in the Early This means that, regardless of the success/failure of the BYE in the
state, Alice MUST be prepared for the establishment of a new dialog Early state, Alice MUST be prepared for the establishment of a new
until receiving the final response for the INVITE and terminating the dialog until receiving the final response for the INVITE and
INVITE transaction. terminating the INVITE transaction.
The choice of BYE or CANCEL in the early state must be made It is not illegal to send BYE in the Early state to terminate a
carefully. CANCEL is appropriate when the goal is to abandon specific early dialog according to the caller's intent. However, the
the call attempt entirely. BYE is appropriate when the goal is choice of BYE or CANCEL in the Early state must be made carefully.
to abandon a particular early dialog while allowing the call CANCEL is appropriate when the goal is to abandon the call attempt
to be completed with other destinations. When using either BYE entirely. BYE is appropriate when the goal is to abandon a
or CANCEL the UAC must be prepared for the possibility that particular early dialog while allowing the call to be completed with
a call may still be established to one (or more) destinations. other destinations. When using either BYE or CANCEL the UAC must be
prepared for the possibility that a call may still be established to
one (or more) destinations.
Appendix B - BYE request overlapped on re-INVITE Appendix B - BYE request overlapped on re-INVITE
UAC UAS UAC UAS
| | | |
The session has been already established The session has been already established
========================== ==========================
| F1 re-INVITE | | re-INVITE F1 |
|--------------------->| |--------------------->|
| F2 BYE | | BYE F2 |
|--------------------->| |--------------------->|
| F3 200(BYE) | | 200(BYE) F3 |
|<---------------------| |<---------------------|
| F4 INVITE(=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 where
there is no response for INVITE for some reasons. The appendix there is no response for INVITE for some reasons. The appendix
explains the behavior in such case and its rationale behind, since explains the behavior in such case and its rationale behind, since
this case is likely to cause confusion. this case 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. RFC3261 [1] details transaction layer and that of the dialog layer. RFC3261 [1] details
the Transaction layer behavior. The dialog layer behavior is the transaction layer behavior. The dialog layer behavior is
explained in this document. explained in this document. It has to be noted that these behaviors
It has to be noted that these behaviors are independent of each are independent of each other, even though the both layers change
other, even though the both layers change their states triggered by their states triggered by sending or receiving of the same SIP
sending or receiving of the same SIP messages (A dialog can be messages (A dialog can be terminated even though a transaction still
terminated even though a transaction still remain, and vice versa). remain, 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 for 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
ini-INVITE, BYE could not be sent before UAC received a provisional ini-INVITE, BYE could not be sent before UAC received a provisional
response to the request with To-tag). response to the request with To tag).
Below is a figure which illustrates UAC's dialog state and Below is a figure which illustrates UAC's dialog state and
transaction state. transaction state.
BYE INV dialog UAC UAS BYE INV dialog UAC UAS
: | | : | |
: | | : | |
| | F1 re-INVITE | | | re-INVITE F1 |
o | |--------------------->| o | |--------------------->|
| | | F2 BYE | | | | BYE F2 |
o | (Mortal) |--------------------->| o | (Mortal) |--------------------->|
| | | | F3 200(BYE) | | | | | 200(BYE) F3 |
| | | |<---------------------| | | | |<---------------------|
| | | | F4 INVITE(=F1) | | | | | INVITE F4(=F1) |
| | | |--------------------->| | | | |--------------------->|
| | | | F5 481(INV) | | | | | 481(INV) F5 |
| | | |<---------------------| | | | |<---------------------|
| | | | F6 ACK(INV) | | | | | ACK(INV) F6 |
| | | |--------------------->| | | | |--------------------->|
| | | | | | | | | |
o | o | | o | o | |
| | | | | |
o | | o | |
| | | |
For UAC, the INVITE client transaction begins at the point F1 is For 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 independent, for BYE and others. However, it should be noted that it
it is prohibited to send a request with a SDP offer while the is prohibited to send a request with a SDP offer while the previous
previous offer is in progress.) offer is in progress.)
After that, F2 triggers the BYE client transaction. At the same time,
the dialog state transits to the Mortal state and then only a BYE or After that, F2 triggers the BYE client transaction. At the same
its response can be handled. time, the dialog state transits to the Mortal state and then only a
BYE or its response 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 transited to the
Terminated state. As it is mentioned above, the dialog and the Terminated state. As it is mentioned above, the dialog and the
transaction behave independently each other. transaction behave independently each other.
Therefore the transaction handling has to be continued even though Therefore the transaction handling has to be continued even though
the dialog moved to the Terminated state. the dialog moved to the Terminated state.
Next, UAS's state is shown below. Next, UAS's state is shown below.
UAC UAS dialog INV BYE UAC UAS dialog INV BYE
| | : | | :
| | : | | :
| F1 re-INVITE | | | re-INVITE F1 | |
|-------------->x | | |-------------->x | |
| F2 BYE | | | BYE F2 | |
|--------------------->| | o |--------------------->| | o
| F3 200(BYE) | (Mortal) | | 200(BYE) F3 | (Mortal) |
|<---------------------| | |<-Start TimerJ |<---------------------| | |<-Start TimerJ
| F4 INVITE(=F1) | | | | INVITE F4(=F1) | | |
|--------------------->| | o | |--------------------->| | o |
| F5 4xx(INV) | o | o | 4xx/5xx(INV) F5 | o | o
|<---------------------| | |<---------------------| |
| F6 ACK(INV) | | | ACK(INV) F6 | |
|--------------------->| |<-Start TimerI |--------------------->| |<-Start TimerI
| | | | | |
| | | | | |
| | o | | o
| | | |
For UAS, it can be regarded that F1 packet is lost or delayed (Here For UAS, it can be regarded that F1 packet is lost or delayed (Here
the behavior is explained for the case UAS receives F2 BYE before F1 the behavior is explained for the case UAS receives F2 BYE before F1
INVITE). Therefore, F2 triggers the BYE transaction for UAS, and INVITE). Therefore, F2 triggers the BYE transaction for UAS, and
simultaneously the dialog moves to the Mortal state. simultaneously the dialog moves to the Mortal state.
Then, upon the reception of F4 the INVITE server transaction begins. Then, upon the reception of F4 the INVITE server transaction begins.
(It is allowed to start the INVITE server transaction in the Mortal (It is allowed to start the INVITE server transaction in the Mortal
state. The INVITE server transaction begins to handle received SIP state. The INVITE server transaction begins to handle received SIP
request regardless of the dialog state.) request regardless of the dialog state.)
UAS's TU sends an appropriate error response for F4 INVITE, either UAS's TU sends an appropriate error response for F4 INVITE, either
481 (because the TU knows that the dialog which matches to the 481 (because the TU knows that the dialog which matches to the
INVITE is in the Terminated state) or 500 (because the re-sent F4 INVITE is in the Terminated state) or 500 (because the re-sent F4 has
has an out-of-order CSeq). an out-of-order CSeq).
(It is mentioned above that F4 (and F1) INVITE is a mid-dialog (It is mentioned above that F4 (and F1) INVITE is a mid-dialog
request. Mid-dialog requests have a To-tag. It should be noted that request. Mid-dialog requests have a To tag. It should be noted that
UAS's TU does not begin a new dialog upon the reception of INVITE UAS's TU does not begin a new dialog upon the reception of INVITE
with a To-tag.) with a To tag.)
Appendix C - UA's behaviour for CANCEL Appendix C - UA's behavior for CANCEL
This section explains the CANCEL and the Expires header behaviors This section explains the CANCEL behaviors which indirectly involve
which indirectly involve in the dialog state transition in the Early in the dialog state transition in the Early state. CANCEL does not
state. CANCEL does not have any influence on UAC's dialog state. have any influence on UAC's dialog state. However, the request has
However, the request has indirect influence on the dialog state indirect influence on the dialog state transition because it has a
transition because it has a significant effect on ini-INVITE. significant effect on ini-INVITE. For UAS the CANCEL request has
Similarly, the Expires header does not have direct influence on the more direct effects on the dialog than the sending of CANCEL by UAC,
dialog state transition, but it indirectly affect the state
transition because its expiration triggers the sending of CANCEL.
For UAS the CANCEL request and the Expires header timeout have more
direct effects on the dialog than the sending of CANCEL by UAC,
because they can be a trigger to send the 487 response. Figure 3 because they 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 Figure 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 signals, 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 virtually handled 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. Below, UAS's flow is explained.
+------------+ +-------------+
| Proceeding |----+ | Preparative |---+
+------------+ | +-------------+ |
: | 1xx(s) | : | 1xx(s) |
: V | : V |
: +-------+ | 2xx(s) : +-------+ | 2xx(s)
: | Early |-----+------+ : | Early |-----+------+
: +-------+ | : +-------+ |
: : V : : V
: : +-----------+ : : +-----------+
: : | Confirmed |<... : : | Confirmed |<...
:.....: +-----------+ : :.....: +-----------+ :
: | : : : | : :
skipping to change at page 48, line 51 skipping to change at page 47, line 48
| |
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 UAS depending on the state when it
receives CANCEL. receives CANCEL.
One is when UAS receives CANCEL in the Proceeding and Early states.
In this case the UAS immediately sends 487 for the INVITE, and the One is when UAS receives CANCEL in the Early states. In this case
dialog transits to the Terminated state. the UAS immediately sends 487 for the INVITE, and the dialog transits
to the Terminated state.
The other is the case in which UAS receives CANCEL in the Confirmed The other is the case in which UAS receives CANCEL in the Confirmed
state. In this case the dialog state transition does not occur state. In this case the dialog state transition does not occur
because UAS has already sent a final response to the INVITE to which because UAS has already sent a final response to the INVITE to which
the CANCEL is targeted. the CANCEL is targeted.
(Note that, because of UAC's behavior, a UAS that receives a CANCEL (Note that, because of UAC's behavior, a UAS that receives a CANCEL
in the Confirmed state can expect to receive a BYE immediately and in the Confirmed state can expect to receive a BYE immediately and
move to the Terminated state. However, the UAS's state does not move to the Terminated state. However, the UAS's state does not
transit until it actually receives BYE.) transit until it actually receives BYE.)
Appendix D - Notes on the request in Mortal state Appendix D - Notes on the request in Mortal state
This section describes UA's behavior in the Mortal state which need This section describes UA's behavior in the Mortal state which needs
careful attention. careful attention. Note that every transaction completes independent
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, BYE can be accepted, and the other messages in
the INVITE dialog usage are responded with an error. However, the INVITE dialog usage are responded with an error. However,
sending of ACK and the authentication procedure for BYE are sending of ACK and the authentication procedure for BYE are conducted
conducted in this state. in this state. (The handling of messages concerning multiple dialog
(The handling of messages concerning multiple dialog usages is out of usages is out of the scope of this document. Refer to [6] for
the scope of this document. Refer to [8] for further information.) 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 TU. However, the ACK for 2xx and the ACK for error responses are
both a part of the INVITE transaction, even though their hadling both a part of the INVITE transaction, even though their handling
differs (Section 17.1.1.1, RFC3261 [1]). differs (Section 17.1.1.1, RFC3261 [1]).
Therefore, the INVITE transaction is completed by the three-way Therefore, the INVITE transaction is completed by the three-way
handshake, which includes ACK, even in the Mortal state. handshake, which includes ACK, even in the Mortal state.
Considering actual implementation, UA needs to keep the INVITE dialog Considering actual implementation, UA needs to keep the INVITE dialog
usage until the Mortal state finishes, so that it is able to ACK for usage until the Mortal state finishes, so that it is able to ACK for
a 2xx response in the Mortal state. a 2xx response in the Mortal state.
If a 2xx to INVITE is received in the Mortal state, the duration of If a 2xx to INVITE is received in the Mortal state, the duration of
the INVITE dialog usage will be extended to 64*T1 seconds after the the INVITE dialog usage will be extended to 64*T1 seconds after the
receiving of the 2xx, to cope with the possible 2xx retransmission. receiving of the 2xx, to cope with the possible 2xx retransmission.
(The duration of the 2xx retransmission is 64*T1, so the UA need to (The duration of the 2xx retransmission is 64*T1, so the UA need to
be prepared to handle the retransmission for this duration.) be prepared to handle the retransmission for this duration.)
However, the UA shall send error response to other requests, since However, the UA shall send error response to other requests, since
the INVITE dialog usage in the Mortal state is kept only for the the INVITE dialog usage in the Mortal state is kept only for the
skipping to change at page 50, line 5 skipping to change at page 49, line 5
be prepared to handle the retransmission for this duration.) be prepared to handle the retransmission for this duration.)
However, the UA shall send error response to other requests, since However, the UA shall send error response to other requests, since
the INVITE dialog usage in the Mortal state is kept only for the the INVITE dialog usage in the Mortal state is kept only for the
sending of ACK for 2xx. sending of ACK for 2xx.
BYE authentication procedure shall be processed in the Mortal state. BYE authentication procedure shall be processed in the Mortal state.
When authentication is requested by 401 or 407 response, UAC resends When authentication is requested by 401 or 407 response, UAC resends
BYE with an appropriate credentials. Also UAS handles the BYE with an appropriate credentials. Also UAS handles the
retransmission of the BYE which it requested authentication itself. retransmission of the BYE which it requested authentication itself.
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 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 with a different To tag to
ini-INVITE (See Section 11.2, 13.1, 13.2.2.4, 16.7, 19.3 etc. of ini-INVITE (See Section 12.1, 13.1, 13.2.2.4, 16.7, 19.3, etc. of RFC
RFC3261). If the TU receives multiple 1xx responses with a different 3261). If the TU receives multiple 1xx responses with a different
To tag, the original DSM forks and a new DSM instance is created. As To tag, the original DSM forks and a new DSM instance is created. As
a consequence multiple early dialogs are generated. 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 transits to the Confirmed state. No DSM state transition
occurs for the other early dialogs, and their sessions (early media) occurs for the other early dialogs, and their sessions (early media)
terminate. The TU of the UAC terminates the INVITE transaction after terminate. The TU of the UAC terminates the INVITE transaction after
64*T1 seconds starting at the point of receiving the first 2xx 64*T1 seconds starting at the point of receiving the first 2xx
response. Moreover, all mortal early dialog which do not transit to response. Moreover, all mortal early dialogs which do not transit to
the Established state are terminated (See Section 13.2.2.4 of the Established state are terminated (See Section 13.2.2.4 of
RFC3261). RFC 3261). By "mortal early dialog" we mean any 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 a
different To tag are received, and then a 200 response for one of the different To tag are received, and then a 200 response for one of the
early dialogs (dialog A) is received. Dot lines (..) in sequences early dialogs (dialog A) is received. Dot lines (..) in sequences
is auxiliary line to represent the influence on dialog B. are auxiliary lines to represent the influence on dialog B.
UAC UAC
dialog(A) | F1 INVITE dialog(A) | INVITE F1
Pre o |-------------------------> Pre o |------------------------->
| | F2 100 | | 100 F2
| |<------------------------- | |<-------------------------
| | F3 180(To-tag=A) | | 180(To tag=A) F3
Ear | |<------------------------- Ear | |<-------------------------
dialog(B) | | dialog(B) | |
forked new DSM | | F4 180(To-tag=B) forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<------------------------- Ear o..........|..........|<-------------------------
| | | | | |
| | | F5 200(To-tag=A) | | | 200(A) F5
terminate->|.....Mora |..........|<------------------------- terminate->|.....Mora |..........|<-------------------------
early | | ^ | F6 ACK(To-tag=A) early | | ^ | ACK(A) F6
media | Est | | |-------------------------> media | Est | | |------------------------->
| | | | | | | |
| | |64*T1 | | | |64*T1 |
| | |(13.2.2.4 of RFC3261) | | |(13.2.2.4 of RFC3261)
| | | | | | | |
| | | | | | | |
| | | |
| | 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
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 reception of a provisional response with a different To tag
(F4 180(To-tag=B)), DSM forks and the early dialog B is generated. (F4 180(To tag=B)), DSM forks and the early dialog B is generated.
After 64*T1 seconds after the dialog A receives 200 OK response, the After 64*T1 seconds after the dialog A receives 200 OK response, the
dialog B, which does not transit to the Established state, dialog B, which does not transit to the Established state,
terminates. 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 a different To tag 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 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 64*T1 INVITE
transaction timeout, its DSM state transits to the Confirmed state. transaction timeout, its DSM state transits to the Confirmed state.
However, the seesion 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 should send an ACK and, early dialog receives a 2xx response, the TU send an ACK and,
immediately after, BYE to terminate DSM. immediately after, the TU usually sends a BYE to terminate DSM. (In
special cases, e.g. a UA intends to establish multiple 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
typically useful action and not the only valid one. Some devices typically useful action and not the only valid one. Some devices
might want to handle things differently. For instance, a conference might want to handle things differently. For instance, a conference
focus that has sent out an invite that forks may want to accept and focus that has sent out an INVITE that forks may want to accept and
mix all the dialogs it gets. mix all the dialogs it gets. In that case, no early dialog is
treated as mortal.
Below is an example sequence in which two 180 responses with a Below is an example sequence in which two 180 responses with a
different To tag are received and then a 200 response for each of the different To tag are received and then a 200 response for each of the
early dialogs is received. early dialogs is received.
UAC UAC
dialog(A) | F1 INVITE dialog(A) | INVITE F1
Pre o |-----------------------> Pre o |----------------------->
| | F2 100 | | 100 F2
| |<----------------------- | |<-----------------------
| | F3 180(To-tag=A) | | 180(To tag=A) F3
dialog(B) Ear | |<----------------------- dialog(B) Ear | |<-----------------------
forked new DSM | | F4 180(To-tag=B) forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<----------------------- Ear o..........|..........|<-----------------------
| | | | | |
| | | F5 200(To-tag=A) | | | 200(A) F5
terminate->|.....Mora |..........|<----------------------- terminate->|.....Mora |..........|<-----------------------
early | | ^ | F6 ACK(To-tag=A) early | | ^ | ACK(A) F6
media | Est | | |-----------------------> media | Est | | |----------------------->
| | |64*T1 | | | |64*T1 |
| | | | F7 200(To-tag=B) | | | | 200(B) F7
Mora |..........|.|........|<----------------------- Mora |..........|.|........|<-----------------------
| | | | F8 ACK(To-tag=B) | | | | ACK(B) F8
Est |..........|.|........|-----------------------> Est |..........|.|........|----------------------->
| | | | F9 BYE(To-tag=B) | | | | BYE(B) F9
Mort |..........|.|........|-----------------------> Mort |..........|.|........|----------------------->
^ | | | | F10 200(To-tag=B) ^ | | | | 200(B) F10
| | | | |<----------------------- | | | | |<-----------------------
|Timer K | | | |Timer K | | |
| | | V | | | | V |
| | | (terminate INVITE transaction) | | | (terminate INVITE transaction)
V | | | V | | |
Morg o | | Morg o | |
| | | |
Finally, when a TU receives multiple 200 responses with a different Figure 5. Receiving 1xx and 2xx responses with different To tags
To tag before 64*T1 timeout of the INVITE transaction, even though
a TU does not receive provisional response, the TU needs to respond Below is an example sequence when a TU receives multiple 200
to the 2xx responses (See Section 13.2.2.4 of RFC3261). In that responses with a different To tag before 64*T1 timeout of the INVITE
case, the DSM state is forked at the Confirmed state, and then the transaction, even though a TU does not receive provisional response,
TU sends an ACK for the 2xx response and, immediately after, BYE. the TU needs to respond to the 2xx responses (See Section 13.2.2.4 of
RFC 3261). In that case, the DSM state is forked at the Confirmed
state, and then the TU sends an ACK for the 2xx response and,
immediately after, the TU usually sends a BYE. (In special cases,
e.g. a UA intends to establish multiple dialogs, the TU may not send
the BYE.)
UAC UAC
dialog(A) | F1 INVITE dialog(A) | INVITE F1
Pre o |-----------------------> Pre o |----------------------->
| | F2 100 | | 100 F2
| |<----------------------- | |<-----------------------
| | F3 180(To-tag=A) | | 180(To tag=A) F3
Ear | |<----------------------- Ear | |<-----------------------
| | | |
| | F4 200(To-tag=A) | | 200(A) F4
Mora |..........|<----------------------- Mora |..........|<-----------------------
| ^ | F5 ACK(To-tag=A) | ^ | ACK(A) F5
Est | | |-----------------------> Est | | |----------------------->
| | | | | |
dialog(B) | |64*T1 | dialog(B) | |64*T1 |
forked new DSM | | | F6 200(To-tag=B) forked new DSM | | | 200(To tag=B) F6
Mora o..........|.|........|<----------------------- Mora o..........|.|........|<-----------------------
| | | | F7 ACK(To-tag=B) | | | | ACK(B) F7
Est |..........|.|........|-----------------------> Est |..........|.|........|----------------------->
| | | | F8 BYE(To-tag=B) | | | | BYE(B) F8
Mort |..........|.|........|-----------------------> Mort |..........|.|........|----------------------->
^ | | | | F9 200(To-tag=B) ^ | | | | 200(B) F9
| | | | |<----------------------- | | | | |<-----------------------
| | | V | | | | V |
|Timer K | (terminate INVITE transaction) |Timer K | (terminate INVITE transaction)
| | | | | | | |
V | | | V | | |
Morg o | | Morg o | |
| | | |
References Figure 6. Receiving 2xx responses with different To tags
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, April 2002.
[3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Below is an example sequence in which the option tag 100rel (RFC 3262
Summers, "Session Initiation Protocol (SIP) Public Switched [5]) is required by a 180.
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
2003.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer If a forking proxy supports 100rel, it transparently transmits to the
Method", RFC 3515, April 2003. UAC a provisional response which contains a Require header with the
value of 100rel. Upon receiving a provisional response with 100rel,
the UAC establishes the early dialog (B) and send PRACK. (Here, also
every transaction completes independent of others".)
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional As Figure. 4, the early dialog (B) terminates at the same time the
Responses in the Session Initiation Protocol (SIP)", RFC 3262, INVITE transaction terminates. In the case where a proxy does not
June 2002. support 100rel, the provisional response will be handled in the usual
way (a provisional response with 100rel is discarded by the proxy,
not to be transmitted to the UAC).
[7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated UAC
Dialog Event Package for the Session Initiation Protocol (SIP)", dialog(A) | INVITE F1
RFC 4235, November 2005. Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
| | 200(A) F4
Mora |..........|<-------------------------
| ^ | ACK(A) F5
Est | | |------------------------->
dialog(B) | | |
forked new DSM | | | 180(To tag=B) w/100rel F6
Ear o..........|.|........|<-------------------------
| | | | PRACK(B) F7
| | | |------------------------->
| | | | 200(B,PRACK) F8
| | | |<-------------------------
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261)
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
[8] Sparks, R., "Multiple Dialog Usages in the Session Initiation Figure 7. Receiving 1xx responses with different To tags (with 100rel)
Protocol", draft-ietf-sipping-dialogusage-06 (work in progress),
Febrary 20, 2007.
Author's Addresses Author's Addresses
All listed authors actively contributed large amounts of text to this All listed authors actively contributed large amounts of text to this
document. document.
Miki Hasebe Miki Hasebe
NTT-east Corporation NTT-east Corporation
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
skipping to change at page 54, line 26 skipping to change at page 54, line 5
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
USA USA
Email: pkyzivat@cisco.com Email: pkyzivat@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
The authors would like to thank Robert Sparks, Dean Willis, Funding for the RFC Editor function is provided by the IETF
Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Administrative Support Activity (IASA).
Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki,
Tadaatsu Kidokoro, Kenichi Hiragi and Dale Worley, for their comments
on this document.
 End of changes. 274 change blocks. 
687 lines changed or deleted 690 lines changed or added

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