Subject: [Sipping] Draft: Essential correction for re-INVITE rollback in RFC3261

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 9 Jan 2009 10:32:36 +0100

Hi,

I've put together the first version of the draft related to the
re-INVITE follback fix, based on the agreed solution.

I had some problems with the IETF submission tool, but the draft can be
found at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-r
ollback-00.txt

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Jan 2009 00:29:26 +0100

Would appreciate if you could distill a single paragraph in section 5 about what goes wrong if the user therefore makes the incorrect decision about what to do as a result of this lack of specification.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, January 09, 2009 9:33 AM
To: sipping LIST
Subject: [Sipping] Draft: Essential correction for re-INVITE rollback in RFC3261

Hi,

I've put together the first version of the draft related to the re-INVITE follback fix, based on the agreed solution.

I had some problems with the IETF submission tool, but the draft can be found at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 Jan 2009 11:08:46 +0100

Hi, 

>1. 
>In "draft-ietf-sipping-sip-offeranswer-08.txt ", there is a use case: 
>The case of 
>adding a new media (like adding video to audio only session) which 
>requires permission from the peer through some user interaction is 
>one example. 
>From the user's viewpoint, he(or she) just reject the modification of session, so 
>the offer/answer should be rollback. 
>So, "any session
>parameters that have been sucessfully changed during the duration of
>the re-INVITE transaction MUST remain unchanged" is not reasonable for all 
>application use case. 

We have agreed that we cannot define different rules for different use-cases. We need to have a generic rule, and implementors shall then use that.

There was a long discussion on which solution to go for, and the text now reflects the agreed solution (which we also informed 3GPP about).

Regards,

Christer

	
	2. 
	There are nested transactions concept in application level above of offer/answer 
	which use a offer/answer pair as a sub-transaction. So, commit/rollback is not just 
	offer/answer issue, it is a application issue(such as precondition may have more than 
	one offer/answer pairs).And application level usage of offer/answer should be open for 
	the future extension. 
	
	3. 
	I just submitted a draft talking about session state 2009-01-08: 
	
	https://datatracker.ietf.org/idst/status.cgi?submission_id=11690 
	
	the document URL: 
	
	http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-00.txt 
	
	(the URL "http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-01.txt" 
	is not available, but the 00.txt is the current one) 

	"Christer Holmberg" <[email-masked]> 
	发件人:  [email-masked] 

	2009-01-09 17:32 

		收件人
		"sipping LIST" <[email-masked]> 
		抄送
		
		主题
		[Sipping] Draft: Essential correction for re-INVITE rollback in        RFC3261

	Hi, 

	http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt <http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt>  

	Regards, 

	Christer _______________________________________________

	--------------------------------------------------------
	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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Jan 2009 08:33:10 +0100

Hi,
 
I agree that pre-conditions may be performed before the user is prompted, which may then cause the re-INVITE to fail. That was also previously discussed on the list.
 
Now, if resources have been reserved, and the re-INVITE fails, there is nothing which prevents entities to release those resources.
 
Also, if additional m- lines have been added, you will need to send a new re-INVITE/UPDATE to remove it. That's what we call a "manual fallback".
 
Also, if you look at the old thread, there was a discussion about a possible race condition which could occur if you do a full fallback.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 13. tammikuuta 2009 2:43
	To: Christer Holmberg
	Cc: sipping LIST; [email-masked]
	Subject: 答复: RE: [Sipping] Draft: Essential correction for re-INVITE rollback in RFC3261

	"draft-gaoyang-sipping-session-state-criterion-00.txt", clarify that there is no 
	 ambiguous state of session modification using current RFC definition. 
	Just using current RFC definition， and without violation or new definition. 
	
	My points of view: 
	
	1、It should make the user have the capability to accept or refuse session modification 
	(see "Intuitionistic(user point of view) requirement for rejecting session modification"). 
	
	In my points of view, IMS(3GPP) as the multimedia platform, it should be enriched with 
	this intuitionistic(user point of view) requirement. 
	
	Considering precondition, it is always exchange offer/answer(and modified the session parameters) 
	before prompting the end user. 
	
	2、offer/answer is atomic, but it can be part of a nested transaction. Such as modification with precondition 
	may have more than one offer/answer pair. So the modification is atomic, and the offer/answer is its part. 
	
	If the precondition is not just about resource reservation(for example, two precondition, one about 
	resource reservation, another about other application aspect). 
	So when meeting precondition about resource reservation, the session parameters have been modified(sucessfully). 
	But if the precondition about other application aspect is not meeted, this modification should be discard. 
	
	So, how the application level will using the offer/answer as part of a nested transaction, is just beyond the offer/answer definition. 
	And we should open the gate for the application level extention. 

	

