With a true public ip you will want the following settings Server behind NAT: off PUBLIC IP: enter the public ip Intranet Subnet: what you have is fine (assuming you dont have any natted remote workers on that subnet) NAT TRAVERSAL: on Use external SBC for Internet Calling: not checked
For remote non-nat workers, deploy the phone using regular DNS SRV records, which will populate the outbound prxy as the domain name For remote works behind NAT, force the outbound proxy server to the servers public IP under the phines line config. Leave the settings as the domain name. When a remote phone behind nat register you will see a the registration line for the phone includes a private ip contact and a public ip. Make sure you have all types of ALG turned on your bridging firewall and the remote works firewall. If you still get disconnects grab a wireshark. -m >>> glomos-info <[email protected]> 02/20/12 3:43 PM >>> Hi Matt, The NIC in the Sipx box has a true public IP address. The unit is safe guarded by a true bridging firewall that is transparent to the sipx machine. Only the required traffic is passed true. No NAT or any port forwarding involved. The Public ip address under Internet calling tab is the correct one. How can I check if the phones are remote? Is there an indicator for that in the ‘contact’string? Or is it just the public ip’s that are listed. The current defined local subnet is the public ip range e.g.: 80.95.123.208/28 Should I change it to only the public IP address itself? Thanks in advance, GJ Van: [email protected] [mailto:[email protected]] Namens Matt White Verzonden: maandag 20 februari 2012 20:28 Aan: [email protected] Onderwerp: Re: [sipx-users] Welcome to the "sipx-users" mailing list When you say your server has a public ip address, do you mean the nic on the server has the public ip assigned to it or that you have a firewall that port forwards/NATS the public ip to your sipx server? If you do have the sipx server outside of a firewall you will want to take great care making sure iptables is done well on sipx. Otherwise you will get DoS real fast. There are a couple of other settings that work in conjunction with the NAT travesal setting. They are the server "public ip address" that is set under the server tab and then the page and the "intranet subnets" under the internet calling tab. But if your server truly has a public ip then they should be enabled. The NAT checkbox allows sipxrelay to re-write the SIP header and inject the "public ip" rather than the private IP. It can do this selectivity based on the intranet subnet of the phone. It also allows it to anchor the media. If it thinks the phones are local, it will not anchor the media when calling between the endpoints. You can see if the phones show as remote by looking at the register page. What you could do is set the public ip as the only only local subnet, and that would make it anchor all media. -m >>> glomos-info <[email protected]> 02/20/12 12:36 PM >>> Dear all, We have deployed a Sipxecs 4.4 server (latest fixes) and are experiencing problems with NAT traversal. Our server has a public IP address. We have a SIP trunk configured to an ITSP. We are using a combination of remote Sip phones both on NAT and without NAT. For supporting the NAT users, the NAT traversal option has been enabled. The problem is that using this configuration the non-NAT phones work OK, but the NAT phones do not setup an RTP connection correctly (no sound both ways). After we enable the 'server behind NAT' checkbox both NAT and non-NAT are able to connect successfully. But with the 'server behind NAT' checkbox enabled the non-NAT phones will lose RTP connection after about 5 minutes on inbound phone calls (session will stay, but sound drops). Outbound phone calls have no problem. The NAT phones thou What are we doing wrong? What does the 'server behind NAT' checkbox exactly do, related to NAT traversal? Why do we have to enable it to get our NAT phones working while our server has a public IP? Help is appreciated very much. Thanks, GJ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
