Home > Asterisk, DIY, networking, Software > Trunking two trixbox servers to solve zap problems

Trunking two trixbox servers to solve zap problems

Updating trixbox (asterisk and/or zaptel) can be like rolling the dice when it comes to zaptel (Digium) cards. What was flawless operation in one version can be totally broken in a new one, with little or no warning. I got burned one time too many with the 1.2 update. There was suddenly horrendous echo that simply would not go away on my TDM400 FXO ports. I considered scrapping the thing and getting another type of FXO solution, but then decided to solve it with what I had on hand:

1) A new VMWare server (now Server1 – Production)
2) A clunky PC and a TDM400 card (now Server2 – Zap Server)

What I did was install a fresh new version of AsteriskAtHome 2.8 on the clunker with the TDM card in it. The PC is an old 500MHz Pentium III with an intel motherboard. I turned off all the other built-in devices on the motherboard, popped 384 MB of RAM, the TDM-400 card and a 15 GB HD drive in it.

I copied my old configuration (less the zap extensions) to a fresh install of 1.2 with updated versions of zaptel and asterisk on the VMWare server.

The beautiful thing about using VMWare is you can take snapshots of a known good configuration, and easily upgrade, back up, or move the system. It is very easy to add or copy additional development or testing servers as well.

The trick I used to get inbound calls from the PSTN  immediately transferred from Server2 to Server1 is made up of two parts:

1) Change the feature code on Server1 for simulating an inbound call from 7777 to another number. I chose 250.

2) Add two outbound routes on server 2 – one for local/emergency/toll free calls, and one for everything else. The first route goes out over the Zap FXO channels, and the other is routed to Server1 using the method I described earlier. Add a Misc Destination for Inbound calls that dials 250.Add an inbound Route for any DID/CID that goes to the Inbound Calls destination.

If you have any zap FXS channels you need to add Misc Destinations for them on Server1, and add them to the outbound route for Server2.

With this new configuration working smoothly, I still noticed some failed calls over the zap FXO channels. They were getting error messages from the CO that seemed to me that dialing was happening before the CO was ready. I added a 1 second pause manually into the dialplan in Extensions_Additional.config. I know full well it may get blown away if I monkey with FreePBX, but I don’t plan to. That’s the idea! I could have done this more simply with a minimal asterisk install, but I wanted to play around with different methods, and Trixbox/AAH allows for that. It ended up being pretty simple anyway. Now the zap channels are frozen in time on the Zap Server.
Here’s a chunk of that file as an example:

exten => _1888NXXXXXX,n,Macro(dialout-trunk,2,ww${EXTEN},,)
exten => _1888NXXXXXX,n,Macro(dialout-trunk,3,ww${EXTEN},,)
exten => _1888NXXXXXX,n,Macro(outisbusy,)
exten => _NXXXXXX,n,Macro(dialout-trunk,2,ww${EXTEN},,)
exten => _NXXXXXX,n,Macro(dialout-trunk,3,ww${EXTEN},,)
exten => _NXXXXXX,n,Macro(outisbusy,)
Each ‘w’ in a dial string is a half second pause.

Categories: Asterisk, DIY, networking, Software
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: