Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 09:01:14 +0300

Right, but the whole thing here is the UA doesn't know if the proxy
  supports STUN/CRLF, or is legacy.  If the UA does draft-outbound and
  so does the proxy, it can find out; if it does draft-sip-keep, it can
  find out.  If the UA finds out the proxy can't do it, then it will not
  do it.

hadriel,

that would break currently working nat traversal with proxies that do
not support CRLF keepalive, i.e., that are not able to response to
double-CRLF with a single one.  

a tcp connected sip UA is namely still able to keep its nat binding open
by sending double CRLFs, because it does get back tcp level
acknowledgements even when it does not get back SIP keepalive
acknowledgement (single CRLF).

if it uses the keep param and does not get back keep=yes, it would not
send CRLFs and its nat binding would die away.  this is not a good idea
at all.

- juha
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 May 2008 11:46:39 +0200

Hi Juha,
 
It is true that you could send and "see what happens", without any knowledge and indication about what the receiver supports. You could also discard the SIP headers indicating which methods, message bodies etc are supported, and just send whatever and then see whether the receiver supports it... :) 
 
I think it is much nicer to have a mechanism to indicate support of, and usage, of the techniques to use - instead of simply trying and see what works. It also gives the possibility for the edge proxy to provide a keep-alive frequency value (and trigger whatever actions if keep-alives are not received), and the UA will know that it will receive "responses" (CRLF "pong" and/or STUN response) to the keep-alives (and trigger whatever actions if not received).
 
Also, for registration cases, if the edge proxy has no knowledge about whether the UA supports any keep-alive techniques, it may cause "keep-alives" by returning a very short registration refresh timer in the registration response. That is not a very good and light solution, but commonly used.
 
In another mail you said:
 
"that does make sense, but then the ua needs to let the proxy know, exactly which keepalive method(s) it supports and the proxy should be able to respond, which one it wants to receive if there is more than one that the us is advertising."
 
As Hadriel said, the "keep" parameter DOES indicate that the UA supports the keep-alive techniques defined in the Outbound spec. It does NOT indicate "I support some kind of keep-alive". 

Last, you say that if the UA does not get keep=yes back the UA will not send CRLFs. Not receiving keep=yes simply indicates that the edge proxy does not support the Outbound keep-alive techniques. What the UA does in that case is a UA implementation issue.
 
Regards,
Christer

________________________________

Lähettäjä: [email-masked] puolesta: Juha Heinanen
Lähetetty: ke 7.5.2008 8:01
Vastaanottaja: [email-masked]
Aihe: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

hadriel,

- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 13:06:25 +0300

Christer Holmberg writes:

 > Last, you say that if the UA does not get keep=yes back the UA will
 > not send CRLFs. Not receiving keep=yes simply indicates that the edge
 > proxy does not support the Outbound keep-alive techniques. 

this is not true, because the proxy may still be able to send back,
e.g., single CRLF, but does not understand your "keep" parameter.  in
fact, that is the case with openser proxy once the CRLF patch has been
committed.

 > What the UA does in that case is a UA implementation issue.

that is not what hadriel said.  in my opinion your draft should
RECOMMENED sending keepalives even if it does not get back keep=yes,
since there is nothing to loose if it does but lots to loose (= nat
binding) if it doesn't.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 May 2008 12:36:32 +0200

Hi,

>since there is nothing to loose if it does but lots to loose (= nat
 
I think we can add some words about the case if keep=yes is not returned. But, if we for example talk about the UA still sending STUN requests I also think we need to say something about the potential issues also.
 
Also, if the UA for example receives a very short registration refresh timer (since the edge proxy did note support "keep"), there probably is no reason to send keep-alives in addition to the registration refreshes.

Regards,
 
Christer

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 13:49:44 +0300

Christer Holmberg writes:

 > I think we can add some words about the case if keep=yes is not
 > returned. But, if we for example talk about the UA still sending STUN
 > requests I also think we need to say something about the potential
 > issues also.

not just "some words", but a clear recommendation (at least for the CRLF
case).  i don't know what the issues with stun might be (possible proxy
crash or blacklisting do not qualify).

 > Also, if the UA for example receives a very short registration
 > refresh timer (since the edge proxy did note support "keep"), there
 > probably is no reason to send keep-alives in addition to the
 > registration refreshes.

you can write that if registration interval would be as short as
default keepalive interval then it is not recommended to send
keepalives.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 7 May 2008 14:37:33 +0200

Hi Juha,

>case).
 
Yes.
 
>i don't know what the issues with stun might be (possible proxy crash or blacklisting do not qualify).

I agree that proxy crash doesn't qualify (as you said earlier, such proxies should not be deployed in the first place), but I DO think the blacklisting is a valid real-life issue.

There is also another thing: I guess one reason the edge proxy doesn't return keep=yes could be because it detects (using whatever mechanism) that the UA is NOT behind a NAT. In that case the UA may end up sending unecessary keep-alives, in case the UA itself doesn't know whether it's behind a NAT or not.

>default keepalive interval then it is not recommended to send
 
Yes.
 
Regards,
 
Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 12:17:54 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Juha
> Heinanen
>

No, I assume currently working proxies for NAT traversal cases have a currently working mechanism, and would use that regardless of this draft, or they'd try this draft mechanism first and revert to previous if it wasn't negotiated.

> send CRLFs and its nat binding would die away.  this is not a good idea

Nope, I didn't mean that - I meant if it doesn't get back the keep param then it won't be using this draft, and would do what it would do if it weren't using this draft.  That may mean the UA sends a single CRLF, or it may mean the proxy makes it send Registers, or sends it Options, or whatever.  And certainly manual provisioning overrides this all anyway, as it overrides anything in any protocol.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 12:22:49 -0400

> fact, that is the case with openser proxy once the CRLF patch has been

Openser will send back a CRLF when it gets a CRLF?  Interesting, but it's proprietary.  There is nothing in SIP to say "send back a CRLF when you get a CRLF".  This draft is proposing a standardized way to do that, for both transport types.

> that is not what hadriel said.

See my other email - it was what I meant - not getting the keep=yes means the other end doesn't support this draft.  Caveat emptor at that point.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 19:24:22 +0300

Hadriel Kaplan writes:

 > Nope, I didn't mean that - I meant if it doesn't get back the keep
 > param then it won't be using this draft, and would do what it would
 > do if it weren't using this draft.

you said earlier that if ua does not get back keep=yes, then ua will not
send keepalives.

it is fine with me if the draft clearly says that if ua does not get
back keep=yes, then this draft does not specify what the ua should do.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 19:31:39 +0300

Hadriel Kaplan writes:

 > Openser will send back a CRLF when it gets a CRLF?  Interesting, but
 > it's proprietary.  There is nothing in SIP to say "send back a CRLF
 > when you get a CRLF".  This draft is proposing a standardized way to
 > do that, for both transport types.

openser will send back back single CRLF later this week, it it receives
double CRLF over tcp connection.  i have not claimed that this practise
has been standardized somewhere.  the behavior is simply implemented,
because several sip UAs, for example, all nokia ones, do send
double-CRLFs without any negotiation if they are behind nats.  as i have
told, i don't see any reason to negotiate this behavior at least when UA
is using tcp.

 > See my other email - it was what I meant - not getting the keep=yes
 > means the other end doesn't support this draft.

this is what you say now, not what you said yesterday.  as i said in my
previous posts, what you say now is fine with me as long as the draft
clearly says that if UA does not get back keep=yes, then this draft does
not specify what the UA should do.  this allow current products keep on
working without this (at least in tcp case) useless negotiation stuff
that the draft is proposing.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 May 2008 14:22:32 -0500

Juha,

Just to clarify.

Are you saying that OpenSer will respond to Double-CRLF with Single-CRLF
over TCP? Regardless of keep or even outbound registration?

I think that's what you are saying. I think that's actually very good.
That's what I would like to see in general.

And for the keep parameter. I agree with you. Keep parameter is just a
mechanism to explictly declare that Keep-alive (Double-CRLF) is supported
even if outbound registration is not used.

But NOT including Keep does NOT mean that keep-alive is not going to be used,
at least for CRLF. Sending unsolicited double CRLF is already allowed in RFC 3261.
It's just that there is no garantee the server will respond with single CRLF. If it
does, good.

For STUN-over SIP, I'm not too sure how it should work. (I don't really care either 
to be honest). I think the point of the outbound draft was to say "don't send STUN
over SIP unless you know your server supports it (through outbound registration, or
explicit configuration, or keep parameter).

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Wednesday, May 07, 2008 09:32
> To: Hadriel Kaplan
> Cc: [email-masked]; Christer Holmberg
> Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt
> 
> Hadriel Kaplan writes:
> 
>  > Openser will send back a CRLF when it gets a CRLF?  
> Interesting, but  > it's proprietary.  There is nothing in 
> SIP to say "send back a CRLF  > when you get a CRLF".  This 
> draft is proposing a standardized way to  > do that, for both 
> transport types.
> 
> openser will send back back single CRLF later this week, it 
> it receives double CRLF over tcp connection.  i have not 
> claimed that this practise has been standardized somewhere.  
> the behavior is simply implemented, because several sip UAs, 
> for example, all nokia ones, do send double-CRLFs without any 
> negotiation if they are behind nats.  as i have told, i don't 
> see any reason to negotiate this behavior at least when UA is 
> using tcp.
> 
>  > See my other email - it was what I meant - not getting the 
> keep=yes  > means the other end doesn't support this draft.
> 
> this is what you say now, not what you said yesterday.  as i 
> said in my previous posts, what you say now is fine with me 
> as long as the draft clearly says that if UA does not get 
> back keep=yes, then this draft does not specify what the UA 
> should do.  this allow current products keep on working 
> without this (at least in tcp case) useless negotiation stuff 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 22:30:56 +0300

> over TCP? Regardless of keep or even outbound registration?

yes, and i don't think there are even any plans to support full outbound
or keep, since they don't add any value.

 > It's just that there is no garantee the server will respond with
 > single CRLF. If it does, good.

