Setting up a VoIP server using trixbox is very easy! Bringing a T1 into your trixbox is not so easy. Bringing an old-style E&M wink T1 into your trixbox is darned difficult!

Here’s an overview of the process:

Before you get started, install trixbox, set up a few SIP extensions (use softphones if you don’t have deskphones yet) and make sure the base system works. Set up a free voicepulse trial account, which will give you two SIP trunks you can use to dial in and out of your new IP PBX. Taking some time to make sure the basic system is configured and working will save you headaches later when you are trying to get the T1 connection up and running.

Once trixbox is up and running, install the Rhino PCI card. If you’re using a different brand, some of the drivers and details will vary, but the process will be largely the same.

You’ve probably been researching this for weeks, and have dozens of bookmarks and tons of configuration instructions printed out. One of the most frustrating things about configuring a T1 card in a trixbox is that most of the information you’ll find on the net is very outdated! If you’re using a recent version of trixbox, you don’t have a zaptel.conf, zapata.conf, or any of the zt* tools! In the latest version of Asterisk, the interface for T1 cards is called DAHDI – many of the functions and settings are the same, but the config files have different names and the commands you’ll use in a dialplan have changed.

Here’s a high-level view of the configuration process:

#1 – Download this RPM with drivers – http://ftp.rhinoequipment.com/Drivers/RPMS/DAHDI/rhino-linux-2.6.18-92.1.18.el5-2.1.0.4-0.99.1.i386.rpm , install the RPM, and run setup-rhino. Reboot.

#2 – Run dahdi_genconf . This will create a basic set of configuration files. The dahdi_genconf script reads some parameters from /etc/dahdi/genconf_parameters, but unfortunately it looks like it only understands how to set up a PRI T1 configuration. Since we’re using E&M winkT1 trunks, we’ll have to edit /etc/dahdi/system.conf by hand.

Before you start on this, you’ll need a “cut sheet” from your phone company that tells you the signal framing and line coding, among other things. If you don’t have it, you can get the settings from your legacy pbx (if you have access) or call to get it.

Each physical jack on your T1 is a “span”, and each span has 24 channels. The jack closest to the motherboard is span 1.

At this point, the system.conf file should have settings for each span on your card, but they’ll all be set up for PRI. Comment out all of the lines that say “termtype”, “bchan” and “dchan”. Adjust the span= lines to match the line coding and signal framing your phone company gave you.

You’ll also need to know how many channels are available for voice calls – it may be less than the full 24. Also, if you’re configuring more than one span, channel numbers are continuous all the way up the card – the first channel on Span 2 is channel 25!

If you have 16 channels on the T1 plugged into span 1, under the span= line add “e&m=1-16″.

If you have a second T1 with another 16 channels, you’d add “e&m=25-40″ under “span=2″.

After you’re done, make a backup copy of the system.conf file! If the dahdi_genconf tool is run, your configuration will be overwritten.

Once you’re done with this, DAHDI should know how to make your T1 card talk to the phone company. It’s time to tell Asterisk what to do with it!

#3 Configure DAHDI channels in asterisk

The file /etc/asterisk/chan_dahdi.conf tells asterisk what channels are available and how to use them.

For e&m wink t1 trunks, delete everything that’s in there and add something like this:

; DAHDI telephony
; Configuration file

[trunkgroups]

[channels]

context=from-phone-company
immediate=no

signalling=em_w
wink=200
debounce=100
flash=300
toneduration=100
starttime=750
group=1
channel => 1-16

context=from-legacy-pbx
immediate=no
signalling=em_w
wink=200
debounce=100
flash=300
toneduration=100
startttime=750
group=2
channel => 25-40

Here’s an explanation of the most important parts:

context=XXX – These entries tell Asterisk where to start in the dialplan when it receives a call on each T1. In this case, we are using a dual-span T1 card. One span is connected to the phone company, and the other to a legacy PBX system. We’ll need to do some custom dialplan programming to route calls back and forth between the legacy system, the trixbox, and the public phone network.

channel => X-Y – this should match the channels you set up earlier in /etc/dahdi/system.conf – remember, channel numbers increment up the entire card, so channel 1 of span 2 is channel 25.

group=Z – Dialplan programming is much easier when we can deal with 16 channels as a group rather than programming them individually like analog phone lines. With this parameter, we can easily write a dialplan that acts the same way no matter which channel a call comes in on for a particular t1, and we can send a call out on a certain t1 and let Asterisk do the grunt work of finding a free channel.

