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

From: Brett Tate <[email-masked]>
Date: Tue, 1 Jun 2010 05:16:37 -0700

> > How can you only apply "checking for glare situations" during
> > a glare situation?
> > 
> > Checking for offer/answer glare is part of normal RFC3311 
> > UPDATE processing.
>
> Making two analyzers in series as: 
> 
>  ---> analyzer1 -----> analyzer2 ----> 
> 
> analyzer1 using the rules in RFC3311, and if there's glares case 
> under it's rule, send 491 or (500+retry) directly; 
> analyzer2 using the rules in the draft. 
> 
> analyzer2 also has two process: 
> 1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. 
> If it can do so, pass the UPDATE to the next step normally; 
> 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) 
> as if it contains Offer and using O/A rules to reject. 
>
> The effected cases/siutation is only these cases/situation which 
> are ambiguous before the draft. 

If this is how the changes mandated by sections 3.5 (last paragraph) and 4.5 are to be interpreted, I recommend that the draft be updated to clarify the rules.

---

From: [email-masked]
Date: Wed, 2 Jun 2010 09:37:20 +0800

> If this is how the changes mandated by sections 3.5 (last paragraph)
> and 4.5 are to be interpreted, I recommend that the draft be updated
> to clarify the rules.

I'd like to confrim do you think it is OK by *my understanding* 
technically?

And if *my understanding* is the same as Gonzalo's, I think we can do the 
revision about it. But I'd like to point out that the *analyzers* is BCP 
level thing, so we *may* use the same protocol semantics replace.

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.

---

From: Brett Tate <[email-masked]>
Date: Wed, 2 Jun 2010 05:36:45 -0700

> I'd like to confirm do you think it is OK by *my understanding* 
> technically? 

It would satisfy my concerns about UPDATE without SDP being restricted by the current offer/answer state on an early dialog.  

Otherwise I currently don't have a strong opinion on the topic.  Because there are so many race conditions within SIP and the working group likes the current flexibility leading to the issues, I doubt that the working group would approve a complete mandatory fix.  Thus it is mostly just picking which glare/race conditions the working group wants closed so the fix isn't considered worse than the problem.