i agree.

 > For STUN-over SIP, I'm not too sure how it should work. (I don't
 > really care either to be honest). I think the point of the outbound
 > draft was to say "don't send STUN over SIP unless you know your
 > server supports it (through outbound registration, or n

openser takes care of udp UAs behind NATs, so to openser UAs stun
provides no added value.  it just complicates the UA implementation.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 May 2008 15:03:51 -0500

On May 7, 2008, at 2:22 PM, Francois Audet wrote:

> really care either

That's exactly the point. You're not likely to DOS yourself by sending  
double-crlf to a proxy. But you ARE likely to DOS yourself by sending  
STUN to the same port to which you send SIP.

  So the rule is "Don't STUN a proxy's SIP port unless you're sure it  
supports it".

Outbound already provides a discovery mechanism letting a UA find out  
whether or not a proxy supports STUN over SIP. If I understand it  
correctly, this draft is an attempt to make such a mechanism available  
in the absence of Outbound.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 7 May 2008 23:12:52 +0300

> in the absence of Outbound.

dean,

that is fine and i hope that the draft is rewritten to clearly limit its
scope to "letting a UA find out whether or not a proxy supports STUN
over SIP".

then existing UA/proxy implementations would not get broken and we
can completely ignore this draft in openser proxy.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 May 2008 15:18:57 -0500

I think it would be reasonable to ask Christer for that clarification
to be added. 

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2008 13:13
> To: Dean Willis
> Cc: Audet, Francois (SC100:3055); Hadriel Kaplan; 
> [email-masked]; Christer Holmberg
>  > Outbound already provides a discovery mechanism letting a 
> UA find out  > whether or not a proxy supports STUN over SIP. 
> If I understand it  > correctly, this draft is an attempt to 
> make such a mechanism available  > in the absence of Outbound.
> 
> dean,
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 16:50:41 -0400

> provides no added value.  it just complicates the UA implementation.

But there is a reason.  As the proxy, you can't currently know whether a UA will send CRLF or not automatically.  The proxy can send stuff down that TCP connection to try to keep it open from the outside, but that has failure issues, not the least of which is the UA is the only one that can re-open the TCP connection and so really the UA has to be smart enough to (1) detect the failure, and (2) trigger itself to re-open it if it failed.

The most common way I know of to do that today is by making the UA send Registers frequently, because that accomplishes both (1) and (2), in all cases and on all transports.  A double-CRLF or STUN is theoretically more efficient to process than a Register, so in theory it should scale better.  So what the proxy needs is a way to know that the UA will do one of those keepalive methods, to do (1) and (2), and can avoid making the UA send Registers as frequently.  Ergo, this keep param is good for a proxy.

Obviously the proxy could instead guess, by seeing a CRLF from a UA and thus backing off the Register frequency, but that assumes the UA will send the CRLF even though it's doing frequent Registers (which not all do).  So that's a chicken/egg problem we can avoid with this simple param.

Then of course there's a proxy-proxy connection, which this draft will also enable keepalives for.

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 May 2008 16:02:36 -0500

> will also enable keepalives for.

For proxy-proxy keepalive'd connections, we have used
the technique in connection-reuse so far (i.e., implicit
assumption that the sender will keep the connection open
if there is an "alias" in the topmost Via.)  Connect-reuse
has been through various WGLCs and is ready to be moved
forward.

Does draft-holmberg-sip-keep need to say anything about that
implicit usage through the "alias" parameter?  In other words,
I can see the look of distress in an implementor's face when
presented with outbound, connect-reuse, and sip-keep!  Some
guidance to provide where to use which strategy should be
detailed in sip-keep.

Comments?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 00:22:04 +0200

> Openser will send back a CRLF when it gets a CRLF?  Interesting, but it's proprietary.  There is nothing in SIP to say "send back a CRLF when you get a CRLF".  This draft is proposing a standardize…

Then we may very well consider making "respond to CRLF with CRLF" a 
proposed standardized way too.
I mean it is simple and works. Which I prefer over negotiation protocols.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 00:29:40 +0200

Hadriel Kaplan wrote:
> The most common way I know of to do that today is by making the UA send Registers frequently, because that accomplishes both (1) and (2), in all cases and on all transports. 

Actually TCP keep-alive is even simpler, even though, alas, just 
TCP-specific.
There are some rumours though that some NATs drop TCP keep-alives, even 
though I have not witnessed that yet.

It seems to me that many these things are actually best-placed in behave 
-- I mean why shell we sip-special-case, how client-servers with 
persistent relationships get over NATs.

>  A double-CRLF or STUN is theoretically more efficient to process than 
a Register, so in theory it should scale better.  So what the proxy 
needs is a way to know that the UA will do one of those keepalive 
methods, to do (1) and (2), and can avoid making the UA send Registers 
as frequently.  Ergo, this keep param is good for a proxy.

I think that's a bit network-centric viewpoint. I'm comfortable with 
leaving the NAT-traversal responsibility on the client. (which kind of 
gets to the root of the problem, which is NATs are client-server 
centric). Then some things (such as server's decision how to keep the 
connections alive) don't have to concern us.

-jiri

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 May 2008 18:15:13 -0500

> Then we may very well consider making "respond to CRLF with 
> CRLF" a proposed standardized way too.

So, basically, you are proposing that for connection-oriented transport,
we use "respond to double-CRLF with single-CRLF" instead of Christer's draft.

I assume that would mean that for UDP transport, we'd still be using
Christer's draft.

Is this your proposal?

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 19:23:25 -0400

I agree it should give such guidance.

I believe your connect-reuse draft specifies re-using the TLS connection for upstream requests, but says nothing about a mechanism used to keep it open, right?  So I was assuming this draft-keep would be orthogonal and complimentary to connect-reuse: if the proxy wants to use one of the keepalive mechanisms, it could indicate such with keep; if it wanted to allow connection reuse, it would do such with alias; and it could do both if it wanted both.  One does not imply the other, does it?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijay K. Gurbani
> Sent: Wednesday, May 07, 2008 5:03 PM
> To: [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 19:27:42 -0400

> From: Jiri Kuthan [mailto:[email-masked]]
>

Obviously I'm not a client guy, but I've been told not all clients have the ability to set their sockets to do that, depending on the OS.

> connections alive) don't have to concern us.

Ironically I'm also trying to let the client do it - by having it tell the proxy "I'm smart enough to keep this connection alive by myself, if you're smart enough to use these mechanisms".

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 May 2008 23:51:54 -0500

Hadriel Kaplan wrote:
> I believe your connect-reuse draft specifies re-using the TLS
> connection for upstream requests, but says nothing about a mechanism
> used to keep it open, right?  So I was assuming this draft-keep would
> be orthogonal and complimentary to connect-reuse: if the proxy wants
> to use one of the keepalive mechanisms, it could indicate such with
> keep; if it wanted to allow connection reuse, it would do such with
> alias; and it could do both if it wanted both.  

Hadriel: Great; thanks.  The above was my expectation as well
on how it should work.  You are correct in that connect-reuse
does not talk about any mechanism to keep the connection
"hot", so these drafts are orthogonal and complimentary.

Christer: As you move this forward, I can draft some text on
a guidance paragraph or so and send it to you.

Thanks,

- vijay

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 09:24:03 +0300

Hadriel Kaplan writes:

 > But there is a reason.  As the proxy, you can't currently know
 > whether a UA will send CRLF or not automatically.  The proxy can send
 > stuff down that TCP connection to try to keep it open from the
 > outside, but that has failure issues, not the least of which is the
 > UA is the only one that can re-open the TCP connection and so really
 > the UA has to be smart enough to (1) detect the failure, and (2)
 > trigger itself to re-open it if it failed. 

you didn't read carefully enough what i wrote in above.  i wrote "udp
UAs", not "tcp UAs".  for tcp UAs, as you point out, openser cannot do
anything to solve their nat problem.  they have to do it themselves by
using CRLF keepalives, which they can start sending without permission
from the proxy.

 > The most common way I know of to do that today is by making the UA
 > send Registers frequently, because that accomplishes both (1) and
 > (2), in all cases and on all transports.  A double-CRLF or STUN is
 > theoretically more efficient to process than a Register, so in theory
 > it should scale better.  So what the proxy needs is a way to know
 > that the UA will do one of those keepalive methods, to do (1) and
 > (2), and can avoid making the UA send Registers as frequently.  Ergo,
 > this keep param is good for a proxy.

as i have told, udp UAs are handled by the proxy without any kind of
keepalive or outbound support in the UAs.  sending registers at 20 sec
frequency is not a possible solution.

if UA is behind tcp, it can keep its nat hole open by sending CRLFs with
or without getting CRLFs back from the proxy.  if a UA is not able to
send CRLFs, the best solution is to not use such UAs.  if that is not
acceptable, then the UA may choose to send registers at such a frequency
that is enough to keep UAs tcp hole open, e.g., at 20 minutes.

in either case, the proxy does not need to know anything about UAs
keepalive capability and can completely ignore the keep draft.

 > Obviously the proxy could instead guess, by seeing a CRLF from a UA
 > and thus backing off the Register frequency, but that assumes the UA
 > will send the CRLF even though it's doing frequent Registers (which
 > not all do).  So that's a chicken/egg problem we can avoid with this
 > simple param.

see above.

 > will also enable keepalives for.

you mean one proxy is behind nat and the other one is not?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 12:27:49 +0300

Christer Holmberg writes:

 > So, you are saying the following: if the UA does not support CRLF the
 > UA itself will include a short registration interval in the REGISTER
 > request?

yes.

 > That is not standardized behavior either, and I am not sure that is
 > how UAs work.

i didn't claim that it is standardized.  it is simply a practical UA
implementers way to solve the problem without yet another addition to
sip protocol, which we sick of.

 > "you can write that if registration interval would be as short as
 > keepalives."

ok, looks like i tried something to make you happy, but i'll take that
back, because the discussion has shown that nothing like that is
needed.  i repeat, if UA is using TCP, your draft should clearly say
that the keep stuff is NOT used.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 11:16:48 +0200

Hi,

>>But, again, HOW does the edge proxy know that the UA actually will use CRLF? If it doesn't know, it may use short 
>>registration timer.
>
>it DOES NOT NEED KNOW, because the UA knows and uses short registration interval.
 
So, you are saying the following: if the UA does not support CRLF the UA itself will include a short registration interval in the REGISTER request?
 
That is not standardized behavior either, and I am not sure that is how UAs work.

>>>"It is RECOMMENDED that the UA uses CRLF for TCP keep-alive even if
>>>the UA doesn't receive keep=true, unless the UA receives a
>>>registration refresh timer value which is equal or less than the UA's
>>>default keep-alive interval in which case the registration refreshes
>>>will act as keep-alives."
>> 
>>I think that is what Juha proposed some e-mails ago.
>
>i didn't say anything about register timers.  i said that tcp UA should
>send CRLFs even if it does not get back CRLF.  but now when we have
>thought this more, because tcp UA anyway sends CRLFs, it makes no sense
>to try to negotiate it.  so please limit your keep protocol to udp UAs
>only.
 
You said the following:
 
"you can write that if registration interval would be as short as default keepalive interval then it is not recommended to send
keepalives."
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 08:52:04 +0200

Hi,

>Ironically I'm also trying to let the client do it - by having it tell the proxy "I'm smart enough to keep this connection alive by myself, if you're smart enough to use 
 
I agree with Hadriel. The idea is to let the client do it, so that the proxy doesn't need to handle it, e.g. by providing short registration refresh timers etc in order to make sure the NAT bindings stay open.
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 13:52:15 +0200

>>Also keep in mind, that by removing TCP we would also remove the
>>possibility for the edge proxy to provide the keep-alive interval to the UA,
>
>the proxy has no way to figure out, which brand of nat the ua happens to
>be behind and which kind of keep-alive interval would be best for the ua.
>
>
>>AND the possibility for the edge proxy to possibly do
>>something if it does not receive a keep-alive within that interval.
>
>it can still do "something" if it wants to.
 
Yes, but it doesn't know exactly when.
 
However, based on the comments I have got from you and others, I will record the TCP as an open issue. I would like to receive some more comments/opinions before permanently removing it, in order to possible having to put it back at a later stage...
 
Regards,
 
Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 11:05:05 -0400

I am not sure I understand your objection to the keep param in TCP.  Christer has already said that he will change the wording to indicate that if the response does not have keep=yes, it doesn't mean a UAC must not send double-CRLF.  In my mind that's just admitting that local configuration on the UAC can trump negotiation, as it can for pretty much anything.

The draft should NOT recommend the UAC sends double-CRLF in such a case, imo.  It should not recommend anything.  It's out of the scope of the draft at that point.

-hadriel

