Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

Hi Gao,

let's proceed as follows. Let's focus our efforts in finishing the
re-INVITE draft for now. Once we are done with it, let's decide whether
or not we want to work on clarifying all the open issues related to
preconditions we have been talking about.

Thanks,

Gonzalo

gao.yang2@zte.com.cn wrote:
> 
> Hi Gonzalo,
> 
> Yes, I also found that not many people showed interest in it.
> 
> By deeply discussion "Re-INVITE handling" draft these days, we find that 
> we should clarify how modified media can/should be used. But how 
> modified media can/should/may be used is a more basic topic.
> 
> This topic has influence on other higher level topics, such as 
> "Re-INVITE handling" draft and etc. So, I hope more people could pay 
> attention to it.
> 
> Thanks,
> 
> Gao
> 
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2@zte.com.cn
> ===================================
> 
> 
> *Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>*
> 
> 2010-01-18 16:14
> 
> 	
> 收件人
> 	"gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>
> 抄送
> 	SIPCORE <sipcore@ietf.org>
> 主题
> 	Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt
> 
> 
> 	
> 
> 
> 
> 
> 
> Hi Gao,
> 
> that is why I wrote the draft about preconditions. However, not many
> people showed interest in it at that time.
> 
> Cheers,
> 
> Gonzalo
> 
> gao.yang2@zte.com.cn wrote:
>  >
>  > Hi,
>  >
>  > Maybe clarification of precons has something beyond Re-INVITE handling
>  > text.
>  >
>  > As Re-INVITE handling text aims for updating of RFC3261, we may need a
>  > detailed normative text for updating RFC3312 & RFC4032. And we can talk
>  > topics relating to precons but outside of the scope of Re-INVITE
>  > handling text, such as "resuming and suspending for session or for
>  > separate stream".
>  >
>  > Two separate text means different maintenance process and lifecycle. If
>  > we can guarantee the consistency and integrality of the two text, I
>  > think two text would be clear for two (relating) topics.
>  >
>  > Thanks,
>  >
>  > Gao
>  >
>  > ===================================
>  > Zip    : 210012
>  > Tel    : 87211
>  > Tel2   :(+86)-025-52877211
>  > e_mail : gao.yang2@zte.com.cn
>  > ===================================
>  >
>  >
>  > *Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>*
>  > 发件人:  sipcore-bounces@ietf.org
>  >
>  > 2010-01-14 16:33
>  >
>  >                  
>  > 收件人
>  >                  SIPCORE <sipcore@ietf.org>
>  > 抄送
>  >                  
>  > 主题
>  >                  Re: [sipcore] Question on 
> draft-camarillo-sipcore-reinvite-01.txt
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  > Hi,
>  >
>  > I have put together a new version of the draft:
>  >
>  > 
> http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt
>  >
>  > Let me know if you have some comments before I submit it.
>  >
>  > Regarding the decision about when a given change in the session state
>  > has been executed when preconditions are used, I have added a paragraph
>  > that summarizes our discussions and the following draft:
>  >
>  > http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt
>  >
>  > Please, read Section 5.
>  >
>  > Sections 7 and 15 contain new rules to avoid glare situations and race
>  > conditions. These rules avoid nasty call flows that were able to get the
>  > UAs out of synch.
>  >
>  > Some time ago, we discussed whether or not unreliable provisional
>  > responses could refresh the remote target. There are several problems
>  > with unreliable responses updating remote targets. First, we would need
>  > to define even more rules to avoid glare situations and race conditions.
>  > Second, SIP does not provide any ordering for unreliable provisional
>  > responses. Responses arriving out of order at the UAC could easily get
>  > both UAs out of synch. Therefore, only reliable responses can refresh
>  > remote targets, as was specified in RFC 3261 anyway.
>  >
>  > We also discussed the applicability of the target refresh rules to
>  > initial INVITEs. The rules in the draft cover them as well so I do not
>  > think we need to add anything else to that end.
>  >
>  > Thanks,
>  >
>  > Gonzalo
>  >
>  > _______________________________________________
>  > sipcore mailing list
>  > sipcore@ietf.org
>  > https://www.ietf.org/mailman/listinfo/sipcore
>  >
>  >
>  >
>  > --------------------------------------------------------
>  > 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.
> 