*Any and all feedback on this thread would be much welcomed.* Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up. The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN. The following REGISTER is sent from a phone. REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0 As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; * NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default. So, I'd like to present the following arguments; * Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack? * Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it. * People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
I have spent many hours working on NAT issues on client end, my server has a public address. With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following: * NDLB-connectile-dysfunction * NDLB-force-rport * Enable SIP ALG on my FIOS router. With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other. I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB "flags" I could never see any difference when enabling SIP ALG. The combination for me has been fantastic. HOWEVER, since there are so many different versions of "success" in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site. HTH, sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Cal Leeming [Simplicity Media Ltd] Sent: Sunday, December 16, 2012 11:15 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] NAT traversal - the final say..! Any and all feedback on this thread would be much welcomed. Hello, There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up. The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN. The following REGISTER is sent from a phone. REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0 As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; * NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default. So, I'd like to present the following arguments; * Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack? * Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it. * People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
Hi Sean, Thank you for the detailed reply. The more info we can get about individual NAT experiences, the better - I'm hoping others will follow suit! Cal On Sun, Dec 16, 2012 at 4:57 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.** **
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513>****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
My main experience is with the Linksys/Cisco (sipura) SPA-2102 ATA. I always disable ALG in the router. I turn on NAT ping of 15 seconds in the Linksys. And.. here's the variable part - I also turn on 2-5 of the VIAs. I haven't really pinned that one down. This is not strictly NAT related... but has bit me a few times: devices by default want to use :5060 for their SIP. Not all are smart enough to see something else is using it and try a different port automatically. And for your peace of mind, try to never need NAT on the server. -Avi On Sun, Dec 16, 2012 at 7:15 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hi Sean,
Thank you for the detailed reply.
The more info we can get about individual NAT experiences, the better - I'm hoping others will follow suit!
Cal
On Sun, Dec 16, 2012 at 4:57 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.* ***
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513<https://mail.google.com/_/mail-static/_/js/main/m_i,t,it/rt=h/ver=dQ95YePrryI.en./sv=1/am=!rQczwx1unpD1BO2bNKsLUpXXtiIjaa01SgsJmP23wMtqPKKB37R0dPvFB_9tzlm4wJdbIQ/d=1>
****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
In my experience there is no 'fix all' procedure, you just have to use sip traces to diagnose individual setups to get around the problems. More often than not I find that the NAT routers at the client end are causing the problems, but different phone/router combinations produce different results. In my current setup, I have freeswitch 1:1 NAT mapped behind pfSense (on someone else's network at the moment) and with the ext-sip-ip and ext-rtp-ip set to stun:stun.freeswitch.org and my phones at home not using STUN behind an OpenWRT-based router, everything is working fine. I did have to install the extra connection tracking modules onto my home router, though. But that's just one setup. On 16 December 2012 17:33, Avi Marcus <avi@avimarcus.net> wrote:
My main experience is with the Linksys/Cisco (sipura) SPA-2102 ATA.
I always disable ALG in the router.
I turn on NAT ping of 15 seconds in the Linksys. And.. here's the variable part - I also turn on 2-5 of the VIAs. I haven't really pinned that one down.
This is not strictly NAT related... but has bit me a few times: devices by default want to use :5060 for their SIP. Not all are smart enough to see something else is using it and try a different port automatically.
And for your peace of mind, try to never need NAT on the server.
-Avi
On Sun, Dec 16, 2012 at 7:15 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hi Sean,
Thank you for the detailed reply.
The more info we can get about individual NAT experiences, the better - I'm hoping others will follow suit!
Cal
On Sun, Dec 16, 2012 at 4:57 PM, Sean Devoy <sdevoy@bizfocused.com>wrote:
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site. ****
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513<https://mail.google.com/_/mail-static/_/js/main/m_i,t,it/rt=h/ver=dQ95YePrryI.en./sv=1/am=!rQczwx1unpD1BO2bNKsLUpXXtiIjaa01SgsJmP23wMtqPKKB37R0dPvFB_9tzlm4wJdbIQ/d=1>
****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
On 16.12.2012 19:33, Avi Marcus wrote:
And for your peace of mind, try to never need NAT on the server.
I've moved FS to public IP, but run into another issue on using multiple registration for same user when two phones connect to pubic IP and internal IP. Putting two sip profiles to use same alias domain end up only the last (in alphabetical order) is aliased. So when calling user, only phones connected to public IP in my case are called. -- Mimiko desu.
I just wanted to add a note "for the record". This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general. I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT'ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below. Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match. I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. It is certainly easy enough to imagine how it would be much simpler to "map" multiple "one to one" external ports to internal ports than to code for a single external port having multiple internal "candidates" on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem - but it is, A LOT of the time. HTH, Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Sean Devoy Sent: Sunday, December 16, 2012 11:57 AM To: 'FreeSWITCH Users Help' Subject: Re: [Freeswitch-users] NAT traversal - the final say..! I have spent many hours working on NAT issues on client end, my server has a public address. With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following: * NDLB-connectile-dysfunction * NDLB-force-rport * Enable SIP ALG on my FIOS router. With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other. I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB "flags" I could never see any difference when enabling SIP ALG. The combination for me has been fantastic. HOWEVER, since there are so many different versions of "success" in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site. HTH, sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Cal Leeming [Simplicity Media Ltd] Sent: Sunday, December 16, 2012 11:15 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] NAT traversal - the final say..! Any and all feedback on this thread would be much welcomed. Hello, There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up. The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN. The following REGISTER is sent from a phone. REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0 As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; * NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default. So, I'd like to present the following arguments; * Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack? * Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it. * People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
I wonder whether this router is one that doesn't rewrite the external port, but accepts traffic to that external port from any IP (allowing hole punching to work) therefore can only map that external port to a single internal device. On 21 December 2012 14:27, Sean Devoy <sdevoy@bizfocused.com> wrote:
I just wanted to add a note “for the record”. This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general.****
** **
I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT’ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below.****
** **
Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match.****
** **
I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. ****
** **
It is certainly easy enough to imagine how it would be much simpler to “map” multiple “one to one” external ports to internal ports than to code for a single external port having multiple internal “candidates” on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem – but it is, A LOT of the time. ****
** **
HTH,****
Sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Sean Devoy *Sent:* Sunday, December 16, 2012 11:57 AM *To:* 'FreeSWITCH Users Help' *Subject:* Re: [Freeswitch-users] NAT traversal - the final say..!****
** **
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.** **
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org<freeswitch-users-bounces@lists.freeswitch.org>] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513>****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Can you add this information to the wiki: http://wiki.freeswitch.org/wiki/Interop_List#Routers You can just about copy and paste this email right in there. Ping me if you have any questions. Thanks, MC On Fri, Dec 21, 2012 at 6:27 AM, Sean Devoy <sdevoy@bizfocused.com> wrote:
I just wanted to add a note “for the record”. This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general.****
** **
I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT’ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below.****
** **
Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match.****
** **
I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. ****
** **
It is certainly easy enough to imagine how it would be much simpler to “map” multiple “one to one” external ports to internal ports than to code for a single external port having multiple internal “candidates” on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem – but it is, A LOT of the time. ****
** **
HTH,****
Sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Sean Devoy *Sent:* Sunday, December 16, 2012 11:57 AM *To:* 'FreeSWITCH Users Help' *Subject:* Re: [Freeswitch-users] NAT traversal - the final say..!****
** **
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
** **
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
** **
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
** **
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.** **
** **
HTH,****
sean****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org<freeswitch-users-bounces@lists.freeswitch.org>] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
** **
*Any and all feedback on this thread would be much welcomed.*****
** **
Hello,****
** **
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
** **
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
** **
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
** **
The following REGISTER is sent from a phone.****
** **
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513>****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
** **
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
** **
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
** **
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
** **
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
** **
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
** **
So, I'd like to present the following arguments;****
** **
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
** **
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
** **
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Hey MC, Cal Leeming started this thread so he could gather info on NAT and add it to the wiki in a structured way. I hope this will be included in that NAT section in some meaningful context. I will certainly add it to the router section as well. Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: Friday, December 21, 2012 12:34 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] NAT traversal - the final say..! Can you add this information to the wiki: http://wiki.freeswitch.org/wiki/Interop_List#Routers You can just about copy and paste this email right in there. Ping me if you have any questions. Thanks, MC On Fri, Dec 21, 2012 at 6:27 AM, Sean Devoy <sdevoy@bizfocused.com> wrote: I just wanted to add a note "for the record". This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general. I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT'ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below. Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match. I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. It is certainly easy enough to imagine how it would be much simpler to "map" multiple "one to one" external ports to internal ports than to code for a single external port having multiple internal "candidates" on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem - but it is, A LOT of the time. HTH, Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Sean Devoy Sent: Sunday, December 16, 2012 11:57 AM To: 'FreeSWITCH Users Help' Subject: Re: [Freeswitch-users] NAT traversal - the final say..! I have spent many hours working on NAT issues on client end, my server has a public address. With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following: * NDLB-connectile-dysfunction * NDLB-force-rport * Enable SIP ALG on my FIOS router. With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other. I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB "flags" I could never see any difference when enabling SIP ALG. The combination for me has been fantastic. HOWEVER, since there are so many different versions of "success" in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site. HTH, sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Cal Leeming [Simplicity Media Ltd] Sent: Sunday, December 16, 2012 11:15 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] NAT traversal - the final say..! Any and all feedback on this thread would be much welcomed. Hello, There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up. The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN. The following REGISTER is sent from a phone. REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0 As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; * NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default. So, I'd like to present the following arguments; * Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack? * Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it. * People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Absolutely, I'm sitting back and digesting all the info coming in, with a view to rewriting the entire NAT section of the wiki - the feedback so far has been fantastic, much better than I was expecting, so thank you everyone. @Anthony, I am very curious though to hear your section on NAT from the next book, as I feel it would really help when updating the wiki... would you consider sending me a draft of just this section alone, before the book is released?? I have some spare time coming up in the holidays, so would be good to have all this to hand. If not, no worries, but thought I'd try! Thanks Cal On Fri, Dec 21, 2012 at 7:59 PM, Sean Devoy <sdevoy@bizfocused.com> wrote:
Hey MC,****
** **
Cal Leeming started this thread so he could gather info on NAT and add it to the wiki in a structured way. I hope this will be included in that NAT section in some meaningful context. I will certainly add it to the router section as well.****
****
Sean****
** **
** **
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Michael Collins *Sent:* Friday, December 21, 2012 12:34 PM
*To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] NAT traversal - the final say..!****
** **
Can you add this information to the wiki:
http://wiki.freeswitch.org/wiki/Interop_List#Routers
You can just about copy and paste this email right in there. Ping me if you have any questions.
Thanks, MC****
On Fri, Dec 21, 2012 at 6:27 AM, Sean Devoy <sdevoy@bizfocused.com> wrote: ****
I just wanted to add a note “for the record”. This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general.****
****
I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT’ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below.****
****
Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match.****
****
I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. ****
****
It is certainly easy enough to imagine how it would be much simpler to “map” multiple “one to one” external ports to internal ports than to code for a single external port having multiple internal “candidates” on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem – but it is, A LOT of the time. ****
****
HTH,****
Sean****
****
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Sean Devoy *Sent:* Sunday, December 16, 2012 11:57 AM *To:* 'FreeSWITCH Users Help' *Subject:* Re: [Freeswitch-users] NAT traversal - the final say..!****
****
I have spent many hours working on *NAT issues on client end*, my server has a public address. ****
****
With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* Enable SIP ALG on my FIOS router.****
With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.****
****
I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.****
****
HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.** **
****
HTH,****
sean****
****
*From:* freeswitch-users-bounces@lists.freeswitch.org [ mailto:freeswitch-users-bounces@lists.freeswitch.org<freeswitch-users-bounces@lists.freeswitch.org>] *On Behalf Of *Cal Leeming [Simplicity Media Ltd] *Sent:* Sunday, December 16, 2012 11:15 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
****
*Any and all feedback on this thread would be much welcomed.*****
****
Hello,****
****
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. ****
****
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.****
****
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.****
****
The following REGISTER is sent from a phone.****
****
REGISTER sip:1.2.3.4:5060 SIP/2.0****
Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
Max-Forwards: 70****
Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513>****
To: "foxx"<sip:2000@1.2.3.4:5060>****
From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448****
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
CSeq: 7 REGISTER****
Expires: 120****
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE****
Supported: replaces****
User-Agent: 3CXPhone 6.0.25732.0****
Content-Length: 0****
****
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; ****
****
* NDLB-connectile-dysfunction****
* NDLB-force-rport****
* apply-nat-acl****
* sip-force-contact****
****
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.****
****
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.****
****
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.****
****
So, I'd like to present the following arguments;****
****
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?****
****
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.****
****
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org****
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
WIKI toll PAID! Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: Friday, December 21, 2012 12:34 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] NAT traversal - the final say..! Can you add this information to the wiki: http://wiki.freeswitch.org/wiki/Interop_List#Routers You can just about copy and paste this email right in there. Ping me if you have any questions. Thanks, MC On Fri, Dec 21, 2012 at 6:27 AM, Sean Devoy <sdevoy@bizfocused.com> wrote: I just wanted to add a note "for the record". This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general. I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT'ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below. Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match. I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port. It is certainly easy enough to imagine how it would be much simpler to "map" multiple "one to one" external ports to internal ports than to code for a single external port having multiple internal "candidates" on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem - but it is, A LOT of the time. HTH, Sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Sean Devoy Sent: Sunday, December 16, 2012 11:57 AM To: 'FreeSWITCH Users Help' Subject: Re: [Freeswitch-users] NAT traversal - the final say..! I have spent many hours working on NAT issues on client end, my server has a public address. With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following: * NDLB-connectile-dysfunction * NDLB-force-rport * Enable SIP ALG on my FIOS router. With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other. I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB "flags" I could never see any difference when enabling SIP ALG. The combination for me has been fantastic. HOWEVER, since there are so many different versions of "success" in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site. HTH, sean From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Cal Leeming [Simplicity Media Ltd] Sent: Sunday, December 16, 2012 11:15 AM To: FreeSWITCH Users Help Subject: [Freeswitch-users] NAT traversal - the final say..! Any and all feedback on this thread would be much welcomed. Hello, There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up. The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN. The following REGISTER is sent from a phone. REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0 As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being; * NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default. So, I'd like to present the following arguments; * Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack? * Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it. * People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. " Part of the problem is that: - Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly. Roll on NAT-less IPv6 for true end-to-end connectivity*. :o) -Steve On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about. Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix. I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email). However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place. With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness. Cal On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com> wrote:
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that:
- Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters
So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
My take on the subject is that we are trying to tackle 2 different problems at once. On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario. On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic. So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available? João Mesquita On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email).
However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
Cal
On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com> wrote:
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that:
- Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters
So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Any other experiences/thoughts from others on this? Feedback so far has been great, lets keep it coming guys! Cal On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita@freeswitch.org>wrote:
My take on the subject is that we are trying to tackle 2 different problems at once.
On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario.
On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic.
So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available?
João Mesquita
On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email).
However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
Cal
On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com> wrote:
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that:
- Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters
So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I am planning on putting up an example of how I have 2 WAN lines both available to FreeSwitch, both used at the same time (load balanced), both are failover for each other. I have tested pulling plugs, etc. There is nothing in FreeSwitch defined for the lines and it runs with "-nonat", the router does SIP ALG fine. I thought the setup example might be useful to someone since it took so long to figure it out. The only hold up has been that I have other wiki updates to do and had FreeSwitch issues this year, each time one is fixed another comes up (memory leak right now) so that has eaten up all the time I could put into the wiki. I have already started it and promise to post on the ML once it's up, should be in the next 2 months. It may help someone in the same situation and requirements. Mario G On Dec 17, 2012, at 6:17 AM, Cal Leeming [Simplicity Media Ltd] wrote:
Any other experiences/thoughts from others on this?
Feedback so far has been great, lets keep it coming guys!
Cal
On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita@freeswitch.org> wrote: My take on the subject is that we are trying to tackle 2 different problems at once.
On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario.
On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic.
So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available?
João Mesquita
On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote: It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email).
However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
Cal
On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com> wrote: "There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that: Not all NAT implementations function in the same way (eg some rewrite ports others do not) Not all SIP ALG implementations work the same/work Not all clients handle NAT in the same way You can encounter other odd situations such as double NAT that further complicate matters So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote: Any and all feedback on this thread would be much welcomed.
Hello,
There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Mario, If at all possible - feel free to just dump into the thread, and I can take care of getting it into a nice format into the wiki (everyones credits will be kept of course). Same for everyone else! Cal On Mon, Dec 17, 2012 at 5:08 PM, Mario G <mario_fs@mgtech.com> wrote:
I am planning on putting up an example of how I have 2 WAN lines both available to FreeSwitch, both used at the same time (load balanced), both are failover for each other. I have tested pulling plugs, etc. There is nothing in FreeSwitch defined for the lines and it runs with "-nonat", the router does SIP ALG fine. I thought the setup example might be useful to someone since it took so long to figure it out. The only hold up has been that I have other wiki updates to do and had FreeSwitch issues this year, each time one is fixed another comes up (memory leak right now) so that has eaten up all the time I could put into the wiki. I have already started it and promise to post on the ML once it's up, should be in the next 2 months. It may help someone in the same situation and requirements. Mario G
On Dec 17, 2012, at 6:17 AM, Cal Leeming [Simplicity Media Ltd] wrote:
Any other experiences/thoughts from others on this?
Feedback so far has been great, lets keep it coming guys!
Cal
On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita@freeswitch.org>wrote:
My take on the subject is that we are trying to tackle 2 different problems at once.
On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario.
On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic.
So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available?
João Mesquita
On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email).
However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
Cal
On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com>wrote:
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that:
- Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters
So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
NDLB-connectile-dysfunction and sip-force-contact are both pretty much deprecated but remain functional as a last resort. Most problems can be solved with one of agressive-nat-detection, NDLB-force-rport, or apply-nat-acl agressive-nat-detection and apply-nat-acl are both geared at the 'how' NAT is detected rather then the how to deal with it which is now centralized into the core of sofia with fs_path support. Stay tuned for the refresh of the FS Book where I just finished a large chapter on NAT. Kind of ironic that the following week everyone joins forces to document NAT so that's great. On Mon, Dec 17, 2012 at 11:20 AM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hi Mario,
If at all possible - feel free to just dump into the thread, and I can take care of getting it into a nice format into the wiki (everyones credits will be kept of course).
Same for everyone else!
Cal
On Mon, Dec 17, 2012 at 5:08 PM, Mario G <mario_fs@mgtech.com> wrote:
I am planning on putting up an example of how I have 2 WAN lines both available to FreeSwitch, both used at the same time (load balanced), both are failover for each other. I have tested pulling plugs, etc. There is nothing in FreeSwitch defined for the lines and it runs with "-nonat", the router does SIP ALG fine. I thought the setup example might be useful to someone since it took so long to figure it out. The only hold up has been that I have other wiki updates to do and had FreeSwitch issues this year, each time one is fixed another comes up (memory leak right now) so that has eaten up all the time I could put into the wiki. I have already started it and promise to post on the ML once it's up, should be in the next 2 months. It may help someone in the same situation and requirements. Mario G
On Dec 17, 2012, at 6:17 AM, Cal Leeming [Simplicity Media Ltd] wrote:
Any other experiences/thoughts from others on this?
Feedback so far has been great, lets keep it coming guys!
Cal
On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita@freeswitch.org>wrote:
My take on the subject is that we are trying to tackle 2 different problems at once.
On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario.
On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic.
So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available?
João Mesquita
On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email).
However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
Cal
On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre@gmail.com>wrote:
"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "
Part of the problem is that:
- Not all NAT implementations function in the same way (eg some rewrite ports others do not) - Not all SIP ALG implementations work the same/work - Not all clients handle NAT in the same way - You can encounter other odd situations such as double NAT that further complicate matters
So what works in one case might not work in another, so it's hard to give a concrete 'this is how to do it' that'll work in all cases. And often that means you need to find a failing client first then put in a NDLB workaround for that specific client. You could enable them by default, but that then can cause problems in other cases where the clients handle NAT correctly.
Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
-Steve
On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060> From: "foxx"<sip:2000@1.2.3.4:5060>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Nice, I'll be looking forward to seeing this..! I had little success with using 'apply-nat-acl' on its own, so I'll take another look at that (if anyone else has had success using this, please take a minute to reply!) Cal On Mon, Dec 17, 2012 at 5:41 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
apply-nat-acl
On the waiting list for the book then!! ;) João Mesquita FreeSWITCH™ Solutions On Mon, Dec 17, 2012 at 2:56 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Nice, I'll be looking forward to seeing this..!
I had little success with using 'apply-nat-acl' on its own, so I'll take another look at that (if anyone else has had success using this, please take a minute to reply!)
Cal
On Mon, Dec 17, 2012 at 5:41 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
apply-nat-acl
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 12/16/2012 11:15 AM, Cal Leeming [Simplicity Media Ltd] wrote:
*Any and all feedback on this thread would be much welcomed.*
We always disable ALG on the client side where possible. It always seems to break the connection. We also have the offsite phones register via tcp instead of udp and that helps. You may also want to look at your keep alives and set them to around 20-40secs or so to keep the connection open with the server. We have had good success with the opensource softphone jitsi. -- Regards -------------------------------------- Gerald Drouillard Technology Architect Drouillard & Associates, Inc. http://www.Drouillard.biz
Just throwing this out there - As it's clear how many problems NAT causes, why don't we all step up the pressure on phone manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us as soon as possible. Just saying - -Tim Cal Leeming [Simplicity Media Ltd] wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 <http://1.2.3.4:5060> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>> From: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16 <http://192.168.0.0/16>, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
IPv6 is NOT a NAT cure all (it may look like it remedies IPv4 PORT-address-translations (PAT, not NAT) issues, but IPv6 brings its own issues to the table. The intrinsic structure of the IPv6 address favors carriers/providers. Today, you get a global IPv4 WAN address and, typically, you then use a 10/8, 172/12, 192.168/16 LAN address schema. WITH IPv6 and WITHOUT IPv6-NAT (or NAT64), as an end user topology, the network portion of your carrier/provider IPv6 WAN address is, all other things being equal, propagated into LAN addresses schema on down to the deepest end points. If you subsequently change carrier/provider, then the network portion changes and, in this use case, ALL your LAN addressing MUST change accordingly. Things like statically addressed servers and router/switch ports, et al, ALL have to be re-configured. WITH IPv6 and WITH IPv6-NAT (and/or NAT64), you can utilize an internal IPv6 LAN address schema that can then be 1:1 IPv6-NAT'ed to anything your carrier/provider throws at you, regardless of whether you change C/P or the C/P periodically changes your addresses. This true NETWORK-address-translation (NAT) affords a 1:1 address mapping, which eliminates the shortfalls of the current IPv4 PORT-address-translations (PAT, not NAT). Other reasons for inside-outside translations include topology hiding (security), et cetera. Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix. IMO, NAT will NOT BE DEAD in an IPv6 universe. PAT may be n-stage, but not NAT. On 22 December 2012 23:19, Tim St. Pierre <fs-list@communicatefreely.net>wrote:
Just throwing this out there -
As it's clear how many problems NAT causes, why don't we all step up the pressure on phone manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us as soon as possible.
Just saying -
-Tim
Cal Leeming [Simplicity Media Ltd] wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, * * There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 <http://1.2.3.4:5060> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102:57787 ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>> From: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>;tag=83311448 Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16 <http://192.168.0.0/16>, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If you have a full IPv6 network, using all the protocols, like dns registration, DHCP-V6 for assigning networks to routers, Neighbor Discovery both directions, so that DNS delegations can be automated, then as long as you reference everything by host name, it should all just work. It's been working that way for me, with the only having to update nameserver helper records once and a while. If you happen have your own address space, and with to managed it downstream, all the services can also be implmented easy so that your down streams don't have to do anything to make all the auto address assignment, and DNS work. If you're going to use IPv6, set up the infrastructure FIRST, so managing it doesn't get out of hand. If done right at all layers it just works, when you use names. --Dave _____ From: Scott [mailto:8f27e956@gmail.com] To: FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org] Sent: Mon, 24 Dec 2012 16:14:03 -0800 Subject: Re: [Freeswitch-users] NAT traversal - the final say..! IPv6 is NOT a NAT cure all (it may look like it remedies IPv4 PORT-address-translations (PAT, not NAT) issues, but IPv6 brings its own issues to the table. The intrinsic structure of the IPv6 address favors carriers/providers. Today, you get a global IPv4 WAN address and, typically, you then use a 10/8, 172/12, 192.168/16 LAN address schema. WITH IPv6 and WITHOUT IPv6-NAT (or NAT64), as an end user topology, the network portion of your carrier/provider IPv6 WAN address is, all other things being equal, propagated into LAN addresses schema on down to the deepest end points. If you subsequently change carrier/provider, then the network portion changes and, in this use case, ALL your LAN addressing MUST change accordingly. Things like statically addressed servers and router/switch ports, et al, ALL have to be re-configured. WITH IPv6 and WITH IPv6-NAT (and/or NAT64), you can utilize an internal IPv6 LAN address schema that can then be 1:1 IPv6-NAT'ed to anything your carrier/provider throws at you, regardless of whether you change C/P or the C/P periodically changes your addresses. This true NETWORK-address-translation (NAT) affords a 1:1 address mapping, which eliminates the shortfalls of the current IPv4 PORT-address-translations (PAT, not NAT). Other reasons for inside-outside translations include topology hiding (security), et cetera. Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix. IMO, NAT will NOT BE DEAD in an IPv6 universe. PAT may be n-stage, but not NAT. On 22 December 2012 23:19, Tim St. Pierre <fs-list@communicatefreely.net> wrote: Just throwing this out there - As it's clear how many problems NAT causes, why don't we all step up the pressure on phone manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us as soon as possible. Just saying - -Tim Cal Leeming [Simplicity Media Ltd] wrote:
*Any and all feedback on this thread would be much welcomed.*
Hello, *
* There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers.
The NAT related wiki documentation is tedious, and depending on the outcome of this thread, I'd like to spend some time cleaning it up.
The most common problem (the same as ours) was having a router with broken ALG and a softphone that does not seem to work with STUN.
The following REGISTER is sent from a phone.
REGISTER sip:1.2.3.4:5060 <http://1.2.3.4:5060> SIP/2.0
Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513> To: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>
From: "foxx"<sip:2000@1.2.3.4:5060 <http://sip:2000@1.2.3.4:5060>>;tag=83311448
Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI. CSeq: 7 REGISTER Expires: 120 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Supported: replaces User-Agent: 3CXPhone 6.0.25732.0 Content-Length: 0
As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;
* NDLB-connectile-dysfunction * NDLB-force-rport * apply-nat-acl * sip-force-contact
The one that has worked in our case was "NDLB-connectile-dysfunction" (otherwise known as NAT HACK), however there seems to be a lot of negative comments about using this.
From what I can tell, the general argument is that NAT HACK is considered a non RFC compliant hack, and the SIP phones should be doing a better job of keeping to the RFCs.
In principle, this is a fair argument - but in practise, it's not a reasonable assumption that all phones are RFC compliant, and (imho) not a reasonable argument to have this functionality disabled by default.
So, I'd like to present the following arguments;
* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?
* Why is NDLB-connectile-dysfunction not enabled by default when certain conditions are met? In the event that FreeSWITCH receives a REGISTER from a phone specifying a Contact/Via as 192.168.0.0/16 <http://192.168.0.0/16>, but received on a public IP, then it should be
obvious that NAT is broken and automatically try to circumvent it.
* People seem to get confused between server side and client side NAT problems, and that they both need to be resolved in a different way. The documentation doesn't seem to reflect this clearly.
------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Dave, when you say, "...If you're going to use IPv6, set up the infrastructure FIRST," we both agree 100%. You appear to have a well ordered DNS infrastructure and an admin discipline and overarch to effect it, where the scope of the tool covers off your operations and problem set. :-) The mental gymnastics -- and the cacoffiny -- will rise over what "infrastructure" components work good/better/best for each admin once the carriers/providers, data centers, hosting providers, wireless, "guestnet" providers -- starbucks, hotels, corporate visitors nets, etc. -- all start trying it their way. And all i'm saying is that 1:1 NAT (not PAT) can (and will) play a viable role in competent/robust IPv6 infrastructures; and, therefore, IMO, NAT isn't going away through IPv6 pass 1, 2, or 3. Bet 'ya a dollar and see you in five-seven years at Cluecon. ;-) Cheers, ————— iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar errors • Last night I played a blank CD at full blast. The Mime next door went nuts. On 2012-12-24, at 21:10, "Dave R. Kompel" <drk@drkngs.net> wrote:
If you're going to use IPv6, set up the infrastructure FIRST,
On 25.12.2012 02:14, Scott wrote:
Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix.
I will use this when moving to ipv6. At my company we have two internet and voip providers for fault tolerance and load balacing. Also for using lowest cost per call. The plans are to have third internet and voip provider. So using internal ipv6 for addressing and dynamically mapping to those, provided by internet providers, is the only way to work. -- Mimiko desu.
if my subnet changes i only need to change ONE setting on my entire network. On 25 December 2012 07:35, Mimiko <vbvbrj@gmail.com> wrote:
On 25.12.2012 02:14, Scott wrote:
Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix.
I will use this when moving to ipv6. At my company we have two internet and voip providers for fault tolerance and load balacing. Also for using lowest cost per call. The plans are to have third internet and voip provider.
So using internal ipv6 for addressing and dynamically mapping to those, provided by internet providers, is the only way to work.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
Also if you're even thinking about using NAT for IPv6, you're doing it wrong and are still thinking of NAT as a useful mechanism which suggests you're not looking at IPv6 with a completely fresh mindset. Yes there are v4/v6 similarities, but they are few and far between. Any problems caused by a missing feature in v6 are because that feature in v4 is BAD. For example, people use NAT as a security mechanism. This is bad, because it's not. NAPT even violates the OSI model. If you want services to only be accessible privately, assign both private and public address and use your host and edge firewalls and listen parameters on the service so that only connections from the local subnets are allowed. IPv6 specifies that all hosts generate a non-routeable link-local address anyway. This makes perfect sense, as it brings ip-related layer 2 services u to layer 3, making them link-type independent. One such example is DHCPv6. There are also specifications for non-externally-routeable site-local addresses, which are only routeable within the LAN but can span multiple subnets. That's larger deployments taken care of. The thing to remember is that IPv6 is designed for each host to have multiple addresses, meaning you can have a link-local, site-local and globally routeable IP address per host which can each be secured independently. Manage it all correctly and there are no problems. A subnet change should just mean that you need to update DNS records for your external services and edge routers with the new subnet mask. Just my 2 cents. On 27 December 2012 14:25, Andrew Cassidy <andrew@cassidywebservices.co.uk>wrote:
if my subnet changes i only need to change ONE setting on my entire network.
On 25 December 2012 07:35, Mimiko <vbvbrj@gmail.com> wrote:
On 25.12.2012 02:14, Scott wrote:
Anyone with medium to large addressable end-points in their installations really needs to look at implementing IPv6 WITH -- repeat WITH -- IPv6-NAT (and/or NAT64) in the mix.
I will use this when moving to ipv6. At my company we have two internet and voip providers for fault tolerance and load balacing. Also for using lowest cost per call. The plans are to have third internet and voip provider.
So using internal ipv6 for addressing and dynamically mapping to those, provided by internet providers, is the only way to work.
-- Mimiko desu.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director
*T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
On Sun, Dec 16, 2012 at 9:15 AM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote:
Any and all feedback on this thread would be much welcomed.
Sorry to be a wet blanket... but when it comes to NAT, there will be no "final say" --only endless suffering ;) Gabe
Just wait til the ISPs who cab to set up IPv6 start double-natting. On 29 December 2012 10:08, Gabriel Gunderson <gabe@gundy.org> wrote:
On Sun, Dec 16, 2012 at 9:15 AM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote:
Any and all feedback on this thread would be much welcomed.
Sorry to be a wet blanket... but when it comes to NAT, there will be no "final say" --only endless suffering ;)
Gabe
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
Lol yes I'm starting to get that feeling. With all this info I'll be able to put something together, but it'll need a lot of proof reading I think Cal On Sat, Dec 29, 2012 at 10:08 AM, Gabriel Gunderson <gabe@gundy.org> wrote:
On Sun, Dec 16, 2012 at 9:15 AM, Cal Leeming [Simplicity Media Ltd] <cal.leeming@simplicitymedialtd.co.uk> wrote:
Any and all feedback on this thread would be much welcomed.
Sorry to be a wet blanket... but when it comes to NAT, there will be no "final say" --only endless suffering ;)
Gabe
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
IMO as a provider, FS does an excellent job at detecting NAT on its own and handling it. We've rarely had any issue with our end sending INVITEs to the wrong place or one / no way speech. connectile dysfunction does nothing more. The only switch we enable is one to enable the SIP options ping and to use sip-force-expires to reduce the time the endpoint re-registers for mobile devices. As with others on this thread, the ALG in most routers is the culprit, I've rarely experienced one which does anything beneficial, most screw up the headers. We also recommend that customers change the SIP port on their handsets to anything other than 5060, older BT routers especially seem to stop forwarding responses after a few minutes, again as they have a very basic ALG. Using port forwarding in the router is the only sure fire way of getting reliable SIP through to a handset, Draytek routers seem to be pretty flaky until you do this or use TCP / TLS. If the router stops forwarding packets because of a poor ALG implementation or other firewall rules, nothing FS can do will overcome this. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/NAT-traversal-the-final-say-tp... Sent from the freeswitch-users mailing list archive at Nabble.com.
Hi all, Thanks for everyones feedback on this, there's a lot of really useful info and this will make life much easier when writing the docs. I'm hoping to make a start on this within the next month (mod_xml_curl and mod_event_socket are first in my list). Of course, others are more than welcome to contribute as well :) Cal On Thu, Jan 3, 2013 at 4:12 PM, peely <freeswitch@peely.com> wrote:
IMO as a provider, FS does an excellent job at detecting NAT on its own and handling it. We've rarely had any issue with our end sending INVITEs to the wrong place or one / no way speech. connectile dysfunction does nothing more. The only switch we enable is one to enable the SIP options ping and to use sip-force-expires to reduce the time the endpoint re-registers for mobile devices.
As with others on this thread, the ALG in most routers is the culprit, I've rarely experienced one which does anything beneficial, most screw up the headers.
We also recommend that customers change the SIP port on their handsets to anything other than 5060, older BT routers especially seem to stop forwarding responses after a few minutes, again as they have a very basic ALG. Using port forwarding in the router is the only sure fire way of getting reliable SIP through to a handset, Draytek routers seem to be pretty flaky until you do this or use TCP / TLS.
If the router stops forwarding packets because of a poor ALG implementation or other firewall rules, nothing FS can do will overcome this.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/NAT-traversal-the-final-say-tp... Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi guys, I've still not had chance to look at this yet, been stuck working with mod_cdr_xml for the last few weeks. If anyone would else would like to make a start, please feel free - I'll pick up as soon as I can. Cal On Fri, Jan 18, 2013 at 2:31 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hi all,
Thanks for everyones feedback on this, there's a lot of really useful info and this will make life much easier when writing the docs.
I'm hoping to make a start on this within the next month (mod_xml_curl and mod_event_socket are first in my list).
Of course, others are more than welcome to contribute as well :)
Cal
On Thu, Jan 3, 2013 at 4:12 PM, peely <freeswitch@peely.com> wrote:
IMO as a provider, FS does an excellent job at detecting NAT on its own and handling it. We've rarely had any issue with our end sending INVITEs to the wrong place or one / no way speech. connectile dysfunction does nothing more. The only switch we enable is one to enable the SIP options ping and to use sip-force-expires to reduce the time the endpoint re-registers for mobile devices.
As with others on this thread, the ALG in most routers is the culprit, I've rarely experienced one which does anything beneficial, most screw up the headers.
We also recommend that customers change the SIP port on their handsets to anything other than 5060, older BT routers especially seem to stop forwarding responses after a few minutes, again as they have a very basic ALG. Using port forwarding in the router is the only sure fire way of getting reliable SIP through to a handset, Draytek routers seem to be pretty flaky until you do this or use TCP / TLS.
If the router stops forwarding packets because of a poor ALG implementation or other firewall rules, nothing FS can do will overcome this.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/NAT-traversal-the-final-say-tp... Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (17)
-
Andrew Cassidy
-
Anthony Minessale
-
Avi Marcus
-
Cal Leeming [Simplicity Media Ltd]
-
Dave R. Kompel
-
Gabriel Gunderson
-
Gerald Drouillard
-
João Mesquita
-
Mario G
-
Michael Collins
-
Mimiko
-
peely
-
S. Scott
-
Scott
-
Sean Devoy
-
Steven Ayre
-
Tim St. Pierre