Subject: [Sip] Glare with PRACK vs. UPDATE. Was: Question on manyfolks 05

From: William Marshall <[email-masked]>
Date: Thu, 7 Mar 2002 09:37:03 -0500 (EST)

Krisztian Kiss wrote:
> I guess Xin's original question concerned the case when the initial INVITE 
> contains an offer + Require:precondition. When sending the PRACK, the 
> precondition has not been met yet, so the question is whether it is allowed 
> to send a new offer in PRACK with Require:precondition.

I believe this is allowed in the current offer/answe description.
The original offer, in the INVITE, was answered in the provisional
response.  So at that point there is no offer pending, and either
endpoint can send a new offer.  The UAC can include the new offer
in the PRACK message.

However, this is an issue of glare here.  Since there is no 
offer pending, the UAS can also send an updated offer in an
UPDATE message.  While UPDATE vs. UPDATE glare needs to be
covered in the update draft, there is also a possibility of
PRACK vs. UPDATE glare.  In that case, I believe UPDATE
should yield to PRACK in order to make the 100rel work.
Can this case also be covered in the discussion of glare
in the next revision of draft-ietf-sip-ipdate?

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  https://www1.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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Mar 2002 23:22:55 -0500

> in the next revision of draft-ietf-sip-ipdate?

There are really two fixes to this problem.

The first fix, is to codify what has already been suggested by Gonzalo
within this thread:

> A PRACK for a 1xx response that contained an answer can contain an offer
> (as stated in the draft), because the UAS will not generate an UPDATE
> until it receives the PRACK... therefore, in that situation, there is
> not a chance of having a glare condition... it is OK as it is specified.

If the UAS can't send an UPDATE till it gets the PRACK for a 18x that
contained an answer, we will have no PRACK/UPDATE glare.

The second approach was suggested by Bill:
> t seems to me that a perfectly valid sequence is
>   --- INVITE (offer) --->
>   <-- 183 (answer) ------
>   --- PRACK (offer) \
>   <-- UPDATE (offer) ----
>                       \--
> and at this point there is glare.
> 
> The 100rel draft now requires the UAS to respond to the offer in the 
> PRACK with an answer in the 200 (OK).
> 
> The nearest text which is close to this case is update-01 section 6.2.1
>   If an UPDATE is received that contains an offer, and the UAS has
>   generated an offer (presumably in an UPDATE of its own) to which it
>   has not yet received an answer, the UAS MUST reject the UPDATE with a
>   491 response.
> 
> This text in 6.2.1 should be generalized to cover this additional glare
> case, by requiring the UAC to respond to an UPDATE request with a 491
> if it has an outstanding offer pending in a PRACK.  I'd suggest:
>   If an UPDATE is received that contains an offer, and the receiver has
>   generated an offer to which it has not yet received an answer, the 
>   UPDATE MUST be rejected with a 491 response.
> 

If you also specify that a PRACK needs to be rejected if you have sent
an UPDATE to which you didn't get an answer, yes, this will work.

Rejecting PRACK is generally a bad thing. You can't specify that "UPDATE
wins", since that would require both participants to recognize there is
glare, and this is not possible. 

So, to avoid rejection of PRACK, I'd prefer the first option, to add the
text suggested by Gonzalo.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com