PDA

View Full Version : NAT Setup - No inbound calls



StanAccy
10-09-2013, 12:09 PM
Im looking for things to check with regards to my NAT/Cisco 7960 setup:

Im running a Cisco 7960G (firmware 8.12) behind a Netgear router. I can make outbound calls fine. However, I have no inbound calls (phone does not ring).
Ive set the phone to use UDP port 5060 for SIP and 16384-32768 for RTP (all UDP).
Ive opened these ports on my firewall and sent all traffic on those ports to the static IP that my phone has on the LAN side.

Looking at my devices page on the voipo site, I see that I have three devices listed - 2 are the Grandstream device, and 1 is the Cisco 7960. However, for the Cisco I see empty entries for "Received" and "Connected To" (unlike the two Grandstream entries which have values set for these fields).

Ive set the following values in my SIPDefault.cnf file:

# NAT/Firewall Traversal
nat_enable: 1; 0-Disabled (default), 1-Enabled
nat_address: "mydomainname.com"; WAN IP address of NAT box (dotted IP or DNS A record only)
voip_control_port: 5060; UDP port used for SIP messages (default - 5060)
start_media_port: 16384; Start RTP range for media (default - 16384)
end_media_port: 32766; End RTP range for media (default - 32766)
nat_received_processing: 1; 0-Disabled (default), 1-Enabled

Any ideas on things to check for the inbound call problems?

Diagnostics dump from phone:

SIP Phone> sh register

LINE REGISTRATION TABLE
Proxy Registration: ENABLED, state: REGISTERED
line APR state timer expires proxy:port
---- --- ------------- ---------- ---------- ----------------------------
1 111 REGISTERED 3595 3564 sip.voipwelcome.com:5060
2 111 REGISTERED 3595 3564 sip.voipwelcome.com:5060
3 ... NONE 0 0 undefined:0
4 ... NONE 0 0 undefined:0
5 ... NONE 0 0 undefined:0
6 ... NONE 0 0 undefined:0
1-BU .1x IDLE 0 0 undefined:0

Note: APR is Authenticated, Provisioned, Registered

So it looks like the phone is connected and authenticated - this leads me to believe its some sort of firewall / port routing issue but Im at a loss as to what to try next.

uf_shane
10-09-2013, 04:14 PM
If you are able too, I would put the device into the DMZ that will take the router out of the equation

StanAccy
10-09-2013, 09:42 PM
Thanks - however to get to the DMZ, traffic still has to cross the router :-)

Its currently in the DMZ, and I spent some time this afternoon trying different firmware - 8.2, 8.8, 8.9 and 8.12 . Im still without inbound calling. Im going to reconfig the network and stick the phones on their own VLAN (so take them out of the DMZ) and route direct - ill see if that makes a difference.

uf_shane
10-09-2013, 09:58 PM
When you put a Mac Addy into the DMZ, all traffic restrictions are bypassed... meaning the internet is given 100% access to that device.

tritch
10-10-2013, 01:17 AM
Attaching more than 1 SIP device behind the same router can cause problems. Basically, you are trying to route SIP traffic from 1 public IP going to your router's WAN to 2 private IP's (Grandstream and Cisco 7960) on your router's LAN. The first thing you want to make sure of is that each SIP device is using a different SIP port. In other words, you want to make sure that the 5060 port is not already being used by either of the Grandstream registered ports. In vPanel under registered devices, look to see if the Grandstream is using 5060 already. If so, change the Cisco device to use something else, like 5079.

Also, do you have any type of port range forwarding in your router for the Grandstream device? If so, remove it. This will cause the inbound calls to work for the Grandstream and fail for the Cisco device because the router will only forward the call traffic to the Grandstream. Likewise, don't use any type of port range forwarding for the Cisco device either or inbound calls to the Grandstream device may begin to fail as well. Bottom line, if you connect more than 1 SIP device behind the same router (where call traffic needs to be routed to different private IP's), you are asking for trouble using port range forwarding for either device.

With all port range forwarding turned off and making sure each device is using a different SIP port, things will likely work......