UKVoIPTalk.com

On 2007-01-30, Tim <nutnews@kooky.org> wrote:
[color=blue]
> Just never ever ever ever use Stun.
>
> It just doesn't help. We've moved on a bit since 2001 :)
>
> Using stun with voip.co.uk will probably break more things than in helps.[/color]

I'm intrigued by this advice. I cannot say I am perplexed because that
would require me to have a good understanding of how STUN works. And I
don't.

Is it possible for you to expand on the reasons for avoiding the use of
STUN? Is it applicable for all situations or only when a VoIP provider
is involved?

Brian.

Brian wrote:[color=blue]
> I'm intrigued by this advice. I cannot say I am perplexed because that
> would require me to have a good understanding of how STUN works. And I
> don't.
>
> Is it possible for you to expand on the reasons for avoiding the use of
> STUN? Is it applicable for all situations or only when a VoIP provider
> is involved?[/color]


First, a little background.

When I wrote my original post, I had spent part of the afternoon with a
senior employee of a well known voip provider. Who said `One of our
biggest problems is customers who put a stun server setting in or who
insist it won't work without Stun`

[sorry for the vague wording, but I know lots about how most of the
major voice networks are setup, and I try not expose commercially
sensitive information]

Anyway.

Why Stun is a bad idea in a modern voip network.

How Stun works.

You have a device behind a NAT router on a private IP address.

The idea for a phone to work out what is the public IP address on the
outside of the NAT router. The phone then uses this IP address in the
via parts of SIP messages and in the SDP packets.

The problem is, this will only work for certain kinds of NAT devices.
The ones that don't do very much checking on inbound packets. On most
routers, stun doesn't help at all. Sometime it can make things appear
worse by letting your SIP registration work, but then call audio will be
in one direction.

But, most SIP service providers deploy Session Border Controllers, or a
B2BUA that is completely symmetric. These will work for almost any nat
with no faffing around.

They usually work by comparing the IP address in the via line with the
IP address and port the packet was actually received from. Also, the
server can check whether the presented IP address is a private IP
address, as defined by RFC 1918.

The SIP server can make informed choices about what to do, based on
whether it thinks the client is behind a NAT.

When a stunned client connects, the SIP server believes the device is on
a public IP address. The device may actually be behind a symmetric
nat, where the stun is not going to help the device make successful calls.

In summary

1) If you take installations in the wild - an average ADSL router in an
average house or small business, stun is very unlikely to work because
the router will still block the incoming RTP.

2) Stun can stop SIP servers nat traversal systems working.


If a SIP service provider suggests Stun as a nat traversal option, then
they are having a laugh.

Use a decent SIP provider with session border controllers, or just get a
public IP address for your SIP phone.


Personally, Stun feels so like a 2002 protocol, and we've moved on a
long way since then.

There is a thing called ICE, which does help for NAT traversal, but it
isn't widely implemented.



I hope this explains in a useful way. Brain is a bit tired now.

Tim