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@lightnex.com <mailto:jstricker@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@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@lightnex.com p: 877-342-3768 w: www.lightnex.com