>  > >proxy NEVER needs to "provide" anything for tcp ua's nat problem.
>  > >as i wrote already, if tcp ua is behind nat it simply sends CRLFs or
>  > >(if it is not able to send CRLFs) uses short enough registration
>  > >interval.
>
>  > Where is that standardized? Is that how all UAs work? IF so,  we can
>  > remove it...
>
> christer,
>
> UA vendors have read outbound draft and figured it out that sending
> CRLFs is a good thing to do for tcp UAs and have ignored the rest if
> outbound as crap.
>
> if you want to formalize sending of CRLFs in your draft, then please do
> it.
> what we are opposing is the keep protocol that is totally unnecessary
> for tcp UAs.
>
> -- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 08:55:22 +0200

Hi Vijay,
 
I would be very thankful if you could provide some text.
 
Thanks!
 
Christer

Lähettäjä: Vijay K. Gurbani [mailto:[email-masked]]
Lähetetty: to 8.5.2008 6:51
Vastaanottaja: Hadriel Kaplan
Kopio: [email-masked]; Christer Holmberg
Aihe: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

Thanks,

- vijay

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 11:51:04 +0200

Hi,

>i didn't claim that it is standardized.  it is simply a practical UA implementers way to solve the problem without yet another addition to sip protocol, which we sick of.
 
I agree it's a prectial way, but is that how UAs work today?
 
I am happy if we can do things without yet another addition to the protocol, but doing things based on assumptions on how we THINK UAs should work isn't going to be very useful.

>>"you can write that if registration interval would be as short as default keepalive interval then it is not recommended to send keepalives."
>
>ok, looks like i tried something to make you happy, but i'll take that back, because the discussion has shown that nothing like that is
>needed.  i repeat, if UA is using TCP, your draft should clearly say that the keep stuff is NOT used.
 
If people agree that TCP is not a problem,  I can remove it.

Regards,
 
Christer

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 18:10:17 +0300

Hadriel Kaplan writes:

 > The draft should NOT recommend the UAC sends double-CRLF in such a
 > case, imo.  It should not recommend anything.  It's out of the scope
 > of the draft at that point.

fine if tcp ua is completely out of scope.  it make no sense to
introduce a new protocol function for the case where it is not needed.
ua vendors have better things to do that implement useless rfcs.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 10:17:16 +0200

Hi,
 
I am NOT arguing against the fact that you can use CRLF without negotation.
 
But, again, HOW does the edge proxy know that the UA actually will use CRLF? If it doesn't know, it may use short registration timer.
 
So, why don't we say something like:
 
"It is RECOMMENDED that the UA uses CRLF for TCP keep-alive even if the UA doesn't receive keep=true, unless the UA receives a registration refresh timer value which is equal or less than the UA's default keep-alive interval in which case the registration refreshes will act as keep-alives."

Regards,
 
Christer

Lähettäjä: Juha Heinanen [mailto:[email-masked]]
Lähetetty: to 8.5.2008 9:28
Vastaanottaja: Jiri Kuthan
Kopio: Christer Holmberg; Hadriel Kaplan; Francois Audet; [email-masked]
Aihe: Re: VS: [Sip] Draft: draft-holmberg-sip-keep-00.txt

Jiri Kuthan writes:

 > For which sake sending a CRLF seems perfectly sufficient to me, without
 > any additional negotiation stuff.

jiri,

thanks for your support.  i forgot to mention that credit to openser's
CRLF implementation belongs to your ser group.

-- juha

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 08 May 2008 13:56:32 +0200

> told, i don't see any reason to negotiate this behavior at least when UA

Double CRLF keepalive as specified in sip-outbound, has been added to
SER v2.1 development version - see the commit log here:

   http://lists.iptel.org/pipermail/serdev/2008-April/012253.html

/alfred

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 09:59:16 +0300

Christer Holmberg writes:

 > I agree with Hadriel. The idea is to let the client do it, so that
 > the proxy doesn't need to handle it, e.g. by providing short
 > registration refresh timers etc in order to make sure the NAT
 > bindings stay open.

christer,

could you then, please, restrict the scope of your draft to udp
connected UAs, because if they are tcp connected, clients can keep
their nat binding open by simply sending double CRLFs.  if they get back
single CRLF, then fine, but if they don't, it is fine too.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 11:17:15 +0300

christer,

if you want to formalize sending of CRLFs in your draft, then please do it.
what we are opposing is the keep protocol that is totally unnecessary
for tcp UAs.

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 09:32:06 +0200

Juha Heinanen wrote:
>  > The UA *CAN* send double CRLF, but the problem is that the edge proxy
>  > doesn't know whether the UA is going to do it, so it may provide
>  > short registration refreshes also for TCP connections.
> 
> christer,
> 
> this directly contradicts what you supported earlier today, i.e., that
> the responsibility to handle nat is in the ua.  proxy NEVER needs to
> "provide" anything for tcp ua's nat problem.  as i wrote already, if tcp
> ua is behind nat it simply sends CRLFs or (if it is not able to send
> CRLFs) uses short enough registration interval.

Absolutely -- that's the most elegant way of doing things which takes no 
support in server, no negotiation protocol, and is placed where it 
belongs, in the client.

I think specific action items that can be taken are:
- TCP-keep-alive as described above
- UDP-keep-alive taking some answer

Both IMO best placed in BEHAVE for reuse by other apps.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 09:27:56 +0200

> single CRLF, then fine, but if they don't, it is fine too.

True, I didn't realize that, with TCP we don't even need the reverse CRLF.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 09:26:29 +0200

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 09:25:05 +0200

> Obviously I'm not a client guy, but I've been told not all clients have the ability to set their sockets to do that, depending on the OS.

That's unfortunately true but I would not let myself distract by it in 
protocol design. There is however another issue -- the rumours are true 
that some NATs ignore TCP-keep-alives when refreshing their bindings. I 
made a bit of survey of a couple of home-routers and I found at least 
one that didn't honor it. This is IMO more concerning. So eventually 
CRLF^2 may be a better idea.

> Ironically I'm also trying to let the client do it - by having it tell the proxy "I'm smart enough to keep this connection alive by myself, if you're smart enough to use these mechanisms".

:-) well made point, it just occurs to me that lack of CRLFs can be used 
as signaling "I'm dumb enough to resort to your help", which is in 
negation exactly the same thing. Or without negation, "as I show using 
CRLF ..." and then as you wrote. In the end really I would like to have 
clients doing CRLF type-of-thing and servers responding to it, without 
all of this.

-jri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 09:14:34 +0200

> I assume that would mean that for UDP transport, we'd still be using

Hi Francois

quite so, even I'm still a bit uncertain about what the least evil is 
:-) I think it is suboptimal to negotiate transport characterictics 
using application-specific protocol. CRLF^2 seems almost the right thing 
for TCP. TCP/keepalive seems even better to me -- I mean we can use it 
for every single app without reinventing the wheel. However I'm afraid 
that even if "cleaner", it would not work quite so well.

The trouble with TCP/keepalive is twofold. One is, as Hadriel mentions, 
there are OSs that can't deal with it. The question is how serious shall 
be in protocol design about OSs whose TCP stack is not yet 
state-of-the-art. I'm inclined to be easy about it, this can be fixed. 
The other problem is very similar: there are NATs that ignore TCP 
keep-alives to extend bindings. The question is again how serious shall 
be in protocol design about software that could have been better. I'm 
actually worried more about the latter under the assumption that network 
is "imperfect" and end-devices better compensate for it. Thus I think 
CRLF^2 is the most preferable way for its robustness.

Regarding UDP -- is there anything speaking against CRLF^2 too? I mean 
keeping things simple and non-special-cased is a good thing and I don't 
realized why this should not work.

-jiri

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 11:29:03 +0300

Christer Holmberg writes:

 > But, again, HOW does the edge proxy know that the UA actually will
 > use CRLF? If it doesn't know, it may use short registration timer.

it DOES NOT NEED KNOW, because the UA knows and uses short registration
interval.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 12:59:15 +0300

> I agree it's a prectial way, but is that how UAs work today?

some are able to send CRLFs and almost all allow the user to set the
registration interval.  i don't know if UAs automatically use short reg
int if behind nat.

 > I am happy if we can do things without yet another addition to the
 > protocol, but doing things based on assumptions on how we THINK UAs
 > should work isn't going to be very useful.

then write down the above, i.e., tcp UA behind nat should use crlf
(preferred) or short reg interval.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 13:04:14 +0300

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 10:44:05 -0500

It will know because the UA send double-crlf. No? 

> Behalf Of Christer Holmberg
> Sent: Thursday, May 08, 2008 01:17
> To: Juha Heinanen; Jiri Kuthan
> Cc: [email-masked]; Audet, Francois (SC100:3055)
> But, again, HOW does the edge proxy know that the UA actually 
> will use CRLF? If it doesn't know, it may use short 
> registration timer.
>  
> "It is RECOMMENDED that the UA uses CRLF for TCP keep-alive 
> even if the UA doesn't receive keep=true, unless the UA 
> receives a registration refresh timer value which is equal or 
> less than the UA's default keep-alive interval in which case 
> the registration refreshes will act as keep-alives."
>  
>  > For which sake sending a CRLF seems perfectly sufficient 
> to me, without  > any additional negotiation stuff.
> 
> jiri,
> 
> thanks for your support.  i forgot to mention that credit to 
> openser's CRLF implementation belongs to your ser group.
> 
> -- juha
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 11:55:38 +0200

Another thing:
 
Also keep in mind, that by removing TCP we would also remove the possibility for the edge proxy to provide the keep-alive interval to the UA, AND the possibility for the edge proxy to possibly do something if it does not receive a keep-alive within that interval.
 
But, again, I will do whatever we agree to do :)
 
Regards,
 
Christer

Lähettäjä: Christer Holmberg
Lähetetty: to 8.5.2008 11:51
Vastaanottaja: Juha Heinanen
Kopio: Jiri Kuthan; Hadriel Kaplan; Francois Audet; [email-masked]
Aihe: VS: VS: [Sip] Draft: draft-holmberg-sip-keep-00.txt

Hi,

 

Regards,
 
Christer

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 10:28:42 +0300

jiri,

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 10:24:04 +0300

christer,

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 10:05:16 +0200

Hi,

>this directly contradicts what you supported earlier today, i.e., that the responsibility to handle nat is in the ua.  
 
What I meant by that was that the network doesn't need to make sure the NAT bindings are kept open by providing a short registration refresh timer.
 
>proxy NEVER needs to "provide" anything for tcp ua's nat problem.  as i wrote already, if tcp
>ua is behind nat it simply sends CRLFs or (if it is not able to send CRLFs) uses short enough registration interval.
 
Where is that standardized? Is that how all UAs work? IF so,  we can remove it...
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 09:16:48 +0200

Hi,

>single CRLF, then fine, but if they don't, it is fine too.
 
The UA *CAN* send double CRLF, but the problem is that the edge proxy doesn't know whether the UA is going to do it, so it may provide short registration refreshes also for TCP connections.
 
So, based on your previous request,  my intention is to do some re-wording and say that it is unspecified what the UA does if it doesn't receive keep=yes. So, that would not forbid the UA to use double CRLF even if it doesn't receive keep=yes.
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 8 May 2008 09:17:06 +0200

Hi Vijay,

Thanks!
 
Regards,
 
Christer

Thanks,

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 11:57:13 +0200

> I am happy if we can do things without yet another addition to the protocol, but doing things based on assumptions on how we THINK UAs should work isn't going to be very useful.

