The material appended to this note consists of four scenarios. Each is
(I believe) a race condition not described in
draft-ietf-sipping-race-examples-06
You will need to view this message in a fixed-width font.
These were discovered by analysis of a formal model of INVITE dialogs,
as posted on
http://www.research.att.com/~pamela/sip.html
What do you think?
Pamela Zave
SCENARIO 1. This scenario occurs within a confirmed dialog.
UAC UAS
re-INVITE 1
<------------------------------------------------------
no sdp
200(re-INVITE 1)
------------------------------------------------------>
offer
ACK 1
-------------------------
/ answer
/ re-INVITE 2
! <--------------------------/---------------------------
/ offer
/
<------------------------
200(re-INVITE 2)
------------------------------------------------------>
answer
ACK 2
<------------------------------------------------------
At the point marked "!", the UAC cannot respond to the re-INVITE
immediately. It must buffer this request until it receives ACK 1,
which completes the ongoing offer/answer exchange.
SCENARIO 2.
UAC UAS
ini-INVITE
------------------------------------------------------>
offer
183(reliable) 1
<------------------------------------------------------
answer
PRACK 1
------------------------------------------------------>
no sdp
200(PRACK 1)
<------------------------------------------------------
UPDATE 183(reliable) 2
------------------------- -------------------------
offer \ / offer
x
/ \
! <------------------------ ------------------------>
491(UPDATE)
<------------------------------------------------------
PRACK 2
------------------------------------------------------>
answer
200(PRACK 2)
<------------------------------------------------------
At the point marked "!", the UAC cannot respond to the 183 immediately,
although immediate response is required by the standard. Rather, it
must
wait until it receives the response to the UPDATE, which will terminate
the ongoing offer/answer exchange. The UAC CANNOT assume that the
update
will fail, because it may succeed, as shown in the next scenario.
SCENARIO 3. This scenario has roughly the same problem as Scenario 2,
although the race condition that causes it is different.
UAC UAS
ini-INVITE
------------------------------------------------------>
offer
183(reliable) 1
<------------------------------------------------------
answer
PRACK 1
------------------------------------------------------>
no sdp
200(PRACK 1)
<------------------------------------------------------
UPDATE
------------------------------------------------------>
offer
200(UPDATE)
-------------------------
/ answer
/
! <--------------------------/---------------------------
/ 183(reliable,offer) 2
/
<------------------------
PRACK 2
------------------------------------------------------>
answer
200(PRACK 2)
<------------------------------------------------------
SCENARIO 4.
UAC UAS
ini-INVITE
------------------------------------------------------>
offer
183(reliable)
<------------------------------------------------------
answer
PRACK
------------------------------------------------------>
offer
200(PRACK)
----------------------
/ answer
/
/ 200(ini-INVITE)
<----------------------------/-------------------------
/ no sdp
/
ACK /
-------------------------/---------------------------->
/
/ re-INVITE
! <---------------------/--------------------------------
/ offer
/
<-------------------
200(re-INVITE)
------------------------------------------------------>
answer
ACK
<------------------------------------------------------
At the point marked "!", the UAC cannot respond to the re-INVITE
immediately. It must buffer this request until it receives 200(PRACK),
which completes the ongoing offer/answer exchange.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
