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

From: William Marshall <[email-masked]>
Date: Mon, 18 Mar 2002 00:44:30 -0500 (EST)

Jonathan wrote, in part:
> You might still end up rejecting PRACK, which you'd generally prefer to
> avoid. My proposal is to incorporate Gonzalos suggestion.

Could I ask you to be a little more clear on the exact proposed change here.
I think I've heard two suggestions in Gonzalo's emails:
  1) that the UAS be prohibited from sending an UPDATE until it has
	received the PRACK from a 1xx containing an answer
  2) that PRACK never contain an offer SDP (or was it any SDP?)

Point #1 is difficult, since answers contained in 200(Ok) to UPDATE
are not positively acknowledged.  I believe the following two cases
should be considered identical:

  --INVITE (offer)--->     --UPDATE (offer)--->
     X-183 (answer)---       X-200  (answer)---
  <--UPDATE (offer)---     <--UPDATE (offer)---
  -----491----------->     -----491----------->

Thus there will always be the case (lost 200 to UPDATE) where one 
side thinks an offer is pending and the other thinks it has been 
answered.  Error 491 will resolve it.  Forcing the UAS to wait for
the PRACK solves one but not the other.

While prohibiting an offer in a PRACK will work (but is an efficiency
tradeoff), we need to allow an answer to be in the PRACK when the
offer is contained in a 1xx reliable provisional response.  Otherwise
we have UPDATEs with answers, and that is a mess.

As for the efficiency argument -- could someone from 3GPP state whether
offers are currently sent in PRACKs?  If so, is it a problem to change?

Bill Marshall
[email-masked]

-----original message-----
Date: Sun, 17 Mar 2002 23:30:21 -0500
From: Jonathan Rosenberg <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Mar 2002 20:43:35 +0200

Hi,

we have three issues here.

>   <--UPDATE (offer)---     <--UPDATE (offer)---

The 491 mechanism was creates to resolve this problem, so I believe we
do not need to specify anything new. 

2) The second one is the UPDATE-PRACK glare (both carrying an offer).
This is solved by making the UAS to wait for the PRACK before sending a
new UPDATE.

3) The third one is somehow related to the previous one, but there is
not glare. The UAS receives an offer in the PRACK and it wants to refuse
it. I believe that refusing the PRACK with an status code that says
(session description not acceptable) is not a good thing.

Therefore, since offers in PRACK cannot be rejected, I would rule them
out completely... yes, this is less efficient, but I still think it is
the right thing to do.

In general, this problem of not being able to refuse an offer is already
present in SIP every time an offer appears in a response. That's why we
RECOMMEND that offers sent in responses are "pretty similar" to the
session description which is already in use.

I would not like to extend the same problem to offers in PRACKs as well.

Regards,

Gonzalo