Back up the custom config file so you can easily fix things if someone uses one of the automated tools and overwrites your work.

Once all of this is done, it’s a good idea to reboot the system, or at least stop asterisk (amportal stop), restart dahdi (service dahdi restart), and then restart asterisk (amportal start).

#4 Pass calls between the legacy pbx and the phone company

Finally we’re done mucking around in the shell, and we can start using some of trixbox’s nice web-based tools to configure the system.

Log in to admin mode, go to the config file editor, and open up extensions_custom.conf .

We need to set up contexts for the two groups of channels. Here is a very basic configuration that tells Asterisk to do two things:

1. When a call comes in on the phone company’s T1, send it to the legacy pbx.

2. When a call comes in from the legacy pbx, send it to the phone company.

[from-phone-company]

exten => _X.,1,Dial(DAHDI/g2/${EXTEN})

[from-nec-trunk]

exten => _X.,1,Dial(DAHDI/g1/${EXTEN})

The “g” in the dial command is important! Our groups are named group=1 and group=2 but you need that lower-case g for the Dial() command to execute properly. Once you have things working just passing calls through, you can expand these dial plans with more intelligent routing. We’ll talk more about this later.

#5 Set up ZAP Trunks in trixbox so VoIP users can dial out on the T1.

Go to PBX Settings, Add a Trunk, Add Zap Trunk (DAHDI compatibility mode). Making an entry here doesn’t change any system settings – it just tells trixbox about the trunks you manually configured so that they are available in the FreePBX web-based configuration screens. For our system, we’ll set up two ZAP Trunks – call them g1 and g2, set the maximum number of channels for each (16 in our example), and fill in the Zap Identifier (again g1 and g2 respectively, where the 1 and 2 refer to the group=1 and group=2 you set up in chan_dahdi.conf).

#6 Set up Outbound Routes

Now that FreePBX knows about our trunks, we can use them to set up outbound routes and let SIP users make calls to the legacy pbx and the outside world!

Set up a “9_outside” route that lets SIP users make an outside call. The dial plan should look like “9|.” and trunk sequence should be “ZAP/g1″.

Set up a “7_inside” route that lets SIP users make a direct call to users on the legacy PBX. The dail plan should look like “7|.” and trunk sequence will be “ZAP/g2″.

Once this is done (and the system reloaded), SIP users can call extensions on the legacy PBX by dialing 7 and the extension, and they can reach the outside world by dialing 9 and a phone number.

#7 Make it transparent

Users want to dial the same way no matter what desk they’re at. 7_inside works okay, if you can remember which phone you’re at, but it would be better if extensions just went where they’re supposed to no matter what phone you are dialing from. We can do this by adding a few things to extensions_custom.conf in the config file editor.

For example, extension 350 is a phone on the legacy system. In the extensions_custom.conf, we’ll add a rule to the [from-internal-custom] section:

exten => 350,1,Dial(DAHDI/g2/350)

When a SIP user dials extension 350, asterisk will pick up a line on our second t1 (to the legacy pbx) and dial 350 there! Repeat this for all of the extensions on the legacy PBX, and SIP users don’t have to learn anything new to make calls to other people in the company.

Going the other way is a little more difficult – you’ll have to figure out how to set up a “virtual” extension in your legacy system, and then call-forward it to what the legacy system thinks is an outside number. In the NEC Elite IPK, you can do this by creating a CAP key, then call forwarding to an external destination (use the legacy system’s prefix to access an “outside” line). The end result is an internal extension “250″ on the legacy system that is call-forwarded to “9250″, or “pick up an outside line and dial 250″ which will then ring extension 250 on the asterisk system.

#8 Make calls ring everywhere!

With some work, you can program the [from-phone-company] context to route direct calls to certain users on the legacy system, and send everything else to somewhere else in Asterisk. We can set up a ring group in FreePBX – we’ll call it “600″ – and then make that ring both SIP extensions AND extensions on the legacy PBX at the same time!

The trick is to use the “7_inside” route we set up earlier. Set up your ring group, and list the SIP extensions you want to ring. To ring extensions on the legacy system, put 7xxx in the extension list. Just be careful about the timing – if an extension on the legacy system has voicemail handled by that system, the call may end up in a particular mailbox on the legacy system instead of staying on the trixbox and being routed according to plan, or it may end up in the legacy system’s auto-attendant. This is less of a problem if you use the ring group to ring a Call Arrival key (CAR) on the legacy system which will only forward to voicemail after a certain amount of time.

If you have questions or comments, feel free to email me at matt@cfcsorlando.com .