>-----Original Message----- >From: sipping-bounces@xxxxxxxx >[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg >Sent: Monday, March 02, 2009 11:48 AM >To: Hadriel Kaplan; Gonzalo Camarillo; sipping >Subject: Re: Summary of Closing the offer/answer >rollback issue? > > >Hi, > >>>I think the one of the main issues at the moment is what >happens after > >>>preconditions have been met on both sides: >>> >>>1) Is the change now commited/in-use, and a re-INVITE failure would >not >>>change that? <----- "in-use" >alternative >>>OR >>>2) Would a re-INVITE failure cause a fallback (this is what is meant >by >>>"late commitment")? <---- "late >commitment" alternative >> >>Ahh. Well if that's the issue, I vote for doing exactly >whatever would >>happen if a normal (non-pre-conditional) SDP offer/answer is >exchanged >>and the re-INVITE fails. I have absolutely no idea what that >would be, >>but it should be the same. :) (I mean I know what 3261 says, that it >>reverts all the way back, but I have no idea if that's actually what >>most people do) > >Sure, the issue is valid also for non pre-condition use-cases. > >For example. > >The UAC sends an SDP offer in a re-INVITE, and receives an SDP >answer in a reliable 18x. But, then what happens when the >re-INVITE fails? To complicate it even futher, there may be some UPDATE transacations with sdp between the two endpoints in session, before there is a final response to re-Invite. Since the transaction is complete in media plane, I think it should stay even if actual signaling transacation finally fails. And that's not what RFC 3261 says. Sanjay > >1) Is the change now commited/in-use, and a re-INVITE failure would not >change that? <----- "in-use" >alternative > >OR > >2) Would a re-INVITE failure cause a fallback (this is what is meant by >"late commitment")? <---- "late >commitment" alternative > >>If I had my druthers the SDP change would stick (not revert), >because I >>personally think it's cleaner, but I can see an argument for >both ways. > >Yes. > >Regards, > >Christer > >_______________________________________________ >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
