Subject: [Sipping] "UPDATE during Re-INVITE" discussion

From: [email-masked]
Date: Mon, 9 Mar 2009 10:49:13 +0800

There are two thought about "UPDATE during Re-INVITE". Which one is better 
or suits for current RFCs

There are two thought about "UPDATE during Re-INVITE".

1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction
RFC3312(Precondition) is a case. As there is such case, we can making all 
UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.

2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction 
of Re-INVITE
There is really need nested-modification, such as precondition and more in 
the future.  But the cascade of nested transaction should be defined in 
application-level, not signal-level. So, it is better to make Re-INVITE 
and UPDATE separatly expect for definition such as precondition.  And this 
obeys current definition of RFC3311.

In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), 
the change of states is committed and effort at once. And making all 
UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation 
of RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as 
Re-INVITE's sub-transaction.

While UPDATE/200OK just refresh "precondition state table" in 
RFC3312("precondition state table" is modified at once, so this obeys 
RFC3312), having no impat on the commitment of modification triggered by 
Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of 
Re-INVITE.
Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE.

Comments/feeling are welcome!

--------------------------------------------------------
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: "Eric.wang" <[email-masked]>
Date: Mon, 9 Mar 2009 20:05:51 +0800

Hi,

I support view 2,not all update can be considered as sub-transaction of
re-INVITE.

According to current RFCs, it’s NOT proper to consider all UPDATEs as
re-INVITE’s sub-transaction 

Eg:

UPDATE nested in re-INVITE  for target refresh can’t be considered as
sub-transaction.

发件人: [email-masked] [mailto:[email-masked]] 代表
[email-masked]
发送时间: 2009年3月9日 10:49
收件人: SIP; SIPPING
主题: [Sip] "UPDATE during Re-INVITE" discussion

2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of
Re-INVITE 
There is really need nested-modification, such as precondition and more in
the future.  But the cascade of nested transaction should be defined in
application-level, not signal-level. So, it is better to make Re-INVITE and
UPDATE separatly expect for definition such as precondition.  And this obeys
current definition of RFC3311. 

In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the
change of states is committed and effort at once. And making all UPDATEs
during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311.
So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's
sub-transaction. 

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

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3918 (20090309) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: [email-masked]
Date: Tue, 10 Mar 2009 14:53:45 +0800

Yes. If we accept view 1, there would be some backward compatible problem. 
And this is a change to RFC3311.

I am waiting for more comments from people want to keep RFC3311 from 
re-write.

Gao

"Eric.wang" <[email-masked]> 写于 2009-03-09 20:05:51:

> Hi,
> 
> I support view 2,not all update can be considered as sub-transaction
> of re-INVITE.
> According to current RFCs, it’s NOT proper to consider all UPDATEs 
> as re-INVITE’s sub-transaction 
> Eg:
> UPDATE nested in re-INVITE  for target refresh can’t be considered 
> as sub-transaction.

> There are two thought about "UPDATE during Re-INVITE". Which one is 
> better or suits for current RFCs 
> 
> RFC3312(Precondition) is a case. As there is such case, we can 
> making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction. 
> 
> 2. Not all UPDATE(during Re-INVITE) can be considered as sub-
> transaction of Re-INVITE 
> There is really need nested-modification, such as precondition and 
> more in the future.  But the cascade of nested transaction should be
> defined in application-level, not signal-level. So, it is better to 
> make Re-INVITE and UPDATE separatly expect for definition such as 
> precondition.  And this obeys current definition of RFC3311. 
> 
> In RFC3311, when the UPDATE is accepted by the other 
> side(UPDATE/200OK), the change of states is committed and effort at 
> once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-
> transaction can be violation of RFC3311. So, we shold not treat all 
> RFC3312("precondition state table" is modified at once, so this 
> obeys RFC3312), having no impat on the commitment of modification 
> triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-
> transaction of Re-INVITE.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Mar 2009 08:22:12 +0100

I support view 1.
 
Regards,
 
Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 10. maaliskuuta 2009 8:54
	To: Eric.wang
	Cc: 'SIP'; 'SIPPING'
	Subject: [Sipping] 答复: [Sip] "UPDATE during Re-INVITE" discussion

	Yes. If we accept view 1, there would be some backward compatible problem. And this is a change to RFC3311. 
	
	I am waiting for more comments from people want to keep RFC3311 from re-write. 
	
	Gao

---

From: [email-masked]
Date: Tue, 10 Mar 2009 15:35:58 +0800

OK. Thanks for your standpoint.

But accepting this means:
1. Rewrite of current software to be as the behavior defined by 
"draft-camarillo-sipping-reinvite-00".
2. Making all UPDATE/200OK "during" Re-INVITE as Re-INVITE's part.

Gao

"Christer Holmberg" <[email-masked]> 
2009-03-10 15:22

