Re: [Sipping] Summary of Closing the offer/answer rollback issue?

["Sanjay Sinha (sanjsinh)" <sanjsinh at cisco.com>]

>-----Original Message-----
>From: sipping-bounces at ietf.org 
>[mailto:sipping-bounces at ietf.org] On Behalf Of Christer Holmberg
>Sent: Monday, March 02, 2009 11:48 AM
>To: Hadriel Kaplan; Gonzalo Camarillo; sipping
>Subject: Re: [Sipping] 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 at cs.columbia.edu for questions on current sip 
>Use sip at ietf.org for new developments of core SIP
>