Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

[[e-mail]]

Hi Gonzalo,

I found time to read this version on weekend. And there are three main 
points:

1. Glare Situations(section 3.5)
As the new way, this part is relatively simple now. And the new way is 
sending a new refresh usage Re-INVITE to synchronize state for any glare 
situations.
This is simple, and effective. So, I am OK at this point.

2. Race Conditions and Target Refreshes(section 4.8)
To disallow target refreshes in unreliable response can solve this 
problem. And in fact, I think it is a nice way, as do "Target Refreshes" 
in unreliable response is unreliable. So, I'm OK with it.
As this rule's meaning is more than glare issue, so we may put this rule 
in a new section, and only mention in section 4.8 that galre problem here 
can be solved by this rule.

3. Section 5
I am OK with this section's revision.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :([phone]
 e_mail : [e-mail]
===================================



Gonzalo Camarillo <[e-mail]> 
发件人:  [e-mail]
2010-07-15 18:26

收件人
Gonzalo Camarillo <[e-mail]>
抄送
SIPCORE <[e-mail]>
主题
Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite






Hi,

thanks for the feedback I have received on and off list. We seem to have
consensus on reducing the scope of the draft to session state and target
refreshes. That is great because it allows us to hugely simplify the
rules to avoid glare conditions (this is something a few of you have
requested on the list in the past). I have put together a new revision
of the draft, which you can fetch from:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-01.txt


In addition to adjusting the scope of the draft and simplifying the
glare-related rules, I have also added a few clarifications to Section 5
in response to Robert's AD review.

Let me know if you have any comments.

Thanks,

Gonzalo


On 05/07/2010 9:34 AM, Gonzalo Camarillo wrote:
> Hi,
> 
> the re-INVITE draft talks about modifications in the session state,
> dialog state, and the dialog's remote target. While it is relatively
> well understood what we mean by session state and the dialog's remote
> target, we do not really have a good definition for dialog state.
> 
> We have discussed it in the past and what people had in mind were things
> such as called party identity. However, the draft is too vague at this
> point; it should be more precise regarding which piece of "dialog state"
> the rules in the draft apply to.
> 
> My suggestion would be to have the draft talk only about session state
> and the dialog's remote target, and forget about any other dialog state.
> New extensions whose parameters can be modified by re-INVITEs can
> specify their own rules, possibly referring to this draft and using the
> rules defined in it by reference. In this way, the applicability of this
> draft would be much clearer.
> 
> Comments?
> 
> Thanks,
> 
> Gonzalo
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> 

_______________________________________________
sipcore mailing list
[e-mail]
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.