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: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Gonzalo Camarillo Sent: Tuesday, March 03, 2009 6:17 PM To: gaoyang Cc: sipping@xxxxxxxx Subject: Re: 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
