Subject: [Sip] INVITE dialogs

From: Pamela Zave <[email-masked]>
Date: Wed, 5 Nov 2008 10:41:03 -0500

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2008 13:20:03 -0500

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

> SCENARIO 1.  This scenario occurs within a confirmed dialog.

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.

> although immediate response is required by the standard.  Rather, it must
> the ongoing offer/answer exchange.  The UAC CANNOT assume that the update

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.)

> although the race condition that causes it is different.

Same response as for 2.

>                  ini-INVITE

I don't understand this one at all. You are showing another *initial* 
invite, which would (by defintion) be establishing a separate dialog. 
There is then no interference between the two dialogs - they should be 
analyzed separately.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Nov 2008 14:32:01 -0500

Correction. In my earlier response below I totally misread scenario 4. 
I'm updating my response to it.

	Paul

Pamela,

Are you familiar with:

	Thanks,
	Paul

Same response as for 2.

>                  ini-INVITE

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

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Thu, 6 Nov 2008 10:22:55 +0800

Some comments for scenario 4 below. thanks
-Rockson 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
Sent: Thursday, November 06, 2008 3:32 AM
To: Pamela Zave
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] [Sip] INVITE dialogs

	Paul

Pamela,

Are you familiar with:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-0
9.txt

	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

> 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.

Same response as for 2.

> immediately.  It must buffer this request until it receives 
> 200(PRACK), which completes the ongoing offer/answer exchange.

[RL] actually, I think caller here could respond 491 for re-INVITE with
offer here, RFC3311 sec 5.2 has similar case.
<snip>
   If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response. 
</snip>

	Thanks,
	Paul
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Nov 2008 10:25:13 -0500

> Some comments for scenario 4 below. thanks

Snipping down to there, then response.

>    not yet received an answer, the UAS MUST reject the UPDATE with a 491

If the UAC lets things get that far, then a 491 might be appropriate. 
But as I noted above, the UAC already has a problem when it gets the 200 
to the initial invite, because it has an incomplete o/a. It doesn't know 
how that is going to work out.

*IF* it decides to send the ACK and then wait for the 200(PRACK), then 
what you suggest makes sense.

If it fails to send the ACK, then that should squelch the possibility of 
getting the reINVITE.

	Thanks,
	Paul

---

From: [email-masked]
Date: Thu, 6 Nov 2008 13:54:21 -0500 (EST)

From: Paul Kyzivat <[email-masked]>

I don't think this is a workable solution -- it means that the logic
for handing the INVITE transaction (specifically, sending the ACK) has
to pay attention to the completion status of other transactions.
That's not a good thing to do.

Dale

---

From: [email-masked]
Date: Thu, 6 Nov 2008 13:54:29 -0500 (EST)

From: Pamela Zave <[email-masked]>

   What do you think?

(It is best not to send a message to both SIP and SIPPING.)

It seems that your formalism is capable of dealing with a real
protocol and discovering problems in it.  I don't know if that has
ever been done before.  We should apply this in the future.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Nov 2008 14:31:24 -0500

> That's not a good thing to do.

Well, since this is the *200* response to the INVITE, the ACK is s 
separate transaction generated by the UAC Core.

There is no need to delay the ACK if the response is an error response, 
which is the case when the ACK is part of the same transaction.

	Thanks,
	Paul