Then let's standardize as a BCP that UAs send CRLF.

> If people agree that TCP is not a problem,  I can remove it.

I violently agree.

-jiri

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 18:53:44 +0300

> It will know because the UA send double-crlf. No? 

francois,

the point was that the proxy does not need do anything regarding
registration interval, because it cannot have any better knowledge about
the properties of UA's NAT than the UA has.  so it the responsibility of
the UA to use a short reg int if it is behind NAT and does not support
CRLF.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 11:02:12 -0500

Hi Juha,

Yes, I understand that the proxy doesn't need to care. That's absolutely
correct. In fact, it should be the most common scenario.

I think the point is that some proxies WANT to know. They want to use
the keep-alive to keep tract of the availability of the UA without
waiting for a request to fail.

I don't want to debate if this is a good idea or not, but I believe this
is why they want this.

> Sent: Thursday, May 08, 2008 08:54
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg; Jiri Kuthan; [email-masked]
> Subject: RE: [Sip] Draft: draft-holmberg-sip-keep-00.txt
> 
> Francois Audet writes:
> 
> the point was that the proxy does not need do anything 
> regarding registration interval, because it cannot have any 
> better knowledge about the properties of UA's NAT than the UA 
> has.  so it the responsibility of the UA to use a short reg 
> int if it is behind NAT and does not support CRLF.
> 
> -- juha
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 11:06:42 -0500

There is a difference however.

It is true that sending double-CRLF is sufficient to keep the NAT
binding alive, even without the CRLF back.

However, getting the CRLF back tells the UA that the proxy is alive.

Remember that outbound can be used for high-availability. The UA can use this
to switch to a backup proxy.

> Behalf Of Jiri Kuthan
> Sent: Thursday, May 08, 2008 00:28
> To: Juha Heinanen
> Cc: [email-masked]; Audet, Francois (SC100:3055); Christer Holmberg
> > > the proxy doesn't need to handle it, e.g. by providing short  > 
> > registration refresh timers etc in order to make sure the NAT  > 
> > bindings stay open.
> > 
> > christer,
> > 
> > their nat binding open by simply sending double CRLFs.  if they get 
> > back single CRLF, then fine, but if they don't, it is fine too.
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 11:11:46 -0500

Jiri,

I think we are in 100% agreement then.

For UDP... I was certainly not a proponent of the STUN idea.
But after 6 months of arguing on the list and about 6000 postings, 
the group decided to use STUN.

I don't think we want to re-open that can of worms.

> Sent: Thursday, May 08, 2008 00:15
> > So, basically, you are proposing that for connection-oriented 
> > transport, we use "respond to double-CRLF with single-CRLF" 
> instead of Christer's draft.
> > 
> :-) I think it is suboptimal to negotiate transport 
> characterictics using application-specific protocol. CRLF^2 
> seems almost the right thing for TCP. TCP/keepalive seems 
> even better to me -- I mean we can use it for every single 
> app without reinventing the wheel. However I'm afraid that 
> even if "cleaner", it would not work quite so well.
> 
> The trouble with TCP/keepalive is twofold. One is, as Hadriel 
> mentions, there are OSs that can't deal with it. The question 
> is how serious shall be in protocol design about OSs whose 
> TCP stack is not yet state-of-the-art. I'm inclined to be 
> easy about it, this can be fixed. 
> The other problem is very similar: there are NATs that ignore 
> TCP keep-alives to extend bindings. The question is again how 
> serious shall be in protocol design about software that could 
> have been better. I'm actually worried more about the latter 
> under the assumption that network is "imperfect" and 
> end-devices better compensate for it. Thus I think
> Regarding UDP -- is there anything speaking against CRLF^2 
> too? I mean keeping things simple and non-special-cased is a 
> good thing and I don't realized why this should not work.
> 
> -jiri
> 
> 
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 19:14:29 +0300

> waiting for a request to fail.

then we are talking about a different application than keeping tcp NAT
binding alive.  was scope of christer's draft to define a general
purpose "is UA alive" detection protocol?

i don't think that existing UA implementations that support CRLF send
them if they are not behind NAT.  if proxy wants to know if UA is still
alive or not, then we need to mandate CRLF keepalive for all UAs whether
behind NAT or not.  in my opinion this would be a quite fundamental
addition to sip UA behavior.

but even in that case the proxy could measure the interval between
the first two CRLFs and thus auto-detect it.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 19:27:51 +0300

> However, getting the CRLF back tells the UA that the proxy is alive.

yes, and if it gets one CRLF back, it can turn on the detection mode.
there is no need to introduce yet another sip protocol level feature
for that purpose.

 > to switch to a backup proxy.

i would have very much liked that outbound would have supported high
availability.  unfortunately, features that would support ha are not
mandatory in outbound draft, which means that proxies cannot rely on
them.  this is the biggest reason why outbound is useless.

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 08 May 2008 18:34:27 +0200

> I think we are in 100% agreement then.

great.

> I don't think we want to re-open that can of worms.

:-)

well perhaps having just a keep-alive app-indepednet document would be 
worth it, regardless what other combined work is going elsewhere :-) 
Anyhow, embedded STUN doesn't in fact appear so terrible to me.

So after all, what do we want to do for keeping bindings alive? a) BCP 
b) ignore c) sip-keep. (sorted in my strongly descending order of 
preference).

-jiri

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 May 2008 11:48:22 -0500

Jiri Kuthan wrote:
> there are OSs that can't deal with it. [...]
> keep-alives to extend bindings.

There is one more problem in TCP keep-alives: they may cause an
otherwise perfect connection between two hosts to be disrupted if
some intermediary router connecting the two hosts hiccups
temporarily.

This is discussed to good length (including the pros and cons
of TCP keepalive) in Chapter 23 of [1].  The reference is old
enough (1994) that it does not contain discussion of NATs, but
the intermediary issue is valid and even mentioned in the more
recent book by Stevens, Fenner, and Rudoff [2]
(see discussion on pg. 201).

[1] W. Richard Stevens, "TCP/IP Illustrated, Volume 1: The Protocols,"
  Addison-Wesley, 1994.

[2] W. Richard Stevens,  Bill Fenner, and Andrew Rudoff,
  "Unix Network Programming: The Sockets Networking API," Addison-
  Wesley, 2004.

Ciao.

- vijay

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 11:51:27 -0500

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. So one
could improve the servers and get HA without requiring new changes on the
UAs that support outbound.

You are welcome to make proposals on high-availability if you want. 

> Sent: Thursday, May 08, 2008 09:28
> Cc: Jiri Kuthan; [email-masked]; Christer Holmberg
> there is no need to introduce yet another sip protocol level 
> feature for that purpose.
> 
>  > Remember that outbound can be used for high-availability. 
> The UA can use this  > to switch to a backup proxy.
> 
> i would have very much liked that outbound would have 
> supported high availability.  unfortunately, features that 
> would support ha are not mandatory in outbound draft, which 
> means that proxies cannot rely on them.  this is the biggest 
> reason why outbound is useless.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 20:04:11 +0300

Francois Audet writes:

 > 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 13:53:07 -0400

> Francois Audet

No, the proxy can't assume that.  If the proxy sets the Registration time to be low, it may stop the UAC from sending double-CRLF, even though the Proxy and UAC would have preferred to use double-CRLF.

For example, Juha mentioned that a Nokia phone sends double-CRLF, but it doesn't when it's connected to my proxy - I don't know if that's a config setting on the phone or because my proxy is making the nokia re-register frequently.  Either way, if the nokia simply told my proxy it could send such double-CRLF in its initial Register, we could avoid any such chicken-egg problem and avoid configuration and so on.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 12:57:17 -0500

(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".

> Sent: Thursday, May 08, 2008 10:04
>  > 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
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 20:58:01 +0300

Hadriel Kaplan writes:

 > For example, Juha mentioned that a Nokia phone sends double-CRLF, but
 > it doesn't when it's connected to my proxy - I don't know if that's a
 > config setting on the phone or because my proxy is making the nokia
 > re-register frequently.

it may be that you need to turn on CRLF using nokia's sip voip settings
tool, but if i remember correctly, it is automatically on if your phone
is behind nat.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 13:59:02 -0400

> the properties of UA's NAT than the UA has.

As a matter of fact, the proxy can have knowledge about the properties of that NAT, but that's a separate topic and not related to this issue.

> so it the responsibility of

I know in the prefect world all UA's are "smart" and up on the latest specs and do the right thing.  And that may be the world for you.  The fact that *some* UAC's are smarter is completely moot.  The fact is not *all* UAC's are smart, and there are some of us who have to make SIP service work with the dumber UAC's as well.  If you don't want to support them that's cool - no one's making you.  No one's making you implement anything, so I don't understand the consternation.(?)

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 21:03:19 +0300

Francois Audet writes:

 > 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

where does it say that the UA MUST register with all proxies in the set?
i fought a long battle on that one and lost.  may be a miracle has
happened and the issue has been revisited?

if there is any text left in the draft that you don't need to register
with all proxies in the set, for example, if you want to save battery
life, then the draft is useless, because proxies in the set cannot trust
that each outbound UA really registers with every proxy.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 21:07:01 +0300

Hadriel Kaplan writes:

 > I know in the prefect world all UA's are "smart" and up on the latest
 > specs and do the right thing.

i didn't claim that all UAs are smart and implement latest specs.  but
in most UAs, even in very old ones, it is possible to manually configure
the reg int.  so if user's UA is behind nat, the user can usually
configure reg int and make it work from behind nat.  on the other hand,
very few old UAs support tcp.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 14:09:50 -0400

> that each outbound UA really registers with every proxy.

Now I'm getting even more confused. :)
First you argue to let the UA's decide what's best for them, and now you're saying the proxy needs to trust/know that each UA registers with every proxy.  Why is that?  How does it change the behavior of the proxy?

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 21:14:04 +0300

> specs and do the right thing.

i would like to add to this that in order for your proxy to be able to
do its "smarts" and reduce the reg int of the UA, the UA would first
need to implement this brand new keep draft (if you want to avoid
reducing reg int for vain).  it is easier for the UA to simply implement
CRLF capability without the keep draft like some and growing number are
already doing.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 21:20:04 +0300

Hadriel Kaplan writes:

 > First you argue to let the UA's decide what's best for them, and now
 > you're saying the proxy needs to trust/know that each UA registers
 > with every proxy.  Why is that?  How does it change the behavior of
 > the proxy?

if every proxy knows that every UA always registers with every proxy in
the set, then implementing the proxy set becomes very simple.  if the
proxy set cannot trust that every ob UA registers with every proxy in
the set, then the proxy set needs to implement various complicated
mechanisms to ensure that every proxy in the set is aware of each
registration and is able to reach every UA even when the UA may be
behind NAT.  you will find lots of discussions about the problems on
various practical sip related mailing lists.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 8 May 2008 13:20:50 -0500

It says "you MUST support sets with a least 2".

If an implementor is dumb enough to not understand that "supporting a set" implies
registering and not just looking at it, maybe he shouldn't be writing software. What
else could it mean?

I don't think we can remove the battery life text. It's better to have
a single proxy (which may fail) than a dead phone when your battery is running low.

Again, if you think the text is not strong enough try to propose something concrete 
(i.e., TEXT).

> Sent: Thursday, May 08, 2008 11:03
> Cc: Jiri Kuthan; [email-masked]; Christer Holmberg; 
> [email-masked]; Rohan Mahy; [email-masked]
> Subject: draft-ietf-sip-outbound
> 
> Francois Audet writes:
> 
>  > 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.
> 
> i fought a long battle on that one and lost.  may be a 
> miracle has happened and the issue has been revisited?
> 
> if there is any text left in the draft that you don't need to 
> register with all proxies in the set, for example, if you 
> want to save battery life, then the draft is useless, because 
> proxies in the set cannot trust that each outbound UA really 
> registers with every proxy.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 8 May 2008 21:38:11 +0300

Francois Audet writes:

 > Again, if you think the text is not strong enough try to propose
 > something concrete (i.e., TEXT).

here comes the required change:

  For each outbound proxy URI in the set, the UAC SHOULD => MUST send a
  REGISTER request using this URI as the default outbound proxy.

and this must be removed:
 
  (The UA could limit the number of flows formed to conserve battery power,
   for example)

it is useless to register with only one proxy in order to save battery
life, because if the call comes via the other one, the phone will not
ring.  this is the very reason why ob as currently written is useless.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 21:46:51 -0400

> Sent: Thursday, May 08, 2008 2:14 PM
>
> Hadriel Kaplan writes:
>

Yes, it is easier for a UAC to simply send double-CRLF than to also insert a semi-colon plus a 4-character string into its Via header.  I'm not arguing it isn't easier to avoid doing that.

All I'm saying is if the UA decides to avoid that huge computational overhead of sending a keep param, it may find itself sending SIP REGISTER requests far more often than it has to, or receiving SIP OPTIONS requests, or getting blacklisted, or whatever.  My simple cave-man brain tells me that may result in more work for the UA in the end than if it simply sent the incredibly complicated keep param to begin with, but I don't write clients so maybe not.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 21:47:52 -0400

> very few old UAs support tcp.

Again I think this is an example of the different worlds of SIP usage meeting each other. :)

