Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
How to manage your Asterisk PBXThese are suggestions on how to setup and manage your Asterisk PBX.
edit: Half of the stuff in here is completely false. Take it all with a grain of salt.
- Caching nameserver: Asterisk 1.2 (and earlier) stop responding when no DNS server is present. Asterisk code does have a problem here, and I'd be reasonably certain part of the problem is the OS underlying dns resolver operates in a blocking mode. In the past, one of the suggested workarounds was to implement a DNS caching-only server on the asterisk box. Another suggested workaround is to use IP addresses only in your configs (which is what I've been doing for three years). But, you'll need to make sure nothing in the configs gets interpreted as a DNS name.
- Use a GUI client that's based upon the manager API (like gastman or astman etc) to obtain an overview of what is currently going on in your PBX. Of course you should also regularly check the log files in /var/log/asterisk and watch/limit their size with logrotate. Be aware: It appears that having more than one concurrent manager API connection to Asterisk increases the risk of crashes (reported by mattf, confirmed by others, however mostly fixed in Asterisk 1.2; still using an AMI proxy is recommended)
- Separate your PC network from your VoIP network, probably using VLAN (see also Quality-of-Service QoS issues). If you have a managed switch then this needs to be configured with specific port, VLAN, and class of service settings. Accepted practice is to provide a voice VLAN and a data VLAN. You could use e.g. Iperf to check the quality of your network (note when using this tool with the --udp option you should use -l and set the packet size based on the codec payload and the control overhead if testing to simulate IAX2 I believe iax2 packet size is 12 bytes + codec payload at gsm = 33 bytes, g723 = 27 bytes).
- Use a network sniffer, for example Wireshark, to analyse your network traffic.
- Ensure a stable Asterisk code base by using some form of staging environment. Latest stable release (tar.gz file) is often not the best choice, but bleeding edge CVS isn't either. Your own preferred patches might also not be in CVS yet. Be aware that a CVS update can remove changes you made to Makefiles to e.g. allow the writing of the uniqueid field for CDR records, or to enable ztdummy. Some admins have reported to use a CVS of their own to ensure the presence of selected patches.
- Remove all unneeded modules from your Asterisk server. For example if you are only doing ZAP and SIP then specify noload= for MGCP, Skinny in modules.conf. That reduces risks of potential exploits sleeping in those modules. See Asterisk Slimming. Also have a look at the Astricon presentation about asterisk security
- restrict RTP ports in rtp.conf and make the hole that needs to be punched into the firewall a lot smaller. The default configuration provided with the Asterisk source opens up far more ports than needed.
- Disallow local users to work on your Asterisk server. The recently published serious kernel exploits all required local user access to start with. In short, allow no user logins, disallow file sharing and other user-services on this server.
- Regularly restart (better: stop and start) your PBX during off-hours. A repetitive reload will not be sufficient, and can actually cause more harm (instability, memory not being released, see bug tracker) than it does good. If you run Asterisk provisioned for automatic reloading this could be as simple as placing a cronjob to execute asterisk -rx 'stop gracefully'. Note however that a restart will cause Asterisk 1.0.x to forget all the phone's current SUBSCRIPTONs (until they are re-requested by the phone). Be aware: In Asterisk 1.2 the (CLI command 'restart' now essentially works like 'reload' and therefore does not cause a clean stop/start.
- Look into your startup script and take provisions to detect and restart and hung asterisk. Check out daemontools for this purpose. You could also regularly telnet into Asterisk (manager.conf) to at least make sure it hasn't completely crashed. ''Running Asterisk can also be done from /etc/inittab, resulting in an automatic restart after a stop. Do make sure your machine at least starts properly, or it will reload at maximum speed. To monitor the livelyness of Asterisk, some tools are available which assist with integration in monitoring systems such as mon, big brother, big sister and netsaint' "Another tool is monit that does the good job. Not only can check if the process is alive, but can also monitor sockets (like the manager port"
- Consider to not use mpg123 for music-on-hold (MOH), or take provisions to kill hung mpg123 threads whenever applicable. mpg123 has the habit to not terminate after stopping Asterisk (fixed in 0.7.0), often preventing a new start. You could entirely refrain from using MOH, or use a pre-recorded mp3 file or 30 min length or so together with Playback() and the like.
- Run Asterisk as a user other than root.
- Run multiple Asterisk instances on your machine (aka Multi asterisk installation). See also bug 3558 on this and read up on Asterisk on a VServer (virutal server).
- Think about creating your Asterisk configuration from database that can be shared like MySQL (or whatever else you are used to). The recently added ODBC support in Asterisk opens up a lot of possibilites. Next to that there is the #include syntax that permits to include other files into any of the .conf files - it can be of good help.
- An unthoughtful change to extension.conf can have a disastrous effect on your entire PBX. Establish a procedure for those changes to be not suddenly left without e.g. emergency services (911 or 999 or 112) without you noticing. Always check the log file after having applied a change to extensions.conf in a production system. One possible approach: use a versioning system, like CVS, for your configuration files. With CVS, if you for any reason change a config file and by accident remove functionality, you're always able to roll back to a working version of the configuration.
- Think about putting a quota on voicemailboxes, or schedule a script that deletes all voicemail older than x days. One way to enable quotas is to trigger an AGI script just before a user is directed to voicemail and then decide if a message can be recorded or of the user has run out of space.
- Set an AbsoluteTimeout value for all cost-producing calls to prevent sky-high bills in case something should ever go wrong with either Asterisk or one of your phones. Take especially the SIP protocol and its limitations to detect a disconnected client into account.
- Spend some thought on redundance, load balancing and maybe even clustering. So far there is no perfect solution worked out for Asterisk, however that should not prevent you from thinking about this issue (a search on the mailing list asterisk-users will reveal a lot of competent postings). Example: There are Failover Switches which can automatically switch to a backup T1/E1, POTS or ethernet connection when one goes down, although you'll lose any calls in progress. Also consider load sharing and SIP redirects to spread load across multiple boxes, and yes, asterisk configs can be pulled from mysql in various ways.
- Upgrading a production system: Keep Asterisk running while doing "make update" or "cvs update" and "make". Note that it is recommended to do a clean CVS checkout instead of a CVS update! After this stop Asterisk for "make install"; Alternatively it is possible to issue a "make install DESTDIR=/somewhere" The install won't break anything even if for some reason the install fails. Keeping different "installed" versions at the server makes it easier to update or to return to the previous version. Another approach is to build some rpm package (replace by the package format your system uses). In the rpm case it is possible to use DESTDIR installation and RPM_BUILD_ROOT feature to build the package without stopping the productive service.
- And of course you'll need a backup: Find out if you need to backup voicemail as well, and make sure to include the source directories, especially when you are used to do regular CVS upgrades (yuk).
- logrotate: How to rotate your logs so they don't get too huge
- Asterisk billing support
- Asterisk configuration from database
- Asterisk monitoring
- Asterisk rollout tips: Tips on how to move from testing to practical rollout.
- Asterisk security: Security in the PBX
- Asterisk at large: Tips for setting up large environments (SIP proxy, load balancing)
- Asterisk High Availability Solutions: Products and techniques to maximize uptime (fail over, load balancing)
- Asterisk on VServer with multiple instances (virtual server)
- Asterisk QoS: How Asterisk supports QoS networking
- Asterisk debugging: How to diagnose and isolate a bug in Asterisk
- Asterisk password files: Where can you find users and passwords in Asterisk configuration files?
- Asterisk slimming: Tips on removing unneeded codecs and modules from configuration
- Asterisk startup scripts
- How To Debug and Troubleshoot VOIP
- Failover Switches
- Prepare your network for VoIP
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+