2009-01-12 18:08 

收件人
<[email-masked]> 
抄送
"sipping LIST" <[email-masked]>, <[email-masked]> 
主题
RE: [Sipping] Draft: Essential correction for re-INVITE rollback in        RFC3261

	Hi, 

	
	
	Regards,
	
	Christer

	                
	                2. 
	                
	                3. 

	                the document URL: 

	                

	                2009-01-09 17:32 

	                                 收件人
	                                 
	                                 主题

	
	
	                Hi, 

	
	
	                Regards,

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 Jan 2009 09:44:14 +0100

>Why we do not choose automatic fallback by two peer(UAC and UAS) to rollback to the state before Re-INVITE , while it has no ambiguous state of session. 
>(please refer to "draft-gaoyang-sipping-session-state-criterion-00") 

We were actually planning to choose full rollback (to the state before the re-INVITE), but then someone raised a race condition problem. I don't remember the name of the thread discussing that, though.

>While automatic fallback has no fault, so I think it is no a better solution to use "manual fallback". 

See the thread about the race condition.

>1、"manual fallback" has race condition too, while the two peer issue its own Re-INVITE/UPDATE. And I think "manual fallback" is much more 
>like a refresh process. It may be a optional process, but it can not be the theoretical explanation. 

The protocol can deal with the case when two peers send re-INVITE/UPDATE.

The race condition (ok, maybe the wording is bad) was related to the fact that the UAS does not know whether an offer is sent before or after the UAC received the re-INVITE error response.

>2、I am glad to get your comments on "draft-gaoyang-sipping-session-state-criterion-00", which has the attitude that 
>there has no ambiguous state of session for unsuccessful Re-INVITE. 
>	
>"draft-gaoyang-sipping-session-state-criterion-00" has no new definition or violation of current RFC, it is just clarification for 
>debate on the topic of "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE".   

Please try to look for the problem I mentioned above, and see whether you think it can be solved.

Regards,

Christer

	

	2009-01-13 15:33 

		收件人
		<[email-masked]> 
		抄送
		"sipping LIST" <[email-masked]>, <[email-masked]> 
		主题
		RE: RE: [Sipping] Draft: Essential correction for re-INVITE rollback in        RFC3261

	Hi, 

	  

	Regards, 
	  
	Christer 

	
	My points of view: 

	

	

	2009-01-12 18:08 

		收件人
		<[email-masked]> 
		抄送

	

	Hi, 

	
	
	Regards,
	
	Christer

	               
	               2. 
	               
	               3. 

	               the document URL: 

	               

	               2009-01-09 17:32 

	                                收件人
	                                
	                                主题

	
	
	               Hi, 

	
	
	               Regards,

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2009 09:21:17 -0500

Just to support Christer: I was initially in favor of the full rollback
approach. But the discussion showed that it had the race condition that
Christer mentions. We considered introducing additional machinery to
resolve that race, but that just complicated things further, especially
backward compatibility, for an obscure case.

So, I have come to understand that there is no ideal answer, and so am
satisfied with the one that was chosen.

I realize that not everybody knows all the history of this, so we
explain it again, but we can't re-open the decision at this point.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 13 Jan 2009 11:47:37 -0800

> Just to support Christer: I was initially in favor of the
> full rollback approach. But the discussion showed that it
> had the race condition that Christer mentions. We
> considered introducing additional machinery to resolve
> that race, but that just complicated things further,
> especially backward compatibility, for an obscure case.
>
> So, I have come to understand that there is no ideal
> answer, and so am satisfied with the one that was chosen.

As mentioned within an August thread, I'm not necessarily opposed to the adjustment.

http://www.ietf.org/mail-archive/web/sipping/current/msg16073.html

However as mentioned within an email I sent Friday, I'm currently still unsure of the specifics of the chosen approach.  What is the meaning of "successfully" updated/changed as criteria to not rollback session parameters?  What are the rules concerning non session parameters (such as Contact)?

http://www.ietf.org/mail-archive/web/sipping/current/msg16567.html

> I realize that not everybody knows all the history of
> this, so we explain it again, but we can't re-open the
> decision at this point.

Since the decision has been made, hopefully somebody knows the answers to the above questions.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2009 15:04:46 -0500

Brett,

If the question is about the rollback, or not, of the Contact address...

IMO there was never really any question of rolling back Contact. If the 
request contains a new contact, and if the request itself succeeds, then 
the Contact is updated, and isn't ever rolled back after that.

Its hard for me to imagine that it could work any other way.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 13 Jan 2009 12:50:08 -0800

