[Asterisk-Users] Almost there--Remote connection

[Benjamin on Asterisk Mailing Lists]

On Tue, 19 Oct 2004 14:07:46 -0400, Ferguson, Michael
<ferguson at brvmlaw.com> wrote:
> Thanks. The server is NAT'd.
> So, Am I to conclude that it is not going to work and I should abandon
> it?

Port forwarding alone won't work because SIP is really SIP+2xRTP which
means there are three data streams that from a TCP/IP point of view
are three different and unrelated connections: one SIP (signalling)
and two RTP (audio) streams. Only the content of the SIP messages
makes them logically belong together, but TCP/IP is meant to only care
about the envelope, not what's inside the packets.

So, your first challenge is to get your NAT router to not throw away
the incoming audio. It does so because it doesn't know nor care about
the content of the SIP messages which say that the two RTP audio
streams belong together and are to be passed on to your Asterisk
server.

Your second challenge is to get your Asterisk server to match
everything up. Because of the NAT, the picture the SIP messages
describe doesn't match the picture your server actually sees, and
since computer software is pretty bad at guessing, it will simply
ignore the bits that it cannot make sense of.


My advice would be this:

If you are curious and feel that a challenge is always worth taking
even if only for the learning experience, then you may want to play
with this a little. You may or may not get it to work, I tend to think
you won't, but trying to make it work will give you insights in how
SIP and NAT work, and in particular how they are not really meant to
work together. This is an insight worth struggling for and it will
help you later to get other things working or be able to make a good
assessment of whether something is just a waste of time.

As you might have guessed, I am one of those rebellious minds who
didn't take the advice from others that SIP and NAT was a waste of
time, I had to find out by myself and I didn't find the holy grail
with the magic oil that makes SIP/NAT traversal work, but I am
grateful for what I learned in the process of trying.

However, if you are a more rational and want to get the job done with
a minimal amount of time and effort, regardless of all the fun you
might miss out on ;-) then you may want to look at alternatives that
are more promising.

In the former case, you will want to put your server into the DMZ and
then use SIP debug on your Asterisk console to see what the SIP
messages say and compare that to a successful SIP connection from
within the NAT. Then you want to play with certain parameters at your
disposal in /etc/asterisk/sip.conf, such as externip, fromdomain,
fromuser etc etc trying to "repair" the incoming SIP messages so that
they make as much sense to your server as the ones of the successful
connection from within the NAT.

This is a little more challenging than if you had the opposite
situation (phone behind NAT, server on a public IP) because you cannot
tweak those parameters on your Grandstream phone which is where the
"broken" SIP messages are going to come from and where naturally the
best place would be to tweak things.

You can already see where the learning is going to come from ;-)

In the latter case, if you just want to get the job done fast, then
your alternatives are this:

1) put your Asterisk server on a public IP

2) connect your Asterisk server and your Grandstream phone to FWD

[Asterisk]---SIP---[NAT router]---SIP---[FWD]---SIP---[Grandstream]

this way, your server becomes a client of FWD, where the FWD is a
server with a public IP. Then all you have to solve is how to connect
your Asterisk client behind NAT to a SIP server outside of the NAT.
That's a lot less of a challenge.

If you still have problems with SIP/NAT traversal, you could always
use IAX to connect to FWD and that's a walk in the park.

3) build a tunnel between the Asterisk server and the Grandstream phone

If your hardware firewall supports a tunneling protocol, ie GRE, IPsec
or PPTP, then you could get some device that supports the same
protocol at the place where your Grandstream phone is and build a
tunnel through which SIP and RTP will travel smoothly without seeing
the NAT.

hope this helps
rgds
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.