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

[Paul]

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 at 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 at 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 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/20130802/fc8195d5/attachment-0001.html