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

Wed Mar 17 11:47:35 PDT 2010

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