draft-ietf-sipping-race-examples-00.txt   draft-ietf-sipping-race-examples-01.txt 
Internet Engineering Task Force M. HASEBE Internet Engineering Task Force M. HASEBE
Internet-Draft J. KOSHIKO Internet-Draft J. KOSHIKO
Expires: Jun 11th, 2007 Y. SUZUKI Expires: Sep 6, 2007 Y. SUZUKI
T. YOSHIKAWA T. YOSHIKAWA
NTT-East NTT-East
P. Kyzivat P. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
Dec 11th, 2006 Mar 5th, 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-00.txt draft-ietf-sipping-race-examples-01.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 June 11, 2007. This Internet-Draft will expire on September 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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. The elements in these call flows include SIP User Agents them. The elements in these call flows include SIP User Agents
and SIP Proxies. Call flow diagrams and message details are shown. and SIP 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 condition . . . . . . . . . . . . . . . . . . . . . . . . .9 3. Race Conditions. . . . . . . . . . . . . . . . . . . . . . . . .10
3.1 Receiving message in the Moratorium State. . . . . . . . . .9 3.1 Receiving message in the Moratorium State. . . . . . . . . .10
3.1.1 Receiving Initial INVITE retransmission(Trying state). .9 3.1.1 Receiving Initial INVITE retransmission(Trying state). .10
3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . .11 3.1.2 Receiving CANCEL(Proceeding or Early state). . . . . . .12
3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .12 3.1.3 Receiving BYE (Early state). . . . . . . . . . . . . . .14
3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .14 3.1.4 Receiving re-INVITE (Established state)(case 1). . . . .15
3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .18 3.1.5 Receiving re-INVITE (Established state)(case 2). . . . .19
3.1.6 Receiving BYE (Established state). . . . . . . . . . . .21 3.1.6 Receiving BYE (Established state). . . . . . . . . . . .24
3.2 Receiving message in the Mortal State. . . . . . . . . . . .23 3.2 Receiving message in the Mortal State. . . . . . . . . . . .24
3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .23 3.2.1 Receiving BYE(Established state) . . . . . . . . . . . .25
3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .26 3.2.2 Receiving re-INVITE(Established state) . . . . . . . . .27
3.2.3 Receiving 200OK for re-INVITE(Established state) . . . .29 3.2.3 Receiving 200OK for re-INVITE(Established state) . . . .30
3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .31 3.2.4 Receiving ACK (Moratorium state) . . . . . . . . . . . .32
3.3 other race condition . . . . . . . . . . . . . . . . . . . .33 3.3 Other race conditions. . . . . . . . . . . . . . . . . . . .34
3.3.1 re-INVITE crossover. . . . . . . . . . . . . . . . . . .33 3.3.1 Re-INVITE crossover. . . . . . . . . . . . . . . . . . .34
3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .37 3.3.2 UPDATE and re-INVITE crossover . . . . . . . . . . . . .38
3.3.3 Receiving REFER(Established state) . . . . . . . . . . .41 3.3.3 Receiving REFER(Established state) . . . . . . . . . . .42
Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .43 Appendix A. BYE on the Early Dialog . . . . . . . . . . . . . . . .44
Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .44 Appendix B. BYE request overlapped on re-INVITE . . . . . . . . . .45
Appendix C. UA's behaviour for CANCEL . . . . . . . . . . . . . . .46 Appendix C. UA's behaviour for CANCEL . . . . . . . . . . . . . . .47
Appendix D. Notes on the request in Mortal state. . . . . . . . . .48 Appendix D. Notes on the request in Mortal state. . . . . . . . . .49
References . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Appendix E. Forking and receiving new To-tags . . . . . . . . . . .50
Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .49 References . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Intellectual Property Statement . . . . . . . . . . . . . . . . . .50 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . . .53
Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . .51 Intellectual Property Statement . . . . . . . . . . . . . . . . . .54
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . .51 Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . . . .55
Acknowledgment. . . . . . . . . . . . . . . . . . . . . . . . . . .51 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
skipping to change at page 4, line 32 skipping to change at page 4, line 33
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 ini-INVITE.
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 The DSM clarifies UA's behavior by subdividing some internal states
showed in the FSM (Finite State Machine) for dialog state of the shown in the FSM (Finite State Machine) for dialog state of the
dialog-package [7], without changing the states of the dialog, dialog-package [7], without changing the states of the dialog,
"early", "confirmed", and "terminated" shown in RFC3261 [1]. "early", "confirmed", and "terminated" shown in RFC3261 [1].
The Preparative state is put before the Early state, which includes The Preparative state is put before the Early state, which includes
the Trying and Proceeding states. The Confirmed state is subdivided the Trying and Proceeding states. The Confirmed state is subdivided
into two substates, the Moratorium and Established states and the into two substates, the Moratorium and Established states and the
Terminated state is subdivided into the Mortal and Morgue states. Terminated state is subdivided into the Mortal and Morgue states.
Messages which are the triggers of the state transitions between
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.
+-----------------------------------------------+ +-----------------------------------------------+
| Preparative | | Preparative |
| +----------+ +--------------+ | | +----------+ +--------------+ |
| | | 100 | |-----C-+ | | | 100 | |-----C-+
| | Trying |---------->| Proceeding | | | 100 | | Trying |---------->| Proceeding | | | 100
| | | | |<----C-+ | | | | |<----C-+
| +----------+ +--------------+ | | +----------+ +--------------+ |
skipping to change at page 6, line 4 skipping to change at page 6, line 4
| | | | | | | | | | | | | | | |
| +---------------+ | | +-----------+ | | +---------------+ | | +-----------+ |
| | | | | | | |
+------------------------+ +------------------+ +------------------------+ +------------------+
(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 (UAC)
Figure 1 represents the UAC's DSM for the INVITE dialog usage. Figure 1 represents the UAC's DSM for the INVITE dialog usage. UAC
UAC MAY send a BYE in the Early state, even though this behavior is MAY send a BYE in the Early state, even though this behavior is
NOT RECOMMENDED. The BYE sent in the Early state terminates the NOT RECOMMENDED. The BYE sent in the Early state terminates the
Early dialog with a specific To-tag. That is, when a proxy is Early dialog with a specific To-tag. That is, when a proxy is
performing forking, the BYE is only able to terminate the Early performing forking, the BYE is only able to terminate the Early
dialog between a particular UA. If UAC wants to terminate all Early dialog with a particular UA. If UAC 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. Moreover, until UAC receives a final response and
terminates the INVITE transaction, the UAC MUST be prepared to terminates the INVITE transaction, the UAC 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 BYE and terminated the dialog (see Appendix A).
+-----------------------------------------------+ +-----------------------------------------------+
| Preparative | | Preparative |
| +----------+ +--------------+ | | +----------+ +--------------+ |
| | | 100 | |-----C-+ | | | 100 | |-----C-+
skipping to change at page 8, line 50 skipping to change at page 9, line 35
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 influences a
dialog. Caller supports the transmission of ACK for a dialog. Caller supports the transmission of ACK for a
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. The
Confirmed state transits to the Mortal state, a substate of the Confirmed state transits to the Mortal state, a substate of the
Terminated state, by sending or receiving a BYE request. Terminated state, by sending or receiving a BYE request.
Mortal (Mort): Caller and callee becomes Mortal state by sending Mortal (Mort): Caller and callee becomes 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 since
there is no dialog. (Here the new requests do not include ACK there is no dialog. (Here the new requests do not include ACK
for 2xx and BYE for 401 or 407 as further explained in the for 2xx and BYE for 401 or 407 as further explained in the
Appendix D below.) 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 is because the use case
skipping to change at page 9, line 24 skipping to change at page 10, line 9
being terminated. Therefore, UA possesses dialog information being terminated. Therefore, UA possesses dialog information
for internal process but dialog shouldn't exist outwardly. The for internal process but dialog shouldn't exist outwardly. The
UA stops managing its dialog state and changes it to the Morgue UA stops managing its dialog state and changes it to the Morgue
state, when the BYE transaction is finished by timer state, when the BYE transaction is finished by timer
(Timer F or Timer K for UAC. Timer J for UAS). (Timer F or Timer K for UAC. Timer J for UAS).
Morgue (Morg): Dialog does not exist any more in this state. Morgue (Morg): Dialog does not exist any more in this state.
Sending or receiving of a signal which influences a dialog is Sending or receiving of a signal which influences a dialog is
not performed. (A dialog is literally terminated.) not performed. (A dialog is literally terminated.)
3. Race condition 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 signals are illustrated. Dialog state transitions Only significant signals are illustrated. Dialog state transitions
caused by sending and receiving of SIP messages as well as '*race*', caused by sending and receiving of SIP messages as well as '*race*',
which indicates race condition are shown. (For abbreviations for which indicates race condition are shown. (For abbreviations for
the dialog state transitions, refer to Chapter 2.) the dialog state transitions, refer to Chapter 2.)
'*race*' indicates the moment when a race condition occurs. '*race*' indicates the moment when a race condition occurs.
skipping to change at page 9, line 49 skipping to change at page 10, line 34
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 Moratorium state. when 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 (Trying state)
in Moratorium state in Moratorium state
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
Pre |------------------------------------>| Pre |------------------------------------>|
| 180 F2(Packet loss) | Pre | 180 F2(Packet loss) | Pre
| x<-----------------------| Ear | x<-----------------------|
| | | | Ear
| ini-INVITE(=F1) F4 200 F3 | | ini-INVITE(=F1) F4 200 F3 |
|------------------ --------------| Mora |------------------ --------------|
| \ / | | \ / | Mora
| X | | X |
| / \ | | / \ |
Mora |<----------------- ------------->| *race* |<----------------- ------------->| *race*
| 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 terminate an INVITE server transaction, according to Section 13.3.1.4
of RFC3261 [1]. of RFC3261 [1].
However, it is reported that terminating an INVITE server transaction However, it is reported that terminating an INVITE server transaction
skipping to change at page 11, line 21 skipping to change at page 12, line 11
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 (Proceeding or Early state)
in Moratorium state in Moratorium state
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
Pre |----------------------------->| Pre Pre |----------------------------->|
| 180 Ringing F2 | | 180 Ringing F2 | Pre
Ear |<-----------------------------| Ear Ear |<-----------------------------|
| | | | Ear
|CANCEL F3 200(INVITE) F4| |CANCEL F3 200(INVITE) F4|
|------------ -------------| Mora |------------ -------------|
| \ / | | \ / | Mora
| X | | X |
| / \ | | / \ |
Mora |<----------- ------------>| *race* |<----------- ------------>| *race*
| | Mora | |
| ACK F6 200(CANCEL) F5| | ACK F6 200(CANCEL) F5|
Est |------------ -------------| |------------ -------------|
| \ / | Est | \ / |
| X | | X |
| / \ | | / \ |
|<----------- ------------>| Est |<----------- ------------>|
| | | | Est
| One Way RTP Media | | One Way RTP Media |
| (Two Way RTP Media possible) | | (Two Way RTP Media possible) |
|<=============================| |<=============================|
| BYE F7 | | BYE F7 |
Mort |----------------------------->| Mort |----------------------------->|
| 200 F8 | Mort | 200 F8 | Mort
|<-----------------------------| |<-----------------------------|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when UAS
skipping to change at page 13, line 24 skipping to change at page 14, line 11
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
| | | |
| ini-INVITE F1 | | ini-INVITE F1 |
Pre |------------------------------->| Pre |------------------------------->|
| 180 F2 | Pre | 180 F2 | Pre
Ear |<-------------------------------| Ear |<-------------------------------|
| | Ear | | Ear
| BYE F4 200(INVITE) F3| | BYE F4 200(INVITE) F3|
Mort |------------- --------------| Mora |------------- --------------|
| \ / | Mort | \ / | Mora
| X | | X |
| / \ | | / \ |
|<------------ ------------->| Mort & *race* |<------------ ------------->| *race*
| | | | Mort
| ACK F5 200(BYE) F6 | | ACK F5 200(BYE) F6 |
|------------- --------------| |------------- --------------|
| \ / ^ | | \ / ^ |
| X | | | X | |
| / \ | | | / \ | |
|<------------ ------------->| |<------------ ------------->|
| ^ | | | ^ | |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
skipping to change at page 14, line 42 skipping to change at page 15, line 28
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 F1 | | ini-INVITE w/offer1 F1 |
Pre |------------------------------->| Pre |------------------------------->|
| 180 F2 | Pre | 180 F2 | Pre
Ear |<-------------------------------| Ear |<-------------------------------|
| | Ear | | Ear
| 200(ini-INV) F3 | | 200(ini-INV) w/answer1 F3 |
Mora |<-------------------------------| Mora |<-------------------------------|
| ACK F4(packet loss) | Mora | ACK F4(packet loss) | Mora
Est |-------------------->x | |-------------------->x |
| | Est | |
| re-INVITE F6 200(=F3) F5 | | re-INVITE F6 200(=F3) F5 |
| w/offer2 w/answer1 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| *race* |<------------ ------------->| *race*
| ACK(=F4) F7 200(re-INV) F8| | 200(re-INV) F8|
| ACK(=F4) F7 w/answer2 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| Est |<------------ ------------->|
| ACK F9 | | ACK 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 before receiving an ACK for ini-INVITE. UAS UAS receives a re-INVITE (w/offer2) before receiving an ACK for
sends a 200 OK to the re-INVITE (F8) because it has sent a 200 OK to ini-INVITE (w/offer1). UAS sends a 200 OK (w/answer2) to the
the ini-INVITE (F3, F5) and the dialog has already been established. 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.
(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.) If a 200 OK to the ini-INVITE has an offer and the
answer is in the ACK, UA should return by a 491 to the 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 re-INVITE (refer to 3.1.5). As it can be seen in Section 3.3.2
below, the 491 response seems to be closely related to session below, the 491 response seems to be closely related to session
establishment, even in cases other than INVITE cross-over. This establishment, even in cases other than INVITE cross-over. This
example recommends 200 be sent instead of 491 because it does not example recommends 200 be sent instead of 491 because it does not
have influence on session. However, a 491 response can also lead to have influence on session. However, a 491 response can also lead to
the same outcome, so the either response can be used. the same outcome, so the either response can be used.
Moreover, if UAS doesn't receive an ACK for a long time, Moreover, if UAS doesn't receive an ACK for a long time,
skipping to change at page 18, line 31 skipping to change at page 19, line 20
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)
State Alice Bob State State Alice Bob State
| | | |
| ini-INVITE F1 | | ini-INVITE (no offer) F1 |
Pre |------------------------------->| Pre |------------------------------->|
| 180 F2 | Pre | 180 F2 | Pre
Ear |<-------------------------------| Ear |<-------------------------------|
| | Ear | | Ear
| 200(ini-INV) F3 | | 200(ini-INV) w/offer1 F3 |
Mora |<-------------------------------| Mora |<-------------------------------|
| ACK F4(packet loss) | Mora | ACK w/answer1 F4(packet loss) | Mora
Est |-------------------->x | |-------------------->x |
| | Est | |
| re-INVITE F6 200(=F3) F5 | | re-INVITE F6 200(=F3) F5 |
| w/offer2 w/offer1 |
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| |<------------ ------------->|
| ACK(=F4) F7 491(re-INV) F8| | ACK(=F4) F7 491(re-INV) F8|
|------------- --------------| |------------- --------------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<------------ ------------->| Est |<------------ ------------->|
| ACK F9 | | ACK 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 since he is not able to properly handle a Bob sends 491 to re-INVITE (F6) since he is not able to properly
new request until he receives an answer. handle a new request until he receives an answer. Even if F6 is
UPDATE with offer, it will reach the same result.
Message Details Message Details
F1 INVITE Alice -> Bob F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0 INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
skipping to change at page 21, line 29 skipping to change at page 22, line 20
offer. */ offer. */
F9 ACK Alice -> Bob F9 ACK 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 |-------------------------->| Pre |-------------------------->|
| 180 Ringing F2 | Pre | 180 Ringing F2 | Pre
Ear |<--------------------------| Ear |<--------------------------|
| | Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
Mora |<--------------------------| Mora |<--------------------------|
| ACK F4(packet loss) | Mora | ACK F4(packet loss) | Mora
Est |--------------->x | |--------------->x |
| Both Way RTP Media | Est | Both Way RTP Media |
|<=========================>| |<=========================>|
| BYE F6 200(=F3) F5| | BYE F6 200(=F3) F5|
Mort |----------- -----------| |----------- -----------|
| \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
|<---------- ---------->| Mort & *race* |<---------- ---------->| *race*
|ACK(=F4) F7 200(BYE) F8| |ACK(=F4) F7 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 22, line 11 skipping to change at page 23, line 4
| X | | X |
| / \ | | / \ |
|<---------- ---------->| |<---------- ---------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
| V | | V |
| | Morg | | Morg
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when UAS
receives an Established message, BYE, in the Moratorium state. receives an Established message, BYE, in the Moratorium state.
An ACK request for a 200 OK response is lost (or delayed). An ACK request for a 200 OK response is lost (or delayed).
Immediately after Bob retransmits the 200 OK to ini-INVITE, and Alice Immediately after Bob retransmits the 200 OK to ini-INVITE, and Alice
sends a BYE request at the same time. sends a BYE request at the same time. Depending on the
Depending on the implementation of a SIP UA, Alice may want to start implementation of a SIP UA, Alice may start a session again by the
a session again by the reception of the retransmitted 200 OK with SDP reception of the retransmitted 200 OK with SDP since she has already
since she has already terminated a session by sending a BYE. In that terminated a session by sending a BYE. In that case, when UAC
case, when UAC receives a retransmitted 200 OK after sending a BYE, receives a retransmitted 200 OK after sending a BYE, a session should
a session should not be started again since the session which is not not be started again since the session which is not associated with
associated with dialog still remains. Moreover, in the case where dialog still remains. Moreover, in the case where UAS sends an offer
UAS sends an offer in a 200 OK , UAS should not start a session again in a 200 OK , UAS should not start a session again for the same
for the same reason if UAS receives a retransmitted ACK after reason if UAS receives a retransmitted ACK after receiving a BYE.
receiving a BYE.
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 24, line 17 skipping to change at page 25, line 11
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
| | | |
| INVITE F1 | | INVITE F1 |
Pre |----------------------->| Pre |----------------------->|
| 180 Ringing F2 | Pre | 180 Ringing F2 | Pre
Ear |<-----------------------| Ear |<-----------------------|
| | Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
Mora |<-----------------------| Mora |<-----------------------|
| ACK F4 | Mora | ACK F4 | Mora
Est |----------------------->| Est |----------------------->|
| Both Way RTP Media | Est | Both Way RTP Media | Est
|<======================>| |<======================>|
| | | |
| BYE F5 BYE F6 | | BYE F5 BYE F6 |
Mort |--------- ----------| Mort |--------- ----------|
| \ / | Mort | \ / | Mort
| X | | X |
| / \ | | / \ |
|<-------- --------->| *race* |<-------- --------->| *race*
| | | |
| 200 F8 200 F7 | | 200 F8 200 F7 |
|--------- ----------| |--------- ----------|
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
|<-------- --------->| |<-------- --------->|
skipping to change at page 26, line 46 skipping to change at page 27, line 37
/* 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
| | | |
| INVITE F1 | | INVITE F1 |
Pre |----------------------->| Pre |----------------------->|
| 180 Ringing F2 | Pre | 180 Ringing F2 | Pre
Ear |<-----------------------| Ear |<-----------------------|
| | Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
Mora |<-----------------------| Mora |<-----------------------|
| ACK F4 | Mora | ACK F4 | Mora
Est |----------------------->| Est |----------------------->|
| Both Way RTP Media | Est | Both Way RTP Media | Est
|<======================>| |<======================>|
| | | |
| BYE F5 re-INVITE F6| | BYE F5 re-INVITE F6|
Mort |--------- ----------| |--------- ----------|
| \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
*race* |<-------- --------->| Mort *race* |<-------- --------->|
| | | | Mort
| 481 F8 200 F7 | | 481 F8 200 F7 |
|--------- ----------| |--------- ----------|
| \ / |^ | \ / |^
| X || | X ||
| / \ ||Timer J | / \ ||Timer J
|<-------- --------->|| |<-------- --------->||
^| ACK F9 || ^| ACK F9 ||
||<-----------------------|| ||<-----------------------||
Timer K|| || Timer K|| ||
|| || || ||
skipping to change at page 29, line 27 skipping to change at page 30, line 18
/* 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
| | | |
| INVITE F1 | | INVITE F1 |
Pre |----------------------->| Pre |----------------------->|
| 180 Ringing F2 | Pre | 180 Ringing F2 | Pre
Ear |<-----------------------| Ear |<-----------------------|
| | Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
Mora |<-----------------------| Mora |<-----------------------|
| ACK F4 | Mora | ACK F4 | Mora
Est |----------------------->| Est |----------------------->|
| Both Way RTP Media | Est | Both Way RTP Media | Est
|<======================>| |<======================>|
| | | |
| re-INVITE F5 | | re-INVITE F5 |
|<-----------------------| |<-----------------------|
| 200 F7 BYE F6 | | 200 F7 BYE F6 |
|--------- ----------| Mort |--------- ----------|
| \ / | | \ / | Mort
| X | | X |
| / \ | | / \ |
Mort |<-------- --------->| *race* |<-------- --------->| *race*
| 200 F8 ACK F9 | Mort | 200 F8 ACK F9 |
|--------- ----------| |--------- ----------|
| ^ \ / | | ^ \ / |
| | X | | | X |
| | / \ | | | / \ |
|<-------- --------->| |<-------- --------->|
| | ^ | | | ^ |
| | Timer K | | | | Timer K | |
| | V | | | V |
| | Timer J | Morg | | Timer J | Morg
| V | | V |
skipping to change at page 32, line 4 skipping to change at page 32, line 40
/* 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 |
Pre |------------------------------->| Pre |------------------------------->|
| 180 F2 | Pre | 180 F2 | Pre
Ear |<-------------------------------| Ear |<-------------------------------|
| 200 F3 | Ear | 200 F3 | Ear
Mora |<-------------------------------| Mora |<-------------------------------|
| | Mora | | Mora
| ACK F4 BYE F5 | | ACK F4 BYE F5 |
Est |------------- --------------| Mort |------------- --------------|
| \ / | Est | \ / | Mort
| X | | X |
| / \ | | / \ |
Mort |<------------ ------------->| *race* |<------------ ------------->| *race*
| 200 F6 | Mort | 200 F6 |
|------------------------------->| |------------------------------->|
| ^ ^ | | ^ ^ |
| | Timer K | | | | Timer K | |
| | V | | | V |
| | Timer J | Morg | | Timer J | Morg
| V | | V |
Morg | | Morg | |
| | | |
This scenario illustrates the race condition which occurs when UAS This scenario illustrates the race condition which occurs when UAS
skipping to change at page 33, line 28 skipping to change at page 34, line 20
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8
;received=192.0.2.201 ;received=192.0.2.201
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 BYE CSeq: 2 BYE
Content-Length: 0 Content-Length: 0
3.3 Other race condition 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. Here explains
the way to handle the race condition generated when UAs treat the way to handle the race condition generated when UAs treat
"What is established by SIP", which has some relation to dialog. "What is established by SIP", which has some relation to dialog.
3.3.1 re-INVITE crossover 3.3.1 Re-INVITE crossover
Alice Bob Alice Bob
| | | |
| INVITE F1 | | INVITE F1 |
|--------------------------->| |--------------------------->|
| 180 Ringing F2 | | 180 Ringing F2 |
|<---------------------------| |<---------------------------|
| | | |
| 200 OK F3 | | 200 OK F3 |
|<---------------------------| |<---------------------------|
skipping to change at page 41, line 26 skipping to change at page 42, line 15
again after 2.1-4.0 seconds. */ again after 2.1-4.0 seconds. */
F14 200 OK Bob -> Alice F14 200 OK Bob -> Alice
3.3.3 Receiving REFER (Establish state) 3.3.3 Receiving REFER (Establish state)
in Mortal state in Mortal state
State Alice Bob State State Alice Bob State
| | | |
| INVITE F1 | | INVITE F1 |
Pre |----------------------->| Pre |----------------------->|
| 180 Ringing F2 | Pre | 180 Ringing F2 | Pre
Ear |<-----------------------| Ear |<-----------------------|
| | Ear | | Ear
| 200 OK F3 | | 200 OK F3 |
Mora |<-----------------------| Mora |<-----------------------|
| ACK F4 | Mora | ACK F4 | Mora
Est |----------------------->| Est |----------------------->|
| Both Way RTP Media | Est | Both Way RTP Media | Est
|<======================>| |<======================>|
| | | |
| BYE F5 REFER F6 | | BYE F5 REFER F6 |
Mort |--------- ----------| |--------- ----------|
| \ / | Mort | \ / |
| X | | X |
| / \ | | / \ |
*race* |<-------- --------->| Mort *race* |<-------- --------->|
| | | | Mort
| 481 F8 200 F7 | | 481 F8 200 F7 |
|--------- ----------| |--------- ----------|
| \ / ^ | | \ / ^ |
| X | | | X | |
| / \ | | | / \ | |
|<-------- --------->| |<-------- --------->|
| ^ | | | ^ | |
| | Timer K | | | | Timer K | |
| V | | | V | |
Morg | Timer J | | Morg | Timer J | |
skipping to change at page 46, line 19 skipping to change at page 47, line 11
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 | | | F1 re-INVITE | |
|-------------->x | | |-------------->x | |
| F2 BYE | | | F2 BYE | |
|--------------------->| (Mortal) o |--------------------->| | o
| F3 200(BYE) | | | | F3 200(BYE) | (Mortal) |
|<---------------------| | |<-Start TimerJ |<---------------------| | |<-Start TimerJ
| F4 INVITE(=F1) | | | | F4 INVITE(=F1) | | |
|--------------------->| | o | |--------------------->| | o |
| F5 4xx(INV) | o | o | F5 4xx(INV) | o | o
|<---------------------| | |<---------------------| |
| F6 ACK(INV) | | | F6 ACK(INV) | |
|--------------------->| |<-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 (probably 481) for F4 UAS's TU sends an appropriate error response for F4 INVITE, either
INVITE, 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. INVITE is in the Terminated state) or 500 (because the re-sent F4
has 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 behaviour for CANCEL
This section explains the CANCEL and the Expires header behaviors This section explains the CANCEL and the Expires header behaviors
which indirectly involve in the dialog state transition in the Early which indirectly involve in the dialog state transition in the Early
state. CANCEL does not have any influence on UAC's dialog state. state. CANCEL does not have any influence on UAC's dialog state.
However, the request has indirect influence on the dialog state However, the request has indirect influence on the dialog state
transition because it has a significant effect on ini-INVITE. transition because it has a significant effect on ini-INVITE.
Similarly, the Expires header does not have direct influence on the Similarly, the Expires header does not have direct influence on the
dialog state transition, but it indirectly affect the state dialog state transition, but it indirectly affect the state
transition because its expiration triggers the sending of CANCEL. transition because its expiration triggers the sending of CANCEL.
For UAS the CANCEL request and the Expires header timeout have more For UAS the CANCEL request and the Expires header timeout have more
direct effects on the dialog than the sending of CANCEL by UAC, direct effects on the dialog than the sending of CANCEL by UAC,
skipping to change at page 48, line 19 skipping to change at page 49, line 9
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. 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 In this case the UAS immediately sends 487 for the INVITE, and the
dialog transits to the Terminated state. 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, from the point of UAC's behavior, it can be expected (Note that, because of UAC's behavior, a UAS that receives a CANCEL
that UAS receives BYE immediately after the reception of CANCEL and in the Confirmed state can expect to receive a BYE immediately and
moves 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 need
careful attention. careful attention.
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 in this state. conducted in this state.
(The handling of messages concerning multiple dialog usages is out of (The handling of messages concerning multiple dialog usages is out of
the scope of this document. Refer to [8] for further information.) the scope of this document. Refer to [8] for further information.)
ACK for error responses is handled by the transaction layer, so the ACK for error responses is handled by the transaction layer, so the
handling is not related to the dialog state. Unlike the ACK for handling is not related to the dialog state. Unlike the ACK for
error responses, ACK for 2xx responses is a request newly generated error responses, ACK for 2xx responses is a request newly generated
by TU. However, the ACK for 2xx and the one 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 hadlings both a part of the INVITE transaction, even though their hadling
differ (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
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
This section details the behavior of TU when it receives multiple
responses with a different To tag to ini-INVITE.
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
ini-INVITE (See Section 11.2, 13.1, 13.2.2.4, 16.7, 19.3 etc. of
RFC3261). If the TU receives multiple 1xx responses with a different
To tag, the original DSM forks and a new DSM instance is created. As
a consequence multiple early dialogs are generated.
If one of the multiple early dialogs receives a 2xx response, it
naturally transits to the Confirmed state. No DSM state transition
occurs for the other early dialogs, and their sessions (early media)
terminate. The TU of the UAC terminates the INVITE transaction after
64*T1 seconds starting at the point of receiving the first 2xx
response. Moreover, all mortal early dialog which do not transit to
the Established state are terminated (See Section 13.2.2.4 of
RFC3261).
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
early dialogs (dialog A) is received. Dot lines (..) in sequences
is auxiliary line to represent the influence on dialog B.
UAC
dialog(A) | F1 INVITE
Pre o |------------------------->
| | F2 100
| |<-------------------------
| | F3 180(To-tag=A)
Ear | |<-------------------------
dialog(B) | |
forked new DSM | | F4 180(To-tag=B)
Ear o..........|..........|<-------------------------
| | |
| | | F5 200(To-tag=A)
terminate->|.....Mora |..........|<-------------------------
early | | ^ | F6 ACK(To-tag=A)
media | Est | | |------------------------->
| | | |
| | |64*T1 |
| | |(13.2.2.4 of RFC3261)
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
The figure above shows the DSM inside a SIP TU. Triggered by the
reception of a provisional response with a different To tag
(F4 180(To-tag=B)), DSM forks and the early dialog B is generated.
After 64*T1 seconds after the dialog A receives 200 OK response, the
dialog B, which does not transit to the Established state,
terminates.
Next, the behavior of a TU which receives multiple 2xx responses with
a different To tag is explained. When a mortal early dialog, which
did not match the first 2xx response the TU received, receives
another 2xx response which matches its To tag before 64*T1 INVITE
transaction timeout, its DSM state transits to the Confirmed state.
However, the seesion on the mortal early dialog is terminated when
the TU receives the first 2xx to establish a dialog, so no session is
established for the mortal early dialog. Therefore, when the mortal
early dialog receives a 2xx response, the TU should send an ACK and,
immediately after, BYE to terminate DSM.
The handling of the second early dialog after receiving the 200 for
the first dialog is quite appropriate for a typical device, such as a
phone. It is important to note that what is being shown is a
typically useful action and not the only valid one. Some devices
might want to handle things differently. For instance, a conference
focus that has sent out an invite that forks may want to accept and
mix all the dialogs it gets.
Below is an example sequence in which two 180 responses with a
different To tag are received and then a 200 response for each of the
early dialogs is received.
UAC
dialog(A) | F1 INVITE
Pre o |----------------------->
| | F2 100
| |<-----------------------
| | F3 180(To-tag=A)
dialog(B) Ear | |<-----------------------
forked new DSM | | F4 180(To-tag=B)
Ear o..........|..........|<-----------------------
| | |
| | | F5 200(To-tag=A)
terminate->|.....Mora |..........|<-----------------------
early | | ^ | F6 ACK(To-tag=A)
media | Est | | |----------------------->
| | |64*T1 |
| | | | F7 200(To-tag=B)
Mora |..........|.|........|<-----------------------
| | | | F8 ACK(To-tag=B)
Est |..........|.|........|----------------------->
| | | | F9 BYE(To-tag=B)
Mort |..........|.|........|----------------------->
^ | | | | F10 200(To-tag=B)
| | | | |<-----------------------
|Timer K | | |
| | | V |
| | | (terminate INVITE transaction)
V | | |
Morg o | |
| |
Finally, when a TU receives multiple 200 responses with a different
To tag before 64*T1 timeout of the INVITE transaction, even though
a TU does not receive provisional response, the TU needs to respond
to the 2xx responses (See Section 13.2.2.4 of RFC3261). 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, BYE.
UAC
dialog(A) | F1 INVITE
Pre o |----------------------->
| | F2 100
| |<-----------------------
| | F3 180(To-tag=A)
Ear | |<-----------------------
| |
| | F4 200(To-tag=A)
Mora |..........|<-----------------------
| ^ | F5 ACK(To-tag=A)
Est | | |----------------------->
| | |
dialog(B) | |64*T1 |
forked new DSM | | | F6 200(To-tag=B)
Mora o..........|.|........|<-----------------------
| | | | F7 ACK(To-tag=B)
Est |..........|.|........|----------------------->
| | | | F8 BYE(To-tag=B)
Mort |..........|.|........|----------------------->
^ | | | | F9 200(To-tag=B)
| | | | |<-----------------------
| | | V |
|Timer K | (terminate INVITE transaction)
| | | |
V | | |
Morg o | |
| |
References References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
SDP", RFC 3264, April 2002. SDP", RFC 3264, April 2002.
[3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. [3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
skipping to change at page 49, line 43 skipping to change at page 53, line 35
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262, Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated [7] Rosenberg, J., Schulzrinne, H., Mahy, R., "An INVITE-Initiated
Dialog Event Package for the Session Initiation Protocol (SIP)", Dialog Event Package for the Session Initiation Protocol (SIP)",
RFC 4235, November 2005. RFC 4235, November 2005.
[8] Sparks, R., "Multiple Dialog Usages in the Session Initiation [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", draft-ietf-sipping-dialogusage-05 (work in progress), Protocol", draft-ietf-sipping-dialogusage-06 (work in progress),
November 9, 2006. 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 51, line 24 skipping to change at page 55, line 15
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 Acknowledgment
The authors would like to thank Robert Sparks, Dean Willis, The authors would like to thank Robert Sparks, Dean Willis,
Cullen Jennings, James M. Polk, Gonzalo Camarillo, Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami,
Kenichi Ogami, Akihiro Shimizu, Mayumi Munakata, Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki,
Yasunori Inagaki, Tadaatsu Kidokoro and Kenichi Hiragi for Tadaatsu Kidokoro, Kenichi Hiragi and Dale Worley, for their comments
the comments on this document. on this document.
 End of changes. 72 change blocks. 
201 lines changed or deleted 361 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/