收件人
<[email-masked]>, "Eric.wang" <[email-masked]>
抄送
"SIP" <[email-masked]>, "SIPPING" <[email-masked]>
主题
RE: [Sipping] 答复: [Sip] "UPDATE during Re-INVITE" discussion

I support view 1.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: 10. maaliskuuta 2009 8:54
To: Eric.wang
Cc: 'SIP'; 'SIPPING'
Subject: [Sipping] 答复: [Sip] "UPDATE during Re-INVITE" discussion

Gao 

 

--------------------------------------------------------
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, 10 Mar 2009 09:01:41 +0100

The reason why we have this whole discussion is because the current specifications are unclear. If everything was clear, and everybody had the same understanding, we wouldn't need to clarify anything.
 
So, whatever solution we choose, I am sure that someone will have to "rewrite their software".
 
....IF that software exists in the first place, that is. 
 
I am not aware of any deployments which would support re-INVITEs with nested UPDATEs/PRACKs. Maybe there are such deployments, but I doubt they would all behave in the way as you describe.
 
Regarding your second bullet, I don't even think that one should send "nested" UPDATEs, if they don't have anything to do with the re-INVITE. I think that is bad application design. Non-related changes should be done outside the re-INVITE transaction.
 
Regards,
 
Christer

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 10. maaliskuuta 2009 9:36
	To: Christer Holmberg
	Cc: Eric.wang; SIP; SIPPING
	Subject: [Sip] "UPDATE during Re-INVITE" discussion

	But accepting this means: 
	1. Rewrite of current software to be as the behavior defined by "draft-camarillo-sipping-reinvite-00". 
	2. Making all UPDATE/200OK "during" Re-INVITE as Re-INVITE's part. 
	
	Gao 

	

2009-03-10 15:22 

收件人

	I support view 1. 
	  
	Regards, 
	  
	Christer 

	

	Gao

---

From: [email-masked]
Date: Tue, 10 Mar 2009 16:28:01 +0800

Hi,

2009-03-10 16:01

收件人
<[email-masked]>
抄送
"Eric.wang" <[email-masked]>, "SIP" <[email-masked]>, "SIPPING" 
<[email-masked]>
主题
RE: [Sip] "UPDATE during Re-INVITE" discussion

The reason why we have this whole discussion is because the current 
specifications are unclear. If everything was clear, and everybody had the 
same understanding, we wouldn't need to clarify anything.
[Gao] I think everything is clear. But people have different view towards 
UPDATE. So we need clarification than re-definition here.
 
So, whatever solution we choose, I am sure that someone will have to 
"rewrite their software".
[Gao] Yes. But we should guard the right understanding. And compel people 
with misunderstanding to "rewrite their software". I think make every 
UPDATE/200OK during Re-INVITE as part of Re-INVITE is a "big" change for 
some software.
I support to take UPDATE/200OK just refreshing "precondition state table" 
as part of Re-INVITE. And I think most of current software is doing so.

I am not aware of any deployments which would support re-INVITEs with 
nested UPDATEs/PRACKs. Maybe there are such deployments, but I doubt they 
would all behave in the way as you describe.
[Gao] I just talked about if we want to obey RFC3311, it is not right to 
take all UPDATE/200OK(during Re-INVITE) as part of Re-INVITE.
 
Regarding your second bullet, I don't even think that one should send 
"nested" UPDATEs, if they don't have anything to do with the re-INVITE. I 
think that is bad application design. Non-related changes should be done 
outside the re-INVITE transaction.
[Gao] It is not bullet, just friendly discussion.
And I think the relationship of Re-INVITE and UPDATEs should be defined by 
application level definition, such as precondition. We should not just 
making relationship  by "during".

Gao

Gao 

收件人

I support view 1. 
  
Regards, 
  
Christer 

Gao

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Mar 2009 09:45:02 +0100

With bullet I didn't mean that you were trying to shoot me, or something. "Bullet" in this context refers to the second statement you gave :)

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 10. maaliskuuta 2009 10:28
	To: Christer Holmberg
	Cc: Eric.wang; SIP; SIPPING
	Subject: 答复: RE: [Sip] "UPDATE during Re-INVITE" discussion

	Hi, 

	

2009-03-10 16:01 

