[Freeswitch-users] Issues with simultaneous call hangup

[Anthony Minessale]

What you are doing is illogical and by design the wrong approach.
exec_after_bridge does not work on hungup channels, plus zombie_exec only
works on a handful of apps.
When the leg is hungup it is dead.  You should not try to do things on a
leg after it hangs up.
There are countless events and cdr collecting modules and code hooks to
properly capture a hangup record.
This is not a bug or a race condition, its abuse of the way the sofftware
is designed.  Its like saying you want your hard drive to sync its data
whenever you unplug the power cord.



On Thu, Jul 16, 2015 at 9:52 AM, Niraj Roy <techfaltu at gmail.com> wrote:

> Hi Michel,
>    Thanks for your reply. I have tested with 4.1.20 and found the same
> result.
> After digging up some more I found that on end call handler if we perform
> any lightweight activity like printing a log, it works fine. But if we
> perform a bit heavy activity like calling a curl for CDR, it gets exhausted
> and not able to execute saying 'channel is hung up already'.
>   I think this is a very common phenomena and should have occur any and
> everyone in the said case. I am not an expert in FS hoping of missing
> something which somebody can rightly point out here.
>
> Thanks,
> Niraj
>
>
> On Tue, Jul 14, 2015 at 9:12 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> Does this happen in the latest 1.4.20 release
>>
>>
>> On Tuesday, July 14, 2015, Niraj Roy <techfaltu at gmail.com> wrote:
>>
>>> Hello Gurus,
>>>     We are using FreeSWITCH Version 1.4.18~64bit. We observed when both
>>> caller and caller hangs up the call simultaneously exec_after_bridge_app
>>> function does not execute for one of the legs.
>>>     Here is the segment of executing the xml file.
>>>                 <action application="set"
>>> data="exec_after_bridge_app=transfer"/>
>>>                 <action application="set"
>>> data="exec_after_bridge_arg=endcall-handler XML CALLENDING"/>
>>>                 <action application="set_zombie_exec"/>
>>>                 <action application="set" data="continue_on_fail=true"/>
>>>                 <action inline="true" application="set"
>>> data="hangup_after_bridge=false"/>
>>>
>>> For normal or sequential call clearing everything works fine, but
>>> somehow this creates a race condition and state mismatch in the freeswitch
>>> which I don't know.
>>> Can anybody shed some light on this?
>>>
>>> Thanks,
>>>
>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.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://confluence.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       ♬ @anthmfs  ♬ @FreeSWITCH  ♬

☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞
http://twitter.com/FreeSWITCH
☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
<http://freeswitch.org/g+>*

ClueCon Weekly Development Call
☎ sip:888 at conference.freeswitch.org  ☎ +19193869900

https://www.youtube.com/watch?v=9XXgW34t40s
https://www.youtube.com/watch?v=NLaDpGQuZDA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150716/c14062de/attachment.html