Subject: [Sip] Review of draft-ietf-sip-outbound-08

From: EKR <[email-masked]>
Date: Sat, 17 Mar 2007 09:12:50 -0700

$Id: draft-ietf-sip-outbound-08-rev.txt,v 1.1 2007/03/11 05:53:17 ekr Exp $

This draft seemed to be in pretty good shape as of -07. The major
change in this draft appears to be that the STUN-based keepalive
system has been replaced with something rather more complicated,
namely:

- STUN for UDP
- CRLF or TCP keepalive for TCP
- Indications in the URL for which kind of keepalive you
  support
- A probing scheme to detect whether or not STUN is supported

I'm having a hard time seeing why any of this is necessary. 
Given that implementations need to support UDP and therefore
need to support STUN, it's really unclear to me why it's an
asset to have to support several different methods. STUN will
work perfectly well over TCP and the demuxers you need
are more or less the same. This is just asking for 
interop problems.

I don't understand why the probing in S 8 is required.
If someone advertises that they support STUN, let's just
assume that they do. Any SIP implementation which blows up when
it sees STUN deserves what it gets.

I think a simple example of the register and its response
would be nice prior the extended example at the end.

   When a URI is created that refers to a SIP node that supports STUN as
   described in this section, the 'keep-stun' URI parameter, as defined
   in Section 12 SHOULD be added to the URI.  This allows a UA to
   inspect the URI to decide if it should attempt to send STUN requests
   to this location.  For example, an edge proxy could insert this
   parameter into its Path URI so that the registering UA can discover
   the edge proxy supports STUN keepalives.

Shouldn't this SHOULD be a MUST?

-Ekr

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sat, 17 Mar 2007 19:49:04 -0500

> it sees STUN deserves what it gets.

I believe it was due to a worry that there might be nodes that DO NOT  
advertise support for stun, but have mis-configured upstream proxies  
that assume due to configuration (and without any run-time checks)  
that they support STUN, and therefore stun them to death, without the  
nodes having any way to report this aberrant behavior to said proxy  
in order to quench it.

It should be obvious from the above that several alternatives might  
satisfy the requirements, but ask-before-stunning was selected by the  
WG during earlier discussion of the subject. I'd be willing to accept  
a "don't configure for stun - always do a run-time detection" or a  
"don't STUN unless STUN support is advertised" or maybe even a "Stop  
STUNing if it isn't working (if, of corse, we can reliably detect  
that condition) model.

But a "Just STUN it and keep it up even if it dies as a result"  
alternative sounds far too much like the Dallas police department's  
TASER policy.

--
Dean

---

From: Aki Niemi <[email-masked]>
Date: Tue, 20 Mar 2007 18:27:48 +0100

> are more or less the same. This is just asking for 

I think your assumption isn't entirely correct. Yes, implementations
need to support UDP in general, but there is no requirement to support
UDP with outbound. In fact, most deployments that use UDP today already
do some sort of poor-man's outbound and work just fine. The don't
necessarily need outbound.

Where outbound comes in extremely handy is with TCP that doesn't work
without outbound, and there it just makes no sense to require use of
STUN, since most of the extra features provided by STUN compared to the
CRLF method are not useful (e.g., learning the new binding after a NAT
reboot).

So I agree having several methods is asking for trouble in interop, but
that problem is easily solved by not specifying UDP procedures in
outbound at all.

> it sees STUN deserves what it gets.

I agree there.

Cheers,
Aki

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 20 Mar 2007 19:35:19 +0200

Aki Niemi writes:

 > In fact, most deployments that use UDP today already

that is correct.

 > CRLF method are not useful (e.g., learning the new binding after a NAT

exactly.

-- juha