收件人
<[email-masked]> 
抄送
"Eric.wang" <[email-masked]>, "SIP" <[email-masked]>, "SIPPING" <[email-masked]> 
主题
RE: [Sip] "UPDATE during Re-INVITE" discussion

	The reason why we have this whole discussion is because the current specifications are unclear. If everything was clear, and everybody had the same understanding, we wouldn't need to clarify anything. 
	[Gao] I think everything is clear. But people have different view towards UPDATE. So we need clarification than re-definition here. 
	  
	So, whatever solution we choose, I am sure that someone will have to "rewrite their software". 
	[Gao] Yes. But we should guard the right understanding. And compel people with misunderstanding to "rewrite their software". I think make every UPDATE/200OK during Re-INVITE as part of Re-INVITE is a "big" change for some software. 
	I support to take UPDATE/200OK just refreshing "precondition state table" as part of Re-INVITE. And I think most of current software is doing so. 

	I am not aware of any deployments which would support re-INVITEs with nested UPDATEs/PRACKs. Maybe there are such deployments, but I doubt they would all behave in the way as you describe. 
	[Gao] I just talked about if we want to obey RFC3311, it is not right to take all UPDATE/200OK(during Re-INVITE) as part of Re-INVITE. 
	  
	Regarding your second bullet, I don't even think that one should send "nested" UPDATEs, if they don't have anything to do with the re-INVITE. I think that is bad application design. Non-related changes should be done outside the re-INVITE transaction. 
	[Gao] It is not bullet, just friendly discussion. 
	And I think the relationship of Re-INVITE and UPDATEs should be defined by application level definition, such as precondition. We should not just making relationship  by "during". 

	Gao 

	
	
	Gao 

2009-03-10 15:22 

收件人

	

	I support view 1. 
	 
	Regards, 
	 
	Christer 

	

	Gao

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Mar 2009 08:04:54 -0700

I think number 2 more accurately represents RFC 3261, RFC 3262, and RFC 3311.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, March 08, 2009 10:49 PM
To: SIP; SIPPING
Subject: [Sip] "UPDATE during Re-INVITE" discussion

There are two thought about "UPDATE during Re-INVITE". Which one is better or suits for current RFCs

1. All UPDATEs during Re-INVITE are Re-INVITE's sub-transaction
RFC3312(Precondition) is a case. As there is such case, we can making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.

2. Not all UPDATE(during Re-INVITE) can be considered as sub-transaction of Re-INVITE
There is really need nested-modification, such as precondition and more in the future.  But the cascade of nested transaction should be defined in application-level, not signal-level. So, it is better to make Re-INVITE and UPDATE separatly expect for definition such as precondition.  And this obeys current definition of RFC3311.

In RFC3311, when the UPDATE is accepted by the other side(UPDATE/200OK), the change of states is committed and effort at once. And making all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction can be violation of RFC3311. So, we shold not treat all UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.

While UPDATE/200OK just refresh "precondition state table" in RFC3312("precondition state table" is modified at once, so this obeys RFC3312), having no impat on the commitment of modification triggered by Re-INVITE, these UPDATE/200OK can be treated as sub-transaction of Re-INVITE.
Other UPDATE/200OK can not be treated as sub-transaction of Re-INVITE.

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Mar 2009 08:04:53 -0700

> The reason why we have this whole discussion is because the 
> current specifications are unclear.

As mentioned before, I think the following RFC 3261 quote is clear although some disagree.

RFC 3261 section 14.1: "If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued."

> Regarding your second bullet, I don't even think that one 
> should send "nested" UPDATEs, if they don't have anything to 
> do with the re-INVITE. I think that is bad application design. 
> Non-related changes should be done outside the re-INVITE transaction.
 
Sending UPDATE per RFC 4028 to refresh or audit the dialog is one of the times UPDATE may be tried while a re-INVITE is occurring.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Mar 2009 16:15:59 +0100

Hi, 

>>"nested" UPDATEs, if they don't have anything to do with the 
>>re-INVITE. I think that is bad application design.
>Sending UPDATE per RFC 4028 to refresh or audit the dialog is 
>one of the times UPDATE may be tried while a re-INVITE is occurring.

True, but normally those UPDATEs are not going to modify session parameters.

So, yes, it may happen, but I think we should recommend against doing so.

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Mar 2009 11:08:35 -0700

>>> should send "nested" UPDATEs, if they don't have anything 
>>> to do with the re-INVITE. I think that is bad application 
>>> design.  Non-related changes should be done outside the 
>>> re-INVITE transaction.
>>
>> Sending UPDATE per RFC 4028 to refresh or audit the dialog
>> is one of the times UPDATE may be tried while a re-INVITE is
>> occurring.
> 

There are two key phrases within rfc3261 which might be adding to the confusion: "session parameters" and "state changes".  RFC 3261 section 12.2.2 and 14.1 basically indicate to rollback as though the re-INVITE was not sent.  There have been numerous proposal concerning what should and shouldn't rollback; it is occasional hard to distinguish if people mean 1) SDP 2) non SDP state data (like Contact, Session-Expires, ...), or 3) both.  

I agree that UPDATE likely wouldn't include SDP when only attempting to refresh or audit the session; however it can.

I think 12.2.2 is sufficiently clear concerning what should occur upon re-INVITE failure; however I think it was unfortunate that section 14.1 indicated "session parameters" instead of "state changes".

