Many of us would like to enjoy a remote SIP phone to connect on our Asterisk PBX server from a remote location. Unfortunatly connecting SIP phones over firewall is not an obvious task.
The configuration described here aims at installing a SIP phone in a remote student room where Internet access is provided by the University accomodation. The same concept would apply for any configuration where the remote site is hiden behind a firewall and a NAT (Network Address Translation ).
The Asterisk server is located in a private house where Internet access is done via a DSL interface (a cable modem would work exactly in the same way) and is also protected by a firewall and a NAT.
The general schematic of the usecase can be represented by the following diagram.
Only the address A1 and B1 are visible from the internet
The address A1 needs to be public or pseudo public. If public fixed address is not offered by your ISP (unfortunatly a quite common issue), a pseudo public address can be acheived via a dynamic DNS. There is no need to get the the B1 address publicly visible from the internet. All other addresses can be private.
A proper management of NAT is needed to route the SIP requests from the internet back into the public domain, as this type of filter is static, it will force some specific configuration on Asterisk PBX and the SIP remote phone.
How to discover NAT my configuration
The simplest is to use a STUN client and a public STUN server.
You can find a STUN client with the project STUN at sourceforge. It's available for Unix, Mac and windows users.
A ready to run binary is offered for Windows users. Unix users (Linux, Solaris, MacOS, ...) will just have to compile the source by running the command make. Then run the newly created / installled command 'client' , you should get a small help.
Type the client command (the actual path may vary) pointing a a public STUN server.
client -v stun.fwdnet.net
If the result indicates that the NAT "preserves ports" in the final result statement it should work. If ports are not preserved then you need to look to other solution such are tunneling or a SIP proxy/router. You just have to double check that the port preservation is also respected for the SIP port (default 5060) and the RTP ports that you plan to use.
You can force the test on a given port by forcing the port with the option -p.
client -p 5060 stun.fwdnet.net
client -p 5004 stun.fwdnet.net
