Asterisk rollout

Asterisk is an Open Source Software. It means that it's not a shrink-wrap application that you can buy and put into production directly. On the other hand, how many large systems can you buy and install directly without testing?

Here's some advice on how to roll out Asterisk in production:

Install test from CVS: Install a test system from the CVS source code tree, see Asterisk Download. Observe that the CVS tree is the development line for Asterisk. There's no guarantee that this code will work all the time, it's where developers submit their changes for testing by all of us in the user base. Don't use this code in production unless you know what you're doing. Please test it and report problems that you see in your environment. When you're settting up your production system, either freeze on a working CVS version or do it on a released, tested, version. Don't CVS update a production system if you're not sure of what you're doing. You will add new functionality, but it may also mean that you're adding bugs to a system your users are using to communicate. (if you use the stable branch of the CVS, you're safer)
Test a full system: Test a full system, including connections to various channels, meaning PSTN connectivity and connectivity to various IP-telephony devices - H.323, SIP, IAX.
Test PBX functionality: Test and document functionality. Do you want to transfer calls? There are several ways to do this in Asterisk, some ways supported by some protocols and some not by other protocols or the PSTN. Asterisk tries to solve the situation in ways that fits all channels, but it might mean that with a particular phone, the button labeled "transfer" may not be the way to transfer a call from the PSTN to a SIP device, or from a SIP device to another manufacturer's SIP device. If you're mixing various devices and protocols, make sure you document the way functions as call transfer, call parking and on hold works in your configuration.
Test echo cancellation: Again, with Asterisk you can combine various solutions like ISDN pri:s, channelbanks, SIP and IAX into new magical combinations that may give side effects you weren't prepared for. Echoes are a good example of what can happen, and it is quite disturbing. Without testing, you're in for an echo hunt. With testing, there's a good chance you won't be surprised by user's complaints as you go along.
Don't think old PBX: If you're just looking for an standard PBX, go buy one. Asterisk is a platform for a new way of handling telephony, it's part of a revolution. Part of the benefit of Asterisk is new solutions you can provide to the user base, things you couldn't with the old setup. Answering calls over broadband VPN's while home with kids? No problem. Setting up an extension to check delivery status of an order? A piece of cake. Blocking an unwanted ex-girlfriend or even forwarding her to the talking clock? Small hack. Connecting the PBX:s on all your offices, across the Internet? Simple. Sooner or later you'll find the new solution that your user's can't live without and can't understand that they could live without. And that solution will be provided without a man-years worth of programming or expensive add-ons to a vendor proprietary hardware.
Share your experiences: Asterisk is an open source project. We're building something new, together. Part of it is to share experiences, good and bad. Tell others how you solved a problem, ask for solutions. Be part of the Asterisk community. You will get it back in more happy customers and a lot of helpful collegues out there.

Checklist

Provided by Rich Adamson

A couple of items to consider (in addition to the technical * implementation issues) are:

End-to-end connectivity: (within each location) as most corp hubs/switches are not on ups, shared devices located under someone's desk where the power cord can be kicked, an employee's space heater trips a breaker.
Legal issues: what happens when an employee needs to call emergency personnel and the phone system doesn't work for whatever reason
QoS: how will you deal with QoS issues when they pop up? (someone decides to backup their fixed disk across the local net; the latest virus/trojan is consuming all available bandwidth; user drag/drops very large directory or files.) Take a look at this guide that will help you prioritize VOIP QoS
Network connectivity: your ISP decides to block a range of ports and didn't tell you; what's the backup plan and how quickly can it be operational
Redundancy: are there requirements for a primary & backup * system, and should this be configured with some automated failover process or left to support personnel to handle manually
Version handling: should you have a formal change control process and how does it apply to downloading cvs updates that can break production * boxes? Should you consider separate Development, Test and Production asterisk machines for hardware and/or software promotion?
Staff backup: are there any business requirements for backup support personnel should you get hit by a bus on the way home from work
24 by 7 support: its not uncommon for infrastructure personnel (eg, switches, routers) to reboot, swap out, upgrade, etc, stuff for various reasons. Is there a need to treat those support requirements different when mgmt is accustomed to phone systems being operational 99.999% of the time?
Rollout: should your plan to implement * include a phase-in approach where only a small part of the business is impacted before moving to the next phase?

voip-info.org

Asterisk rollout tips

Asterisk rollout

Checklist

See also

Comments

VPN for VoIP Blocking

Here is my asterisk roll out guide. (a work in progress)

Side by Side