[Freeswitch-users] Cannot Kill stale channels

Marc de Corny marcdecorny at gmail.com
Wed Mar 20 01:36:57 MSK 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130319/ba7ceb40/attachment-0001.html 


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