[Asterisk-Users] Almost there--Remote connection

Ferguson, Michael ferguson at BRVMLAW.COM
Tue Oct 19 12:36:19 MST 2004


Benjamin,
Thanks for your feedback.

-----Original Message-----
From: Benjamin on Asterisk Mailing Lists
[mailto:benjk.on.asterisk.ml at gmail.com] 
Sent: Tuesday, October 19, 2004 2:53 PM
To: Ferguson, Michael
Cc: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Almost there--Remote connection


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.



More information about the asterisk-users mailing list