[Freeswitch-users] Call parking strategy/best practice in freeswitch?
Tom Christensen
pavera at gmail.com
Tue Mar 16 11:06:49 PDT 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100316/27a4fa9c/attachment-0002.html
More information about the FreeSWITCH-users
mailing list