[asterisk-users] Building the Perfect Box

[Conrad Wood]

> > 1. Good box, see above

We used IBM, HP/Compaq and Fujitsu Siemens. None of them came close to
supermicro opteron servers. The Serverworks-HT1000 Chipset rocks (apart
from the broadcom nic). Things "just work" and I tell it exactly which
IRQs to use for which slot. 
And boy, do they feel fast when working with. Actual spec isn't that
impressive but the whole board is designed so well it easily outperforms
any HP, Fujitsu,Dell or IBM I've seen so far.


> > 2. Good LAN - this is so critical and so often overlooked in the day and age
> > of guys crimping their own cables and running $150 switches. You can't do
> > that, and if you do, you do so at your own peril. Managed swiches,
> > professional cable installation. This is not a problem for me since I *am* a
> > professional cable installer but I have actually witnessed people making
> > patch cables with a flat blade screwdriver and a hammer!

Did we meet? ;-) I used to do that in the 90s with coax wiring until I
finally saw the light ;)
And then I wondered why my fluke tester said "no".
Seriously though, you're quite right decent cabling is _essential_

> 
> > 3. Tuning of the LAN - VLAN's are good. QoS packets are good. Switches that
> > honor the QoS packets are good. 
> 
I tend to use a different switch altogether and lock the switch ports
(because people do plug weird stuff in which suddenly acts as a dhcp
server or does other annoying things)

> 
> > 4. Handset selection - this is another biggie. I've selected Snom 360's, and
> > yes they have warts, but they are feature rich for the price and Snom is

snom 360s are definitely the best, but our clients seem to prefer the
look and feel of cisco 79xx. 

> > USERS INVOLVED.
> > 5. Tuning of Asterisk box itself - this cannot be under emphasized. This is
> > a very important step and tuning methodologies vary according to distro,
> > skill of the admin, and particular circumstances. I've learned *way* more
> > than I ever wanted to about processor affinity sinc I started using
> > Asterisk. 
> 
I install the box minimalistic to begin with (debian usually). Compiling
a preemptive kernel helps too. Stop unnecessary daemons and off it goes.

> 
> > 6. Termination of PSTN. Basically I would never do an Asterisk install where
> > I was forced to do something stupid like aggregate a dozen Centrex lines or
> > some mickey mouse deal with FXO ATA's or whatever except for a hobby or
> > prototype install. PRI, BRI, IAX or SIP, don't mess around with anything
> > else. 
> 
absolutely. 

> > 7. Relationship with provider. What is their SLA? Is it the incumbent or the
> > clec? An incumbent will be more expensive and more difficult to deal with
> > but they will tend to be more reliable. A clec will be cheaper and they will
> > be way more accomodating but you will most likely not get five 9's from
> > them. A VoIP provider should never be trusted, period. You will not get five
> > nines from them, ever. Plan failover situations accordingly. 
> 
> "SLA?  What's a 'SLA'?"  :-)

Service Level Agreement. Normally it means if your line fails you get
£50 or so. Maybe £100. But *never* enough to compensate for the trouble.
You have to have a backup plan.

> 
> Amusingly, a client's * box went down this morning.  I didn't get the
> washout, but the mitigation wasn't well planned either -- everyone with
> an Asterisk box should know what they're going to do if it falls over,
> in detail.  In a notebook.  Just like when the nuclear missles start
> going.

Yes of course. These notebooks tend to get forgotten in a cupboard until
the day they're needed. And then they're so out of date that they're
more damaging that useful.
Do you update the text on the server itself somewhere? How do you go
about keeping it up-to-date? "Just discipline"? Do you work in a team
with others?

> 
> > 8. Plan plan plan plan. A good install of ANYTHING is 80% planning 20% doing
> > it. What is your plan when your primary PSTN provider fails? What is your
> > plan if your Asterisk box goes pear shaped? My dialplan can survive either
> > PSTN, WAN or LAN failure (albeit with reduced functionality). I also keep a
> > cold spare, an identically configured box that I can literally throw into
> > the rack, turn it on, plug in the PRI's and no problem. 

Planning is vital, but do you play through disaster recovery scenarios
regularly ?

> I was musing on giving station users a list of pseudo-CLASS dialcodes
> they could punch to mark that there was a problem with a previous call,
> so it would go into the logs and could be checked latter.

This is actually quite a cool idea.  
That's almost a MOS test ;) Press 1-5 to rate the call ;-)))
Would be even better if I could do that *during* the call already. Maybe
in features.conf...hm.

Conrad