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

Tue Mar 16 17:43:31 PDT 2010

when a user parked to a slot how to handle the park time out. Is there any
way to transfer to the call back to a receptionist.

Thanks
Lloyd

On Tue, Mar 16, 2010 at 5: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100316/90a38507/attachment-0002.html 