In my world, humans aren't typically expected to configure anything on their UA; short of maybe their AoR, username, and password.  And even that is sometimes pre-installed on the UA.

Furthermore, the registration interval is actually set to varying numbers, for example depending on transport.  And there are some proxies which actually have a mechanism to dynamically determine how long that interval should be based on the UAC's specific NAT, such that one UA using UDP might get 30 seconds for example, while another UA gets 120 seconds for UDP.

On the flip side, for the UAC's which try to be smarter by themselves: some of them send proprietary SIP request methods when they detect they're behind a NAT, or send proprietary message formats altogether which do not even comply with SIP request formatting rules.  Although to be fair those proprietary hacks mostly happen when UA's detect the registrar to be one from their own manufacturer, which never took into account a possibility that there could be proxies in the path between.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 00:04:04 -0500

On May 8, 2008, at 2:27 AM, Jiri Kuthan wrote:

>> back

Well, without the reverse CRLF, you may not notice for 20 minutes that  
your connection is down. The TCP stack will take a while to timeout  
from SYN.

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 00:11:28 -0500

> purpose "is UA alive" detection protocol?

It's about keeping your NAT binding alive and KNOWING that it is  
alive, rather than just hoping. That requires bidirectional traffic.  
Ideally, it requires bidirectional traffic that changes with each  
operation and is not symmetric -- something different comes back than  
what was sent. Otherwise there are some weird "echo" failure scenarios  
where you think your NAT binding is alive but you're really just  
talking to yourself. And if this occurs in a CRLFCRLF->CRLF mode, then  
every "probe" sent by the UA doubles the "think it is alive" timer,  
and things get very strange.

> addition to sip UA behavior.

Mostly it's about the UA knowing whether or not the proxy (or  the  
connection to that proxy)  is alive, and knowing it in a timely  
fashion so that it can re-establish the connection quickly if it fails.

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 00:17:13 -0500

> ring.  this is the very reason why ob as currently written is useless.

Why would the call come via the other proxy if there's no registration  
there? Your proxies do have a shared statebase for sorting this stuff  
out, right? Or are they useless?

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 08:44:00 +0300

Hadriel Kaplan writes:

 > In my world, humans aren't typically expected to configure anything
 > on their UA; short of maybe their AoR, username, and password.  And
 > even that is sometimes pre-installed on the UA.

then you must really hate the outbound id that does not
provide any standard means for the UA to learns its ob proxy set!  that
is another reason why ob draft is useless.

my point is that tcp UA should just start sending LRLFs and use normal
reg int.  there is no need to implement the keep param, just a need to
implement CRLF.  that keeps the NAT open no matter if the proxy supports
it or not.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 08:46:19 +0300

> your connection is down. The TCP stack will take a while to timeout  

yes and for that reason it makes sense in the proxy to implement CRLF
capability as has been already done.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 08:48:41 +0300

> alive, rather than just hoping. That requires bidirectional traffic.

yes and as i have said many times, CRLF has already been implemented in
ser and openser proxies.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 08:52:44 +0300

> out, right? Or are they useless?

yes we do have that, but if all UAs would register with all proxies,
there would be no need for a shared database which would greatly
simplify the implementation.  by the way, there is no good open source
shared database system available today.

it is not just about shared database, since if the UA is behind nat,
the other proxy is not able to reach the UA.  and if the proxy the ua
registered with is down, then ...

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 9 May 2008 09:14:36 +0200

I don't understand Juha's argument about proxies "knowing things".

If a UA does not register an outbound flow via a certain proxy that
proxy doesn't have to know anything about other proxies, because no call
to/from the UA will ever go through that proxy. 

Regards,

Christer 

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 8. toukokuuta 2008 21:20
To: Hadriel Kaplan
Cc: Francois Audet; [email-masked]; Christer Holmberg;
[email-masked]; [email-masked]
Subject: RE: [Sip] draft-ietf-sip-outbound

Hadriel Kaplan writes:

> you're saying the proxy needs to trust/know that each UA registers  >
with every proxy.  Why is that?  How does it change the behavior of  >
the proxy?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 10:29:07 +0300

> to/from the UA will ever go through that proxy. 

it would be nice if it would be easy implement a redundant, load
balancing sip proxy cluster, where each proxy would be able to serve any
UA.  if only one proxy is able to serve a particular UA, then the
implementation is not a high availability one.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 10:40:53 +0300

Christer Holmberg writes:

 > I agree, but that doesn't mean you need to register to EVERY proxy you
 > are aware of.

then how would an UA calling you know which proxy you have registered
with?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 02:52:34 -0500

> yes and as i have said many times, CRLF has already been implemented  

But how does a UA know in advance that a proxy is going to send it?  
And how does the UA know that it is coming from a proxy in response to  
its own CRLF stream, and is not an artifact of an echoing NAT or other  
weirdness?

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 03:15:15 -0500

> then how would an UA calling you know which proxy you have registered

It doesn't. The proxies that you haven't registered with have to know  
which one(s) you have registered with or which one(s) you are supposed  
to register with.

So the UA calling you only has to get the request to a proxy that  
knows how to find a proxy that knows how to find you.

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 03:12:48 -0500

> to/from the UA will ever go through that proxy.

The real question is to which proxy in a cluster of proxies should  
requests to you be sent?

Typically a cluster of proxies will be represented by multiple SRV  
records.

Assume there are N proxies in the cluster. If your UA is registered to  
all N, then any of them will work. It doesn't matter which SRV record  
gets picked.

Assume now that a flow drops between your UA and one of those N  
proxies.  However, according to the DNS, that proxy is still  
authoritative for your domain, and it might get a request meant for  
you. What does that proxy do if it gets a request for you? Returning a  
404 would be uncool. So it has to be able to figure out which of the  
other proxies in the pool have a flow with your UA.

In a shared-state system, some sort of database (which could be  
distributed, centralized, bus-multicast, whatever) informs every proxy  
in the cluster about your flow-bindings (either as they come and go,  
or on demand).  A proxy (like the one above) that has lost its flow  
for your UA uses this to find a proxy that has a flow with your UA in  
order to send a request.

There are all sorts of optimization hacks and approaches for making  
this work more efficiently or more manageably.

One nifty technique is to pair up the proxies, such that there are N/2  
pairs, then define a hash across the namespace that maps to each user  
ID to one of those pairs, Your UA will then end up registering to and  
forming a flow with both proxies in its assigned pair. Other proxies  
in the pool that receive a request for you can use the hash to find  
the right pair, and if either proxy in the pair has lost the flow, it  
knows to consult the other member of the pair. If a whole pair goes  
down for service (or a new pair gets brought on-line), the hash  
algorithm gets updated and the system rebalances.

Another approach is to consider the set of N proxies a ring, and  
define a hash on the namespace across the N proxies, where your UA  
ends up registered to the proxy to which it is hashed (call it M) and  
the (M+1)modN proxy. This gives a smoother distribution curve. Or one  
could use an even fancier hash (or pair of hashes) to pick two proxies  
that are not adjacent.  This buys some advantages if the allocation  
algorithm works to make a local proxy "preferred" and a non-local  
proxy "secondary" for each user -- this way, if one data center  
crashes, we don't have a real avalanche restart.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 11:34:13 +0300

> knows how to find a proxy that knows how to find you.

i know all this.  the only thing i was trying to say is that things
would be much simpler and more efficient if there would not need to be
any inter-proxy communication.

if we take the case where a UA supports two ob proxies and only register
with one (as the draft currently allows), then the probability is 50%
that the request to the UA comes to the wrong proxy.  there is thus no
load balancing or availability advantage that the two proxies could
provide if the ob draft would not be brain damaged.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 11:24:24 +0300

> But how does a UA know in advance that a proxy is going to send it?  

it doesn't need to know in advance.

 > its own CRLF stream, and is not an artifact of an echoing NAT or other  

so you assume that nat or some other network box sends back on its own a
single CRLF when UA sends double CRLF to its proxy and in that response
all tcp layer stuff would match?  in my opinion trying to cope with that
kind of "weirdness" goes too far.  how do you know that your nat box
didn't generate on its own a 200 ok when you sent invite?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 11:46:50 +0300

Dean Willis writes:

 > knows to consult the other member of the pair.

dean,

i would really love to implement something like this, but the problem is
that because of ob draft you cannot assume that "UA will then end up
registering to and forming a flow with both proxies in its assigned
pair".  

in order cope with proxy failure, you must then play with all kinds
tricks to make the still working proxy in the pair to assume the ip
address and (in case of tcp) the flows of the dead proxy, which is not
easy at all.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 9 May 2008 09:33:12 +0200

>it would be nice if it would be easy implement a redundant, load
balancing sip proxy cluster, where each proxy would be 
>able to serve any UA.  if only one proxy is able to serve a particular
UA, then the implementation is not a high 
>availability one.

Regards,

Christer

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 09 May 2008 08:02:50 -0500

Juha,

I agree with you, except on on this:

>there is no good open source

Have you looked at the http://opendht.org/ ?

Henry

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 9 May 2008 16:24:32 +0300

> Have you looked at the http://opendht.org/ ?

no, i'll take a look.  i only have experience with mysql and postgre.

-- juha

---

From: [email-masked]
Date: Fri, 9 May 2008 19:04:50 -0400

From: [email-masked] (Juha Heinanen)

   UA.

Speaking as someone who has implemented a redundant, load-balancing
SIP proxy cluster:  It would be nice if it can be done easily, but
that isn't possible.  You need very disciplined inter-proxy
communication to allow the UA to "register against one proxy" and yet
be served by all proxies.

