[Asterisk-Users] Multi-line help

[Steven Critchfield]

On Sun, 2004-01-04 at 20:42, Rich Adamson wrote:
> > On Sun, 2004-01-04 at 18:18, Sean Garland wrote:
> > > I am looking for common practice ideas on how to handle multiple line
> > > phones.  Is it common with asterisk to have the lines appear as
> > > programmable buttons? Or to just have itcm like buttons and use the dial
> > > 9 approach?  What I am specifically interested in, is to have my line
> > > one appear on the first button (sip polycom phones) line two appear on
> > > the second button, and use the third as an intercom (internal extension)
> > > button.  I have managed to get the line 1 to ring on the line 1 button
> > > and the same for line two.  I have even managed to get extension
> > > transfers to happen on the itcm button.
> > > 
> > > The trouble I have is that I don't know if someone else is on the
> > > particular line, and when I dial, it picks up the first available button
> > > (line) so even if I dial an extension, it looks like I am dialing from
> > > line 1 to the extension.  How do I make it pick the third button, etc...
> > > 
> > > Confusing?  I have read the "handbook" and countless searches through
> > > wiki and Google, but cannot find practical examples of multi-line use
> > > with asterisk.
> > 
> > The reason you didn't find anything is because the multiline approach
> > doesn't scale beyond a small handful of lines. It shouldn't matter what
> > line a call is on if you are supposed to answer it. If you have hunt or
> > rollover on your lines, it doesn't matter what line you dial out on. In
> > the long, the only thing that your phone should know is how to get you
> > to the PBX, the pbx will take care of the rest.
> 
> Steve, I'll have to beg to differ with you. In some cases, which line or
> extn is used does make a difference (from a business perspective).
> Example, if x3002 is to be answered "Customer Service" and x3008 is to
> be answered as "President" (or whatever), you really do want to know
> which extn is ringing. Likewise, if you make a call from the Presidents
> line to certain employees, there is some value/meaning when an employee
> sees the call is coming from the President and not just 'another' customer
> service call.

Like I said, a button for each line doesn't scale well. We have a PRI, I
don't want to have a phone with 23 buttons to pick a line when a simple
prefix chooses one for me. Scale that to a larger corporation and you
may have many PRIs in one building. Do you want to bother choosing which
of a hundred or more lines to choose from you will dial out on? It
doesn't scale. 

If you need to know whether it is coming in for Pres. or Support, use
CallerID. We have a similar need. We have a timeout on our main line
that will ring all phones, and our tech support line rings all phones.
It is acceptable for our programmers to ignore the main line if there
are others in the office, but it isn't acceptable to ignore the support
line ever. So we change the CallerID display for these calls. We all can
choose once we see the CallerID as to what to answer. This solution
scales because it is possible to send any arbitrary string to the
CallerID unit without touching the phone number.

Maybe I'm a bit cheap, but I don't like choosing solutions that will
junked as soon as growth is experienced. My last office was such a
place. They had a switch that was configured to show line appearances
for 8 lines. That was a hardware limitation of the phones since they
only supported 8 buttons. It was generally known that line 8 was tech
support, but what if it was already in use? Some people gave out the
numbers for specific lines so they knew after hours what was a personal
call or a business call. Can you see how that does not scale at all. As
soon as they needed 1 more phone line, they had to go buy a new switch
as the old one was at the limit.   

> Other examples: share tennant services (how would you answer a phone that
> has six extensions, each belonging to a different business and you are
> the shared operator?  Happens all the time, at least in the US. Departmental
> accounting is another (which department pays for which calls originated
> from the exact same phone; sales vs collections vs cust services). Or, 
> the shared services (again) and the operator is asked to call a dozen
> foreign locations (who pays for that is determined by which button the
> very non-technical hardly-trainable operator pushes).

I haven't experienced the shared tenant situation for more than 2 weeks
once. It was important for us to not have been on someone elses phone
switch. It also made the pain of moving our service to a new location a
non issue. I know if you are looking at providing the service, the
headache of moving isn't of interest, but the ease of move in is
important. 

It would seem to me that utilizing the CallerID is much easier to train
than specific call appearances on a phone. The benefit is again that the
CallerID is almost infinitely flexible where as a line appearance
mechanism can only scale to the number of buttons you can manage and
implement.

As far as who pays part of the question, that could be as simple as a
special dial out code. unlike the problems of a dial in menu, your
extensions can be stuffed behind a specific number, and you can have a
default code for each phone that i used when you dial 9. Any other
company department codes can be selected from a menu, or other than 9
dial out prefixes. Look into the AMA(?) codes. 

> So, his question is very valid.

Only if you reduce yourself to old ways of doing things. Would you like
to put your operator back behind a switch board with wires and large
phono plugs to connect the calls?

> With Cisco phones, no problem. We define each button to be whatever extn
> we want and any callerid we want, and by pushing that button on the phone, 
> we can initiate a call from "that" extn as well. Operates more like the 
> older US key systems.

But for how long? I face similar problems in our industry dealing with
doctors. Older ones have learned their technology and don't want to
change unless they make obscene money for it. Newer Doctors have been
brought up with the newer technology and don't want to be chained to the
older technology just because thats what the older ones want. 

Why hinder your deployment when it won't be long till you hire younger
operators who can deal with a change.

> I could probably list several dozen valid business reasons for doing
> what he's asking, but probably very few (if any) valid technical reasons.
> More of an issue in small business then in large ones, but I also know
> the same kind of thing goes on in government offices as well.

Of course I can point you to the IBM commercials of late that also point
out that you should still act like a big business even if you aren't
_YET_. 

BTW, Businesses have needs not reasons. Technology is about answering
needs most of the time. So as you can tell from my above answer, your
business needs have different technical answers available. One of the
answers is dead easy to implement and fits easily with what is here, the
other is not as easy to implement and has other limitations that can
bite you in the butt when you expand.
-- 
Steven Critchfield <critch at basesys.com>