Networking

SolutionBase: Configure Asterisk to support a T1 PRI connection

Setting up an Asterisk PBX server won't do you much good if you don't connect it to the outside world. In this article, Brian Smith shows how to configure Zaptel drivers and connect an Asterisk PBS to a T1 line.

Asterisk provides an open source solution for those who want to deploy VoIP in an organization, but don't want to invest a lot of money in a proprietary solution. After you get the software installed on a server, you have some more work to do. You have to connect your server to an outside voice line.

In this article, I'm going to show you how to set up the Asterisk Soft PBX system interface with a T1 PRI connection. Afterwards, you should be able to install a Zaptel-compatible PRI card, configure it for your needs, and modify your Asterisk dial plan to begin making outgoing phone calls from your internal SIP phones, as well as receive phone calls over your PRI line to your SIP clients.

Author's note

There are many different options for configuring your outgoing trunk, and it's impossible to cover all of the options in the scope of this article. What will be covered is the most common configuration in the United States, which is for a T1 PRI. I recommend that you become friendly with your sales/support representative and tech support, as you should ask questions about what the channel stepping method is, encodings, and D-Channel.

Zaptel device preparation

Before you can worry about making a connection, you should have Asterisk installed on your server, as well as have inserted and installed your PRI card into your server. To start the install process, you'll need libpri and the Zaptel package of drivers; you can download the sources to these packages from the Asterisk Web site. Since we are using the Gentoo distribution for our examples, you&'ll need to log in as root to install these (or su over the command shell). From here, you need to run emerge -pv libpri zaptel, as shown in Figure A.

Figure A

Run the emerge command to install Zaptel packages.

If you've installed Asterisk with all the USE flags, then you can probably skip this step, as these packages are already installed.

When installing these packages using emerge, you can view the available options with the -pv argument if you're using a BRI connection or require any additional settings for the Zaptel package. You can also add the appropriate USE flag in the /etc/portage/package.use file. For example, if you were using a BRI line, your package.use file may have these following entries.

net-libs/libpri bri

net-misc/zaptel bri

Zaptel device configuration

Now that you've installed the drivers needed by your PRI card, you'll need to load the appropriate module's using modprobe <module>. In this case, the command is modprobe wct1xxp.

Whatever your kernel module is, you'll probably want to have it automatically loaded when your server boots. To do this in Gentoo, just append the module name to /etc/modules.autoload.d/kernel-2.6 (if you're using the Linux kernel 2.4 series, this file is kernel-2.4).

Next, you'll need to configure the /etc/zaptel.conf with the options for Zaptel to understand how your PRI will behave. This is where you need to contact your support representative from your provider and find out a few configuration options, such as the required framing and coding (typically ESF framing and B8ZS coding). You'll also need to know what channels are your B (data) channels and which channel is your D (control) channel. Unless you're using a partial/split T1, your card will most likely be configured with 1-23 for your B channels and 24 for your control channel. For our T100P PRI card, this configuration in /etc/zaptel.conf looks like:

[/etc/zaptel.conf]

span=1,0,0,esf,b8zs

bchan=1-23

dchan=24

This defines one trunk group exists using ESF signaling and B8ZS coding. The trunk spans across B (data) channels 1-23, using channel 24 as the control (D) channel.

After setting the configuration and loading the Zaptel kernel modules, you can start the Zaptel service. The first time you start the service, you should begin with a verbose debug run to make sure everything is working. To do this, use the ztcfg -vv command. The results should list each of the channels and the status of the channel, as shown in Figure B.

Figure B

Do a test run before the final configuration.

After you have tested the configuration, you can start the Asterisk service via the Gentoo init script /etc/init.d/zaptel start. The next step is to configure Asterisk to accept the Zaptel span.

Configuring the Asterisk Zap channel

The Zap module is what Asterisk uses to interface with the Zaptel device driver. In this file, you'll need to add your definitions for the context of the PRI connection, signaling, and available channels. There are many configuration parameters available for configuring the Zap device, including automatic fax detection, caller ID details, echo cancellation, and default ring cadences. These details, however, are going to be either outside the scope of this article or may be covered in later articles in this series.

Signalling

The important parameters for the Zap device are going to be under the [channels] context. Using a text editor, modify /etc/asterisk/zapata.conf, find the option signalling, and make it signalling=fxo_ls. For the options that will work with your specific configuration, you need to speak with your provider; but here's the list of available options, as provided by http://www.voip-info.org/:

  • em: E & M Immediate Start
  • em_w: E & M Wink Start
  • em_e1: E & M CAS signalling for E1 lines
  • featd: Feature Group D (The fake, Adtran style, DTMF)
  • featdmf_ta: Feature Group D (The real thing, MF [domestic, US]) through a Tandem Access point
  • fgccama: Feature Group C-CAMA (DP DNIS, MF ANI)
  • fgccamamf: Feature Group C-CAMA MF (MF DNIS, MF ANI)
  • featdmf: Feature Group D (The real thing, MF [domestic, US])
  • featb: Feature Group B (MF [domestic, US])
  • fxs_ls: FXS (Loop Start)
  • fxs_gs: FXS (Ground Start)
  • fxs_ks: FXS (Kewl Start)
  • fxo_ls: FXO (Loop Start)
  • fxo_gs: FXO (Ground Start)
  • fxo_ks: FXO (Kewl Start)
  • pri_cpe: PRI signalling, CPE side
  • pri_net: PRI signalling, Network side (for instance, side that provides the dialtone)
  • sf: SF (Inband Tone) Signalling
  • sf_w: SF Wink
  • sf_featd: SF Feature Group D (The fake, Adtran style, DTMF)
  • sf_featdmf: SF Feature Group D (The real thing, MF [domestic, US])
  • sf_featb: SF Feature Group B (MF [domestic, US])
  • e911: E911 (MF) style signalling. Originating switch goes off-hook, far-end winks, originating sends KP-911-ST, far-end gives answer supervision, Originating-end sends KP-0-ANI-ST

