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

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

William Marshall wrote:
> 
> 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?

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
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip