[VOIPSEC] Put STUN in NAT Boxes?

[Simon Horne]

At 06:37 AM 27/06/2007, you wrote:
>I don't know if you bumped into my discussion of STUN Control, but in
>case you haven't, it's at:
>http://www1.ietf.org/mail-archive/web/behave/current/msg02392.html
>
>In that post, I describe some of the motivations for STUN Control.
>
>In summary -- no, this isn't "giving up".  Rather, STUN Control
>allows optimizing STUN when your own NAT(s) support STUN Control.
>The most useful optimizations to STUN are (a) reducing keepalives
>(which isn't a characteristic of STUN, but rather of any sort of
>UDP hole-punching technique; STUN is one such technique), and (b) getting 
>per-call bindings without involving the STUN server
>on the Internet.

It also fixes some problems in ICE with both parties need to always create 
a public STUN candidate for every call regardless of the type of NAT which 
can overload the STUN server since the stun server is statically 
provisioned (ie not allocated by the server which can do some type of load 
balancing and allocated directly by the UA either manually or via DNS 
records) this can become a problem.

It also fixes some nested NAT issue by providing candidates at each hop (I 
assume it does) and reducing the delay in finding of a workable candidate

Although I think it has good merit for SIP. But while over 190 million 
people use SKYPE which doesn't seem to have any need for special 
routers......you get what I mean.

Simon