[Freeswitch-users] Cannot Kill stale channels

Anthony Minessale anthony.minessale at gmail.com
Wed Mar 20 06:18:23 MSK 2013


look for loops in the script not calling session:ready() if session:ready()
ever returns 0 you must exit the script instantly.



On Tue, Mar 19, 2013 at 5:36 PM, Marc de Corny <marcdecorny at gmail.com>wrote:

> Hi,
>
> I have been quite busy and not been able to pursue this issue further,
> however i still haven't resolved this. if somebody has an idea I'd be very
> grateful
>
> Thanks for your response Peter, that sounds very likely.
>>
>> My diaplan sends everything into the queue and then my background lua
>> script empties the queue every 10 seconds and tries to connect the call.
>> Ideally my lua scripts "forgets" about the connected call so that it does
>> not get stuck and can take another call out of the queue 10 seconds later
>> independantly of the previous call being hung up.
>>
>>
>> Am i going about this the wrong way? the only reason I do this is that
>> the mod_fifo as it is does not give me enough flexibility.
>>
>> My script basically calls out from the FS and if connected successfully (
>> new_session), perform a
>>
> What does this mean? You have something like this?
> <action application="lua" data="my_script.lua"/>
>
> [
>
> so my inbound calls come into the dialplan and are sent straight to the
> queue without any lua
> <condition field="destination_number" expression="^(DDI)">
> <action application="answer"/>
> <action application="playback"
> data="tone_stream://%(400,200,400,450);%(400,2200,400,450)"/>
> <action application="sleep" data="1000"/>
> <action application="set" data="queuetag=TestQueue"/>
> <action application="info"/>
> <action application="set" data="fifo_orbit_exten=marc_queue:30/>
> <action application="set" data="fifo_orbit_dialplan=XML"/>
> <action application="set" data="fifo_orbit_context=default"/>
> <action application="set" data="fifo_orbit_announce="/>
> <action application="set" data="fifo_caller_exit_key=1"/>
> <action application="set" data="fifo_caller_exit_to_orbit=true"/>
> <action application="set" data="fifo_override_announce="/>
> <action application="fifo" data="queue1 in undef
> /usr/local/freeswitch/sounds/moh.wav"/>
>
>
> then I have a lua script that gets launched on startup and that is an
> endless loop that queries the queue1 for any calls in queue.
> Once found a call, it queries a database of "available" users to take a
> call and sim rings them all until one of them picks up.
>
>   local new_session = freeswitch.Session(new_call_string);
>  <------------------- calling out to the agents.
>     new_session:execute("set", "call_timeout=9");
>     new_session:execute("set", "hangup_after_bridge=true");
>  if ( new_session:ready() ) then
> call_state = api:executeString("uuid_exists "..queue1_caller_uuid );
>      <------ checks that call was still in the queue.
>  freeswitch.consoleLog("info", "call_state  = ".. call_state .. "\n");
> if call_state == "true" then
>  freeswitch.consoleLog("info", "Call Answered by service agent and call
> there.\n");
> new_session:execute("transfer", "agent_to_queue_marc_queue_service XML
> default");
>  else
> new_session:hangup();
>  new_session:destroy();
> end
> end
>
> once one of those agents does pick up, the LUA script executes the line
> below which transfers the call to another part of the dialplan ( below )
> which basically connected the existing call out to the agents to the oldest
> call in queue1.
>
> new_session:execute("transfer", "agent_to_queue_marc_queue_service XML
> default");
>
>
> <include>
> <extension name="agent_to_queue_marc_queue_service">
> <condition field="destination_number"
> expression="^(agent_to_queue_marc_queue_service)">
> <action application="fifo" data="queue1 out nowait"/>
> </condition>
> </extension>
> </include>
>
> it actually all works very well as far as functionality is concerned, but
> the issue is that if I make 100 connected calls, then under the status, the
> total number of calls keep incrementing until we hit the max number of
> session and then the freeswitch restarts it seems : ( I can increase the
> value, but am trying to avoid the issue)
>
> UP 0 years, 6 days, 6 hours, 13 minutes, 33 seconds, 121 milliseconds, 907
> microseconds
> FreeSWITCH (Version 1.3.17 git 5f733b2 2013-03-11 10:04:05Z) is ready
> 23 session(s) since startup
> 3 session(s) - 0 out of max 30 per sec    <----------------------------
> this figure.
> 1000 session(s) max
> min idle cpu 0.00/100.00
> Current Stack Size/Max 240K/8192K
>
>
>   ]
>
>
> new_session:execute("transfer",
>> "agent_to_queue_paymentsense_queue_service XML default");
>> and connect via the dialplan with :<action application="fifo"
>> data="queue77 out nowait"/>
>>
>> if I use a bridge instead of the transfer, the scripts sleeps until the
>> call is hung up, with transfer, it can go 10 seconds later and take
>> another call out of the queue.
>>
>> so is there a command I need to add to the dialplan like
>> hangup_after_bridge on the outbound call?
>> <action application="set" data="hangup_after_bridge=true"/>
>>
>> any ideas?
>>
> What, exactly does your Lua script do? Do you have an explicit exit clause
> in there anywhere?
>
> [
> so as described above. there is no exit clause as the LUA script is
> launched on startup and then constantly polls the queue. if I don;t do a
> transfer, the LUA script stays on that command until the call is cleared.
> the transfer resolves that issue but creates a stale session.
>
>
> now it could be that I am looking at this the wrong way. my key
> requirement here is that I want to be able to control who the queued call
> is connected to based on a number of parameter from an external DB like
> agents and distribution mechanism
>
> Anybody got any good ideas? I would have thought it was a relatively
> common setup. I could potentially run an individual instance of a LUA
> script of each inbound call in the queue and then it would clear
> automatically when the bridged call is hung up, but that would potentially
> mean that I could be running 100s of identical LUA scripts that last for an
> unpredictable length of time.
>
> I'd be very grateful to hear any suggestions
>
> thansk
> Marc
>
> ]
>
>
> On Mon, Dec 10, 2012 at 9:17 PM, Michael Collins <msc at freeswitch.org>wrote:
>
>>
>>
>> On Mon, Dec 10, 2012 at 12:42 PM, Marc de Corny <marcdecorny at gmail.com>wrote:
>>
>>> Thanks for your response Peter, that sounds very likely.
>>>
>>> My diaplan sends everything into the queue and then my background lua
>>> script empties the queue every 10 seconds and tries to connect the call.
>>> Ideally my lua scripts "forgets" about the connected call so that it does
>>> not get stuck and can take another call out of the queue 10 seconds later
>>> independantly of the previous call being hung up.
>>>
>>>
>>> Am i going about this the wrong way? the only reason I do this is that
>>> the mod_fifo as it is does not give me enough flexibility.
>>>
>>> My script basically calls out from the FS and if connected successfully
>>> ( new_session), perform a
>>>
>> What does this mean? You have something like this?
>> <action application="lua" data="my_script.lua"/>
>>
>>
>>> new_session:execute("transfer",
>>> "agent_to_queue_paymentsense_queue_service XML default");
>>> and connect via the dialplan with :<action application="fifo"
>>> data="queue77 out nowait"/>
>>>
>>> if I use a bridge instead of the transfer, the scripts sleeps until the
>>> call is hung up, with transfer, it can go 10 seconds later and take another
>>> call out of the queue.
>>>
>>> so is there a command I need to add to the dialplan like
>>> hangup_after_bridge on the outbound call?
>>> <action application="set" data="hangup_after_bridge=true"/>
>>>
>>> any ideas?
>>>
>> What, exactly does your Lua script do? Do you have an explicit exit
>> clause in there anywhere?
>> -MC
>>
>>
>>>
>>> thanks
>>> marc
>>>
>>>
>>>
>>> On Mon, Dec 10, 2012 at 4:40 PM, Peter Olsson <
>>> peter.olsson at visionutveckling.se> wrote:
>>>
>>>> Are you exiting the lua script? Usually when this happens it means you
>>>> have not
>>>> released all references to the call session object.
>>>>
>>>> /Peter
>>>>
>>>> 10 dec 2012 kl. 16:28 skrev "Marc de Corny" <marcdecorny at gmail.com
>>>> <mailto:marcdecorny at gmail.com>>:
>>>>
>>>> Hi
>>>>
>>>> I have calls that come into a queue and then get pulled out by a lua
>>>> script in background and transfered to a destination. all works fine except
>>>> that it looks like the sessions a not clearing from FS when all the parties
>>>> clear the calls.
>>>>
>>>> When I do show channels, I get this for example:
>>>> uuid    direction       created created_epoch   name    state
>>>> cid_name        cid_num ip_addr dest    presence_id     presence_data
>>>> callstate       callee_name     callee_num      callee_direction
>>>>  call_uuid       hostname        sent_callee_name        sent_callee_num
>>>> 5e8215e7-b036-4cce-9b96-e57db92f13ee    outbound        03/12/2012
>>>> 09:32        1.35E+09        sofia/external/02031950164      CS_HANGUP
>>>>   Outbound Call   2031950164      135.196.144.32
>>>>  agent_to_queue_paymentsense_queue_service                       ACTIVE
>>>>              SEND    5e8215e7-b036-4cce-9b96-e57db92f13ee    freeswitch2
>>>>   4.4209E+11      2089623100
>>>>
>>>> But when I try to get kill or query it, I get a message that the call
>>>> is not anywhere in the FS.
>>>>
>>>> /usr/local/freeswitch/bin/fs_cli -H 10.5.2.105 -x "uuid_kill
>>>> 5e8215e7-b036-4cce-9b96-e57db92f13ee"
>>>> -ERR No Such Channel!
>>>>
>>>> /usr/local/freeswitch/bin/fs_cli -H 10.5.2.105 -x "uuid_exists
>>>> 5e8215e7-b036-4cce-9b96-e57db92f13ee"
>>>> false
>>>>
>>>> Does anyone have an idea how I can kill that call. If I restart the FS,
>>>> they clear, but the problem is that they are hitting my limit on number of
>>>> simultaneous calls.
>>>>
>>>> Any help much appreciated.
>>>>
>>>> Thansk
>>>> marc
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> !DSPAM:50c5fb8c32767955115405!
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org<mailto: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<mailto:
>>>> FreeSWITCH-users at lists.freeswitch.org>
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users<
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users>
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>> !DSPAM:50c5fb8c32767955115405!
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> 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/20130319/82192dd1/attachment-0001.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list