(See
http://sipxecs.sipfoundry.org/rep/sipXecs/main/sipXregistry/doc/SyncDesign.txt
for the details.)

   the only thing i was trying to say is that things would be much
   simpler and more efficient if there would not need to be any
   inter-proxy communication.

I don't see how you can avoid inter-proxy communication unless the UA
maintains a separate registration with each proxy.  And even if the UA
does maintain a separate registration with each proxy, since the
proxies are load-balancing, any proxy can receive a request, and if it
does not have a path to the destination UA, it needs to know how to
send the request to a proxy that does have a path to the destination
UA.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 19:40:32 -0500

> registering to and forming a flow with both proxies in its assigned

Then you're reading a different outbound draft than I am, because as  
far as I know, enabling the UA to bind multiple proxies is what the  
outbound draft does. Without it, you have no real way to do this.

Yes, binding multiple proxies is optional with respect to the  
protocol. In general, UAs will be configured (and this draft doesn't  
specify configuration) to bind multiple proxies, but it's true that  
UAs do not absolutely have to bind multiple proxies in order to place  
and receive calls. Deployments just scale the number of proxies based  
on the desired reliability.

Since the mechanism works with a single binding, there's no rationale  
under RFC 2119 for making usage of multiple bindings a MUST.  If we  
did that , then we'd have to make it a MUST for proxies to always be  
deployed in pairs, and that clearly isn't going to happen in every  
deployment scenario. I can only afford one proxy!

> address and (in case of tcp) the flows of the dead proxy, which is not

No, in order to deal with proxy failure in a single proxy case, the  
easiest thing to do is wait for the UA to note that its flow has  
dropped (because its keepalive failed) and rebind. You could certainly  
do a state-transfer to the standby-router thing, but that probably  
costs more than just deploying dual proxies would have.

But if the UA used the optional multi-proxy binding then there would  
be no need to wait. This provides operational advantages, at cost, so  
it's up to each deployment to decide whether the advantages outweigh  
the costs.

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 19:46:03 -0500

> didn't generate on its own a 200 ok when you sent invite?

Barring very clever timing and counting, it's hard to tell whether a  
CRLF stream  coming back to a a UA is really single CRLFs in response  
to double CRLFs or is CRLFs being echoed from a broken firewall.

And yes, I have seen firewall boxes get confused and echo stuff back.  
I've also seen TCP stacks get in strange loopback states where the  
echo is "local" rather than coming from a NAT box. I've never yet seen  
one get confused enough to send a 200 OK that matches an INVITE, but I  
suppose somebody could make one that does someday. Never underestimate  
the power of stupid people in large numbers.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 19:51:50 -0500

> implementation is not a high availability one.

In the absence of the outbound draft (or something much like it) this  
sort of implementation is pretty much impossible. With the outbound  
draft, I believe it becomes a possibility.

It would be nice if it were easy too, but I feel the same way about  
mountain climbing.

---

From: Dean Willis <[email-masked]>
Date: Fri, 9 May 2008 19:49:41 -0500

> is another reason why ob draft is useless.

The outbound draft also doesn't include any discussion of how to  
configure the user ID and passwords to be used by a UA. And it failed  
to calculate my federal income tax correctly, too. Oh horrors! It must  
be really broken!

Or perhaps it is that both configuration discovery and income tax  
calculation are  out of scope for the outbound draft.

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 08:40:14 +0300

> outbound draft does. Without it, you have no real way to do this.

ob draft does not "anable UA to bind to multiple proxies".  rfc3261
already allows and enables UA to bind to multiple proxies.

 > deployment scenario. I can only afford one proxy!

then the ob set that you tell to your UAs would consist of only one
proxy, which would be perfectly fine.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Sat, 10 May 2008 02:45:05 -0500

> already allows and enables UA to bind to multiple proxies.

Not and detect when they've dropped and need to be re-connected, and  
not in a way that allows the proxies to reach the UAs back across a  
NAT reliably,
> proxy, which would be perfectly fine.

Earlier, you were apparently arguing that having only one proxy  
configured should be a violation of the spec, and that Outbound is  
useless because it does not require a UA to register with multiple  
proxies. Now you're saying that this would be perfectly fine.

Are you saying that the configuration mechanism should have an  
indicator to tell a configured UA which or how many proxies it should  
bind to, out of a larger set of available proxies that it can choose  
from? For example, we might have a configuration that says "Here are  
the six proxies available for you to use. We expect you to register  
with at least two of them, and if you lose any bindings, please make a  
new one. Registering with only one is a violation of your terms of  
service and will force us to neuter your cat." Or perhaps another  
config that says "Here are four proxies. You must register with all of  
them."

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 15:49:03 +0300

> proxies. Now you're saying that this would be perfectly fine.

i said that UA MUST register with EVERY proxy in its set.  if there is
only one in the set, then it is fine too.  

 > from? 

no, see above.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 16:06:05 +0300

Christer Holmberg writes:

 > >reg int. 
 > Yes, and it would have been great if RFC2543 would have mandated
 > that. But unfortunately it didn't.

i don't understand what rfc2543 has to do with this.  rfc2543 does not
have the keep param either.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 15:59:35 +0300

Christer Holmberg writes:

 > I have registered with my home registrar. My home registrar then
 > knows about the outbound flows towards me, and will choose one of
 > those.

if there is only one and this only one becomes unavailable, the proxy is
not able to reach the UA.  therefore it does not make much sense to
register with only one if the set consists of two.  and as i told
earlier, by registering with only one, you still consume resources of
both and thus loose load balancing advantage.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 16:03:34 +0300

Christer Holmberg writes:

 > Since there seems to be different opinions on whether CRLF has
 > already been implemented by everyone

i don't think that anyone has claimed that CRLF has been implemented by
EVERYONE.  it has been implemented by SOME UAs without keep param and
the number if growing.

 > whether an indication is needed etc, what is wrong with what you
 > proposed earlier, that the draft
 > would not explicitly forbid sending CRLF even if keep=yes is not
 > returned?

it should explicitly RECOMMEND it.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 May 2008 12:52:24 -0400

> EVERYONE.  it has been implemented by SOME UAs without keep param and

And there's the rub.  The set of UA's which will send CRLF vs. not, and the set of Proxies which will handle it as a keepalive rather than nothingness, is a Venn diagram.  We have mechanisms in SIP to solve that and find out which portion of the diagram each party is in.  For some reason you don't want such mechanisms to be used.

> it should explicitly RECOMMEND it.

No, it really shouldn't, imo.  It should say nothing about it.  If you support the draft, then use the keep.  If you don't support the draft, all bets are off and your mileage will vary on what will happen.  It's just local policy at that point, and you could guess wrong.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 May 2008 12:58:34 -0400

> already allows and enables UA to bind to multiple proxies.

But 3261 would sometimes make the registrar-proxy fork requests to those contacts through the multiple edge proxies, because as far as it knew they were unique instances.  Outbound would not.  3261 would also keep stale contacts (from dead flows) for the register lifetime, whereas outbound replaces them.  And 3261 did not have connect-reuse behavior for the endpoint-proxy flow, although obviously in practice many proxies did that anyway for endpoint flows.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 10 May 2008 12:55:15 +0200

Hi Juha,
 
Since there seems to be different opinions on whether CRLF has already been implemented by everyone, whether an indication is needed etc, what is wrong with what you proposed earlier, that the draft would not explicitly forbid sending CRLF even if keep=yes is not returned? That would work both for those who think an indication is needed and those (including yourself) who don't think it's not needed.
 
Regards,
 
Christer

From: [email-masked] on behalf of Juha Heinanen
Sent: Fri 09/05/2008 07:48
To: Dean Willis
Cc: [email-masked]; Francois Audet; Christer Holmberg
Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 10 May 2008 12:43:26 +0200

Hi,

>>I agree, but that doesn't mean you need to register to EVERY proxy you are aware of.
>
>then how would an UA calling you know which proxy you have registered with?

I have registered with my home registrar. My home registrar then knows about the outbound flows towards me, and will choose one of those.

I think it is important to distinguish between edge proxy and registrar proxy.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 10 May 2008 13:00:32 +0200

Hi,

>my point is that tcp UA should just start sending LRLFs and use normal

Yes, and it would have been great if RFC2543 would have mandated that. But unfortunately it didn't.
 
Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Sat, 10 May 2008 13:31:21 -0500

> I think it is important to distinguish between edge proxy and  

But what if your home registrar is also a cluster?

---

From: Dean Willis <[email-masked]>
Date: Sat, 10 May 2008 13:39:52 -0500

>> bind to, out of a larger set of available proxies that it can choose

So if, for example, there are 32 SRV records in the DNS for the proxy,  
then the UA would register with every one of them? While that might  
work, it also might be overkill for environments that have some state  
awareness in their proxies.

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 10 May 2008 21:55:23 +0300

> awareness in their proxies.

ob draft has this text:

   For each outbound proxy URI in the set, the UAC SHOULD send a
   REGISTER request using this URI as the default outbound proxy.

i understand this so that if one ob proxy uri maps to 32 srv records, it
will not send a successful register request to more than one of them.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 11 May 2008 12:45:32 +0200

Hi,

>register with only one if the set consists of two.
 
Again, I agree. The UA registers with X edge proxies, and the home registrar then has X different flows to choose between tp reach the UA.
 
But, that still doesn't mean that the UA has to register with every edge proxy it is aware of.
 
Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 11 May 2008 12:55:40 +0200

>>>Since there seems to be different opinions on whether CRLF has already been implemented by everyone
>
>>i don't think that anyone has claimed that CRLF has been implemented by EVERYONE.  it has been implemented by SOME UAs without keep param and the number if growing.
>
>And there's the rub.  The set of UA's which will send CRLF vs. not, and the set of Proxies which will handle it as a keepalive rather than nothingness, is a Venn diagram.  We have mechanisms in SIP to solve that and find out which portion of the diagram each party is in.  For some reason you don't want >such mechanisms to be used.
>
>
>>>whether an indication is needed etc, what is wrong with what you proposed earlier, that the draft would not explicitly forbid sending CRLF even if keep=yes is not returned?
>

I agree with Hadriel. It is very difficult to, in a spec, say what an entity not supporting the spec should do - because implementors may not even have read the spec. But, again, we can choose to not explicitly forbid sending CRLF, which means that people not supporting "keep" can continue sending CRLF without anyone being able to tell them that what they are doing goes against some spec etc.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 11 May 2008 12:42:46 +0200

Hi,

>But what if your home registrar is also a cluster?

That is beyond the scope of Outbound, I think.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 11 May 2008 14:27:06 +0300

Christer Holmberg writes:

 > I agree with Hadriel. It is very difficult to, in a spec, say what an
 > entity not supporting the spec should do - because implementors may
 > not even have read the spec. 

i don't remember i have proposed saying something about an entity (UA)
not supporting the spec.  what i have proposed is that an UA supporting
the keep spec should still send CRLFs even it does not get back
keep=yes.

 > But, again, we can choose to not
 > explicitly forbid sending CRLF, which means that people not
 > supporting "keep" can continue sending CRLF without anyone being able
 > to tell them that what they are doing goes against some spec etc. 

i still don't understand why we need an addition to sip protocol for
CRLFs keepalives.

why can't you instead say in your draft that before sending a register
or any other sip request, UA sends double-CRLF to find out if ob proxy
supports CRLF keepalives.  it does, if UA gets back a single-CRLF and
otherwise not.  

