(Changing the thread).

4.2.1 says "However, a UA MUST support sets with at least two outbound proxy 
URIs
and SHOULD support sets with up to four URIs.". This section makes it very 
clear that
you are supposed to support multiple proxies. There is some wording about 
limiting
it for battery life, etc., but it is pretty clear to me that's it is not 
optional.

Section 4.4 basically says that if a flow fails, you re-do 4.2. It says:

   The UA needs to detect when a specific flow fails.  The UA actively
   tries to detect failure by periodically sending keep alive messages
   using one of the techniques described in Section 4.4.1 or
   Section 4.4.2.  If a flow with a registration has failed, the UA
   follows the procedures in Section 4.2 to form a new flow to replace
   the failed one.

Are you saying that this paragraph should have mandatory language (i.e., 
replace "needs to" with "MUST" and "follows" with "MUST follow"?

If so, you should make this comment on the list. It would be much more 
productive to make a concrete proposal to address your concern instead of 
saying 
past WGLC that a document is "useless".


> -----Original Message-----
> From: Juha Heinanen [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, May 08, 2008 10:04
> To: Audet, Francois (SC100:3055)
> Cc: Jiri Kuthan; [email protected]; Christer Holmberg
> Subject: RE: [Sip] Draft: draft-holmberg-sip-keep-00.txt
> 
> Francois Audet writes:
> 
>  > I think that outbound in written in a way that 
> High-availability could be  > added on top of it without 
> requiring new changes on the clients. 
> 
> the changes that would be needed are that outbound clients 
> MUST try another proxy in the set if one of them dies and 
> MUST register with all proxies in the set.  today there are 
> no such MUSTs in the draft, which makes outbound draft 
> completely useless.
> 
> on the other hand, i have not heard of any UAs on the market 
> that would implement outbound, so in that sense, no changes 
> would be needed in current outbound UAs because such UAs don't exist.
> 
> -- juha
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to