Subject: [Sip] Comments to sip-outbound

From: Aki Niemi <[email-masked]>
Date: Fri, 17 Mar 2006 17:05:11 +0200

Hi,

I've got a couple of comments on the -02 version:

1) I understand the need to configure the outbound proxy sets, but I
don't like the fact that the registrar URIs would also be configured (as
is mentioned in 3.3.).

I've seen enough user agent configurations asking for the registrar URI
(when the AoR is really all you need), that I would like to discourage
that behavior rather than encourage it. Human users' ability to
configure things is limited to perhaps an address and a password at
most, and well, automagic configuration doesn't really work in real life.

How about saying that the registrar domain returns the registrar URIs in
a 300 to REGISTER. Of course, in certain "rare" setups, the proxy set
could also be returned in a 305. This would be optional, of course, and
those domains that want to make things difficult could still rely on
configuration. :)

2) In 4.5:

If the number of consecutive-failures is large enough that the
   maximum of 1800 seconds is reached, the UA will keep trying forever
   with a random time between 900 and 1800 seconds between the attempts.

You don't really mean "forever" here, right?

3) In 5.3:

Note that techniques to ensure that mid-dialog requests are routed
   over an existing flow are out of scope and therefore not part of this
   specification.

How can this work then with symmetric NATs? I mean, a BYE from the other
end would fail, wouldn't it? So shouldn't the edge proxy always record
route? This is only an issue with UDP, btw.

4) The draft mentions rport, but doesn't say much about how rport and
sip-outbound work together. Actually, i think it would be simple and
elegant for TCP flows to use a combination of TCP keepalives and rport.
Wouldn't that work teh same as with STUN?

In fact, it might be wise to separate the keepalive behavior of TCP and
UDP a little better. In some sense, I agree with a previous post in that
perhaps sip-outbound-tcp and sip-outbound-udp need not be that tied
together in terms of keepalives and NAT binding detection. Remind me
again why does the UA need to find out the NAT address/port with TCP?

5) About the open issues:

   Do we want to include the Double CRLF keep alive option?

Might as well, as an option to TCP keepalives, perhaps.

   Are thre any deployments that could use Algorithm 1 and if not can we
   remove it?

Don't remove.

   We should change syntax from "sip-stun" to "keep-alive=sip-stun".

Looks good.

Overall, nice draft.

Cheers,
Aki

_______________________________________________
Sip mailing list  https://www1.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: Rohan Mahy <[email-masked]>
Date: Fri, 17 Mar 2006 08:50:55 -0800 (PST)

> I've got a couple of comments on the -02 version:

Thanks Aki.

> those domains that want to make things difficult could still rely on

The problem with using a 3xx is that we want the semantics to be that you
register with all the provided outbound addresses.  I agree the user
should need less to get started though.  Jonathan actually suggested using
a separate (optional) type of SRV lookup to find your outbound proxy set.

> You don't really mean "forever" here, right?

Yeah, I don't like forever or infinite either.  How about "indefinitely"?

> route? This is only an issue with UDP, btw.

The edge proxy needs to do something, but we don't specify what.  In the
normal case, the edge proxy can just record-route and that is sufficient. 
Folks that want to do failover or per-dialog state blobs may need to do
something extra.  The community has already figured out how to do this, so
Additional normative language in *this* spec is more likely to irritate
rather than help an implementor.

> again why does the UA need to find out the NAT address/port with TCP?

First a disclaimer.  I DONT CARE ANYMORE which keepalive technique we use
for TCP.

Using the OS-provided TCP keepalives is insufficient (too short).  Using
double CRLF would work and STUN would both work.  The argument in favor of
STUN is that you would do the same thing over both transports so it would
be only one thing to implement.

I will point out however that the main motivation for outbound is to make
TCP and TLS work, so folks may not implement outbound support for TCP and
UDP at the same time.

>    We should change syntax from "sip-stun" to "keep-alive=sip-stun".

thanks much,
-rohan

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Mar 2006 13:03:43 -0600

> most, and well, automagic configuration doesn't really work in real  

Hmm. The address of my POP server cannot be deduced from my email  
address, yet I seem to be able to configure my email client, as do  
most users.

I've also found the UAs that fail to different between registrar  
address and AOR to be unusable in many situations that have cropped  
up with various experimental and demonstration configurations. Quite  
often, I really DO want my UA to send its REGISTER requests to a  
destination that is not DNS-congruent with the domain part of my AOR.  
This is especially common if the registrar is dual-homed, with one  
leg in a private network and one leg in a public network. The UA,  
also on the private network, needs to send its REGISTER requests to  
the "private" side of the registrar, whereas its the "public" side of  
the registrar that gets the DNS pointer.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Mar 2006 13:09:47 -0800

I think that 95% of people are going to want to *not* configure any of this
or the 500 other things a UA allows you to configure. That is why I think
the configuration framework is so key to get done soon and make simple.

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Mar 2006 09:50:04 +0200

Rohan Mahy writes:

 > Jonathan actually suggested using

i support that too.  we MUST define how the SRV lookup is done before
outbound is publishes and outbound RFC MUST mandate that every UA
implementing outbound also implements the lookup.  user MUST not need to
configure manually anything else than AoR, username and password to the
phone.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Mar 2006 09:54:58 +0200

Dean,

it is ok for the UA to allow manual configuration of anything (like
registering to two proxys), but there MUST be a default mode of
operation where nothing else is needed that AoR, username and passord.
the rest it will learn via SRV queries.

-- juha

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 16:57:42 +0200

Hi,

> a separate (optional) type of SRV lookup to find your outbound proxy set.

SRV sounds like a good option. To make the redirection work, it might
require a new 3xx that specifically says something like "Multiple
Outbound Targets", and would be shown only to a UA that had, say,
outbound in their supported.

Not arguing this is any better necessarily than SRV, but it might enable
more options for distributing load. For example, based on the first
character of the userpart of the AoR.

> Yeah, I don't like forever or infinite either.  How about "indefinitely"?

Perhaps also an implementation note, that at some point, the process
should abort with a user displayed error.

> Using the OS-provided TCP keepalives is insufficient (too short).

Are you saying NATs don't update their bindings on keepalives? Then
that's really bad.

There's one nice thing about TCP keepalives (where available) related to
security. If you run TLS, TCP level keepalives would rid you of having
to send data over the encrypted channel.

> Using

Then there's also this dummy UDP I've heard Juha Heinänen talk about lately.

Cheers,
Aki

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 19 Mar 2006 16:18:05 +0100

> a separate (optional) type of SRV lookup to find your outbound proxy set.

| SRV sounds like a good option. To make the redirection work, it might
| require a new 3xx that specifically says something like "Multiple
| Outbound Targets", and would be shown only to a UA that had, say,
| outbound in their supported.

Instead of a new 3xx code, perhaps a header similar to 'Request-Disposition' 
(RFC3841) would be more appropriate. Something like "Contact-Disposition: 
all" (absence of this header would retain current semantics)

Regards,

jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 19 Mar 2006 07:50:41 -0800

> Are you saying NATs don't update their bindings on keepalives? Then

No, that generally works.  The problem is that the application won't 
detect a TCP keepalive failure for an annoyingly long period of time.  
I think there is an informational note on this in the draft, but I 
would not be surprised if it gets missed.

thanks,
-rohan

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 17:54:40 +0200

ext Rohan Mahy wrote:
> detect a TCP keepalive failure for an annoyingly long period of time.  I
> think there is an informational note on this in the draft, but I would
> not be surprised if it gets missed.

This has been the topic of a parallel thread. Some (most?) OSs actually
let you configure the idle times, probe intervals and the number of
probes on a per-connection basis. It's not available universally
(depends on the OS and the programming language) but where available, is
the best choice.

Things have changed since the note on the draft. ;)

Cheers,
Aki

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 19 Mar 2006 19:12:56 +0100

Rohan,

> think there is an informational note on this in the draft, but I would not 
> be surprised if it gets missed.
>

I just did another small test: setting TCP keep-alive interval to a random 
value between 95 and 120 seconds, with repeat interval at 1 second. When I 
disconnect the server cable, a TCP-keepalive is sent when the interval timer 
expires, and retransmitted 4 times with 1-second intervals (so in total 5 
tries). This means that with these settings, failure is detected after 125 
seconds (worst case). The application gets an IO event with 
NT_STATUS_REMOTE_DISCONNECT (0xc000013c)

I suppose the recommended value for the repeat interval would be T1. I am 
not sure if the number of retries can be set per connection, probably not.

Regards,

Jeroen

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 21:03:43 +0200

ext Jeroen van Bemmel wrote:
> I suppose the recommended value for the repeat interval would be T1. I
> am not sure if the number of retries can be set per connection, probably
> not.

At least in Linux, you can set this via TCP_KEEPCNT, and at least in my
running kernel (2.6.12), it's implemented as well.

But another thing occurred to me about the use of TCP keepalives. Since
they are only hop-by-hop, they may not guarantee a flow is alive in the
presence of proxy or proxies in the path to a registrar. At least not in
the same way a CRLFx2 would.

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 20 Mar 2006 00:25:47 -0600

> the same way a CRLFx2 would.

True; this has been the traditional rub against TCP keepalives.
If an intermediary (router) is down but the endpoints are up, the
endpoints may erroneously tear the connection down based on
this information (Unix Network Prorgamming by Fenner et al.
discusses this, as did the older TCP/IP Illustrated
by W. Richard Stevens).

What has been interesting about Jeroen's experiments has
been the fact that the keepalive is now supported on a per
connection basis.  Even the last authoritative book on this
subject (according to me), "Unix Network Programming: The
Sockets Networking API" by Fenner et al. (Nov 2003) makes
reference to the fact that keepalive value is system-wide,
not per connection.  It appears that some modern operating
systems have started to support keepalives at the per-
connection level, but this support is not as yet universal
(I don't know whether it is driven by the tcpm WG in the
TSV area).

One more observation: if the intent is to ensure that the
peer is still alive, one can do so by simply monitoring
certain exceptional events on the socket.  For instance, if one
end of the connection crashes (i.e., the peer crashes,
but the host is up), the other end's TCP will receive
a RST (Fenner et al.'s book mentions this).  But, if the host
on which a peer runs is made unavailable (cable pulled out,
its default router being down, etc.) then the other peer
will obviously not receive anything, not even a RST.  So
certain cases in outbound can be supported through normal
programming tricks, without even resorting to CRLFx2.  It is
the remaining cases which will cause headaches.

Thanks.

- vijay

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Mar 2006 21:21:21 +0200

> discusses this, as did the older TCP/IP Illustrated

That's not really what I'm talking about here. A double-CRLF would
receive an ack from the registrar, not the first proxy in the proxy
chain. Therefore the question is, whether the sip-outbound keepalive is
only meant to keep a NAT binding open (which is usually located between
the UA and the first hop proxy), or should it really check the liveness
of the flow all the way up to the registrar.

Cheers,
Aki