Subject: [Sipping] draft-wang.libo-sipping-nested-updates-00.txt

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

Hi all,

I have just written a rough draft about nested UPDATEs. 
As it cannot be uploaded at this moment, I send a copy by the list of 
sipping.

This is just a first version draft and may have mistakes even spelling 
one, thanks for pointing them out.
The only aim of this draft is to make SIP simple but more operational, and 
it is just a suggestion, not intended to forbid anything：）

And, any comments/criticism/sarcasm/flames are welcomed.

Have a nice day. :)

--------------------------------------------------------
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: Dean Willis <[email-masked]>
Date: Thu, 12 Mar 2009 00:35:42 -0500

On Mar 11, 2009, at 10:05 PM, [email-masked] wrote:

> As it cannot be uploaded at this moment, I send a copy by the list  
> of sipping.
>

You know, if we used an eTag to identify a dialog-state, we could  
detect and deal with nested/overlapping/etc. dialog state changes.  
Just an idea.

--
Dean

---

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

Hi，

Thanks for comments.

Tag may be used to identify the classification, help to act different when 
received different UPDATEs.
But i don't think tag will solve the conflicts between new SDP UPDATEs and 
2xx-6xx final response or other message, as these UPDATEs are unexpected.
Regards

---

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

Hi,

Thanks for your comments.

But I think the main branching is treating all UPDATE as sub-transaction 
of Re-INVITE or just treating "precondition"(UPDATE) as sub-transaction of 
Re-INVITE.

Gao 

Dean Willis <[email-masked]> 
2009-03-12 13:35

收件人
[email-masked]
抄送
Gonzalo Camarillo <[email-masked]>, 
<[email-masked]>, "Ian Elz" <[email-masked]>, 
[email-masked], [email-masked], <[email-masked]>, 
<[email-masked]>
主题
Re: [Sipping]  draft-wang.libo-sipping-nested-updates-00.txt

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 12 Mar 2009 08:51:23 +0100

Hi,
 
Comment: 1. If I understand correctly, this draft does only show use-cases, and gives a BCP recommendation, right? It does not talk about what happens when a re-INVITE is rejected, how to solve race conditions etc etc etc.
                2. I agree that is is bad practise to start adding new stuff (codecs, streams etc) in a nested UPDATE - I think that should be done in the re-INVITE itself, and the nested UPDATEs are then used for preconditions, codec refine etc etc. However, I am not sure that a new codec would really require approval from the user. Most people don't care - and/or how no clue - about what codecs are used.
 
Criticism: Even if one would follow the recommendation in chapter 4, I don't think that solves all of our problems.
 
Sarcasm: The examples show that we have a problem, because in some cases you say that you want to add video, but the message flows indicate that you want to add vEdeo.
 
Flames: We now have 4 documents showing use-cases related to this issue (yours, Gao's, and the two from Gonzalo).
 
Regards,
 
Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 12. maaliskuuta 2009 5:06
	To: Gonzalo Camarillo; Christer Holmberg; Ian Elz; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: [Sipping] draft-wang.libo-sipping-nested-updates-00.txt

	Hi all,
	
	I have just written a rough draft about nested UPDATEs. 
	As it cannot be uploaded at this moment, I send a copy by the list of sipping. 
	
	This is just a first version draft and may have mistakes even spelling one, thanks for pointing them out. 
	The only aim of this draft is to make SIP simple but more operational, and it is just a suggestion, not intended to forbid anything：）

	Have a nice day. :)

---

From: [email-masked]
Date: Thu, 12 Mar 2009 16:31:14 +0800

Hi,

First,thanks for your comment, criticism, sacasm,and flames!!

Below are my answers.

> 
> Comment: 1. If I understand correctly, this draft does only show 
> use-cases, and gives a BCP recommendation, right? It does not talk 
> about what happens when a re-INVITE is rejected, how to solve race 
> conditions etc etc etc.

Yes, it's a BCP recommendation, but if every terminal obeys the 
suggestions, solution to rejected re-INVITE seems easier.

>                 2. I agree that is is bad practise to start adding 
> new stuff (codecs, streams etc) in a nested UPDATE - I think that 
> should be done in the re-INVITE itself, and the nested UPDATEs are 
> then used for preconditions, codec refine etc etc. However, I am not
> sure that a new codec would really require approval from the user. 
> Most people don't care - and/or how no clue - about what codecs are 
used.

I agree, Codec refine modification usually donesn't need user approval.
But nested UPDATEs with new video probably need.

> Criticism: Even if one would follow the recommendation in chapter 4,
> I don't think that solves all of our problems.
> 

I'm glad to hear the problems:)

> Sarcasm: The examples show that we have a problem, because in some 
> cases you say that you want to add video, but the message flows 
> indicate that you want to add vEdeo.

I will correct it next version,thanks!!

> 
> Flames: We now have 4 documents showing use-cases related to this 
> issue (yours, Gao's, and the two from Gonzalo).

My document is not intended to provide ways to solve the rollback 
problems, and I think 
there are lots of arguments about the rollback and will be solved at last.

My document aims to make the scene more clear, negotiation easier, but 
more controllable!!

Thanks for comments again!

> To: Gonzalo Camarillo; Christer Holmberg; Ian Elz; pkyzivat@cisco.
> com; [email-masked]; [email-masked]; [email-masked]

sipping.
> 
> This is just a first version draft and may have mistakes even 
> spelling one, thanks for pointing them out. 
> The only aim of this draft is to make SIP simple but more 
> operational, and it is just a suggestion, not intended to forbid 
anything：）

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