When hanging up a call coming in to a FusionPBX/FreeSwitch SIP client from a PSTN endpoint the latter doesn't automatically hang up also. If the other endpoint is a mobile phone it will hang up shortly after as expected. What setting would make the PSTN endpoint hang up also, please?
Hangup not noticed by other PSTN party?
- Thread starter legolas108
- Start date
- Status
You may get more help if you describe your system setup and post relevant log entries and/or a packet capture of the SIP messages.
Just a guess, it may be an issue related to NAT. Possibly your BYE is going missing because of an incorrect SIP contact header. Without more detail we can only guess.
Just a guess, it may be an issue related to NAT. Possibly your BYE is going missing because of an incorrect SIP contact header. Without more detail we can only guess.
Thanks for quick response!
Running FusionPBX 4.5.10 on FreeSwitch 1.8.4 in a dedicated Ubuntu 18.04 server KVM "pbx" on a Ubuntu 18.04 server box with dedicated NIC pass-through connected to the modem. There's a VPN connection from "pbx" (IP 192.168.4.3, subnet 192.168.4.0/24 dedicated to SIP server and clients) to a cloud VPS (sanitized IP 12.34.56.78 configured with VoIP provider).
Relevant ports are forwarded by FireHOL (iptables) on the cloud VPS. To make the VPN work had to replace the FusionPBX iptables rules by FireHOL rules. Also had to replace $${local_ip_v4} with 192.168.4.3 in FusionPBX Variables and SIP profiles, as well as set ext-rtp-ip and ext-sip-ip to "autonat:12.34.56.78" in the external profile, and remove the "-nonat" from the DAEMON_OPTS in /etc/default/freeswitch to make up for wrong local_ip_v4 detection and NAT issues causing one-way sound. Would have preferred to do without the VPN and manage the dynamic IP from the ISP, but didn't succeed. Otherwise it's now running fine except for this hangup issue.
Enclosed the probably relevant excerpt of a fs_cli log. Caller (PSTN): 1234567890, called (VoIP): 9876543210.
Thanks for any hint in the right direction!
Running FusionPBX 4.5.10 on FreeSwitch 1.8.4 in a dedicated Ubuntu 18.04 server KVM "pbx" on a Ubuntu 18.04 server box with dedicated NIC pass-through connected to the modem. There's a VPN connection from "pbx" (IP 192.168.4.3, subnet 192.168.4.0/24 dedicated to SIP server and clients) to a cloud VPS (sanitized IP 12.34.56.78 configured with VoIP provider).
Relevant ports are forwarded by FireHOL (iptables) on the cloud VPS. To make the VPN work had to replace the FusionPBX iptables rules by FireHOL rules. Also had to replace $${local_ip_v4} with 192.168.4.3 in FusionPBX Variables and SIP profiles, as well as set ext-rtp-ip and ext-sip-ip to "autonat:12.34.56.78" in the external profile, and remove the "-nonat" from the DAEMON_OPTS in /etc/default/freeswitch to make up for wrong local_ip_v4 detection and NAT issues causing one-way sound. Would have preferred to do without the VPN and manage the dynamic IP from the ISP, but didn't succeed. Otherwise it's now running fine except for this hangup issue.
Enclosed the probably relevant excerpt of a fs_cli log. Caller (PSTN): 1234567890, called (VoIP): 9876543210.
Thanks for any hint in the right direction!
For this call the hangup looks fine from your side. Your edge sends the BYE and 131ms later it is responded to with a 200 OK from your provider.
Does this hangup delay happen for every inbound call from a land line? Clearly from what you say, an inbound call from a mobile hangs up OK. Have you tried a call from a different landline?
Twilio uses 54.172.60.0 - 54.172.60.3 on a 10 minute TTL, have you whitelisted them all in your firewall?
Your log file does not show the whole call but from what I can see, it doesn't look like the issue is a your end.
Does this hangup delay happen for every inbound call from a land line? Clearly from what you say, an inbound call from a mobile hangs up OK. Have you tried a call from a different landline?
Twilio uses 54.172.60.0 - 54.172.60.3 on a 10 minute TTL, have you whitelisted them all in your firewall?
Your log file does not show the whole call but from what I can see, it doesn't look like the issue is a your end.
Thanks so much for your prompt response and looking into the details!
Tried one other land line number and it was the same, no automatic hangup.
All Twilio IPs (54.172.60.0/23, 34.203.250.0/23, 54.244.51.0/24) are whitelisted in the firewall.
Logged another brief test call, complete fs_cli log enclosed.
Seems to be more of an inconvenience only for the PSTN endpoint, or could this have more serious consequences, if we left it like that?
Tried one other land line number and it was the same, no automatic hangup.
All Twilio IPs (54.172.60.0/23, 34.203.250.0/23, 54.244.51.0/24) are whitelisted in the firewall.
Logged another brief test call, complete fs_cli log enclosed.
Seems to be more of an inconvenience only for the PSTN endpoint, or could this have more serious consequences, if we left it like that?
Hi I have had a quick look through your latest log/SIP trace, I can't see anything obviously wrong with it right now, I will have a closer look in the morning.
I feel sure the issue is not within your network.
I'm not at all familiar with the way your provider works. The wholesale providers I work with here in the UK never send packets from a different ports (53411) than the ones advertised in the Record-Route, Contact and Via headers, and certainly do not put RFC1918 IP addresses (172.18.60.240) in their Contact and Via headers. Having said that, your call seems to work OK.
As I said earlier, you send the BYE and your provider responds with a 200 OK within 200ms. As far as you are concerned that's the job done. Maybe a proxy further down the line is having trouble forwarding the BYE? It's difficult to say because you don't see that information.
I feel sure the issue is not within your network.
I'm not at all familiar with the way your provider works. The wholesale providers I work with here in the UK never send packets from a different ports (53411) than the ones advertised in the Record-Route, Contact and Via headers, and certainly do not put RFC1918 IP addresses (172.18.60.240) in their Contact and Via headers. Having said that, your call seems to work OK.
As I said earlier, you send the BYE and your provider responds with a 200 OK within 200ms. As far as you are concerned that's the job done. Maybe a proxy further down the line is having trouble forwarding the BYE? It's difficult to say because you don't see that information.
Hi Adrian
Thanks a lot for your review and background info, much appreciated. Good to know from an expert that we're (most likely) OK with our setup.
Thanks a lot for your review and background info, much appreciated. Good to know from an expert that we're (most likely) OK with our setup.
A thought just occurred to me...
You said that mobiles hang up as expected but calls from PSTN landlines do not. Are these landline endpoints analogue phones?
You said that mobiles hang up as expected but calls from PSTN landlines do not. Are these landline endpoints analogue phones?
The landline endpoints are with a 20+ year old phone system, a Panasonic KX-TD1232, which accommodates analog and digital phones (and which we want to replace by the VoIP system). For the test used a Panasonic KX-TGA652 DECT 6.0 cordless digital handset.
OK, that may be the reason then. If the system is connected via ISDN, then it should get a distant end clear down notification, but it has to be configured correctly to recognise it and act upon it. If it is on an analogue line (copper pair) then we get into loop guarded and loop unguarded configurations. Generally in the UK we used to set the systems to loop unguarded on the basis that it was a user of that system that made the call, so they can go on paying for it until they decide to hang up. On some systems we used to set unguarded release clear timers. We really don't want to get into this old stuff!
Anyway, I don't think you have anything to worry about.
Anyway, I don't think you have anything to worry about.
Last edited:
These old systems should get fewer and fewer one would assume, so over time this issue should disappear then.
Thanks so much for looking into it and giving your expert advice and so promptly, highly appreciated!
Thanks so much for looking into it and giving your expert advice and so promptly, highly appreciated!
- Status