[Freeswitch-users] FreeSWITCH -- 30 Second call drop

[Carlos Flor]

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 at prosperity4ever.com> wrote:

>
>
> On Thu, 1 Aug, 2013 at 1:47 PM, E.J.C. Lindner <office at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130801/ae34ddfb/attachment.html