[asterisk-users] How to use stun server?

[Gordon Henderson]

On Thu, 2 Aug 2007, Rizwan Hisham wrote:

> hi again.....well i have been trying to know what is the relationship
> between asterisk and stun. what i mean is, i understand that a client
> requests stun server to know whether its behind a nat or not. if its not,
> then its ok. if it is behind nat, then what? Now client knows what kind of
> nat it is behind, what is the roll of asterisk in it. asterisk already knows
> client's public ip whether its behind nat or not, if the client is
> registered. So how does stun simplify things if there are nat problems.

There is no relationship between asterisk and STUN.

> After requesting stun server and recieving the required information from
> stun server.....what happens next?
> I hope im clear in stating my problem.

I'm not a STUN/SIP protocol gury by any means, but this is my 
understanding (and it might be a bit simplistic)

When something communicates with something else using SIP, the sending 
device (eg phone) puts it's own IP address inside the SIP data packet. 
That IP address is the IP address of the device - it doesn't know anything 
about anything else, just the IP address it has. This would work well if 
NAT hadn't been invented, unfortunately it was.


The listening side (eg. asterisk), extracts this IP address and uses it to 
send data back.

So if the originating device is behind NAT, and it's on (eg) 192.168.0.42 
then the other end, gets that IP address and tries to send data back to 
it.

Which, as 192.168.0.42 is on a private network, it can't do.

Oops.

So the original device uses a STUN server to poke a few bytes over the 
interweb and the STUN server replys back with some information - such as 
the real external IP address and port numbers it's using.

The STUN server is a tiny bit of software running on a host somewhere with 
a real IP address (or 2!) and is (or can be) quite independant of the 
asterisk server.

Original device can then put those values returned from the STUN server 
inside the SIP data packets (rather than it's 'real' natted IP address) 
and send them off to the other end, which can then use them to send the 
replys back to.

The device should only need to access the STUN server once in it's life, 
but devices periodically check, just in-case things have changed. They do 
not relay data through the STUN server.

So that's for device to asterisk box.

Asterisk boxes are supposed to be directly connected to the Internet with 
no NAT and a real live IP address. (or at least that's the best possible 
way to do it!)

If they aren't ... Then the first thing you need to do is arrange 
port-forwarding from the firewall to the asterisk box. You'll need to 
forward the ports you need - eg. for SIP it might be 5060-5069 and for RTP 
it might be 10000-20000.

But the asterisk server still needs to know what it's real external IP 
address is so it can put that in the SIP packets rather than it's own 
NATted address, and as asterisk can't use a STUN server, you need to 
explicitly tell it - this is in the sip.conf file and looks like:

   nat=yes
   localnet=192.168.2.0/24
   externip=1.2.3.4

So now the asterisk server knows that anything that originates from the 
local network doesn't need to be translated, but anything going out needs 
to have the SIP data re-written with the real external IP address.


Now (AIUI) some SIP proxys can look inside SIP data packets and see that 
the IP address given by the device is not the same as the IP address that 
the packet came from and adjust things accordingly.. Asterisk, not being a 
SIP proxy doesn't do this, so if your phone is talking to a server via a 
proxy, then you may not need to tell the phone about a STUN server. The 
people running the asterisk+SIP proxy will tell you if this is the case.

I'm sure there was a perfectly good reason for encoding the devices IP 
address inside the SIP data when they invented it, but right now, I can't 
think why... See http://www.ietf.org/rfc/rfc3261.txt for the details!

Gordon