<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 3:14 PM, Michael Collins <span dir="ltr"><<a href="mailto:msc@freeswitch.org">msc@freeswitch.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Mar 15, 2010 at 11:59 PM, Tom Christensen <span dir="ltr"><<a href="mailto:pavera@gmail.com" target="_blank">pavera@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hello,<div>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!</div>
<div><br></div><div>One issue I've run into, and I'm not sure if its just that my use case is abnormal, hence the email.</div><div><br></div><div>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)</div>
<div><br></div><div>This scenario requires a few things:</div><div>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</div><div>
2) Party X (the intended recipient) needs to be able to access that specific place (extension) from any phone inside the company</div><div>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)</div>
<div>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... </div>
<div><br></div><div>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...)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks for your time, sorry for the long email, hopefully it explains well enough what I'm trying to accomplish.</div><div><br></div><font color="#888888"><div>-Tom</div></font></blockquote><div><br>
</div></div></div></div>Tom,<br><br>First of all, welcome to FreeSWITCH - the future of telephony! :P Secondly, thank you for actually looking at the documentation before asking your question. <br><br>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? :)<br>
<font color="#888888">
<br>-MC<br>
</font><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><div>Michael,</div><div>Thanks for the reply. I worked on it more with the business in question today and we came up with a hybrid solution which I think will cover all the bases.</div><div>1) I implemented a "call park" extension on each phone, these are standard mod_fifo queues with SLA/BLA on each phone (LOVED the power of the freeswitch config here BTW, like 8 lines in the dialplan handles this for all 50 extensions). This way everyone has a call park extension that can be picked up anywhere, the numbering scheme is essentially take your extension prepend a 2, that is your call park extension, so if someone pages you, you just pick up any phone and dial 2+ext and that will pick the call up. Everyone in the office can use this feature to park a call for anyone, because only calls for a specific person will ever be parked in that queue, you can put multiple people there without issue.</div>
<div>2) Implemented as mentioned a "parking lot" set of mod_fifo queues that have SLA/BLA set up on the receptionist phone. She can use these queues to quickly and easily park a bunch of people at once (IE when there are call floods) and then send them off to where they need to go as time permits. If she isn't at her phone, she can still answer calls and park them onto individual users park extensions. Still doesn't have the "safety" of not double parking someone in the parking lot, but we'll trust her to be able to see red lights :)</div>
<div><br></div><div>This whole thing goes live Thursday, so wish me luck :)</div><div>Thanks again!</div><div>Tom</div>