Sjpone behind a NAT

Sifting through hundreds of posts, I have not seen a post applying to this configurations.

I have two * servers. One is on a local network and the other is on an external network. The PCs on the local network are behind a NAT (the * server is not). I have no problems at all with my local server. However when I try to use the outside server, I can make and recieve calls, but once the session is open there is no voice. I assume that the asterisk configuration is okay, and the problem is with NAT or sjphone. I would like some advice.
The router/nat is a Belkin wireless box.

Here is the account definition is sip.conf

callerid=“Aharon Friedman”<8888>

This problem is now solved courtesy of Sergey Okhapkin from

  1. In sip.conf in the [general] section set:

  2. In the individual accounts you can change this.

When you are using sip and have to traverse a NAT/Firewall the first thing you need to do is make sure have have all of the ports open and forwarding correctly.

When you can make a call with sip, but there is no audio typically denotes that the RTP traffic is being lost somewhere.

By default Asterisk sends sip traffic on port 5060. This seems to be working ok for you. Also it sends RTP traffic (the audio) on ports 10000 - 20000. These ports need to be open and forwarding to the correct location for the audio to work. The ports used for rtp are in the rtp.conf file. You can use any range, just make sure you have enough for the capacity of your server.

If this doesn’t help or fix the solution please describe your situation a little more. Are you trying to connect the sjphone directly to a remote * server? Are you connecting the sjphones to the local * server, and then having the local * server connect to the remote * server? Does you get audio at all, or does it only happen on inbound / outbound calls? Are you getting any errors on the * console?

Good Luck,

Thank Dan, but as you can see the problem is solved. The problem is that by default * “reinvites” once the session is established. Meaning it lets the two ends communicate directly through RTP. Being behind a NAT, this would break down because the NAT does not have those ports mapped unless they originate from within. The solution (or one of them) is to insure that * “know” not to invite. This is done by setting the default to nat=yes in the general section and setting canreinvite=nonat there. That way * automatically assumes that the extension is behind a NAT and will stay in the middle of the session.

Of course for extensions that are not behind a NAT you want to explicitly tell * canreinvite=yes and nat=no.

I have tried it since behind two NATs and it works.