<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">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></span>