It's 2 in the morning and I'm really sleepy so pardon me if it does not make a lot of sense but maybe something to do with php timeout closing the socket and dropping the call? Em 22/07/2013 14:33, "Michael Collins" <msc@freeswitch.org> escreveu:
Hi Fraser,
I'm curious about this line (#842 from PB 21211): 2013-07-20 10:42:15.093114 [NOTICE] mod_commands.c:2960 Hangup sofia/internal/sip:12605@192.168.1.43:51977 [CS_EXECUTE] [NORMAL_CLEARING]
That hangup is coming from mod_commands.c, which suggests that there is something going on related to the originate API. For test purposes, what happens when you manually perform the originate from fs_cli without using the web/PHP stuff? See if the symptom occurs there or not and that may help narrow down where to look next.
-MC
On Sat, Jul 20, 2013 at 5:15 AM, Fraser Redmond <fraserredmond@gmail.com>wrote:
Some of our calls are getting disconnected after exactly 5 minutes. I've finally narrowed it down to be something to do with how the calls are initiated. We have 2 ways of initiating calls:
1) Direct from a softphone out to a gateway to a landline number - this doesn't disconnect after 5min
2) From our webapp using php and fsock to call a command like this: api originate {otherVarsGetPassedThruHereFromPhp=x}user/12605@$freeswitchDomain 442030112233 (I pass through about 8-10 vars. I've tried removing them all, but it still disconnects.) The call works fine and everything is normal until 5 minutes after the call was answered, at which point it hangs up (usually with a second or two, sometimes up to 10 seconds after the 5 minute mark.)
A few things I've already tried and ruled out:
- I've stripped out all the javascript files that we run, variables we set, and commands we run, so that the only part of the dialplan that gets executed are just: <action application="bridge" data="sofia/gateway/flowroute/796000#442030112233"/>
- Right before it disconnects there are no extra lines in the sip log (other than those to handle the hangup.) There's also no sip messages in the log immediately before it disconnects.
- A year ago I set "record_waste_resources=true" and that seemed to fix it at the time - but it may have only fixed the calls direct from the softphone.
- In the internal and external profiles I've set rtp-timeout-sec=3600 (it used to be 300, and I thought that might be the cause.)
- I've done a file compare between the log outputs of each type of call and theres differences that I'd expect because of the different types of call, but otherwise they're about the same. (Differences in how the codec gets set, and a slightly different route through the dialplan.)
A few other details about our setup
- I upgrade to the latest version of freeswitch regularly, but the problem has been happening for months or years.
- Our production server is on Amazon AWS, so there could be a NAT issue... but it also happens on my dev server on my local network (though that is behind a NAT too, so it could be the NAT between my dev server and the gateway... what would I do about that? And why would it happen with one type of call, but not the other.)
- Normally, all our calls are recorded, so I'm not doing bypass-media. The wav file for a 5min recording is just slightly under 10mb, so I had been wondering if that was the limit being hit, but it still disconnects if recording is off.
- I've tried with a different gateway and different softphone, and it still happens.
- Here's a full log output (with sip) if you want to take a look:
http://pastebin.freeswitch.com/21211 http://pastebin.freeswitch.com/21212 (this is direct from the softphone, in case the comparison helps)
I'm stumped, so any ideas or advice would be much appreciated. I have a pcap I can send if you want to look at one.
My best guess right now is that it's a bug to do with api originate. (That it's setting a variable that a normal call doesn't, or vice-versa.)
Or is there something I should change about the format of either: user/12605@$freeswitchDomain or sofia/gateway/flowroute/796000#442030112233 (I set up the format of both of those strings about 3 years ago, so maybe there's a better way to do it now.)
Cheers, Fraser
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ 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