Hi Paul,

Thanks for the response.  Reply inline.

> If the question is about the rollback, or not, of

That was one of the questions.

> IMO there was never really any question of rolling
> back Contact.

Draft-holmberg-sipping-reinvite-rollback-00 section 1 indicates:

"Different solutions were discussed, and it was agreed that session parameters that have been sucessfully updated are not rolled back in the case of a re-INVITE failure.  The same applies to any other parameter, e.g. that remote target, that have been sucessfully changed."

Draft-holmberg-sipping-reinvite-rollback-00 does contain normative text associated with the last sentence of the above quote.  It also does not define "sucessfully updated" concerning session parameters and other parameters; thus I'm not sure what it means.

1) received re-INVITE, 2) sent 18x, 3) reliable 18x's PRACK successful prior to sending failure response, 4) sent INVITE 2xx 5) UPDATE transaction was successful during the re-INVITE transaction which failed and/or 6) something else.

> If the request contains a new contact,
> and if the request itself succeeds, then the Contact
> is updated, and isn't ever rolled back after that.

What is meant by "request itself succeeds": 1) received re-INVITE, 2) sent 18x, 3) reliable 18x succeeds PRACK successful prior to sending failure response, 4) sent INVITE 2xx 5) UPDATE transaction was successful during the re-INVITE transaction which failed and/or 6) something else.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2009 20:35:38 -0500

Brett,

Sorry, I'm busy and didn't think much before replying.
You are right that it isn't clear. If you receive a reINVITE with a 
changed Contact, and respond with something other than 2xx, then what do 
you do about the Contact?

There are some cases in which you shouldn't accept it. E.g. if you are 
responding with 401 or 481, or maybe if you respond with 100 while you 
think about it. But if you decide it is good enough to begin to process, 
(which would be evidenced eventually by a 1xx or 2xx response, but you 
may decide before sending that) then I think you accept the Contact, and 
then never roll it back.

Is it necessary that the UA sending the changed Contact to know that it 
has been accepted? I think only if it has the ability to continue to 
support both and needs to know when it can stop supporting the old one. 
The best evidence for doing that is receiving a message at the new 
address, but that might not happen for a long time in some cases.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Jan 2009 07:46:24 +0100

Hi, 

>If Re-INVITE issues session modification of adding new media component(such as vedio), and the modification is rejected by the peer. 
>	
>The media parameters may changed successfully before rejection(such as precondition), the media parameters should rollback. 
>
>
>	
>	My main attitude is that: 
>	
>	1、Offer/Answer after the Re-INVITE may be part of the modification issued by Re-INVITE. Such as UPDATE(with precondition notification) and PRACK(refine codecs in 3GPP usage). 

Correct. But, the UPDATE may also be used for something ELSE than precondition notification.

>	2、If Offer/Answer after the Re-INVITE is a new modification, it has nothing to do with Re-INVITE and its failure. (we have no reason to say that 
>	the the new successful modification should be commited by the signal(2XX of Re-INVITE) associate to the original 
>	modification request.) 

Isn't that what we are saying? If I send UPDATE after re-INVITE, and receive 2xx for UPDATE, whatever was changed in the UPDATE transaction stays changed. It doesn't matter if I then receive non-2xx for the re-INVITE.

It would be much easier if we had a dedicated SIP request for precondition notifications (we used to have COMET, didn't we? :). We could then say that it is fully rolled back if the re-INVITE fails. The problem now is that UPDATE can be used for precondition notficiations AND actual parameter changes.

Regards,

Christer

	draft: 
	URL: http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-00.txt 

	Brett Tate <[email-masked]> 
	发件人:  [email-masked] 

	2009-01-14 03:47 

		收件人
		Paul Kyzivat <[email-masked]>, Christer Holmberg <[email-masked]>, sipping LIST <[email-masked]> 
		抄送
		
		主题
		Re: [Sipping] Draft: Essential correction for re-INVITE rollback        in        RFC3261

	

	
	
	Thanks,
	Brett

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 14 Jan 2009 07:50:49 +0100

Hi,
 
How do I know whether an UDPATE has "association" with the original modification (triggered by re-INVITE)?
 
For preconditions I guess we could say so. 
 
But, if I e.g. do some codec changes in an UPDATE, is that "associated" with the original modification? If I change the contact parameter, is that "associated" with the original modification?
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 14. tammikuuta 2009 7:56
	To: Paul Kyzivat
	Cc: Christer Holmberg; sipping LIST; [email-masked]
	Subject: 答复: Re: [Sipping] Draft: Essential correction for re-INVITE rollback in RFC3261

	Adding more expatiation on it: 
	
	If latter Offer/Answer(such as in UPDATE/200OK) having nothing to do with the original modification triggering by Re-INVITE, it is just a new modification 
	as the original one. Its commit/rollbak having nothing to do with Re-INVITE(and its failure). 
	
	But if latter Offer/Answer(such as in UPDATE/200OK) having association with the original modification triggering by Re-INVITE, it should be explained with 
	nest transaction semantics. I just explained it using nest transaction concept, without introducing any new definition. 
	
	I find that current well known extension usage of Offer/Answer such as precondition(and others) just keeping to the explanation using nest transaction concept. The nest transaction concept is the nature property of such extension usage of Offer/Answer, not my invention. Such as suspending of session establishment/modification. 
	
	How extension usage of Offer/Answer define the association of latter Offer/Answer and the original modification is the responsibility of the extension usage itself. And it should be open for extension usage of Offer/Answer in the future. 
	I just point out this, I mean all of this is just clarify, no definition. 

	
Paul Kyzivat <[email-masked]> 

2009-01-13 22:21 

收件人
Christer Holmberg <[email-masked]> 
抄送
[email-masked], [email-masked], sipping LIST <[email-masked]> 
主题
Re: [Sipping] Draft: Essential correction for re-INVITE rollback in        RFC3261

	
	
	                Thanks,
	                Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jan 2009 09:13:54 -0500

A race condition occurs in some cases if the sender of a reINVITE
subsequently sends an UPDATE before receiving the final response for the
reINVITE. If a failure response to the reinvite is sent at roughly the
same time, the UPDATE may be received either *before* or *after* the
failure response is sent.

So if we are trying to roll back any changes occurring within the
reINVITE, we then have to decide if this UPDATE is associated with the
reINVITE or not. To the UAC it certainly is. But to the UAS, it is if
received before the sending the failure response, but not if received
after sending that response. So the UAC will always roll it back, and
the UAS will *sometimes* roll it back, and sometimes not. This of course
will lead to trouble.

	Thanks,
	Paul

[email-masked] wrote:
> If latter Offer/Answer(such as in UPDATE/200OK) having nothing to do 
> with the original modification triggering by Re-INVITE, it is just a new 
> modification
> But if latter Offer/Answer(such as in UPDATE/200OK) having association 
> with the original modification triggering by Re-INVITE, it should be 
> explained with
> nest transaction semantics. *I just explained it using nest transaction 
> concept, without introducing any new definition.*
> 
> I find that current well known extension usage of Offer/Answer such as 
> precondition(and others) just keeping to the explanation using nest 
> transaction concept. *The nest transaction concept is the nature 
> property of such extension usage of Offer/Answer*, not my invention. 
> Such as suspending of session establishment/modification.
> 
> How extension usage of Offer/Answer *define the association of latter 
> Offer/Answer and the original modification is the responsibility of the 
> extension usage itself*. And it *should be open for extension usage of 
> Offer/Answer in the future*.
> *Paul Kyzivat <[email-masked]>*
> 
> 2009-01-13 22:21
> 
> 	
> 收件人
>  >> Why we do not choose automatic fallback by two peer(UAC and UAS) to 
> rollback to the state before Re-INVITE , while it has no ambiguous state 
> of session.
>  > We were actually planning to choose full rollback (to the state 
> before the re-INVITE), but then someone raised a race condition problem. 
> I don't remember the name of the thread discussing that, though.
>  >
>  >                  
>  >> 1、"manual fallback" has race condition too, while the two peer 
> issue its own Re-INVITE/UPDATE. And I think "manual fallback" is much more
>  > The race condition (ok, maybe the wording is bad) was related to the 
> fact that the UAS does not know whether an offer is sent before or after 
> the UAC received the re-INVITE error response.
>  >
>  >
>  >> 2、I am glad to get your comments on 
> "draft-gaoyang-sipping-session-state-criterion-00", which has the 
> attitude that
>  >> "draft-gaoyang-sipping-session-state-criterion-00" has no new 
> definition or violation of current RFC, it is just clarification for
>  >                                   RE: RE: [Sipping] Draft: Essential 
> correction for re-INVITE rollback in        RFC3261
>  >
>  >                                  
>  >
>  >
>  >
>  >
>  >                    
>  >                  Hi,
>  >                    
>  >                  I agree that pre-conditions may be performed before 
> the user is prompted, which may then cause the re-INVITE to fail. That 
> was also previously discussed on the list.
>  >                    
>  >                  Now, if resources have been reserved, and the 
> re-INVITE fails, there is nothing which prevents entities to release 
> those resources.
>  >                    
>  >                  Also, if additional m- lines have been added, you 
> will need to send a new re-INVITE/UPDATE to remove it. That's what we 
> call a "manual fallback".
>  >                    
>  >                  Also, if you look at the old thread, there was a 
> discussion about a possible race condition which could occur if you do a 
> full fallback.
>  >                    
>  >                  Regards,
>  >                    
>  >                  Christer
>  >                    
>  >                    
>  >                    
>  >                  
>  >                  
>  >                  Subject: 答复: RE: [Sipping] Draft: Essential 
> correction for re-INVITE rollback in RFC3261
>  >                  
>  >                  
>  >                 
>  >                  Considering precondition, it is always exchange 
> offer/answer(and modified the session parameters)
>  >                  2、offer/answer is atomic, but it can be part of a 
> nested transaction. Such as modification with precondition
>  >                  may have more than one offer/answer pair. So the 
> modification is atomic, and the offer/answer is its part.
>  >                  
>  >                  If the precondition is not just about resource 
> reservation(for example, two precondition, one about
>  >                  So when meeting precondition about resource 
> reservation, the session parameters have been modified(sucessfully).
>  >                  But if the precondition about other application 
> aspect is not meeted, this modification should be discard.
>  >                  
>  >                  So, how the application level will using the 
> offer/answer as part of a nested transaction, is just beyond the 
> offer/answer definition.
>  >                                   RE: [Sipping] Draft: Essential 
> correction for re-INVITE rollback in        RFC3261
>  >
>  >
>  >                                  
>  >
>  >
>  >                  
>  >                  
>  >                  
>  >                  
>  >                  Hi,
>  >                  
>  >                  
>  >                  >1.
>  >                  We have agreed that we cannot define different rules 
> for different use-cases. We need to have a generic rule, and 
> implementors shall then use that.
>  >                  
>  >                  There was a long discussion on which solution to go 
> for, and the text now reflects the agreed solution (which we also 
> informed 3GPP about).
>  >                  
>  >                  Regards,
>  >                  
>  >                  Christer
>  >                  
>  >                  
>  >                                
>  >                                
>  >                                 2.
>  >                                 There are nested transactions concept 
> in application level above of offer/answer
>  >                                 which use a offer/answer pair as a 
> sub-transaction. So, commit/rollback is not just
>  >                                 offer/answer issue, it is a 
> application issue(such as precondition may have more than
>  >                                 one offer/answer pairs).And 
> application level usage of offer/answer should be open for
>  >                                 the future extension.
>  >                                
>  >                                 3.
>  >                                 (the URL 
> "http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-01.txt" 
> 
>  >                                                  [Sipping] Draft: 
> Essential correction for re-INVITE rollback in        RFC3261
>  >                  
>  >                                                  
>  >                  
>  >                  
>  >                  
>  >                  
>  >                  
>  >                                 Hi,
>  >                  
>  >                                 I've put together the first version 
> of the draft related to the re-INVITE follback fix, based on the agreed 
> solution.
>  >                  
>  >                                 I had some problems with the IETF 
> submission tool, but the draft can be found at:
>  >                  
>  >                                 
> <http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt> 
>  
>  >                  
>  >                                 Regards,
>  >                  
>  >                                 Christer 
>  >                                 Sipping mailing list 
>  https://www.ietf.org/mailman/listinfo/sipping
>  >                                 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.
>  >                  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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 Jan 2009 14:19:39 +0100

Hi, 

>If it is a new modification, it should be commited. 
>	
>The failure of Re-INVITE just show the ending of the old modification. 
>	
>Modification is exclusive, so when the new one is in process, the old one has discarded. 

Isn't this exactly what we are trying to say? When the re-INVITE fails, any old UPDATE/PRACK modification remains unchanged.

But, it seems like you want some types of modifications to remain unchanged, and others to be rolled back to the state BEFORE the re-INVITE, beased on the "association" with the re-INVITE. You need to give a generic definition for that association. We can not list detailed use-case, and say which is associated and not, because then we need to figure out every possible use-case and say whether they are associated or not.

Regards,

Christer

	

	2009-01-14 14:46 

		收件人
		<[email-masked]>, "Brett Tate" <[email-masked]> 
		抄送
		"Paul Kyzivat" <[email-masked]>, "sipping LIST" <[email-masked]>, <[email-masked]> 
		主题
		RE: Re: [Sipping] Draft: Essential correction for re-INVITE rollback        in        RFC3261

	Hi, 

	

	Regards,
	
	Christer

	

	                
	                
	                draft: 

	
	                2009-01-14 03:47 

	                                 收件人
	                                 
	                                 主题

	

	                

	                
	                Thanks,
	                Brett