[Freeswitch-users] Calls from api originate disconnect after 5 minutes

Tue Jul 23 09:42:57 MSD 2013

The mod_commands line Michael refers to is evidence you are calling
sched_hangup on the uuid of the channel with an arg of 0 or a non-numeric
val which evals to 0 which is instant hangup.
There is no way around it that is the exact line of code in this revision
being executed.

My guess is a bug in your controlling script sending a syntax err like

sched_hangup $uuid 0
sched_hangup $uuid foo

        if ((hsession = switch_core_session_locate(uuid))) {
            if (sec == 0) {
                switch_channel_t *hchannel =
switch_core_session_get_channel(hsession);
                switch_channel_hangup(hchannel, cause);
            } else {
                switch_ivr_schedule_hangup(when, uuid, cause, SWITCH_FALSE);
            }

On Tue, Jul 23, 2013 at 12:15 AM, Wesley Akio <wesleyakio at tuntscorp.com>wrote:

> 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 at 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 at 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 at 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 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
>>>
>>>
>>
>>
>> --
>> Michael S Collins
>> Twitter: @mercutioviz
>> http://www.FreeSWITCH.org
>> http://www.ClueCon.com
>> http://www.OSTAG.org
>>
>>
>> _________________________________________________________________________
>> 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
>>
>>
> _________________________________________________________________________
> 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
>
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130723/1eb6dda2/attachment.html 