[Freeswitch-users] valet_park timeout and spot announcement
Jeremy Stricker
jstricker at lightnex.com
Fri Oct 15 10:21:36 PDT 2010
Michael,
Thank you very much for your time and effort on this! I had to make a
few changes to your code to make it work. In the "global" extension
section I had to add a backslash to the end of the first condition tag
otherwise FS complained about nested conditions or missing </extension>
tag (you'll also notice that I changed it to work for our parking setup
of valet at 20 and spaces at 21-29):
<condition field="${ani}" expression="^(1\d\d)$"/> <!-- include
only 'parker' extensions -->
<condition field="destination_number" expression="^(20)$">
<anti-action application="hash"
data="insert/valet_recall/${destination_number}/${uuid}"/>
</condition>
In the valet_park extension sections, on the sched_api action, I had to
change api_res to api_result, I had to add parenthesis to the sched_api
function call, and I had to swap uuid_transfer and ${valet_uuid} to
match the arguments I understood:
<extension name="valet_park_retrieve">
<condition field="destination_number" expression="^(2[1-9])$">
<action application="answer"/>
<action application="lua" data="cancel_valet_recall.lua
valet_lot $1"/>
<action application="valet_park" data="valet_lot $1"/>
</condition>
</extension>
<extension name="valet_park_with_recall_timer">
<condition field="destination_number" expression="^(20)$">
<action application="answer"/>
<action application="set"
data="valet_uuid=${hash(select/valet_recall/${caller_id_number})}"/>
<action application="log" data="INFO Pulled [${valet_uuid}]
from hash valet_recall/${caller_id_number}"/>
<!-- the magic happens on the next line. The +30 means 30
seconds later x-fer the call back to the parker -->
<action application="set" data="api_result=${sched_api(+30
${valet_uuid} uuid_transfer ${valet_uuid} ${ani})}"/>
<action application="valet_park" data="valet_lot auto in 21 29"/>
</condition>
</extension>
Upon making these changes, the recall works great when the original
answerer makes the park.
If the call is transferred somewhere else first or picked up from the
first park on a different extension and then parked again, it doesn't
recall the second parker. The error it gives when it fires the
scheduled task is:
2010-10-15 11:16:21.131565 [DEBUG] mod_commands.c:3092 Command
uuid_transfer(aca7ca8d-c33d-457e-a453-9f1e0899dad3 102):
-ERR No Such Channel!
2010-10-15 11:16:21.131565 [DEBUG] switch_scheduler.c:138 Deleting task
22 sched_api_function (aca7ca8d-c33d-457e-a453-9f1e0899dad3)
I'm guessing that a new uuid is assigned when the call is transferred,
but since we have already set the uuid variable we are looking at, the
function call fails. To be honest though, I'm not very familiar with
this part of FS yet.
I will continue to test and provide feedback, but I think you're on to
something good here. The way it works right now will solve a majority
of the lost calls in the system I'm working with presently.
Thanks again!
Jeremy
On 10/12/2010 06:58 PM, Michael Collins wrote:
> Jeremy,
>
> My apologies for taking so long to reply. I was kicking around ways to
> do this. Comments inline.
>
> On Tue, Oct 5, 2010 at 11:10 AM, Jeremy Stricker <jstricker at lightnex.com
> <mailto:jstricker at lightnex.com>> wrote:
>
> Hello all,
>
> Is there anyway to set a call timeout when a call is valet parked so
> that it will ring back to the extension that parked it if it isn't
> answered by the intended recipient? We have an user who parks calls and
> then blindly announces the parking spot over an intercom. With this
> setup there is a great risk of a caller getting stuck in park. If there
> isn't a timeout method, can anyone recommend any alternate setup that
> would allow at least two parking spots with visual indication of calls
> parked on the handsets (Aastra 6730i and 6757i).
>
>
> I couldn't find a simple way to do this but the following method worked
> for me in a lab environment. Assume that 6100 is the park extension and
> 6101-6199 are the parking stalls. Add these <condition> blocks to the
> end of your "global" extension (it needs to be executed for every call):
>
> <condition field="${ani}" expression="^(10\d\d)$"> <!-- include only
> 'parker' extensions -->
> <condition field="destination_number" expression="^(6100)$">
> <anti-action application="hash"
> data="insert/valet_recall/${destination_number}/${uuid}"/>
> </condition>
>
> Then create the valet_park extensions:
>
> <extension name="valet_park_retrieve">
> <condition field="destination_number" expression="^(61\d[1-9])$">
> <action application="answer"/>
> <action application="lua" data="cancel_valet_recall.lua valet_lot $1"/>
> <action application="valet_park" data="valet_lot $1"/>
> </condition>
> </extension>
>
> <extension name="valet_park_with_recall_timer">
> <condition field="destination_number" expression="^(6100)$">
> <action application="answer"/>
> <action application="set"
> data="valet_uuid=${hash(select/valet_recall/${caller_id_number})}"/>
> <action application="log" data="INFO Pulled [${valet_uuid}] from hash
> valet_recall/${caller_id_number}"/>
> <!-- the magic happens on the next line. The +30 means 30 seconds later
> x-fer the call back to the parker -->
> <action application="set" data="api_res=${sched_api +30 uuid_transfer
> ${valet_uuid} ${valet_uuid} ${ani}}"/>
> <action application="valet_park" data="valet_lot auto in 6101 6199"/>
> </condition>
> </extension>
>
> The trick is to use "sched_api" API to schedule the other leg to be
> transferred back to the parker. We use the hash API to store some
> information, namely the parker's extension number and the uuid of the
> parked leg. Change the +30 to however many seconds you want the call to
> be parked before recalling. Here's the catch: if someone does come along
> and grab that call out of the parking stall then we need to remove the
> scheduled transfer! I thought a Lua script would be the easiest way to
> handle that, so when the person picking up the parked call dials 6001
> e.g. then it launches a quickie Lua script that removes the sched_api
> from the task list. Here's the Lua script:
>
> -- cancel_valet_recall.lua
> --
> -- parse the valet lot in question and find the uuid for the extension
> -- remove the uuid from the sched task list since this call is now being
> unparked
> --
>
> valet_lot = argv[1]
> valet_ext = argv[2]
> uuid = session:getVariable('uuid')
>
> --freeswitch.consoleLog('INFO','Lot: ' .. valet_lot .. ' , Ext: ' ..
> valet_ext .. ' , uuid: ' .. uuid .. "\n")
>
> api = freeswitch.API()
>
> if ( valet_lot == nil and valet_ext == nil ) then
> -- improper args... (feel free to do some better error handling)
> else
> -- sched_del uuid for the uuid in valet_lot, valet_ext
> valet_info = api:executeString('valet_info ' .. valet_lot)
> -- freeswitch.consoleLog("INFO","\n" .. valet_info .. "\n\n")
>
> valet_data = string.match(valet_info,"<extension uuid=.->" ..
> valet_ext .. "</extension>")
> -- freeswitch.consoleLog("INFO","uuid data line is: " .. valet_data
> .. "\n\n")
>
> valet_uuid = string.gsub(valet_data,'<extension uuid="(.-)">' ..
> valet_ext .. "</extension>","%1")
> --freeswitch.consoleLog("INFO","valet uuid is: " .. valet_uuid ..
> "\n\n")
>
> -- perform the sched_del
> api_res = api:executeString('sched_del ' .. valet_uuid)
> --freeswitch.consoleLog("INFO","result of sched_del " .. valet_uuid
> .. " is " .. api_res .. "\n\n")
> end
>
> Throw this into conf/scripts/cancel_valet_recall.lua and give it a shot.
> Let me know how it goes. If it works and if no one has any obvious
> improvements then I will toss it up on the wiki as an example of how to
> do a valet_park recall timer.
>
> If you want to learn more about how this works then uncomment the log
> statements in the Lua script. Also after parking but before picking up
> the call go to the fs_cli and do "show tasks" and you'll see what the
> task looks like. I used the parked leg's uuid as the 'group id' in
> sched_api so that it is easy to find and remove when unparking the call.
>
> Have fun and let me know if this helps or not.
> -MC
>
>
> Secondly, is there anyway to stop read-back of the parking spot on the
> parkee's side of the call? Currently, the parker performs an attended
> transfer, waits for and hears the spot read-back. The parkee hears MOH
> while the transfer is being performed, but then the spot announcement
> themselves as soon as the parker finishes the attended transfer by
> hanging up.
>
>
> The parker is hanging up too soon. If he/she waits until he/she hears
> music and then completes the transfer it should be okay. I just tested this.
> -MC
>
>
>
> _______________________________________________
> 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
--
Jeremy Stricker
LightNex Communications
e: jstricker at lightnex.com
p: 877-342-3768
w: www.lightnex.com
More information about the FreeSWITCH-users
mailing list