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

[Michael Collins]

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