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

Wed Mar 17 08:43:55 PDT 2010

Rupa & Tom , Thank you for the suggestion.

Lloyd

On Tue, Mar 16, 2010 at 10:18 PM, Tom Christensen <pavera at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20100317/6de94f03/attachment-0002.html 