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

[William Marshall <wtm@research.att.com>]

> 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
wtm@research.att.com

-----original message-----
Date: Mon, 18 Mar 2002 20:43:35 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
To: William Marshall <wtm@research.att.com>
Cc: jdrosen@dynamicsoft.com, sip@ietf.org
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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip