Matt,
>From below you wrote - Make sure you have all types of ALG turned on your >bridging firewall and the remote works firewall. Shouldn’t that read??; Make sure you have all types of ALG turned *off* - on your bridging firewall and the remote works firewall. don From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Matt White Sent: Monday, February 20, 2012 4:00 PM To: sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] Sipxecs 4.4 / NAT traversal / Server behind NAT / 5 min drop 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 <i...@glomos.com> 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: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] Namens Matt White Verzonden: maandag 20 februari 2012 20:28 Aan: sipx-users@list.sipfoundry.org 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 <i...@glomos.com> 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 though work perfectly (both inbound and outbound) with the 'server behind NAT' setting enabled. 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 sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ "The information in this electronic mail message is the sender's confidential business and may be legally privileged. It is intended solely for the addressee(s). Access to this internet electronic mail message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful." "The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. The sender's employer is not liable for any loss or damage arising in any way from this message or its attachments." "In connection with representing sellers and/or buyers in real estate transactions, Coldwell Banker Residential Brokerage real estate sales associates have absolutely no authority to create binding contractual obligations on behalf of a seller or on behalf of a buyer via any written or verbal communications including, but not limited to email communications." [v1.0.07.109]
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
