Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

From: [email-masked]
Date: Mon, 31 May 2010 19:00:21 +0800

It seams the two methodology are antitheses.

But I think it again, and *feel* the two methodology might have 
intersection. That is, using "Refashion way", but saves current right case 
as it is. Then, the two methodology would be same technically, while using 
different representation.

If we can do it like this, I'd like to change my preference from "Patching 
way" to "Refashion way".

And I need a little time to do the evaluation carefully.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================
----- 转发人 GaoYang140197/user/zte_ltd 时间 2010-05-31 18:51 -----

GaoYang140197/user/zte_ltd 写于 2010-05-31 16:29:11:

> 
> 
> 
> > I *think* that considerations of *glare* occur when there is something 

> > to be *negotiated* and either side may initiate the negotiation. The 
> > negotiated piece of state that has been considered to date for glare 
is 
> > the pair of SDP bodies that describe the media sessions.
> 
> Your classification: 
> 
> "O/A glare case" and "Session Timer glare case" are subset of 
> "negotiated glare case";
> 
> "Target-refresh ambiguous misorder" and "Updating PAI" are subset of
> "Declaring ambiguous misorder";
> 
> "negotiated glare case" and "Declaring ambiguous misorder" are 
> subset of "ambiguous case".
> 
> I once had a classification as "glare case" = "ambiguous case". But 
> if we choose the "Patching way"(see below), I guess my 
> classification is enough. If we want the "Refashion way", your more 
> refined classification might be needed.
> 
> > 
> > As noted elsewhere in this thread, another piece state that is 
> > *negotiated* is session-timer. As a result, there could be a glare 
> > situation around that. The determination of whether glare has occurred 

> > ought to be independent for each kind of negotiated state. So one 
> > determination for SDP, another for session-timer. But there is only 
one 
> > mechanism for signaling the glare in either case, the 491 response 
code. 
> > So it would be used if *either* sdp-glare or session-timer-glare 
occurred.
> > 
> > Target-refresh is somewhat different, because it isn't *negotiated* - 
it 
> > is simply *declared* independently in each direction. So I don't think 

> > it really ought to be considered a glare situation.
> > 
> > Another in this category is sending an updated PAI, or changing From. 
> > This to is a declaration rather than a negotiation, so that glare 
> > shouldn't apply.
> > 
> > In both of those cases, there remains an ordering issue, and perhaps 
the 
> > answer is to forbid behavior that can result in ambiguity. But I fear 
> >that cure is worse than the disease, so I'm inclined to seek a better 
cure.
> 
> I think there are two different methodology for this issue:
> 1. Patching way: Saving current right case as it is, and cure 
> ambiguous case without any breach for current right case(or making 
> the breach as little as possible). I think the way defined in the 
> draft belongs to "Patching way". 
> 
> 2. Refashion way: Based on the refined classification of "ambiguous 
> case", seek solution and redefine rules on each classification's 
> semantics. This way might forbid some *current right case*.
> 
> Technically, I think "Refashion way" is better. But considering 
> there's would be a serious interworking issue behind the "Refashion 
> way"(there would be a quit long period for most vendors adopting 
> this draft), I finally prefer the "Patching way" for nowadays.
> 
> Personally, I prefer this draft has relative narrow aspect, and with
> tiny impact on current right working things. If someday, we have a 
> 3261bis plan, I would prefer the "Refashion way" more.
> 
> > 
> > I'm especially concerned about that in the case of target refresh. If 
> > the sender has lost its old address, then we are on the brink of 
losing 
> > the call entirely. Saving the call is more important than whether we 
> > have the proper o/a state - that can be fixed after the new target 
> > address is established. 
> 
> I admire this point.
> 
> > Also, target refresh cases are typically rare. 
> > Two successive ones in close succession in the same direction should 
be 
> > rare^2. (A target refresh of both ends in quick succession could be 
more 
> > likely - for instance if the same event causes both to lose their 
> > address. It seems unlikely that this will be a recoverable event.)
> > 
> > So, I think we ought not be forbidding target refresh just because of 
> > other state. Ambiguity about which is the old target and which is the 
> > new one can be measured by which is a change - assuming there aren't 
two 
> > changes in quick succession. I think Gao has also recommended this.
> 
> Yes. And I think Gonzalo's current text in the draft covered this, 
> technically. 
> 
> While some words level enhancement might needed for enhancing it's 
> understandability. 
> 
> Thanks,
> 
> 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.