Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

William Marshall wrote:
> 
> Gonzalo wrote:
> > 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.
> 
> I'm still a little confused about this.  I don't see where the
> restriction
> is written that the UAS MUST NOT generate a new offer until its answer
> is acknowledged -- only that it send the answer before a new offer.

Right, this is not written at this time, although I believe it should
be.

> 
> There are four separate drafts that interact in making the rules:
> 
> in offer-answer-02, section 8
>   At any point during the session, either participant MAY issue a new
>   offer to modify characteristics of the session.  ...
> in 2543bis-09, section 13.2.1
>   If the initial offer is in an INVITE, the answer MUST be in a reliable
>   non-failure message from UAS back to UAC which is correlated to that
>   INVITE.  ...
> in 100rel-06, section 5
>   If the INVITE contained an offer, the UAS MAY generate an answer in a
>   reliable provisional response. ... If the UAC receives a reliable
>   provisional response with an answer, it MAY generate an additional
>   offer in the PRACK.  If the UAS receives a PRACK with an offer, it
>   MUST place the answer in the 2xx to the PRACK.
> in update-01, section 6.1.1
>   ... for the callee:  If the UPDATE is being sent before the completion
>   of the INVITE transaction, and the initial INVITE contained an offer,
>   the UPDATE annot be sent unless the callee has generated an answer
>   in a reliable provisional response, and has not sent or received
>   other UPDATE requests containing offers that have not been answered.
> 
> It seems to me that a perfectly valid sequence is
>   --- INVITE (offer) --->
>   <-- 183 (answer) ------
>   --- PRACK (offer) \
>   <-- UPDATE (offer) ----
>                       \--
> and at this point there is glare.

Correct.

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

You might still end up rejecting PRACK, which you'd generally prefer to
avoid. My proposal is to incorporate Gonzalos suggestion.


> An editorial nit in update-01, section 6.1.1 final paragraph should
> reference section 14.1 of RFC BBBB, not section 4.1.

Fixed.

-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