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

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.