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

From: William Marshall <[email-masked]>
Date: Mon, 18 Mar 2002 13:54:35 -0500 (EST)

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

is this the start of rfc3262bis-00?

Bill Marshall
[email-masked]

-----original message-----
Date: Mon, 18 Mar 2002 20:43:35 +0200
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05

Hi,

we have three issues here.

1) The first one is update glare:

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

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

_______________________________________________
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 21:49:25 +0200

Hi,

> is this the start of rfc3262bis-00?

There is not such an RFC in the archives, so there is no reason for a
bis.
http://www.ietf.org/iesg/1rfc_index.txt

Regarding
http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-06.txt

You are right that we may need a small modification. If this suggestion
was taken into account, it would be necessary to remove the following
lines from the draft:

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

But it may be too late for doing so, so we may have to live without
refusing offers in PRACKs.

Regards,

Gonzalo