in my opinion, it would be much simpler than inventing yet another
addition to sip protocol on top to the countless additions there already
exists and that no-one has implemented.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 11 May 2008 14:57:28 +0300

> edge proxy it is aware of.

i have been fighting this battle in order to make very simple
implementation possible of what i consider a COMMON case.  this common
case is the one where a SINGLE HOST has enough processing power to serve
as a sip proxy/registrar of the user community, such as a good size
enterprise or even a small voip provider.

the only problem with this single host implementation of proxy/registrar
is lack of redundancy.  this problem could be trivially solved by adding
a second sip/proxy registrar that could run independently from the first
if we could assume that each UA would setup flow and register with BOTH
of these proxy/registrars when configured with an ob proxy set
consisting of two URIs matching these two proxy/registrars.

so i would like to propose that ob draft mandates UA to set up flows and
register with AT LEAST TWO ob proxies if ob proxy set is bigger than
one.  second paragraph of 4.2.1. Initial Registrations could then go
like this:

  For each outbound proxy URI in the set, the UAC SHOULD send a
  REGISTER request using this URI as the default outbound proxy.  If the
  set has more than one URI, the UAC MUST send a REGISTER request using at
  least two of them as the default outbound proxy.

this would make the above described trial implementation of common case
possible and at the same time would support whatever more complicated
scenarios and also the simple scenario where there is only one ob proxy
in the set.

-- juha

---

From: [email-masked]
Date: Sun, 11 May 2008 22:35:39 -0400

i have been fighting this battle in order to make very simple
   implementation possible of what i consider a COMMON case.  [...]

   one.  [...]

I understand what you're saying with one exception:  Your first
statement is that you want to make this implementation *possible*, but
your second statement is that the implementation be *mandatory*.
Which are you advocating for?

Dale

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 08:45:47 +0300

> Which are you advocating for?

simple implementation is not possible if it is not mandatory for UAs to
set up flows and register via at least two ob proxies (if more than one
is given).

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:09:55 +0200

> entity not supporting the spec should do - because implementors may  >
not supporting the spec.  what i have proposed is that an UA supporting
the keep spec should still send CRLFs even it does 
>not get back keep=yes.
>
>>But, again, we can choose to not explicitly forbid sending CRLF, which
means that people not  > supporting "keep" can continue sending CRLF
without anyone being able
CRLFs keepalives.
or any other sip request, UA sends double-CRLF to find out if ob proxy
supports CRLF keepalives.  it does, if UA gets back 
>a single-CRLF and otherwise not.  
>

That still doesn't indicate to the edge proxy that the UA supports the
keep-alives. I don't think we can expect the edge proxy to remember
every IP address/port from where it has received a double-CRLF, before
it has received a SIP request from that same IP address/port. 

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:12:53 +0200

Juha, just for my clarification: what do you mean by "ob proxy"? Edge
proxy, or registrar supporting Outbound?

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juha Heinanen
Sent: 12. toukokuuta 2008 8:46
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] draft-ietf-sip-outbound

[email-masked] writes:

 > I understand what you're saying with one exception:  Your first  >

-- juha
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 09:13:41 +0300

Christer Holmberg writes:

 > keep-alives. 

why does the edge proxy need to know that a TCP UA supports keepalives?
openser does not keep track of that and everything works fine.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:20:55 +0200

>openser does not keep track of that and everything works fine.

I don't know what openser does, but I DO know about edge proxies that
set the registration timer to a short value in order to use the
registration requests as "keep-alives", which is a very "heavy" method.
Again, the idea is that they don't need to do that if they receive an
explicit indication that the UA supports double-CRLF (and STUN).

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 09:23:24 +0300

> proxy, or registrar supporting Outbound?

i mean what ob draft means with it when it says:

if that is not clear then please fix the text and we'll after return to
this.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 09:25:24 +0300

> registration requests as "keep-alives", which is a very "heavy"

we discussed this already.  it is the responsibility of the UA, not a
proxy, to use small reg int if ob proxy does not support CRLF
keepalives.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:30:29 +0200

Hi, 

this.

My understanding is that it refers to the edge proxies. IF so, that says
nothing about which registrar you are going to reach.

So, if you want to register to different registrars Outbound is not
going to provide that functionality. You may use separate R-URIs in your
REGISTER request, or your home network will take care it.

So, without thinking about the draft text for a moment: let's focus on
what you want. 

Do you want to be able to 1) register via multiple edge proxies (which
Outbound allows you to do), or to 2) register with multiple registrars
(which, in my opinion, is outside the scope of Outbound)?

If 1), the following question is: do you want to 3) mandate that one
registers via AT LEAST 2 edge proxies, or do you want to 4) mandate that
one registers via ALL edge proxies it is aware of?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:37:08 +0200

> set the registration timer to a short value in order to use the  >
registration requests as "keep-alives", which is a 
>>very "heavy" method.

That is not specified anywhere, and that is not general behavior. The
registration interval offered by the UA may be something which has been
provided by the operator/service provider/internet provider. And, the UA
may not even know whether it is behind a NAT or not - at least not
before it has sent some SIP request, after which it may check the Via
etc.

Also, please also remember that one use-case in the draft is
non-registration calls, in which case the register refresh method can't
be used in the first place.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 09:44:22 +0300

> nothing about which registrar you are going to reach.

that is fine with me, because in the very common case that i outlined,
there are no edge proxies, just two proxy/registrars, for example,
p1.domain.com and p2.domain.com.  the ob proxy set configured in UAs
then is [sip:p1.domain.com, sip:p2.domain.com].  simple implementation
of the common case is possible if ob draft mandates UAs to register via
at least two ob proxies in the set (if more than one is given).

 > REGISTER request, or your home network will take care it.

looks like you didn't read my email where i described the common case.

 > (which, in my opinion, is outside the scope of Outbound)?

see my common case description.

 > one registers via ALL edge proxies it is aware of?

please read the exact text that i provided and let me know if there is
something unclear in it.  if there is something unclear then, in my
opinion, also the original text has had to be unclear and has to be
fixed before it makes sense to continue this discussion.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 09:49:01 +0300

> before it has sent some SIP request, after which it may check the Via

i have not followed, but isn't there a protocol called stun that an ua
should use to figure out it is behind nat or not?

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 09:02:12 +0200

Juha, maybe the original text IS unclear. But, instead of trying to
figure out what the text means I try to figure out what you want :)

Ok, maybe I've missed/missunderstood your earlier description of what
you want. I will have to take a second look.

Regards,

Christer

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 12. toukokuuta 2008 9:44
To: Christer Holmberg
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-outbound

Christer Holmberg writes:

 > My understanding is that it refers to the edge proxies. IF so, that
says  > nothing about which registrar you are going to reach.

> going to provide that functionality. You may use separate R-URIs in
your  > REGISTER request, or your home network will take care it.

 > Do you want to be able to 1) register via multiple edge proxies
(which  > Outbound allows you to do), or to 2) register with multiple
registrars  > (which, in my opinion, is outside the scope of Outbound)?

> registers via AT LEAST 2 edge proxies, or do you want to 4) mandate
that  > one registers via ALL edge proxies it is aware of?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 May 2008 01:57:15 -0500

> openser does not keep track of that and everything works fine.

The edge proxy and registrar might collude to set a short registration  
interval if they don't know the UA supports keepalives and they know  
the UA is one the wrong side of a NAT.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 09:16:15 +0200

Hi,

>>The edge proxy and registrar might collude to set a short registration
interval if they don't know the UA supports keepalives and they know the
UA is one the wrong side of a NAT.
> 
>this has been discussed at least three times already.  in my opinion,
it is UAs responsibility to choose a short reg int if it behind nat and
does not support CRLF keepalives.
>
>one more think.  if there is an edge proxy between UA and registrar,
isn't it the edge proxy that processes the keep param and not the
registrar?

Yes. The draft does talk about the edge proxy.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 08:59:56 +0200

registration interval offered by the UA may be something which has been
provided by the operator/service 
>>provider/internet provider. And, the UA may not even know whether it
is behind a NAT or not - at least not before it has sent some SIP
request, after which it may check the Via etc.

Sure, if the UA knows that the edge proxy supports STUN (I think we have
also said that one should not send STUN requests to entities without
knowing whether they support it or not), or the UA is aware of other
STUN servers.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 10:12:45 +0300

> the UA is one the wrong side of a NAT.
 
this has been discussed at least three times already.  in my opinion, it
is UAs responsibility to choose a short reg int if it behind nat and
does not support CRLF keepalives.

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 12 May 2008 13:37:47 +0200

Dean Willis wrote:
> your connection is down. The TCP stack will take a while to timeout from 
> SYN.

Well, that's compelling enough indeed to have CRLF back and forth.

-jiri

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 14:20:50 +0100

Christer,

I think Juha's proposed text is clear - I will comment on it separately.
You and Juha seem to make a habit of talking past each other, both on
this thread and on the sip-keep thread. Perhaps the two of you should
have a phone call to sort things out, rather than continuing to
perpetuate these long threads.

John

> Sent: 12 May 2008 08:02

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 14:21:23 +0100

Juha,

> Sent: 11 May 2008 12:57
> Cc: [email-masked]; Francois Audet; [email-masked]; 
> [email-masked]
[JRE] Or alternatively, why not mandate that a UA has to be able to be
configured with an outbound proxy set of between 1 and n entries, where
n must not be less than two, and that the UA must be able to register
with each of the outbound proxies in its configured set? I see no
purpose in a UA being able to be configured with 5, say, entries in its
set if it is never going to register with more than 2.

John

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 12 May 2008 16:24:18 +0300

> perpetuate these long threads.

i have made my opinions clear and will quick on both threads now.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 May 2008 12:04:41 -0500

> knowing whether they support it or not), or the UA is aware of other

We said one should not send STUN to the SIP port of a device without  
knowing whether it supports it or not. This is to keep from either  
breaking the device or having it blacklist you for sending malformed  
packets.

However, one can STUN the STUN port with less restraint. And that  
would be the usage of STUN we are talking about.

Of course, if we had sense enough to send signaling and media to/from  
the same ports, then media could act as a keepalive for the signaling  
while we're sending it.  But we're bellheads here and think of user-to- 
user traffic as somehow different from user-to-network traffic. That,  
I believe, was our first architectural mistake.

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 May 2008 12:16:41 -0500

> does not support CRLF keepalives.

I respectfully disagree:  the registrar has control of setting the  
registration refresh under the protocol. UAs might send them more  
frequently. And they might get kicked off for generating excessive  
load on the proxy if they do so needlessly, or in other violation of  
the proxy's policy.

> isn't it the edge proxy that processes the keep param and not the

Yes, but nothing keeps the edge proxy from communicating with the  
registrar to help it set up policy.

Note also in the current draft  the registrar sees the "keep=yes" via  
parameter even if the edge proxy doesn't take further action to  
communicate what is happening with keepalive to the registrar.

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 12 May 2008 10:18:52 -0700

> But we're bellheads here and think of user-to-

This is correct. The Internet does not have UNI and NNI but the e2e
principle. Forgetting or ignoring this leads to such intractable issues.

> But we're bellheads here and think of user-to-

How is one supposed to know this?

Henry

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 May 2008 12:25:33 -0500

> How is one supposed to know this?

