[Freeswitch-users] valet_park timeout and spot announcement

Michael Collins msc at freeswitch.org
Tue Oct 12 17:58:31 PDT 2010


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


More information about the FreeSWITCH-users mailing list