[Asterisk-Users] Asterisk behind LinkSys NAT Routing

[Rich Adamson]

> > Problem I have is this.  outside firewall (extension 2003) can call me 
> > inside firewall (extension 2000) and all is fine.  If I call from 
> > inside firewall (extension 2000) to outside firewall (extension 2003) 
> > I hear no ringing and person at other end can pick up and I hear for 
> > maybe a half second then I go to voicemail.  If I add another 
> > extension on the outside then communication between outside and 
> > outside through * is not possible at all.  I know I can not be the 
> > only one who has tried to do this.  Please any help would be greatly 
> > appreciated.
> >  
> 
> You need to get Asterisk onto a public IP address.. Using the DMZ 
> function on the router will not work.. If you search the archives you 
> will see that it has been attempted many times..

I don't believe a public IP address is required in this case. I've not
actually tried * on a Linksys DMZ, however it appears that Linksys is
exposing all tcp & udp ports and only doing basic NAT. If that
impression is true, it should work.

> The reason is not in the IP but in the SIP headers.. they will be sent 
> out from the Asterisk server with the internal IP address of the server, 
> this means that when the SIP UA reads the SIP message and responds it 
> will respond to the incorrect IP address..

I don't think that is what keeping the original poster's system from
working. The issue is "one" extension is configured for canreinvite=no
and the other is canreinvite=yes. One extension believes all RTP must
be passed through * while the other is attempting to negotiate a
phone-to-phone RTP session, thus dropping the audio.

There may be some exceptions somewhere, but asterisk located behind
a nat box can work and others have done it. But, it really requires
a basic understanding of how the sip protocol does call setup, the
functions implemented in the sip phones, and the ability to "see" what
each box is doing in order to set acceptable perameters in each.

One of the key issues in making it work is an understanding that sip
phones (not asterisk) initiates the majority of all actions. By that
I mean:
 1. sip phones must register with * on udp 5060, which is simple layer-3
    functions that can be handled by 99% of all nat products.
 2. sip phone to sip phone calls can be handled in two ways:
    a. canreinvite=no (all rtp traffic passes through asterisk on rtp
       udp ports that can be specified and properly handled by nat boxes)
    b. canreinvite=yes (allowing the two sip phones to negotiate the 
       rtp channel without asterisk involvement)
 3. In both 2a and 2b (for the original poster), the sip phones initiate
    the rtp negoitiation process and therefor asterisk does not have to
    rewrite the sip headers (only the sip phones). Asterisk already
    knows what the Internet address is of the remote sip phone because
    the sip phone told it (via it rewriting the header).

The original poster should be able to get either 2a or 2b to work with
the appropriate nat box mappings and sip configuration parameters. He
can't expect it to work when you tell one sip phone to rtp one way and 
tell the second sip phone to do it different way.

If the same original poster had indicated that 100 sip phones existed
on the Internet and another 100 existed on his internal nat'ed network,
then the answer to his question may be completely different.