Re: [Freeswitch-users] FreeSWITCH -- 30 Second call drop
On Thu, 1 Aug, 2013 at 1:47 PM, E.J.C. Lindner <office@fordior.net> wrote:
Hi Paul,
I saw you emails regarding 30 seconds call drop. I have exactly the same issue when I want to connect my client over OpenVPN to my FS server, which is also the vpn server at the same time (server is on a public IP).
All my calls are dropped after 32 seconds... very annoying and I can't find the solution. So I'm constantly switching config for standard vs vpn for my client and FS (the standard config is just connecting to the public ip which is unencrypted).
Did you find a solution in the mean time? Please inform me, cause it's really killing me. :=|
I hope you can inform me on a short term; really appreciated!
-- Yours sincerely, E.J.C. Lindner
Yes I found a solution to my problem. My case differs a little bit from yours in that my openvpn server is on the router, not on the PBX, in your case it's probably even a little simpler. So here is what I can advise you, 1. Ensure NAT is working properly over openVPN, so to test that all you need to do is have 2 phones on the same PBX able to call each other internally (extension 100 to extension 101 for instance). If that works then your VPN NAT is probably good. 2. Ensure that your PBX is reporting the correct external address to your vendor upstream (this is where it was messing me up). For example, for me my PBX was 10.0.0.40 (itnernal address) which the router was NATing to 24.38.231.4 (just a sample external address) and the same on the way back, when a request would come in for 24.38.231.4 it would translate it to 10.0.0.40. Because my PBX was not aware of 24.38.231.4 as it's external address, it was only listening on 10.0.0.40, it wasn't responding to the SIP ACK packets correctly, and the call was being perceived as finished and therefore hung up. To fix it in FreeSwitch I had to edit external.xml and insert the proper IP address for sip_ext_ip and rtp_ext_ip (this is from memory) I hope this helps you out cuz it cost me hours of frustration :) Paul
If that doesn't work, check your mtu and/or make sure you aren't blocking icmp on your firewall if you want to do path-mtu discovery. I had a 31 second call drop problem and it was because my icmp unreachable (needs fragmentation) packets weren't getting all the way back to me (in my case it was a bad route) and so I my device wasn't adjusting my mtu and the call would drop exactly at 31 seconds in every single time. On Thu, Aug 1, 2013 at 5:13 PM, Paul <pasha@prosperity4ever.com> wrote:
On Thu, 1 Aug, 2013 at 1:47 PM, E.J.C. Lindner <office@fordior.net> wrote:
Hi Paul, I saw you emails regarding 30 seconds call drop. I have exactly the same issue when I want to connect my client over OpenVPN to my FS server, which is also the vpn server at the same time (server is on a public IP). All my calls are dropped after 32 seconds... very annoying and I can't find the solution. So I'm constantly switching config for standard vs vpn for my client and FS (the standard config is just connecting to the public ip which is unencrypted). Did you find a solution in the mean time? Please inform me, cause it's really killing me. :=| I hope you can inform me on a short term; really appreciated! -- Yours sincerely, E.J.C. Lindner
Yes I found a solution to my problem.
My case differs a little bit from yours in that my openvpn server is on the router, not on the PBX, in your case it's probably even a little simpler.
So here is what I can advise you,
1. Ensure NAT is working properly over openVPN, so to test that all you need to do is have 2 phones on the same PBX able to call each other internally (extension 100 to extension 101 for instance).
If that works then your VPN NAT is probably good.
2. Ensure that your PBX is reporting the correct external address to your vendor upstream (this is where it was messing me up).
For example, for me my PBX was 10.0.0.40 (itnernal address) which the router was NATing to 24.38.231.4 (just a sample external address) and the same on the way back, when a request would come in for 24.38.231 .4 it would translate it to 10.0.0.40.
Because my PBX was not aware of 24.38.231.4 as it's external address, it was only listening on 10.0.0.40, it wasn't responding to the SIP ACK packets correctly, and the call was being perceived as finished and therefore hung up.
To fix it in FreeSwitch I had to edit external.xml and insert the proper IP address for sip_ext_ip and rtp_ext_ip (this is from memory)
I hope this helps you out cuz it cost me hours of frustration :)
Paul
_________________________________________________________________________ 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
That's a great piece of information to have as well. I do have my router not responding to ICMP requests, and I was noticing some errors in regards to ICMP unreachable packets while I was having issues, but for me setting the correct external ip for freeswitch and natting it correctly solved my audio issues. Not sure if the ICMP errors are still there or not, they might be, this is making me go back and look :) Paul On Thu, 1 Aug, 2013 at 6:29 PM, Carlos Flor <jackal@cybershroud.net> wrote:
If that doesn't work, check your mtu and/or make sure you aren't blocking icmp on your firewall if you want to do path-mtu discovery. I had a 31 second call drop problem and it was because my icmp unreachable (needs fragmentation) packets weren't getting all the way back to me (in my case it was a bad route) and so I my device wasn't adjusting my mtu and the call would drop exactly at 31 seconds in every single time.
On Thu, Aug 1, 2013 at 5:13 PM, Paul <pasha@prosperity4ever.com> wrote:
Hi Paul,
I saw you emails regarding 30 seconds call drop. I have exactly the same issue when I want to connect my client over OpenVPN to my FS server, which is also the vpn server at the same time (server is on a public IP).
All my calls are dropped after 32 seconds... very annoying and I can't find the solution. So I'm constantly switching config for standard vs vpn for my client and FS (the standard config is just connecting to the public ip which is unencrypted).
Did you find a solution in the mean time? Please inform me, cause it's really killing me. :=|
I hope you can inform me on a short term; really appreciated!
-- Yours sincerely, E.J.C. Lindner
Yes I found a solution to my problem.
My case differs a little bit from yours in that my openvpn server is on the router, not on the PBX, in your case it's probably even a little simpler.
So here is what I can advise you,
1. Ensure NAT is working properly over openVPN, so to test that all you need to do is have 2 phones on the same PBX able to call each other internally (extension 100 to extension 101 for instance).
If that works then your VPN NAT is probably good.
2. Ensure that your PBX is reporting the correct external address to your vendor upstream (this is where it was messing me up).
For example, for me my PBX was 10.0.0.40 (itnernal address) which the router was NATing to 24.38.231.4 (just a sample external address) and the same on the way back, when a request would come in for 24.38.231 .4 it would translate it to 10.0.0.40.
Because my PBX was not aware of 24.38.231.4 as it's external address, it was only listening on 10.0.0.40, it wasn't responding to the SIP ACK packets correctly, and the call was being perceived as finished and therefore hung up.
To fix it in FreeSwitch I had to edit external.xml and insert the proper IP address for sip_ext_ip and rtp_ext_ip (this is from memory)
I hope this helps you out cuz it cost me hours of frustration :)
Paul
_________________________________________________________________________ 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
Hello Paul, I tried your checklist, but that wasn't the solution in my setup. For everyone who's running FS on a public server (WAN ip) in combination with a VPN: ---- sip_profiles/internal.xml: <param name="rtp-ip" value="your-internal-VPN-ip"/> <param name="sip-ip" value="your-internal-VPN-ip"/> <param name="ext-sip-ip" value="your-internal-VPN-ip"/> <param name="ext-rtp-ip" value="your-internal-VPN-ip"/> ---- My mistake was giving both ext-sip-ip and ext-rtp-ip my WAN IP address. After several dumpcaps and analysing these with wireshark, I noticed a change in the 'Via:' address of the SIP Message Header. Instead of the internal VPN ip address, it changed to my WAN address. So the ACK wasn't answered and therefor the call was disconnected after 32 seconds. (Please note that all these values in the sip_profiles/external.xml need to have the WAN ip address.) Maybe this information will help someone else some day... @jackal: Thanks for pointing out some usefull informations regarding ICMP and MTU. Cheers! -- EL
participants (3)
-
Carlos Flor
-
EL
-
Paul