SOLVED Freeswitch 1.8.5 NAT bug

DigitalDaz · Mar 11, 2019

There exists in Freeswitch 1.8.5 a NAT bug that will result in some users having problems witch calls, one symptom of this is some calls not being hung up correctly.

To work around this I have created a set of packages for freeswitch 1.8.4 as this does not appear to suffer from this problem.

I do not know how fusionpbx is going to officially work around this until a fix, I think the recommendation may be to go back to source compiling, I do not want to do that unless absolutely necessary.

In the mean time, if you wish, you can use the following method to use my packages.

Instead of the official fusionpbx instructions, use:

Code:

wget -O - https://raw.githubusercontent.com/digidaz/fusionpbx-install.sh/master/debian/pre-install.sh | sh;
cd /usr/src/fusionpbx-install.sh/debian && ./install.sh

Please note, that this is not officially supported and if I had the skill I could have modified the code to steal all your credentials, use at your own risk!

UCtech · Mar 29, 2019

Interesting . . . I've been testing FusionPBX/Freeswitch in a mid/large network and have had all kinds of NAT issues I just solved using 1.8.5 and some settings changes. My network test involved 3 networks which is probably typical for a mid sized company: External (fixed public IP, NAT'd), Private VOIP network (NAT'd), and Private network A (routed to VOIP network for softphones). Firewall is pfSense, Outbound NAT is set to "Static Port" for max compatibility.

Symptoms I experienced while trying different settings:
NAT issues symptoms:
1. External Inbound calls drop at 32 seconds (Outbound was fine)
2. Internal routed networks have 1 way audio, and can't hang up from one end, call drops at 30 seconds.

I've been playing with theses settings:
1. Edit /etc/default/freeswitch from the CLI and remove -nonat (restart Freeswitch)
2. Advanced-Sip Profiles - Internal & External, ext_rtp_ip & ext_sip_ip change to autonat:XXX.XXX.XXX.XXX with the x's being the public IP

What worked and not: Before I removed the -nonat and added the autonat's I could not get External NAT to work properly no matter the setting. Inbound calls would work, but drop at 32 seconds. Removing the -nonat and adding the autonat's fixed that (after a Freeswitch restart). Unfortunately, adding the autonat settings to both the Internal & External SIP profile resulted in routing problems between internal networks (like with softphones not on the VOIP LAN segment -- these phones would have 1 way audio and not be able to hang up). I then put the Internal SIP profile back to defaults (ext_rtp_ip & ext_sip_ip to $${local_ip_v4} ). Then everything worked. To summarize the settings that worked:

1. Edit /etc/default/freeswitch from the CLI and remove -nonat (restart Freeswitch)
2. Advanced-Sip Profiles - External (NOT Internal), ext_rtp_ip & ext_sip_ip change to autonat:XXX.XXX.XXX.XXX with the x's being the public IP
3. Restart Freeswitch

Curious if my settings that "work" with 1.8.5 would still work with 1.6 or 1.8.4 or whatever comes next, and how they might be different from what DigitalDaz has done? Basically did I find a workaround, or is that the way it is supposed to work?

ad5ou · Mar 29, 2019

The nat bug is for certain type of NAT and I believe I saw a reference to freeswitch correcting the bug.

DigitalDaz · Mar 31, 2019

Yes, I haven't tested yet but my understanding is the bug is now fixed in the 1.8.4 source branch. I have just looked and it does not look as if the packages at http://files.freeswitch.org/repo/deb/freeswitch-1.8/pool/main/f/freeswitch/ have been rebuilt so the bug still appears to exist in the packaged version.

ZPM · May 23, 2019

Digi the above install instructions will install with 1.8.4? and will I need to hold back running apt-get updates until they release a updated package?

DigitalDaz · May 23, 2019

No, the above install scripts will add MY repo to the apt sources list. So apt get update will do nothing for freeswitch unless I upgraded mine.

I will add a quick script to run to switch the sources list back to freeswitch one they have made a release.

I'm also going to continue adding new freeswitch packages to my own repo though as freeswitch deletes the old ones and I want the ability to roll back to a previous version.

markjcrane · May 23, 2019

I will contact FreeSWITCH developers and see if we can get an official fix released.
My opinion we are better off if we are able to stick with the official FreeSWITCH packages.

DigitalDaz · May 23, 2019

Sorry, I can't agree with that. What about the next time they release a buggy one and then take months to fix it. Its now then end of May and the current packages on their site are from January. Going forward I will just keep copies of the official packages but being as they are deleting previous ones, I had no choice other than to build myself.

anthm · May 23, 2019

Hi, The original JIRA on this was filed in Feb and Closed in March. If something is still wrong we would need a followup bug report or we may not realize there is still a problem as there was a consensus it was working from reporters.

DigitalDaz · May 24, 2019

I have just been doing some further testing. I thought this may be the same as: https://freeswitch.org/jira/browse/FS-11814

Mike Jerris reports this as fixed in master but I do not see the issue I am seeing fixed. I have just installed on master and tested.

On an inbound call from carrier, If A leg hangs up, B leg does not receive a BYE. This looks to a novice like me that the BYE is not using the fs_path and is instead going straight to the natted contact which is a private IP. I will continue to dig then make a jira:

Code:

Registrations:
=================================================================================================
Call-ID:        1_1613032849@192.168.50.132
User:           200@pbx.mypbxdomain.com
Contact:        "200" <sip:200@192.168.50.132:12080;transport=TCP;fs_nat=yes;fs_path=sip%3A200%40185.223.XXX.YY%3A38617%3Btransport%3DTCP>
Agent:          Yealink SIP-T41S 66.84.0.35
Status:         Registered(TCP-NAT)(unknown) EXP(2019-05-24 10:48:56) EXPSECS(170)
Ping-Status:    Reachable
Ping-Time:      0.00
Host:           fstest
IP:             185.223.XXX.YY
Port:           38617
Auth-User:      200
Auth-Realm:     pbx.mypbxdomain.com
MWI-Account:    200@pbx.mypbxdomain.com

Total items returned: 1
=================================================================================================

An UPDATE method appears to be sent by the server correctly to the address contained in fs_path

Code:

nua.c:810 nua_update() nua: nua_update: entering
nua_stack.c:529 nua_signal() nua(0x7f2da8001220): sent signal r_update
nua_stack.c:569 nua_stack_signal() nua(0x7f2da8001220): recv signal r_update
nua_params.c:482 nua_stack_set_params() nua: nua_stack_set_params: entering
soa.c:403 soa_set_params() soa_set_params(static::0x7f2de4006ca0, ...) called
soa.c:1302 soa_init_offer_answer() soa_init_offer_answer(static::0x7f2de4006ca0) called
soa.c:1426 soa_generate_offer() soa_generate_offer(static::0x7f2de4006ca0, 0) called
soa_static.c:1148 offer_answer_step() soa_static_offer_answer_action(0x7f2de4006ca0, soa_generate_offer): called
soa_static.c:1029 soa_sdp_mode_set() soa_sdp_mode_set(0x7f2de4008bc0, (nil), ""): called
soa.c:1270 soa_get_local_sdp() soa_get_local_sdp(static::0x7f2de4006ca0, [(nil)], [0x7f2e0b0a0c48], [0x7f2e0b0a0c44]) called
nta.c:2665 nta_tpn_by_url() nta: selecting scheme sip
tport.c:4592 tport_by_name() tport(0x7f2de4004900): found 0x7f2de401dd00 by name TCP/185.223.XXX.YY:38617
tport.c:3261 tport_tsend() tport_tsend(0x7f2de401dd00) tpn = TCP/185.223.XXX.YY:38617
tport.c:3598 tport_vsend() tport_vsend(0x7f2de401dd00): 1055 bytes of 1055 to tcp/185.223.XXX.YY:38617
tport.c:3496 tport_send_msg() tport_vsend returned 1055
tport.c:2298 tport_set_secondary_timer() tport(0x7f2de401dd00): reset timer
nta.c:8310 outgoing_send() nta: sent UPDATE (4791019) to TCP/185.223.XXX.YY:38617

The BYE, however does not seem to be using the fs_path and instead just goes to the contact

Code:

nua.c:645 nua_bye() nua: nua_bye: entering
nua_stack.c:529 nua_signal() nua(0x7f2da8001220): sent signal r_bye
nua_stack.c:569 nua_stack_signal() nua(0x7f2da8001220): recv signal r_bye
nua_params.c:482 nua_stack_set_params() nua: nua_stack_set_params: entering
soa.c:403 soa_set_params() soa_set_params(static::0x7f2de4006ca0, ...) called
soa.c:1784 soa_terminate() soa_terminate(static::0x7f2de4006ca0) called
soa.c:1302 soa_init_offer_answer() soa_init_offer_answer(static::0x7f2de4006ca0) called
nta.c:2665 nta_tpn_by_url() nta: selecting scheme sip
tport.c:3261 tport_tsend() tport_tsend(0x7f2de4004900) tpn = TCP/192.168.50.132:12080
tport.c:4050 tport_resolve() tport_resolve addrinfo = 192.168.50.132:12080
tport.c:4684 tport_by_addrinfo() tport_by_addrinfo(0x7f2de4004900): not found by name TCP/192.168.50.132:12080
tport.c:862 tport_alloc_secondary() tport_alloc_secondary(0x7f2de4004900): new secondary tport 0x7f2de4012da0
tport_type_tcp.c:203 tport_tcp_init_secondary() tport_tcp_init_secondary(0x7f2de4012da0): Setting TCP_KEEPIDLE to 30
tport_type_tcp.c:209 tport_tcp_init_secondary() tport_tcp_init_secondary(0x7f2de4012da0): Setting TCP_KEEPINTVL to 30
tport.c:1032 tport_base_connect() tport_base_connect(0x7f2de4012da0): connecting to tcp/192.168.50.132:12080/sip
tport.c:2298 tport_set_secondary_timer() tport(0x7f2de4012da0): reset timer
tport.c:3786 tport_queue() tport_queue(0x7f2de4012da0): queueing 0x7f2de4012580 for tcp/192.168.50.132:12080
nta.c:8310 outgoing_send() nta: sent BYE (4791020) to TCP/192.168.50.132:12080
tport.c:4164 tport_pend() tport_pend(0x7f2de4012da0): pending 0x7f2de4012580 for tcp/192.168.50.132:12080 (already 0)

DigitalDaz · May 24, 2019

I have just removed the line added in commit 185ddcb860f13 in Mar 2018 and recompiled latest master and it works.

This is the commit that broke things

DigitalDaz · May 24, 2019

I have added this info to FS-11814

yukon · May 24, 2019

AWESOME WORK DIGIDAZ! Let's hope FS actually releases a fix soon.

Matthew Main · May 28, 2019

Cheers DigiDaz top work

Incubugs · Jun 1, 2019

I have looked at the freeswitch file archives and noticed they have rebuilt the packages in may , is the nat bug now fixed ?

DigitalDaz · Jun 1, 2019

Incubugs said:
I have looked at the freeswitch file archives and noticed they have rebuilt the packages in may , is the nat bug now fixed ?

You are seeing something I don't then. Where do you see this? A couple of days ago, the same bug was present in 1.9 master.

Incubugs · Jun 1, 2019

Sorry m8 i was looking at the source not packages ignore my last

would this nat bug issue cause speech loss on phones that are external to the system ? ie phones are behind nat but fusion is on public ip ?

DigitalDaz · Jun 1, 2019

I don't think so.

Incubugs · Jun 1, 2019

Was thinking outload here, as my setup is very dependant of freeswitch version and as they have a tendancy to break in new updates

is there any way i can setup my own package repo and change the fusionpbx installer to pull freeswitch from my repo and not freeswitches ?

DigitalDaz · Jun 1, 2019

Incubugs said:
Was thinking outload here, as my setup is very dependant of freeswitch version and as they have a tendancy to break in new updates is there any way i can setup my own package repo and change the fusionpbx installer to pull freeswitch from my repo and not freeswitches ?

Freeswitch is very difficult these days to build your own packages. I'm just gonna keep them all going forward. I believe 1.8.4 is stable, you can use them out of my repo.

SOLVED Freeswitch 1.8.5 NAT bug

Administrator

Member

Active Member

Administrator

Member

Administrator

Active Member

Administrator

New Member

Administrator

Administrator

Administrator

Member

Member

Member

Administrator

Member

Administrator

Member

Administrator