I don't know it. I merely believe it, and my beliefs are subject to  
change based on a shift in the preponderance of evidence presented.  
It's more like a civil trial than a criminal trial, except that the  
only final verdict is the last one reached before death.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 May 2008 12:46:01 -0500

Let me try to summarize where we are at with the draf-ietf-sip-outbound thread, and let's try
to conclude.

The current text says the following:

   At configuration time, UAs obtain one or more SIP URIs representing
   the default outbound-proxy-set.  This specification assumes the set
   is determined via any of a number of configuration mechanisms, and
   future specifications can define additional mechanisms such as using
   DNS to discover this set.  How the UA is configured is outside the
   scope of this specification.  However, a UA MUST support sets with at
   least two outbound proxy URIs and SHOULD support sets with up to four
   URIs.

   For each outbound proxy URI in the set, the UAC SHOULD send a
   REGISTER request using this URI as the default outbound proxy.
   (Alternatively, the UA could limit the number of flows formed to
   conserve battery power, for example).  UAs that support this
   specification MUST include the outbound option tag in a Supported
   header field in a REGISTER request.  Each of these REGISTER requests
   will use a unique Call-ID.  Forming the route set for the request is
   outside the scope of this document, but typically results in sending
   the REGISTER such that the topmost Route header field contains a
   loose route to the outbound proxy URI.

What Juha is worried about is that there is enough wiggle room in there
that some UAs will not register with the minimum of 2.  It is true
that it is unclear if the text about battery life was meant to allow
for not registering with all the entries in the route set, but still 
keep the minimum of two, or not.

I propose is that the text would look like this:

   At configuration time, UAs obtain one or more SIP URIs representing
   the default outbound-proxy-set.  This specification assumes the set
   is determined via any of a number of configuration mechanisms, and
   future specifications can define additional mechanisms such as using
   DNS to discover this set.  How the UA is configured is outside the
   scope of this specification.  However, a UA MUST support sets with at
   least two outbound proxy URIs and SHOULD support sets with up to four
   URIs.

   For each outbound proxy URI in the set, the UAC SHOULD send a
   REGISTER request using this URI as the default outbound proxy.  
   (Alternatively, the UA could limit the number of flows formed to 
   conserve battery power, for example).  If the set has more than one 
   URI, the UAC MUST send a REGISTER request to at least two of the 
   default outbound proxies from the set. UAs that support this specification 
   MUST include the outbound option tag in a Supported header field in a 
   REGISTER request.  Each of these REGISTER requests will use a unique 
   Call-ID. Forming the route set for the request is outside the scope of this
   document, but typically results in sending the REGISTER such that the
   topmost Route header field contains a loose route to the outbound
   proxy URI.

I think this is reasonable. Basically, what this boils down to is very simple: 
is the minimum number of registration for a proxy set that is bigger than one 2 or 1.
If you are against this proposal, it it is presumably because you believe
a UA should be allowed to use only ONE proxy from the set and ignore the 
second one.

I'd like to get opinions from the list, and close on the issue.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 May 2008 14:41:54 -0400

After talking with Juha, I think this is the best compromise.
I think an operator who really wants clients to connect with only one 
proxy can configure a single DNS name for the outbound proxy, and then 
give multiple DNS (SRV or A, depending upon how you want to play) 
records for the details of that single name.

Joel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 21:31:15 +0200

When it comes to the outbound thread, I agree that I may have missed Juha's point. I may have focused more on the what-does-the-text-in-the-draft really means issue more than on what-does-Juha-want.
 
When it comes to the keep thread, I think the issue is that Juha and I simply have different opinions. 

From: Elwell, John [mailto:[email-masked]]
Sent: Mon 12/05/2008 15:20
To: Christer Holmberg; Juha Heinanen
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-outbound

Christer,

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 12 May 2008 22:15:14 +0200

Hi Francois,
 
If you, as you propose, say:
 
"If the set has more than one URI, the UAC MUST send a REGISTER request to at least two of the
 default outbound proxies from the set."
 
...do you then really need the sentence saying:
 
"For each outbound proxy URI in the set, the UAC SHOULD send a REGISTER request using this URI as the default outbound proxy."
 
Wouldn't it be enough to say that the UAC MUST register with at least two?
 
I guess the question is whether UACs "with battery life issues" want to be able to establish single flows or not. Since the current draft does seem to allow it (at least it doesn't explicitly forbid it) it could be rather unwise to remove that possibility at this point, because it COULD be seen as a rather big change. Maybe one solution would be to strongly recommend against it, and add some words about the lost functionality by doing so, but not explicitly forbid it.
 
On the other hand, assuming the keep-draft moves forward: if you are only going to establish a single flow I am not sure you would need Outbound in the first place - keep would be enough :)
 
Regards,
 
Christer 

From: Francois Audet [mailto:[email-masked]]
Sent: Mon 12/05/2008 19:46
To: Juha Heinanen; Dean Willis
Cc: Christer Holmberg; Hadriel Kaplan; [email-masked]; [email-masked]; Elwell, John
Subject: RE: [Sip] draft-ietf-sip-outbound

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 May 2008 15:39:24 -0500

Again, this is very simple.

The questions is "is the mininum 1 or 2".

Juha is arguing for 2.
I'm fine with 2 also (in fact, that's how I read the spec in the first place).

Which minimum is acceptable to you:
a) 1
b) 2
c) Either but I prefer 1
d) Either but I prefer 2

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 13:15
> To: Audet, Francois (SC100:3055); Juha Heinanen; Dean Willis
> Cc: Hadriel Kaplan; [email-masked]; [email-masked]; 
> Elwell, John
> "If the set has more than one URI, the UAC MUST send a 
> REGISTER request to at least two of the  default outbound 
> proxies from the set."
>  
> "For each outbound proxy URI in the set, the UAC SHOULD send 
> a REGISTER request using this URI as the default outbound proxy."
>  
> I guess the question is whether UACs "with battery life 
> issues" want to be able to establish single flows or not. 
> Since the current draft does seem to allow it (at least it 
> doesn't explicitly forbid it) it could be rather unwise to 
> remove that possibility at this point, because it COULD be 
> seen as a rather big change. Maybe one solution would be to 
> strongly recommend against it, and add some words about the 
> lost functionality by doing so, but not explicitly forbid it.
>  
> On the other hand, assuming the keep-draft moves forward: if 
> you are only going to establish a single flow I am not sure 
> you would need Outbound in the first place - keep would be enough :)
>  
> Regards,
>  
> Christer 
> 
>  
>  
>  
>  
> 
> Let me try to summarize where we are at with the 
> draf-ietf-sip-outbound thread, and let's try to conclude.
> 
> What Juha is worried about is that there is enough wiggle 
> room in there that some UAs will not register with the 
> minimum of 2.  It is true that it is unclear if the text 
> about battery life was meant to allow for not registering 
> with all the entries in the route set, but still keep the 
> minimum of two, or not.
> 
> If you are against this proposal, it it is presumably because 
> you believe a UA should be allowed to use only ONE proxy from 
> the set and ignore the second one.
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 May 2008 16:16:43 -0500

Actually, let me ask an even simpler question.

Is anybody against the "2 minimum", i.e., that if there are more than one 
outbound proxies in the set, the the UA MUST use at least 2 of them.

So far, we have NOT heard anybody speak against this.

If not, then I think we should integrate Juha's comment.

---

From: [email-masked]
Date: Mon, 12 May 2008 17:29:05 -0400

From: "Elwell, John" <[email-masked]>

   I see no purpose in a UA being able to be configured with 5, say,
   entries in its set if it is never going to register with more than
   2.

I assume the idea is that if 2 of the proxies are down or unreachable,
the UA will register with 2 of the remaining 3 proxies.  Presumably
the idea is that the proxies are not individually reliable, and the UA
will have to search through a set of them to find ones that it can
register with.

Dale

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 May 2008 07:21:34 +0200

Hi,

The UA can register with all 5 if it wants to. "At least two" allows for
as many as you want :)

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 13. toukokuuta 2008 0:29
To: [email-masked]
Subject: Re: [Sip] draft-ietf-sip-outbound

I assume the idea is that if 2 of the proxies are down or unreachable,
the UA will register with 2 of the remaining 3 proxies.  Presumably the
idea is that the proxies are not individually reliable, and the UA will
have to search through a set of them to find ones that it can register
with.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 13 May 2008 14:01:27 -0500

> Cc: [email-masked]; Elwell, John; [email-masked]
> ..do you then really need the sentence saying:
>  

Well, yes: it says you SHOULD do them all (but MUST at least 2). The
battery life stuff is justification for the SHOULD (i.e., why it's not
a MUST).

> Wouldn't it be enough to say that the UAC MUST register with 

If it's clearer, I could do this instead:

   For each outbound proxy URI in the set, the UAC SHOULD send a
   REGISTER request using this URI as the default outbound proxy:
   however, if the set has more than one URI, the UAC MUST send a 
   REGISTER request to at least two of the default outbound proxies 
   from the set. The reason for not mandating all the proxies in
   the set is that the UA could limit the number of flows formed to 
   conserve battery power, for example. The reason for mandating at
   least two is ensure high-availability if available. UAs that [...]

> lost functionality by doing so, but not explicitly forbid it.

That's why we are asking for feedback. So far I have heard 
nobody saying that 2 as a minimum is not acceptable.

But we have one stong opinion that 1 is not good.

The draft is ambibuous about 2 or 1. I for one read it 
as saying that 2 was the minimum (because it says 
"However, a UA MUST support sets with at least two outbound 
 proxy URIs and SHOULD support sets with up to four URIs."

So it's very unclear to to me that we would be "changing" from
1 to 2 "late in the game".

So, let's wait for more opinions.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 13 May 2008 21:40:48 +0200

Hi,
 
>battery life stuff is justification for the SHOULD (i.e., why it's not

There are other reasons than batterly life also, e.g. if the UA is able to choose between different access technologies and the outbound proxies are access technology dependent. Radio resources is also one issue.
 
And, in visited schenarios, the UA may be provided with a large number of outbound proxies in the visited network, but the home registrar still only wants to use a smaller number of flows, so the UA has been configured to not establish more than that.
 
I do NOT want to spend time on discussing all those use-case, whether they are valide etc, but the point is that there most likely will be a number of non-battery related use-cases where a UA would not want to register with all outbound proxies.

>   least two is ensure high-availability if available. UAs that [...]
 
I think that looks good. You COULD add, after "battery power", ", access resources, or if the registrar only supports a certain number of flows". 
 
But, if you don't want to do that I will not insist. I do not want to delay the draft :)

>But we have one stong opinion that 1 is not good.
 
I also agree that 1 is not good, because it basically removes most of the Outbound functionality. And, even if we would allow 1, I think it is important that the lost functionality is clearly indicated.

>The draft is ambibuous about 2 or 1. I for one read it as saying that 2 was the minimum (because it says "However, a UA MUST support sets with at least two outbound proxy URIs and SHOULD support sets with up to four URIs."
>
>So it's very unclear to to me that we would be "changing" from 1 to 2 "late in the game".
 
Support a set of two, and register with two, are two different things :)

Regards,
 
Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 May 2008 15:39:29 -0500

Ok, I have confirmed with the author of that part of the spec (Cullen), that
the intent of the wording was that the UA supporting 2 absolutely meant that
it would register with two. So I was right.

That settles the issue and I will clarify the document accordingly.

> Sent: Tuesday, May 13, 2008 12:41