Internet Engineering Task Force M. HASEBE
Internet-Draft NTT-East
Expiration: Dec 19th, 2006 J. KOSHIKO
NTT-East
Y. SUZUKI
NTT-East
T. YOSHIKAWA
NTT-East
P. Kyzivat
Cisco Systems, Inc.
Jun 19th, 2006
Examples call flow in race condition on Session Initiation Protocol
draft-hasebe-sipping-race-examples-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document gives examples of Session Initiation Protocol (SIP)
call flows in race condition. Call flows in race conditions are
confusing and this document shows the best practices to handle
them. The elements in these call flows include SIP User Agents
and SIP Proxies. Call flow diagrams and message details are shown.
Hasebe [Page 1]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 General Assumptions. . . . . . . . . . . . . . . . . . . . . 3
1.2 Legend for Message Flows . . . . . . . . . . . . . . . . . . 3
1.3 SIP Protocol Assumptions . . . . . . . . . . . . . . . . . . 4
2. The Dialog State Machine(for Race Condition) . . . . . . . . . . 4
3. Race condition . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Receiving message in the Moratorium State. . . . . . . . . . 10
3.1.1 Receiving Initial INVITE retransmission(Trying state). . 10
3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . . 13
3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . . 16
3.1.4 Receiving re-INVITE (Established state)(case 1). . . . . 18
3.1.5 Receiving re-INVITE (Established state)(case 2). . . . . 22
3.1.6 Receiving BYE (Established state). . . . . . . . . . . . 26
3.2 Receiving message in the Mortal State. . . . . . . . . . . . 29
3.2.1 Receiving BYE(Established state) . . . . . . . . . . . . 29
3.2.2 Receiving re-INVITE(Established state) . . . . . . . . . 32
3.2.3 Receiving 200OK for re-INVITE(Established state) . . . . 34
3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . . 37
3.3 other race condition . . . . . . . . . . . . . . . . . . . . 39
3.3.1 re-INVITE crossover. . . . . . . . . . . . . . . . . . . 39
3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . . 43
3.3.3 Receiving REFER(Established state) . . . . . . . . . . . 47
Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . . 50
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 52
Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . . 53
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 53
Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Overview
The call flows shown in this document were developed in the design of
a SIP IP communications network. These examples are of race condition,
which stems from the state transition of the dialog mainly established
by INVITE.
In various situations which may happen when SIP is implemented,
especially, when a situation which serves as a norm of implementing in
RFC is not illustrated, by showing operation of a terminal or a server
as an example, it will be a help to a SIP implementors.
This document clarifies SIP UA behaviors when messages cross each other
as race conditions. By clarifying operation under race conditions,
different interpretations between implementations are avoided
and interoperability is expected to be promoted.
Hasebe [Page 2]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
It is the hope of the authors that this document will be useful for
SIP implementors, designers, and protocol researchers and will help
them achieve the goal of a standard implementation of RFC 3261 [1].
These call flows are based on the current version 2.0 of SIP in RFC
3261 [1] with SDP usage described in RFC 3264 [2].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [4].
1.1 General Assumptions
A number of architecture, network, and protocol assumptions underlie
the call flows in this document. Note that these assumptions are not
requirements. They are outlined in this section so that they may be
taken into consideration and help in understanding of the call
flow examples.
These flows do not assume specific underlying transport protocols
such as TCP, TLS, and UDP. See the discussion in RFC 3261 for details
on the transport issues for SIP.
1.2 Legend for Message Flows
Dashed lines (---) and slash lines (/,\) represent signaling messages
that are mandatory to the call scenario.(X) represents crossover of
signaling messages. Arrow indicate the direction of message flow.
Double dashed lines (===) represent media paths between network
elements.
Messages with parentheses around their name represent optional
messages.
Messages are identified in the Figures as F1, F2, etc. These numbers
are used for references to the message details that follow the Figure.
Comments in the message details are shown in the following form:
/* Comments. */
1.3 SIP Protocol Assumptions
This document does not prescribe the flows precisely as they are
shown, but rather illustrates the principles for best practice.
They are best practice usages (orderings, syntax, selection of
features for the purpose, or handling of error) of SIP methods,
Hasebe [Page 3]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
headers and parameters. NOTE: The flows in this document must not
be copied as they are by implementors because additional
characteristics were incorporated into the document for ease of
explanation. To sum up, the procedures described in this document
represent well-reviewed examples of SIP usage, which are best common
practice according to IETF consensus.
For simplicity in reading and editing the document, there are a
number of differences between some of the examples and actual SIP
messages. Examples are: Call-IDs are often repeated; CSeq often
begins, at 1; header fields are usually shown in the same order;
usually only the minimum required header field set is shown; and
and Accept, Allow, etc are not shown.
Actors:
Element Display Name URI IP Address
------- ------------ --- ----------
User Agent Alice sip:alice@atlanta.example.com 192.0.2.101
User Agent Bob sip:bob@biloxi.example.com 192.0.2.201
User Agent Carol sip:carol@chicago.example.com 192.0.2.202
Proxy Server ss.atlanta.example.com 192.0.2.111
2. The Dialog State Machine(for Race Condition)
Race conditions are generated when the dialog state of the receiving
side differs from the dialog state of the sending side.
For instance, a race condition occurs when UAC (User Agent Client)
sends a CANCEL on Early state while UAS (User Agent Server) is
transitting from Early state to Confirmed state by sending a
200 OK to ini-INVITE.
The dialog state machine (DSM) is represented as follows to help
the understanding of UA's behavior in such race conditions.
The DSM clarifies UA's behavior by subdividing some internal
states showed on FSM (Finate State Machine) for dialog state of the
dialog-package[7], without changing the states of the dialog,
"early", "confirmed", and "terminated" shown in RFC3261.
Preparative state is put before the Ealy state, which includes
Trying and Proceeding. Moreover, Confirmed state is devided into
two sub-states, Moratorium and Established. In addition,
Terminated state is subdivided into two states, Mortal and Morgue.
Below represent the DSM for UAC and UAS respectively.
Hasebe [Page 4]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
+-----------------------------------------------+
| Preparative |
| +----------+ +--------------+ |
| | | 100 | |-----C-+
| | Trying |---------->| Proceeding | | | 100
| | | | |<----C-+
| +----------+ +--------------+ |
| |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| V |
| +------------------+ |
| 3xx-6xx | |--+ 1xx-tag |
+<--------| Early | | w/new tag |
| | |<-+ (new DSM |
| +------------------+ instance |
| | | created) |
| | BYE | 2xx |
| | +-------------+--+
| | |
+-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | |
| | +<----C---------| | |
| | | | BYE | | |
| | V | | V |
| | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+ 2xx
| | | Mortal | | | BYE(r)| | Moratorium| | | w/new tag
| | | |<--C-+ | | |<-C-+ (new DSM
| | +------------+ | | +-----------+ | instance
| | | | | | | created)
| | | Timeout | | | ACK |
| | | (Timer K) | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | | |
| | Morgue | | | |Established| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(r): indicates only reception is allowed.
Where (r) is not indicated, a response means receive, a request
means send.
figure 1. Dialog State Machine for UAC
Hasebe [Page 5]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Figure 1 shows a DSM for UAC.
UAC MAY send a BYE in Early state. However, this behavior is
NOT RECOMMENDED. The dialog which is to be terminated by BYE in
Early state. Early state is the one that exists between the UAC
and the UAS that constitutes the early dialog with each other.
In Early state, it is possible that UAC receives responses from
other UASs in forking. Therefore, until the UAC receives the final
response and terminates the INVITE transaction, UAC MUST be prepared
to establish a dialog by receiving a new response even though it had
sent a BYE and terminated the dialog (see Appendix A).
+-----------------------------------------------+
| Preparative |
| +----------+ +--------------+ |
| | | 100 | |-----C-+
| | Trying |---------->| Proceeding | | | 100
| | | | |<----C-+
| +----------+ +--------------+ |
| |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| V |
| +------------------+ |
| 3xx-6xx | |--+ |
+<--------| Early | | 1xx-tag |
| | |<-+ |
| +------------------+ |
| | | |
| | BYE or | 2xx |
| | CANCEL +-------------+--+
| | |
+-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | |
| | +<----C---------| | |
| | | | BYE(sr) | | |
| | V | | V |
| | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+
| | | Mortal | | | BYE | | Moratorium| | | 2xx
| | | |<--C-+ | | |<-C-+
| | +------------+ | | +-----------+ |
| | | | | | |
| | | Timeout | | | ACK |
| | | (Timer J) | | | |
| | | or 487 | | | |
Hasebe [Page 6]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | | |
| | Morgue | | | |Established| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(sr): indicates sending reception is allowed.
Where (sr) is not indicated, a response means send,
a request means receive.
figure 2. Dialog State Machine for UAS
Figure 2 shows a DSM for UAS.
The DSM for UAS includes state transition caused by BYE.
Originally, the correct description is that a CANCEL request does
not cause a dialog state transition, but the UAS terminates the
dialog and triggers the dialog transition by sending 487 immediately
after the reception of the CANCEL.
In Figure 2, an arrow that indicates the dialog state transition by
a CANCEL request is included, since a 487 response is triggered by
the CANCEL and assuming that there is little delay in sending the
487 after receiving the CANCEL.
However, note that the reception of a CANCEL request in Confirmed
state, unlike Early state, does not influence the UAS'dialog state.
(Section 3.1.2 shows that actual state transition to Terminate state
is triggered by BYE instead of CANCEL, even though the reception of
a CANCEL request in Confirmed state implies the termination of the
dialog by the subsequent reception of a BYE request from the UAC)
The following is UA's behaviors in each state.
Preparative(Pre): Preparative is a state until the Early dialog
is established by sending and receiving a provisional
response with To-tag after an ini-INVITE is sent and received.
The dialog has not existed yet in Preparative state. The
dialog state transit from the Preparative to the Early by
sending or receiving a provisional response with To-tag.
Moreover, the dialog state transit to Moratorium which is a
substate of Confirmed state, if UA sends or receives a 2xx
response. In addition, the dialog state transit to Morgue
state which is a substate of Terminated state, if UA sends
or receives a 3xx-6xx response. Sending an ACK to a 3xx-6xx
response and retransmissions of 3xx-6xx are not expressed on
this DSM because they are sent by INVITE transactions.
Trying(Try): Trying is substate of Preparative and inherits the
Hasebe [Page 7]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
behavior of Preparative. Trying is started by sending and
receiving an ini-INVITE. It transits to Proceeding by sending
or receiving a 1xx (usually 100 trying) without To-tag.
UAC may retransmit an INVITE on transaction layer and UAC
must not send a CANCEL request. UAS may send a 1xx-6xx
response.
Proceeding(Pro): Proceeding is substate of Preparative and inherits
the behavior of Preparative. Dialog becomes Proceeding state
if dialogs in Trying state send or receive a 1xx without
To-tag (usually 100 trying). UAC may send a CANCEL, and UAS
may send a 1xx-6xx response in Proceeding state.
Early(Ear): The early dialog is established by sending or receiving
a provisional response with To-tag. The early dialog exists
though the dialog has not existed in this state yet. The
dialog state transits from Early to Moratorium, substate of
Confirmed by sending or receiving a 2xx response. In addition,
the dialog state transits to the Morgue subdivided internally
in the Terminated by sending and receiving a 3xx-6xx response.
Sending an ACK to a 3xx-6xx response and retransmissions of
3xx-6xx are not expressed on this DSM because they are sent
by INVITE transactions. UAC may send CANCEL in Early
state. UAC may send BYE (although it is not recommended.)
UAS may send a 1xx-6xx response.
Sending or reception of a CANCEL request does not have direct
influences on dialog state. For UAC, its dialog state is changed
by the reception of the final response to INVITE, not the
response to CANCEL. For UAS, its dialog state is changed by
sending a 487 response to INVITE after responding to CANCEL.
However, the state transition by CANCEL is described, since,
for UAS, a 487 response is triggered by the reception of CANCEL.
Confirmed(Con): Sending or receiving 2xx final response
establishes a dialog. Dialog exists in this state. BYE message
changes state from Confirmed to Mortal, substate of Terminated.
Confirmed has two substates, Moratorium and Established,
they are different in messages UA are allowed to send.
Moratorium(Mora): Moratorium is a substate of Confirmed and
inherits the behavior of Confirmed. Moratorium transits to
Established by sending or receiving an ACK request. UAC may
send an ACK and UAS may send a 2xx final response.
Established(Est): Established is a substate of Confirmed and
inherits the behavior of Confirmed. Both caller and callee may
send various messages which influences a dialog. Caller
supports the transmission of ACK to a retransmission of a 2xx
response to an ini-INVITE.
Hasebe [Page 8]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Terminated(Ter): Terminated state is devided into two substates,
Mortal and Morgue, to consider a behavior when a dialog is
being terminated. In this state, UAs hold information about
the dialog which is being terminated. Confirmed transits to
Mortal, a substate of Terminated, by sending or receiving a
BYE request.
Mortal(Mort): Caller and callee becomes Mortal state by sending or
receiving a BYE. UA MUST NOT send any new requests since there
is no dialog. The new requests here include an ACK for a 200
response to an INVITE request. (ACK for error responses is not
included since it is not a new request generated by TU, but is
sent within the INVITE transaction handling.)
It may be anticipated that the retransmission of 200 from the
UAS may not stop because the UAC does not send ACK.
However, it is considered that the ACK is not required, since
the TU of the UAS understands that its state moved to Mortal
state by the reception of BYE and SHOULD stop retransmitting
the ACK. (TU retransmits the 200 response, not INVITE server
transaction)
No problem is expected even though the ACK for the 200 response
is sent in Mortal state to quench the retransmission of the 200.
In this state, only a BYE or its response can be handled, and
no other messages can be received. This is because the use case
is taken into consideration that a BYE message are sent by both
a caller and a callee to exchange reports about the session
when it is being terminated.
Therefore, UA possesses dialog information for internal process
but dialog shouldn't exist outwardly. UA stops managing dialog
state and changes it to Morgue state, when the BYE transaction
is done by timer. (Timer F or Timer K for UAC. Timer J for UAS.)
Morgue(Morg): Dialog doesn't exist any more in this state. Sending
or receiving a signal which influences a dialog is not
performed. (It is literally terminated.)
3. Race condition
This section details race condition between two SIP User
Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com)
and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or
SIP-enabled devices.
Only significant signals are illustrated. Dialog state transitions
caused by sending and reception of SIP messages as well as '*race*',
which indicates race condition, are shown. (For abbreviations for the
dialog state transitions, refer to Chapter 2)
'*race*'indicates the moment when a race condition occurs.
Examples of such race conditions are shown below.
Hasebe [Page 9]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
3.1 Receiving message in the Moratorium State
This section shows some examples of call flow in race condition
when receiving the message from other states in the Moratorium state.
3.1.1 Receiving Initial INVITE retransmission(Trying state)
in Moratorium state
State Alice Bob State
| |
| ini-INVITE F1 |
Pre |------------------------------->| Pre
| 180 F2(Packet loss) |
| X<---------------------| Ear
| |
| ini-INVITE F4 200 F3 |
|------------- --------------| Mora
| \ / |
| X |
| / \ |
Mora |<------------ ------------->| *race*
| ACK F5 |
Est |------------------------------->| Est
| |
| |
This scenario illustrates the race condition which occurs when UAS
receives a Preparative message in Moratorium state. All provisional
responses to the initial INVITE(ini-INVITE F1) are lost, 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 terminate an
INVITE server transaction. (RFC3261, 13.3.1.4)
However, it is reported that terminating an INVITE server transaction
by 200OK is a SIP bug. (http://bugs.sipit.net/, #769)
Therefore, the INVITE server transaction is not terminated at F3, and
the F4 MUST be properly handled as a retransmission.
(UAs that do not deal with this bug still need to recognize the
retransmission relying on its From-tag and Call-ID, even though it
does not match the transaction.
Message Details
F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Hasebe [Page 10]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
/* A 180 response is lost and does not reach Alice. */
F3 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
Hasebe [Page 11]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* According to 13.3.1.4 of RFC3261, an INVITE server transaction
is terminated at this point. However, this has been reported as
a SIP bug, and UAS MUST correctly recognize the ini-INVITE (F4) as
a retransmission. */
F4 INVITE(retransmission) Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* When UAs do not deal with the bug reported in #769 (an INVITE
server transaction is terminated by 200 to INVITE), this
request does not match the transaction as well as the dialog
since it does not have a To-tag.
However, Bob have to recognize the retransmitted INVITE correctly,
without treating it as the new INVITE. */
F5 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
Hasebe [Page 12]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Content-Length: 0
3.1.2 Receiving CANCEL(Proceeding or Early state)
in Moratorium state
State Alice Bob State
| |
| INVITE F1 |
Pre |----------------------->| Pre
| 180 Ringing F2 |
Ear |<-----------------------| Ear
| |
|CANCEL F3 200 OK F4 |
|--------- ----------| Mora
| \ / |
| X |
| / \ |
Mora |<-------- --------->| *race*
| |
| ACK F6 200 F5 |
Est |--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->| Est
| |
| Both Way RTP Media |
|<======================>|
| BYE F7 |
Mort |----------------------->| Mort
| 200 F8 |
|<-----------------------| Morg
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition which occurs when UAS
receives an Early message (CANCEL) in Moratorium state. Alice sends
a CANCEL and Bob sends a 200 OK response to the initial INVITE
message at the same time. As described in the previous section,
according to RFC3261 an INVITE server transaction is terminated by
a 200 response, but this has been reported as a bug in #769.
This section describes a case in which an INVITE server transaction
is not terminated by a BYE response to the request. In this case,
Hasebe [Page 13]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
there is an INVITE transaction which matches a CANCEL request, so a
200 response is sent for the request. This 200 response simply means
that the next hop received the CANCEL request.
(Successful CANCEL (200) does not mean an INVITE failure)
When UAS does not deal with #769, UAC MAY receive a 481 response for
CANCEL since there is no transaction which matches the CANCEL request.
This 481 simply means that there is no matching INVITE server
transaction and CANCEL is not sent to the next hop.
Regardless of the success/failure of the CANCEL, Alice checks the
final response to INVITE, and if she receives 200 to the INVITE
request she immediately sends a BYE and terminates a dialog.
(RFC3261, 15)
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 CANCEL Alice -> Bob
CANCEL sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch= z9hG4bK74bf9
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 CANCEL
Content-Length: 0
/* Alice sends a CANCEL on the Early state. */
F4 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: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
Hasebe [Page 14]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Alice receives a 200 to INVITE(F1) on the Moratorium state. */
F5 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 CANCEL
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
/* A 200 to CANCEL simply means that the CANCEL was received.
The 200 response is sent, since this document deals with the
bug reported in #769. When an INVITE server transaction is
terminated as the procedure stated in RFC3261, UAC MAY receive
a 481 response instead of a 200. */
F6 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
/* INVITE is successful, and a CANCEL becomes invalid. RTP streams
are established. However, the next BYE request immediately cleans
up the dialog just established. */
F7 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
Hasebe [Page 15]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
CSeq: 2 BYE
Content-Length: 0
F8 200 OK 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
3.1.3 Receiving BYE (Early state)
in Moratorium state
State Alice Bob State
| |
| ini-INVITE F1 |
Pre |------------------------------->| Pre
| 180 F2 |
Ear |<-------------------------------| Ear
| |
| BYE F4 200(INVITE) F3|
Mort |------------- --------------| Mora
| \ / |
| X |
| / \ |
|<------------ ------------->| Mort & *race*
| |
| 200(BYE) F5 |
|<-------------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition which occurs when
UAS receives an Early message (BYE) in Moratorium state.
Alice sends a BYE on the early dialog and Bob sends a 200 OK
response to the initial INVITE message at the same time. Bob
receives a BYE on the Confirmed dialog though Alice sended a
BYE on the Early dialog. A BYE functions normally even if it
Hasebe [Page 16]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
is received after the INVITE transaction terminates because a
BYE differs from a CANCEL, and is sent to not request but the
dialog. Alice gets into a Mortal state on receiving the BYE
response, and remains Mortal until the Timer K timeout occurs.
In Mortal state, UAC does not establish a session, even though
it receives a 200 response for INVITE. Mortal state does not
allow new request sending, so UA does not send an ACK if it
receives a 200 to INVITE. (However, no problem is expected in
implementations when an ACK is sent to quench the retransmission
of 200.)
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK(ini-INVITE) 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: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 BYE Alice -> Bob
BYE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 BYE
Content-Length: 0
Hasebe [Page 17]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F5 200 OK(BYE) Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
;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
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
3.1.4 Receiving re-INVITE (Established state)
in Moratorium state(case 1)
State Alice Bob State
| |
| ini-INVITE F1 |
Pre |------------------------------->| Pre
| 180 F2 |
Ear |<-------------------------------| Ear
| |
| 200 F3 |
Mora |<-------------------------------| Mora
| ACK F4(packet loss) |
Est |-------------------->X |
| |
| re-INVITE F6 200 F5 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| *race*
| ACK F7 200 F8 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| Est
| ACK F9 |
|------------------------------->|
| |
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (re-INVITE) in Moratorium state.
UAS receives a re-INVITE before receiving an ACK to ini-INVITE. UAS
sends a 200 OK to the re-INVITE (F8) because it has sent a 200 OK
Hasebe [Page 18]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
to the ini-INVITE (F3, F5) and the dialog has already been confirmed.
However, if a 200 OK to the ini-INVITE has an offer and the answer
would be in the ACK, UA should return by a 491 to the re-INVITE.
(refer to 3.1.6) If UAS doesn't receive an ACK for a long time,
it should send a BYE and terminate the dialog.
Editor's Note:
In this sequence, UAS comes to know that UAC receives a 200 OK to the
ini-INVITE, when UAS receives a re-INVITE on the dialog. Therefore,
it's believed that UA may view an ACK to be received already if it has
received a mid-dialog request such as a re-INVITE even though it hasn't
actually received an ACK. (However, only provided an ACK plays a role
to transmit that UAC receives the 200 OK. In other words, in case that
an ACK doesn't have an answer. )
It is a difficult problem if UAS in Moratorium state accepts the
message generated by Established state.
Therefore, this example may be corrected.
Message Details
F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Hasebe [Page 19]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Length: 0
F3 200 OK Bob -> Alice
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: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 ACK Alice -> Bob
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
/* A ACK request is lost. */
F5 200 OK Bob -> Alice (retransmission)
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
Hasebe [Page 20]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Content-Type: application/sdp
Content-Length: 147
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 an ini-INVITE since it didn't receive
a ACK. */
F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
F7 ACK Alice -> Bob (retransmission)
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
Hasebe [Page 21]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F8 200 OK(re-INVITE) Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
F9 ACK Alice -> Bob
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
3.1.5 Receiving re-INVITE (Established state)
in Moratorium state(case 2)
State Alice Bob State
| |
| ini-INVITE F1 |
Pre |------------------------------->| Pre
| 180 F2 |
Ear |<-------------------------------| Ear
| |
| 200 F3 |
Mora |<-------------------------------| Mora
| ACK F4(packet loss) |
Est |-------------------->X |
| |
Hasebe [Page 22]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
| re-INVITE F6 200 F5 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK F7 491 F8 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| Est
| ACK F9 |
|------------------------------->|
| |
| |
This scenario is basically the same with 3.1.4, but differs in
sending an offer in 200 and an answer in ACK. Different to the
previous case, the offer in the 200 and the answer in the ACK
collide with each other, so re-INVITE is responded by 491.
Message Details
F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=udp>
Content-Length: 0
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=udp>
Hasebe [Page 23]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Content-Length: 0
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: 147
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
/* An offer is made in 200 */
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-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* An ACK request is lost. */
Hasebe [Page 24]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F5 200 OK Bob -> Alice (retransmission)
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: 147
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 an ini-INVITE since it didn't receive
an ACK. */
F6 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
F7 ACK Alice -> Bob (retransmission)
ACK sip:bob@client.biloxi.example.com SIP/2.0
Hasebe [Page 25]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
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-Type: application/sdp
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F8 491 (re-INVITE) Bob -> Alice
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 0
F9 ACK Alice -> Bob
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
3.1.6 Receiving BYE (Established state)
in Moratorium state
State Alice Bob State
| |
| INVITE F1 |
Pre |------------------------>| Pre
| 180 Ringing F2 |
Hasebe [Page 26]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Ear |<------------------------| Ear
| |
| 200 OK F3 |
Mora |<------------------------| Mora
| ACK F4(packet loss) |
Est |--------------->X |
| Both Way RTP Media |
|<=======================>|
| BYE F6 200 F5 |
Mort |---------- ----------|
| \ / |
| X |
| / \ |
|<--------- --------->| Mort & *race*
| 200 OK F7 |
|<------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (BYE) in Moratorium state.
An ACK request to a 200 OK response is lost (or delay),
immediately after Bob sends the retransmitted 200 OK to
ini-INVITE and Alice sends a BYE at the same time.
Depending on the implement of a SIP user agent, Alice may start
a session again by reception of the retransmitted 200 OK with SDP
since she has already terminated a session by sending a BYE. In
that case, if UAC receives a retransmitted 200 OK after sending a
BYE, you should not start a session again since the session which
is not associated with dialog remains. Moreover, in the case where
UAS sends an offer with a 200 OK, if UAS receives a retransmitted
ACK after receiving a BYE, UAS should not start a session again
for the same reason.
As 3.1.3, Alice's TU does not send new requests because there is
no dialog in Mortal state. Therefore, no ACK is sent for 200.
Furthermore, Bob's TU ceases the retransmission of 200 since he
is in Mortal state after the reception of BYE.
(However, it is considered that, from implementation point of view,
no problem is expected when Alice sends a new request ACK simply to
quench the retransmission of 200 just in case it does not stop.)
Message Details
Hasebe [Page 27]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
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
/* An ACK request is lost. */
F5 200 OK(retransmission) 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: 147
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 an ini-INVITE since it didn't receive
an ACK. */
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
Hasebe [Page 28]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
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. */
F7 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 a BYE. */
3.2 Receiving message in the Mortal State
This section shows some examples of call flow in race condition
when receiving the message from other states in the Mortal state.
3.2.1 Receiving BYE(Establish state)
in Mortal state
State Alice Bob
| |
| INVITE F1 |
Pre |----------------------->| Pre
| 180 Ringing F2 |
Ear |<-----------------------| Ear
| |
| 200 OK F3 |
Mora |<-----------------------| Mora
| ACK F4 |
Est |----------------------->| Est
| Both Way RTP Media |
|<======================>|
| |
| BYE F5 BYE F6 |
Mort |--------- ----------| Mort
| \ / |
| X |
Hasebe [Page 29]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
| / \ |
|<-------- --------->| *race*
| |
| 200 F8 200 F7 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (BYE) in Mortal state.
Alice and Bob send a BYE at the same time. A dialog and session
is ended shortly after a BYE request is passed to a client
transaction. As shown in section 2, UA remains in Mortal state.
UAs in Mortal state return error responses to the requests that
operate dialog or session, such as re-INVITE, UPDATE, or REFER.
However, UA shall return 200 OK to the BYE because it can give then
dialog in Mortal State a finishing stroke and send it to the Morgue.
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
F4 ACK 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
Hasebe [Page 30]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
/* The session is terminated at the moment Alice sends a BYE.
The dialog still exists then, but it is certain to be
terminated in a short period of time. The dialog is
completely terminated when the timeout of the BYE request
occurs. */
F6 BYE Bob -> Alice
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 terminates a session and a dialog. */
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 Moratorium state, Bob responds with
a 200 to the BYE. */
Editor's Note:
In the old version, UA sends a 481 since the dialog is terminated by
sending a BYE request.
(draft-hasebe-sipping-exceptional-procedure-example-02.txt)
In this draft, UA's behavior in the example is modified to return
200 OK. It is an advantage of returning of 200 over 481 that
information when the dialog is terminated can be passed on by the
BYE response.
F8 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
Hasebe [Page 31]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
;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 Mortal
state by sending a BYE, Alice responds with a 200 to a BYE. */
3.2.2 Receiving re-INVITE(Establish state)
in Mortal state
State Alice Bob
| |
| INVITE F1 |
Pre |----------------------->| Pre
| 180 Ringing F2 |
Ear |<-----------------------| Ear
| |
| 200 OK F3 |
Mora |<-----------------------| Mora
| ACK F4 |
Est |----------------------->| Est
| Both Way RTP Media |
|<======================>|
| |
| BYE F5 re-INVITE F6|
Mort |--------- ----------|
| \ / |
| X |
| / \ |
*race* |<-------- --------->| Mort
| |
| 481 F8 200 F7 |
|--------- ----------|
| \ / |^
| X ||
| / \ ||Timer J
|<-------- --------->||
^| ACK F9 ||
||<-----------------------||
Timer K|| ||
V| ||
Morg | |V
| | Morg
| |
Hasebe [Page 32]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
This scenario illustrates the race condition which occurs when
UAS receives an Established message (re-INVITE) in Mortal state.
Bob sends a re-INVITE, and Alice sends a BYE at the same time.
The re-INVITE of Bob is returned by a 481, since TU of Alice has
transited from Established state to Mortal state by sending a BYE.
Bob sends an ACK to a 481 response, because an ACK to an error
response is not a new request but is sent by the transaction layer,
and at this point a client transaction of a re-INVITE remains still.
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
F4 ACK 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 a session, and transits from
the confirmed state to the terminnated state. */
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
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.
The state of dialog transits to Mortal state at the moment
Alice sends a BYE, but Bob doesn't know it until he receives
Hasebe [Page 33]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
the BYE. Therefore, the dialog is Terminated state from
Alice's point of view, but the dialog is Confirmed state
from Bob's point of view. A race condition occurs. */
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
F8 481 Call/Transaction Does Not Exist 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 Mortal state, she responds with a 481 to the
re-INVITE. */
F9 ACK Bob -> Alice
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
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
Content-Length: 0
3.2.3 Receiving 200OK for re-INVITE(Establish state)
in Mortal state
State Alice Bob
| |
| INVITE F1 |
Hasebe [Page 34]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Pre |----------------------->| Pre
| 180 Ringing F2 |
Ear |<-----------------------| Ear
| |
| 200 OK F3 |
Mora |<-----------------------| Mora
| ACK F4 |
Est |----------------------->| Est
| Both Way RTP Media |
|<======================>|
| |
| re-INVITE F5 |
|<-----------------------|
| 200 F7 BYE F6 |
|--------- ----------| Mort
| \ / |
| X |
| / \ |
Mort |<-------- --------->| *race*
| 200 OK F8 |
|----------------------->|
| ^ ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (200 to re-INVITE) in Mortal
state. Bob sends a BYE immediately after sending a re-INVITE,
(A user is not conscious that refresher sends a re-INVITE
automatically. For example, in the case of a telephone application,
it is possible that a user places a receiver immediately after
refresher.) When Alice receives a BYE other than ACK, she stops
retransmitting of 200 OK. Since ACK for 2xx responses is not a
server transaction, it is that UAS core transmits directly.
With UAS core, since the dialog which matches 200 OK received
is terminated, 200 OK is ignored, without sending ACK.
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
Hasebe [Page 35]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F4 ACK Alice -> Bob
F5 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
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
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=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 a BYE immediately after sending of a re-INVITE.
Bob terminates a session and transits from Established
state to Mortal state. */
F7 200 OK(re-INVITE) Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.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
/* Bob sends a BYE, and Alice responds with a 200 OK to re-INVITE.
A race condition occurs. */
F8 200 OK(BYE) Alice -> Bob
SIP/2.0 200 OK
Hasebe [Page 36]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8
;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: 2 BYE
Content-Length: 0
/* The UAC core of Bob does not send a ACK after receiving 200 OK to
a re-INVITE.(Bob has terminated the dialog by sending of a BYE.)
The UAS core of Alice does not retransmit 200 OK to a re-INVITE.
(Since the dialog is terminated by reception of BYE, Alice does
not retransmit 200 OK even if she does not receive ACK from Bob.)
*/
3.2.4 Receiving ACK (Moratorium state)
in Mortal state
State Alice Bob State
| |
| ini-INVITE F1 |
Pre |------------------------------->| Pre
| 180 F2 |
Ear |<-------------------------------| Ear
| 200 F3 |
Mora |<-------------------------------| Mora
| |
| ACK F4 BYE F5 |
Est |------------- --------------| Mort
| \ / |
| X |
| / \ |
Mort |<------------ ------------->| *race*
| 200 F6 |
|------------------------------->|
| ^ ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (ACK to 200) in Mortal state.
Alice sends an ACK and Bob sends a BYE at the same time. When the
offer is in a 2xx, and the answer is in an ACK, this example is
in a race condition. Do not begin the session by receiving an ACK
Hasebe [Page 37]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
because Bob has already terminated the session by sending the BYE.
The answer of ACK is just ignored.
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
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 */
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 a session and dialog. */
F6 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
Hasebe [Page 38]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
3.3 Other race condition
Here, examples in race condition that doesn't relate directly
to the dialog state transition are shown. In this section, it
is shown that how to treat the race condition which generated
when UAs treat "What is established by SIP" which related
closely with dialog.
3.3.1 re-INVITE crossover
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
|re-INVITE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ ACK F10|
|--|--------- ----|--------|
| | \ / | |
| | X | |
| | / \ | |
|<-|---------- ---|------->|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F11 | |
|<------------------|--------|
| 200 OK F12 | |
|-------------------|------->|
| ACK F13 | |
Hasebe [Page 39]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
| re-INVITE F14 v |
|--------------------------->|
| 200 OK F15 |
|<---------------------------|
| ACK F16 |
|--------------------------->|
| |
| |
In this scenario, Alice and Bob send a re-INVITE at the same
time. When two re-INVITEs cross in the same dialog, they resend
re-INVITEs after different intervals.(RFC3261, 14.1) When Alice
sends an initial INVITE, an INVITE will be sent again after
2.1-4.0 seconds because she generated the Call-ID (owner of the
Call-ID). Bob will send an INVITE again after 0.0-2.0 seconds,
because Bob isn't the owner of the Call-ID. Therefore, each user
agent must remember whether they has generated the Call-ID of the
dialog or not, in case INVITEs may be crossed by another INVITE.
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
F4 ACK Alice -> Bob
F5 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
Hasebe [Page 40]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
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
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* A case where a re-INVITE for a session refresh and a re-INVITE for
hold are sent at the same time. */
F7 491 Request Pending Bob -> Alice
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Length: 0
/* Since an INVITE is in progress, a 491 response are returned. */
F8 491 Request Pending Alice -> Bob
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
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
F9 ACK(INVITE) Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74bf9
Hasebe [Page 41]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 ACK
Content-Length: 0
F10 ACK(INVITE) Bob -> Alice
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7
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 ACK
Content-Length: 0
F11 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.1
Session-Expires: 300;refresher=uac
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Since Bob is not the owner of Call-ID, Bob sends an INVITE again
after 0.0-2.0 seconds. */
F12 200 OK Alice -> Bob
F13 ACK Bob -> Alice
F14 re-INVITE Alice -> Bob
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0
Hasebe [Page 42]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of Call-ID, Alice sends an INVITE again
after 2.1-4.0 seconds. */
F15 200 OK Bob -> Alice
F16 ACK Alice -> Bob
3.3.2 UPDATE and re-INVITE crossover
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
| UPDATE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
|------------ -------------|
Hasebe [Page 43]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ |
|<-|----------------|--------|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F10 | |
|<------------------|--------|
| 200 OK F11 | |
|-------------------|------->|
| ACK F12 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
| UPDATE F13 v |
|--------------------------->|
| 200 OK F14 |
|<---------------------------|
| |
| |
In this scenario, the UPDATE contains SDP offer, therefore UPDATE
and re-INVITE are returned error response(491) as in the case of
"re-INVITE crossover". When an UPDATE for refresher which doesn't
contain a session description and the re-INVITE crossed each
other, both request don't fail by 491 and succeed with 200 because
491 means that UA have a pending request. Moreover, the same is
equally true of UPDATE crossover, in case that either UPDATE
contains a session description fail with 491, other cases
succeed with 200.
Editor's Note:
A 491 response is considered a result that UA judged the
effectiveness of request to "What is established by SIP".
Therefore, it is considered that 491 will be used in all the
requests that demand operation to "What is established by SIP".
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
Hasebe [Page 44]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F4 ACK Alice -> Bob
F5 UPDATE Alice -> Bob
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 UPDATE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
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
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* A case where a re-INVITE for a session refresh and a re-INVITE for
hold are sent at the same time. */
F7 491 Request Pending Bob -> Alice
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 UPDATE
Content-Length: 0
Hasebe [Page 45]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
/* Since an INVITE is in process, a 491 response are returned. */
F8 491 Request Pending Alice -> Bob
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
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
F9 ACK(re-INVITE) Alice -> Bob
ACK sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
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 ACK
Content-Length: 0
F10 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.1
Session-Expires: 300;refresher=uac
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 147
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* Since Bob is not the owner of Call-ID, Bob sends an INVITE again
after 0.0-2.0 seconds. */
Hasebe [Page 46]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
F11 200 OK Alice -> Bob
F12 ACK Bob -> Alice
F13 UPDATE Alice -> Bob
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 3 UPDATE
Content-Length: 151
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of Call-ID, Alice sends an INVITE again
after 2.1-4.0 seconds. */
F14 200 OK Bob -> Alice
3.3.3 Receiving REFER(Establish state)
in Mortal state
State Alice Bob State
| |
| INVITE F1 |
Pre |----------------------->| Pre
| 180 Ringing F2 |
Ear |<-----------------------| Ear
| |
| 200 OK F3 |
Mora |<-----------------------| Mora
| ACK F4 |
Est |----------------------->| Est
| Both Way RTP Media |
|<======================>|
| |
| BYE F5 REFER F6 |
Mort |--------- ----------|
Hasebe [Page 47]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
| \ / |
| X |
| / \ |
*race* |<-------- --------->| Mort
| |
| 481 F8 200 F7 |
|--------- ----------|
| \ / ^ |
| X | |
| / \ | |
|<-------- --------->|
| ^ | |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition which occurs when
UAS receives an Established message (REFER) in Mortal state.
Bob sends a REFER, and Alice sends a BYE at the same time. Bob
send a REFER in the same dialog. Alice sends an error response
to request like a REFER which operates the session, because,
by sending a BYE, Alice had terminated the session which would
have corresponded to the REFER. For handling of dialogs with
multiple usages, as can be seen in the use of REFER method,
see the draft on dialog usage [8].
Message Details
F1 INVITE Alice -> Bob
F2 180 Ringing Bob -> Alice
F3 200 OK Bob -> Alice
F4 ACK 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
Hasebe [Page 48]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
Content-Length: 0
/* Alice sends a BYE and terminates a session, and transits from
Confirmed state to Terminnated state. */
F6 REFER Bob -> Alice
REFER 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
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.
Bob sends a REFER on the INVITE dialog.
The state of dialog transits to Mortal state at the moment
Alice sends a BYE, but Bob doesn't know it until he receives
the BYE. A race condition occurs. */
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.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
F8 481 Call/Transaction Does Not Exist 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 REFER
Content-Length: 0
/* Since Alice is terminated the session, she responds with a 481
Hasebe [Page 49]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
to the REFER. */
Appendix A - BYE on the Early Dialog
This section, related to 3.1.3, explains why BYE is not recommended
in Early state, illustrating the case in which BYE in Early dialog
triggers confusion.
Alice Proxy Bob Carol
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |----------------->| |
|<---------------| 180(To-tag=1) F4 | |
| 180(1) F5 |<-----------------| |
|<---------------| | |
| | INVITE(Fork) F6 |
| |------------------------>|
| | 100 F7 |
| BYE(1) F8 |<------------------------|
|--------------->| BYE F9 | |
| |----------------->| |
| | 200 F10 | |
| 200 F11 |<-----------------| |
|<---------------| 487 F12 | |
| |<-----------------| |
| | | |
| | |
| | 200(To-tag=2) F13 |
| 200(2) F14 |<------------------------|
|<---------------| |
| ACK F15 | |
|--------------->| ACK F16 |
| |------------------------>|
| BYE F17 | |
|--------------->| BYE F18 |
| |------------------------>|
| | 200 F19 |
| 200 F20 |<------------------------|
|<---------------| |
| | |
| | |
Here advises some care for the sending of BYE in Early state
when proxy forks. A BYE request progress normally, and it
succeeds in correctly terminating the dialog with Bob.
However, Alice receives the final request for INVITE (a 200
Hasebe [Page 50]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
from Carol) even though she could terminate the dialog with Bob.
This means that, regardless of the success/failure of BYE in
Early state, Alice MUST be prepared for the establishment of a
new dialog until it receives the final response for INVITE and
the INVITE transaction is terminated.
Namely, the BYE in Early state, different to ordinary BYE, it
is not possible to regard that simply sending the BYE does not
finish all transaction related to the dialog.
In this point, the Bye in Early sate needs more care than the
ordinary BYE in Confirmed state. To obviate this care on BYE,
simply CANCEL is utilized instead of BYE. BYE using CANCEL,
the dialog between Alice and Bob is terminated, and if a proxy
forks, CANCEL for INVITE can be forked.
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
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.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
2003.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated
Dialog Event Package for the Session Initiation Protocol (SIP)",
RFC 4235, November 2005.
[8] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", draft-ietf-sipping-dialogusage-01 (work in progress),
March 2, 2006.
Author's Addresses
Hasebe [Page 51]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
All listed authors actively contributed large amounts of text to this
document.
Miki Hasebe
NTT-east Corporation
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
EMail: hasebe.miki@east.ntt.co.jp
Jun Koshiko
NTT-east Corporation
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
EMail: j.koshiko@east.ntt.co.jp
Yasushi Suzuki
NTT-east Corporation
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
EMail: suzuki.yasushi@east.ntt.co.jp
Tomoyuki Yoshikawa
NTT-east Corporation
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: pkyzivat@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
Hasebe [Page 52]
Internet Draft Exceptional Procedure Examples Mar 3th,2006
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
The Expiration date for this Internet Draft is:
Dec 19th, 2006
Hasebe [Page 53]