The following are used for Radio interfaces:

  • fxs_rx: Receive audio/COR on an FXS kewlstart interface (FXO at the channel bank)
  • fxs_tx: Transmit audio/PTT on an FXS loopstart interface (FXO at the channel bank)
  • fxo_rx: Receive audio/COR on an FXO loopstart interface (FXS at the channel bank)
  • fxo_tx: Transmit audio/PTT on an FXO groundstart interface (FXS at the channel bank)
  • em_rx: Receive audio/COR on an E&M interface (1-way)
  • em_tx: Transmit audio/PTT on an E&M interface (1-way)
  • em_txrx: Receive audio/COR AND Transmit audio/PTT on an E&M interface (2-way)
  • em_rxtx: Same as em_txrx (for our dyslexic friends)
  • sf_rx: Receive audio/COR on an SF interface (1-way)
  • sf_tx: Transmit audio/PTT on an SF interface (1-way)
  • sf_txrx: Receive audio/COR AND Transmit audio/PTT on an SF interface (2-way)
  • sf_rxtx: Same as sf_txrx (for our dyslexic friends)

Switchtype

The next option you want to look at is your PRI switch type. This is controlled through the switchtype option. The default is national; however, here is a list of available options:

  • national: National ISDN type2 (common in the US)
  • ni1: National ISDN type 1
  • dms100: Nortel DMS100
  • 4ess: AT&T 4ESS
  • 5ess: Lucent 5ESS
  • euroisdn: EuroISDN
  • qsig: Minimalistic protocol to build a "network" with two or more PBX of different vendors

Channels and context

After the signalling and switchtype are defined, the next step is to define the channels that the Zap channel works on. These translate to the D channels of the PRI device, which is defined through the option channel => 1-23.

You'll need to define the context that these channels with operate in context = remote. Optionally, if your configuration will be splitting your T1 channels for dedicated DID's to groups/spans of channels, it's important to note that your context is defined after the channel group. So if you need channels 1-12 to be in context A and channels 13-23 to be in context B, you can do it.

The dial plan

Now that your Zap channel in Asterisk is configured to work with the Zaptel device, it's time to modify the dial plan to allow for incoming and outgoing calls on your PRI trunk. You'll want to have the outside world call you on your DID numbers that will connect to your PRI card, then to Asterisk, then on to your SIP client phone inside your office.

You should remember from the previous section that we set Zap channels 1 through 23 in the context remote. This is to signify that all communications on these channels connect directly to the PSTN (Public Switched Telephone Network), and thus are remote connections.

The first thing to do is to open /etc/asterisk/extensions.conf with your favorite text editor. At the bottom of the file, add the extensions that will describe the remote context and our PRI connections. Figure C shows our remote context in action.

Figure C

Add the extensions you need to the /etc/asterisk/extensions.conf file.

In this example, you can see that the extension is the DID (Direct Inward Dialing) number (your telephone number). It's picked up on the first step using the Goto function. In Asterisk, it forwards the call to the office context at extension 212 priority 1. This translates to 555-1234 being the direct number to extension 212 in the office. Alternatively you can treat the call like any other extension, including being able to run an AGI script, or forward the call to a call queue which will be covered in depth in later articles.

Outgoing connections

To allow users in the office to make an outgoing call, you must first add them to the outgoing context. To do this, edit extensions.conf, and under the [office] context, add include => outgoing.

Now that telephone calls from the outside world can be delivered into the Asterisk controlled PBX network, there needs to be a method to allow the extensions in the office context to call out, perhaps to order a pizza. To do this, define a new context labeled "outgoing". This will ensure that outbound phone calls are separate in access from the rest of your dial plan. Figure D shows what the edits look like.

Figure D

Additional changes to the /etc/asterisk/extensions.conf file allow outgoing phone calls.

This is different than what you've done so far. First, you're going to notice the underscore (_) before the context. The underscore tells Asterisk to match the extension against the pattern that is going to follow the underscore. The format for the pattern is simple, and contains attributes close to a lightweight implementation of regular expressions:

  • X references any digit from 0-9
  • Z references any digit from 1-9
  • N references any digit from 2-9

There are other matching methods also, but are closer to regular expressions pattern matching functionality. In the example, you can see that there is a dial plan for seven- and 10-digit telephone numbers, and the pattern should match any telephone number in the United States. The dial command uses the context variable ${EXTEN} which is the dialed extension that matches the pattern. The dial function dials the first group on the Zap channel we configured earlier and attempts to connect to the extension across that channel. At this point, the extension being dialed is an outside telephone number and an actual call is going to be made.

As with any extension in Asterisk, you have complete control over the dial plan. So in this dial plan, if someone decides they want to dial a (900) adult phone line, the call will be immediately disconnected. Using the above matching methods, you can control who has access make long-distance phone calls, or create a process that requires a PIN number in order to make a long-distance call.

That's it

Now everything is put together. You've configured your Zaptel drivers, the Asterisk Zap channel, and modified the dial plan to allow incoming and outgoing telephone calls. Now you'll want to reload Asterisk by running /etc/init.d/asterisk restart.

Alternatively, you can access the Asterisk console by running asterisk -vvvvcr on the command line and enter the restart gracefully command at the asterisk*CLI> prompt. The gracefully command will instruct Asterisk to wait until all open channels are closed before shutting down, and then start itself up again.

1 comments
ambiorixg12
ambiorixg12

This is an excellent info, work perfect in pri T1 in Dominican Republic, just missing the zapata.conf now called chan_dahdi.conf

Editor's Picks