[asterisk-users] How to park calls on a specific extension

[Tom Rymes]

On Nov 29, 2006, at 11:40 PM, Lacy Moore - Aspendora wrote:

[snip]

> I went from a Lucent Merlin Legend system to Asterisk.  For me,  
> it's a tradeoff for features.  To my users, it was a step  
> backward.  I also upgraded an office from a Partner system to  
> Asterisk.  To the users, it is a huge step backward.  They have yet  
> to figure out how to transfer a call.  On their old system, they  
> put the call on hold and pressed the line button at another phone.   
> Today, they hold the phone against their leg so the caller doesn't  
> here them yell for the person to come to the phone, and then the  
> person who the call is for comes to that phone and answers the  
> call.  It will remain that way for them, because learning how to do  
> it the right way takes more work than the person coming to the  
> phone, or so they say.

Sounds like you have stumbled upon one of the truisms of replacing  
office phone systems: people hate it when you take away their key  
system "lines". So you're right, it would be a good idea for Asterisk  
to implement that functionality, and they are working on it, IIRC. It  
also sounds like you need to talk to your customers more before you  
roll out a system, so they know ahead of time what the interface will  
be and what changes they should expect. If you let them know ahead of  
time, and get management on board, you should be OK.

> I won't be doing another Asterisk install for a while.  Customer #2  
> has made sure of that by telling everyone how their new phone  
> system sucks.  Until I can find a suitable solution, I am dead in  
> the water.  And yes, I am trying to learn C so that I can write it  
> myself, or modify something else to make it work.

Given the flexibility inherent in Asterisk, you really shouldn't have  
to code your own. It's a great skill, but not necessary.

> But seriously, the attitude of either write it yourself or deal  
> with it won't cut it for business users.  If Asterisk is only for  
> geeks, then fine, it will work perfectly.

Well, not to be rude, but if you plan to sell, install, and maintain  
Asterisk systems, you shouldn't be just a "business user", you should  
be at least a little bit geeky. I would suggest that Asterisk works  
excellently for business users, but it requires a person who is a bit  
of a geek to set it up properly for those business users so they  
don't notice how geeky it really is.

>  If all phones behaved the same, it would help.  Cisco, using SIP,  
> has no park button.  Cisco, using chan_sccp, has a great parking  
> concept.  Polycom has a park button that doesn't appear to work  
> with Asterisk.  We use Cisco (SIP) and Polycom.  Aastra and SNOM  
> seem to have an easier "parking" interface.  The chan_sccp  
> implementation not only reads back the parking spot, but also  
> displays it on the screen.

Why don't you take the specific phone interface out of it? Most of  
your (and your users') gripes seem to be things that could be  
resolved with a little research, planning, and a better grasp of  
Asterisk configuration.

for example: In your example above where they can't figure out how to  
transfer, why don't you edit features.conf and define the transfer  
key as # or something. Then, when they have a call for "Bill" across  
they way, they can do this:

1.) Answer call, determine call is for Bill.
2.) Press #. Asterisk reads back "Transfer".
3.) Dial parking extension number (700, for example)
4.) System reads back parking space number (703, for example)
5.) Call or shout to Bill "You have a call on 703"

This is not really much harder or more complicated than what they are  
used to with their old key system:
1.) Same as above
2.) Press Hold Button
3.) Look at phone to see which line #
4.) Call or shout to Bill "You have a call on Line X"

This approach also cuts out the "press More button, press Transfer  
Button" issue you mention below.

Getting users to make that change shouldn't really be that difficult,  
especially if you let the customer know what to expect from the  
beginning. Focus on management and stress the advantages they receive  
as a result of Asterisk being a full-fledged PBX, not a key system.  
Then explain that minor changes in the user interface are the small  
price they must pay for those advantages.

>  What I have tried to do is the following scenario.  Assign two  
> line keys as Park 720 and Park 721, and using third party patches,  
> been able to monitor those lines (which are actually parking spots)  
> using hints.  Also, using third party patches, I can transfer to  
> those lines (transfer directly to a parking spot), but again, that  
> is a several step process (it requires a blind transfer which take  
> pressing transfer, then blind on the Polycom, this method, due to  
> no BLF does not work on the Ciscos) that just won't happen in small  
> businesses.  It just takes too many button presses.  Plus, as I  
> mentioned, this is third party patches that aren't in the Asterisk  
> main branch, and makes upgrades near impossible.

Again, this seems overly complicated, and implies that you are not  
aware of the ability to specify a key for transfer in features.conf  
as I mentioned above. Try to think outside of the box here. Don't  
spin your wheels trying to replicate a key system using Asterisk. you  
might approximate it, but as you have found out, it's a lot of work  
for only so-so functionality. Instead, focus on the users' complaints  
about the way your install is set up and then streamline it and  
redesign to take those complaints into account. You can't provide  
them with the same thing, but if you provide them with a reasonably  
easy interface and better features, you'll get buy in.

Just some thoughts, hopefully constructive.

Tom