Correction. In my earlier response below I totally misread scenario 4.
I'm updating my response to it.
Paul
Pamela,
Are you familiar with:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-09.txt
The race-examples draft and the offeranswer draft got going
independently, with different foci, but there is an area of overlap in
scope. There is a lot in the offeranswer draft that touches on your
cases. In particular, section 4.1 of that document addresses this sort
of thing. I'll say more in line.
I do appreciate your coming at this from a formal model perspective. We
weren't that thorough, and can easily have left holes. We just have to
get your models to adequately reflect reality. (And unfortunately the
reality is sometimes not pretty.)
Thanks,
Paul
Pamela Zave wrote:
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.
I think this is indeed a new case. The UAC can't distinguish this from
the case where the re-INVITE 2 was sent even before the prior 200 was
received. But it is very close to what is described in section 14.2 of
3261.
My thought is that the UAC should send a 491 response to the re-INVITE
2. But this case isn't specifically addressed.
The UAC could also try delaying in hope of getting the ACK, but that
seems more trouble.
This *ought* to be addressed in section 4.1 of offeranswer. I just
rewrote that section last weekend because nobody could understand it
before. But sadly it misses this case. Table 4 needs another row or two
to cover this.
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.
This case is declared to be illegal. The rule (not so clear in the RFCs,
clarified in offeranswer) is that after the first o/a exchange of an
INVITE, you cannot initiate another o/a exchange using the 1xx/2xx/PRACK
for that same INVITE. (If you want another o/a exchange before
completing the INVITE you must use UPDATE to do it.)
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)
<------------------------------------------------------
Same response as for 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.
I think the alarm bells go off for the UAC when it receives the 200 for
the ini-invite. It really shouldn't want to send the ACK yet, because as
far as it is concerned, it has an unanswered offer outstanding.
So my inclination would be that the UAC should just ignore the
200(ini-INVITE), sending no ACK. This will force the UAS to retransmit
it. The UAC doesn't know that the PRACK with answer is enroute, but in
this case it would then probably arrive before the 200 is retransmitted,
so things would recover.
But this is an interesting case to call out.
As I noted above, I just rewrote section 4.1 of the offer/answer draft,
but it is lacking your scenarios 1 & 4. If you have any thoughts on how
to better treat section 4.1 I would be pleased to hear them.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
