Hi, > Comments for > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.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
