| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-02 16:17 |
|
Hi,
Regarding "committed new modification during Re-INVITE", I don't think there is a difference between yours and Gonzalo's proposal, right?
[Gao] Yes. But the deducing process is not same:
By my proposal, it is committed because it is a new modification. And it can not be rollback by the unsuccess of original pending modification. So, it is commited.
By Gonzalo's, any "in use" modification can not be rollback. So, it is committed.
Regards,
Christer
From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
Sent: 2. maaliskuuta 2009 9:09
To: Sanjay Sinha (sanjsinh)
Cc: Christer Holmberg; Gonzalo Camarillo; Hadriel Kaplan; sipping; sipping-bounces@xxxxxxxx
Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback issue?
| "Sanjay Sinha (sanjsinh)"
<sanjsinh@xxxxxxxxx> 发件人: sipping-bounces@xxxxxxxx 2009-03-02 15:00 |
|
>-----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: [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.
[Gao] Yes.
IMO:
Modification triggered by Re-INVITE MUST rollback as the failure of Re-INVITE. --That is the original concept of RFC3261
Any committed new modification during Re-INVITE with other SIP transaction, would have nothing to do with the Re-INVITE's failure or success. --That is the original concept of RFC3311.
Do you think so?
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
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
