Re: [Sipping] Rollback issue: a proposal - impact on essential corrections draft

["Christer Holmberg" <[e-mail]>]

 
Hi,

If we decide to adopt the proposal in Gonzalo's draft, it will of course
have impact on the draft which tries to identify the essential
corrections based on the re-INVITE failure solution. I would say that
Gonzalo's proposal probably has less (if any) normative impacts than the
current solution. 3261 already says indicates that a full rollback
occurs in the case of re-INVITE failure, so I guess the question is we
need to add something extra.

But, we can discuss that once we have decided whether we are going to
adopt the new proposal.

In addition, we would also need to send a new LS reply to 3GPP.

Regards,

Christer



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Gonzalo Camarillo
Sent: Tuesday, March 03, 2009 6:17 PM
To: gaoyang
Cc: [e-mail]
Subject: Re: [Sipping] Rollback issue: a proposal

Hi,

> Comments for
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-0
> 0.txt
>  
> 1. I think that it is BCP level. And the solution can be effective by 
> restricting Non-2xx when Offer/Answer pair has been exchanged.

yes, we will need to decide on the status (BCP vs. PS vs. Informational)
at some point.

> 2. Your proposal considered legacy UAS. But currently, the situation 
> is legacy UAC with legacy UAS. And it is the original issue.

the draft describes the behavior of a new UAC that faces a legacy UAS,
which is the interesting situation. Other situations are not interesting
because a legacy UAC will be able to do the right thing when facing a
new UAS and if we have a legacy UAC against a legacy UAS, there is
nothing we can do because they were implemented some time ago and are
already out there.

> 3. "In order to undo changes that were already executed, the UAS uses
a new
>    offer/answer exchange or a target refresh request."
> If the new offer/answer exchange need precondition, the other side can

> reject it with 504. then the modification(undo changes) may not be 
> done by UPDATE/200OK. And Re-INVITE can not be used here(for the 
> pending original Re-INVITE).

The whole point is that the UAS should not send an error response. It
should send a 200 (OK) to the re-INVITE and then use traditional
mechanisms (i.e., UPDATEs or re-INVITEs) to modify the session if
needed.


> Comments for
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00
> .txt
>  
> 1. "However, the fact that the UAs can start using the new media 
> parameters does not mean that they need to start using them 
> immediately." Yes.

we agree on this one, then.

> More than one Offer/Answer pais before Precondition Ok, and Caller can

> be answerer for some and Callee for the others. Then the two sides may

> waiting peer using new parameters after Precondition OK. It may be 
> deadlock.

No, they will not be a deadlock because the UAS is in charge of starting
using the new parameters and of initiating a new offer/answer exchange.

Thanks for your comments,

Gonzalo
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[e-mail] for questions on current sip Use
[e-mail] for new developments of core SIP