Sign in to follow this  
Followers 0
systems_glitch

Building an Asterisk Box

4 posts in this topic

Finally got time to build a "permanent" Asterisk box -- the previous "experimental" box had been running for around 2 years on an old POS Dell Dimension 2400. I threw an install of Arch Linux on it and promptly forgot about it, so in addition to being POS hardware, it was also unmaintainable and basically impossible to install new software on without an OS reinstall.

 

Here's the specs on the new box:

 

- Rackable Systems 1U half-depth rack mount enclosure

- Intel entry-level Socket 478 P4 server motherboard

- 2.8 GHz Pentium 4 processor

- 1 GB DDR-333 RAM

- 40 GB Western Digital Caviar IDE drive

- Digium Wildcard TDM800P 8-port analog card with 8x FXS ports, no hardware echo canceller

 

Total hardware cost was around $100. The TDM800P came from eBay for $75. Here's the box with everything installed:

 

post-2713-0-62092600-1395947381_thumb.jp

 

I had to build a "Molex extension cord" to get power to the TDM800P. Rackable Systems must order custom power supply pigtail lengths or something, even after cutting the bundling, none of the pigtails would reach the PCI card area. I usually save the pigtails off of dead PC power supplies and fans with Molex plugs for this purpose:

 

post-2713-0-84229000-1395947472_thumb.jp

 

No heatshink, so it got electrical taped. Plugging the two ends together will help keep the pins aligned when you tape the wires down, and make it easier to plug in when you're finished.

 

Slackware is my distro of choice for boxes like this -- boxes where you'll basically set them up and only apply security patches during their life. I went with Slackware 14.1, Asterisk 11.8.1, and DAHDI 2.9.1-rc1. Additionally, I installed fail2ban to limit SIP bruteforce attempts and Munin for monitoring the system, fail2ban, and Asterisk. I went ahead and recompiled a custom kernel. The most useful change you can probably make in the kernel config is switching the preemption model to "no forced preemption," which is geared toward server environments and will reduce the chances of some other process affecting call quality.

 

I ended up chasing a problem with the TDM800P and the DAHDI drivers: loading the wctdm24xxp module would throw an error for "invalid opcode," indicating that the driver module was trying to use some opcode my lowly P4 didn't support. I set conservative CFLAGS for GCC and recompiled, which got rid of the invalid opcode but produced a different error with failure to communicate with the TDM800P. `lspci` showed the card, but a hardware revision of "ff". It turned out to be a dirty PCI riser card connector. After cleaning it, I was able to load the module and use the card. The CFLAGS tweaking isn't necessary with non-faulty hardware, though it's interesting that GCC produces an invalid opcode!

 

Here's a picture with the box finished and racked in the server room:

 

post-2713-0-73045000-1395948032_thumb.jp

 

Time to plug in more telephones!

1

Share this post


Link to post
Share on other sites

Dang. You've got some skills!

0

Share this post


Link to post
Share on other sites

Honestly I think it's just best to run asterisk on a vps, far cheaper that way.

0

Share this post


Link to post
Share on other sites
Honestly I think it's just best to run asterisk on a vps, far cheaper that way.

 

Yeah, but then what you can do with it is sort of limited. The Asterisk box I have mostly exists to be an adjunct to the Definity PBX in my closet.

 

Very handy work, though :) . It looks really well done.

Edited by ThoughtPhreaker
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0