[Freeswitch-users] Call parking question/best practice advice

Aloysius Lloyd lloyd.aloysius at gmail.com
Wed Mar 17 12:07:05 PDT 2010

Thanks Antony.


On Wed, Mar 17, 2010 at 2:47 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> side note:
> Some of mod_valet_parking seems undocumented you can do the following
>  <extension name="park-in">
>       <condition field="destination_number" expression="^(8000)$">
>         <action application="valet_park" data="auto in 8001 8999"/>
>       </condition>
>     </extension>
>  <extension name="park-out">
>      <condition field="destination_number" expression="^(8\d{3})$">
>         <action application="answer"/>
>         <action application="valet_park" data="test $1"/>
>      </condition>
> </extension>
> So if you attended transfer to 8000, you will park them at the next
> available slot
> This is missing the blf like fifo has but it will be unique announced
> slots.
> also
> you can add this before any call
>  <action application="bind_meta_app" data="1 a s valet_park::test auto in
> 8001 8999"/>
> so when on the phone you can dial *1 to park the call to the next free slot
> 8001-8999
> On Tue, Mar 16, 2010 at 9:17 PM, Tom Christensen <pavera at gmail.com> wrote:
>> On Tue, Mar 16, 2010 at 3:14 PM, Michael Collins <msc at freeswitch.org>wrote:
>>> On Mon, Mar 15, 2010 at 11:59 PM, Tom Christensen <pavera at gmail.com>wrote:
>>>> Hello,
>>>> Pretty new, but so far very happy with freeswitch!  The setup and config
>>>> is really nice, straightforward, and I appreciate the design of the system.
>>>>  I've worked with Asterisk pretty regularly for the last 4-5 years, and am
>>>> really looking for something more stable, and I think I've found it here!
>>>> One issue I've run into, and I'm not sure if its just that my use case
>>>> is abnormal, hence the email.
>>>> I've worked with PBX systems for a number of years (11 now...), and in
>>>> all of the systems I've worked with, call parking was kind of a "roaming"
>>>> feature.  By this I mean, you think party X (the intended recipient of the
>>>> call) is in the building, but they are not at their desk.  So, you park the
>>>> call, and then page, or by some other means attempt to locate party X and
>>>> tell them "get to the nearest phone and pick up 5901".  If you can't locate
>>>> party X or you can't find them in time, the call should time out back to the
>>>> parking party (receptionist) to be handled appropriately (message taken,
>>>> sent to voicemail, transferred to party X's boss)
>>>> This scenario requires a few things:
>>>> 1) the receptionist/person who actually receives the call needs to be
>>>> able to put the call in a specific place (extension) that doesn't change
>>>> 2) Party X (the intended recipient) needs to be able to access that
>>>> specific place (extension) from any phone inside the company
>>>> 3) Order must be preserved (IE, the mod_fifo call park in freeswitch is
>>>> inadequate, because if the receptionist parks 2 people on 5900, one for
>>>> party X and one for party Y, in that order, but party Y gets to a phone
>>>> first, they will be connected to party X's caller)
>>>> 4) The receptionist has to be protected from or provided with sufficient
>>>> information to avoid connecting 2 customers with each other (IE the
>>>> valet_park in freeswitch is inadequate, because if she parks a caller for X
>>>> on 6001, then parks a caller for Y on 6002, then a caller for Z calls in,
>>>> how can she know if 6001 is free yet? valet_park doesn't support BLA/SLA so
>>>> what can she do?  What if she just forgets and sends that caller to 6001?
>>>>  Then the 2 customers are bridged together and thats a big no-no)  Also, I
>>>> haven't seen a way to make valet_park timeout?  But maybe I'm wrong
>>>> there...
>>>> The closest I can get to implementing the above scenario is by using
>>>> multiple mod_fifo queues (one for each parking spot), and SLA/BLA on the
>>>> receptionist phone to "notify" her that someone is already parked in a
>>>> certain queue.  Unfortunately, there is no enforcement of this policy by the
>>>> system, and if she fat fingers her transfer, she will double up a queue,
>>>> creating the problem indicated in 3 above.  The other shortcoming of this
>>>> setup is that without a large phone (IE, with 10-15 SLA/BLA slots) it
>>>> becomes impossible to appropriately handle call park.  If the receptionist
>>>> is away from her desk and attempts to answer a call, she can't tell which
>>>> parking spots are free at all on a regular 2 line phone.  Also, regular
>>>> users are prohibited from using call park as they cannot know which slots
>>>> are free (the need for this arises often in certain industries, such as law,
>>>> client is speaking with attorney, attorney finishes and says "let me connect
>>>> you with my assistant to schedule an appointment and handle x, y, and z for
>>>> you.", paralegal is not at desk, atty needs to park call and page his
>>>> assistant, maybe they are in the copy room, or the library doing
>>>> research...)
>>>> The asterisk parking lot seems to solve this problem quite elegantly
>>>> (although the stability issues of asterisk undermine it).  It is simple to
>>>> use (receptionist and everyone else only needs to remember 1 extension to
>>>> park any call), The callers/parking spots are maintained by the system to
>>>> prevent double parking, and each caller sits at a specific extension until
>>>> they are picked up or time out.
>>>> So, the question boils down to how do people using freeswitch view/use
>>>> call park?  Is there a "better" roaming feature that I just don't know
>>>> about?  If it is just something that hasn't been implemented/thought about
>>>> this way yet, any idea what it would take to get a call parking feature that
>>>> satisfies these requirements into freeswitch?
>>>> Thanks for your time, sorry for the long email, hopefully it explains
>>>> well enough what I'm trying to accomplish.
>>>> -Tom
>>> Tom,
>>> First of all, welcome to FreeSWITCH - the future of telephony! :P
>>> Secondly, thank you for actually looking at the documentation before asking
>>> your question.
>>> You've got yourself quite the little conundrum. Many of us use park in a
>>> more limited role, or we rely on the receptionist not to do silly things
>>> like sending one external caller to the slot of another external caller. We
>>> all agree that's a bad idea, unless it is done deliberately to connect two
>>> external parties. It sounds to me like this particular situation needs an
>>> operator panel app where the receptionist can have a pretty web page showing
>>> what calls are parked where. To my knowledge, this does not yet exist in
>>> FreeSWITCH. The good news is that FS provides all the requisite building
>>> blocks to create such an application using the event socket. How do you feel
>>> about doing a little development? :)
>>> -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
>> Michael,
>> Thanks for the reply. I worked on it more with the business in question
>> today and we came up with a hybrid solution which I think will cover all the
>> bases.
>> 1) I implemented a "call park" extension on each phone, these are standard
>> mod_fifo queues with SLA/BLA on each phone (LOVED the power of the
>> freeswitch config here BTW, like 8 lines in the dialplan handles this for
>> all 50 extensions).  This way everyone has a call park extension that can be
>> picked up anywhere, the numbering scheme is essentially take your extension
>> prepend a 2, that is your call park extension, so if someone pages you, you
>> just pick up any phone and dial 2+ext and that will pick the call up.
>>  Everyone in the office can use this feature to park a call for anyone,
>> because only calls for a specific person will ever be parked in that queue,
>> you can put multiple people there without issue.
>> 2) Implemented as mentioned a "parking lot" set of mod_fifo queues that
>> have SLA/BLA set up on the receptionist phone.  She can use these queues to
>> quickly and easily park a bunch of people at once (IE when there are call
>> floods) and then send them off to where they need to go as time permits.  If
>> she isn't at her phone, she can still answer calls and park them onto
>> individual users park extensions.  Still doesn't have the "safety" of not
>> double parking someone in the parking lot, but we'll trust her to be able to
>> see red lights :)
>> This whole thing goes live Thursday, so wish me luck :)
>> Thanks again!
>> Tom
>> _______________________________________________
>> 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 <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
> _______________________________________________
> 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/20100317/7dc1d9b2/attachment-0002.html 

More information about the FreeSWITCH-users mailing list