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

Tue Mar 16 19:18:46 PDT 2010

http://wiki.freeswitch.org/wiki/Mod_fifo#Dialplan_Example
At least with mod_fifo (the call parking solution I'm using) there is a
pretty clear example in the wiki.

On Tue, Mar 16, 2010 at 6:43 PM, Aloysius Lloyd <lloyd.aloysius at gmail.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/7d767137/attachment-0002.html 