RFC 3261 section 12.2.2: "Requests sent within a dialog, as any other requests, are atomic.  If a particular request is accepted by the UAS, all the state changes associated with it are performed.  If the request is rejected, none of the state changes are performed."

Concerning UPDATE in relation to section 12.2.2, I consider it an atomic transaction.  And for it is worth, I consider PRACK to not be an atomic transaction.

---

From: [email-masked]
Date: Wed, 11 Mar 2009 08:22:57 +0800

Precondition do modify session parameters. Precondition state is part of 
session parameters.

The point is that if SDP only refresh "precondtion state table", it has no 
impact on the commitment of session modification.

"Christer Holmberg" <[email-masked]> 
发件人:  [email-masked]
2009-03-10 23:15

收件人
"Brett Tate" <[email-masked]>, "SIPPING" <[email-masked]>, "SIP" 
<[email-masked]>
抄送

主题
Re: [Sipping] [Sip] "UPDATE during Re-INVITE" discussion

Hi, 

>one of the times UPDATE may be tried while a re-INVITE is occurring.

True, but normally those UPDATEs are not going to modify session 
parameters.

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: [email-masked]
Date: Wed, 11 Mar 2009 08:18:59 +0800

Thanks for your standpoint.

And more commment/feeling from more people are welcome.

Brett Tate <[email-masked]> 
2009-03-10 23:04

收件人
"[email-masked]" <[email-masked]>, SIP <[email-masked]>, SIPPING 
<[email-masked]>
抄送

主题

I think number 2 more accurately represents RFC 3261, RFC 3262, and RFC 
3311.

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Sunday, March 08, 2009 10:49 PM
To: SIP; SIPPING
Subject: [Sip] "UPDATE during Re-INVITE" discussion

---

From: [email-masked]
Date: Wed, 11 Mar 2009 08:34:06 +0800

Hi,

I also consider UPDATE/200OK as atomic transaction. And I think UPDATE's 
atomicity has no conflict with Re-INVITE's atomicity in current RFCs. 

As we know, atomicity's semantics is "all or nothing".  And if new 
modification is acceptted, the older pending one would be discarded(that 
is the semantics of "nothing"). Then, UPDATE's atomicity has no conflict 
with Re-INVITE's atomicity.

One special thing is precondition:
First, we should make sure the effect of the later Offer/Answer pairs
   which are used as "refreshing the precondtion state table" during
   suspending state of session.  By RFC3312, these Offer/Answer pairs
   just refresh the precondtion state table, but it has no impact on the
   commitment of the modification.

   Then, as the UAs has adjusted the session parameters(refresh the
   precondtion state table) accordingly, it obeys RFC3311.

   And as current pending session modification is still the one
   triggered by Re-INVITE, and it is only discarded for the failure of Re-
   INVITE, not by "refreshing the precondtion state table".  This obeys 
RFC3261.

Gao

Brett Tate <[email-masked]> 
发件人:  [email-masked]
2009-03-11 02:08

收件人
Christer Holmberg <[email-masked]>, SIPPING 
<[email-masked]>, SIP <[email-masked]>
抄送

主题
Re: [Sip] "UPDATE during Re-INVITE" discussion

> So, yes, it may happen, but I think we should recommend 

There are two key phrases within rfc3261 which might be adding to the 
confusion: "session parameters" and "state changes".  RFC 3261 section 
12.2.2 and 14.1 basically indicate to rollback as though the re-INVITE was 
not sent.  There have been numerous proposal concerning what should and 
shouldn't rollback; it is occasional hard to distinguish if people mean 1) 
SDP 2) non SDP state data (like Contact, Session-Expires, ...), or 3) 
both. 

I agree that UPDATE likely wouldn't include SDP when only attempting to 
refresh or audit the session; however it can.

I think 12.2.2 is sufficiently clear concerning what should occur upon 
re-INVITE failure; however I think it was unfortunate that section 14.1 
indicated "session parameters" instead of "state changes".

RFC 3261 section 12.2.2: "Requests sent within a dialog, as any other 
requests, are atomic.  If a particular request is accepted by the UAS, all 
the state changes associated with it are performed.  If the request is 
rejected, none of the state changes are performed."

Concerning UPDATE in relation to section 12.2.2, I consider it an atomic 
transaction.  And for it is worth, I consider PRACK to not be an atomic 
transaction.

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

---

From: [email-masked]
Date: Thu, 12 Mar 2009 11:41:13 +0800

===================================
 高扬/固网软件开发一部/中心研究院/中兴通讯
 Tel    : 87211
 MSN    : [email-masked]
 e_mail : [email-masked]
 Addr   :南京市雨花台区紫荆花路68号 210012
===================================

收件人

主题

Hi, 

Regards,

Christer