The Public Switched Telephone Network (PSTN) has existed for over a century. It is the precursor to many of the technologies that shape our world today, from the Internet to MP3 players.
There are two types of fundamental technology that phone carriers use to deliver telephone circuits: analog and digital.
The first telephone networks were all analog. The audio signal that you generated with your voice was used to generate an electrical signal that was carried to the other end. The electrical signal had the same characteristics as the sound being produced.
Analog circuits have several characteristics that differentiate them from other circuits you might wish to connect to Asterisk:
No signaling channel exists—most signaling is electromechanical.
Disconnect supervision is usually delayed by several seconds, and is not completely reliable.
Far-end supervision is minimal (for example, answer supervision is lacking).
Differences in circuits means that audio characteristics will vary from circuit to circuit, and will require tuning.
Analog circuits that you wish to connect to your Asterisk system will need to connect to a Foreign eXchange Office (FXO) port. Since there is no such thing as an FXO port in any standard computer, an FXO card must be purchased and installed in the system in order to connect traditional analog lines.[72]
Analog ports are not generally used in medium to large systems. They are most commonly used in smaller offices (less than 10 lines; less than 30 phones). Your decision to use analog might be based on some of the following factors:
From a technical perspective, you would normally want to have digital rather than analog circuits. Reality does not always accommodate, though, so analog will likely be around for a few more years yet.
Digital telephony was developed in order to overcome many of the limitations of analog. Some of the benefits of digital circuits include:
In an Asterisk system (or any PBX, for that matter), there are several types of digital circuits you might want to connect:
Used in Canada and the United States (mostly for ISDN-PRI)
Used in the rest of the world (ISDN-PRI or MFC/R2)
Used for ISDN-BRI circuits (Euro-ISDN)
Note that the physical circuit can be further defined by the protocol running on the circuit. For example, a T1 could be used for either ISDN-PRI, or CAS, and an E1 could be used for ISDN-PRI, CAS, or MFC/R2. We’ll discuss the different protocols in the next section.
Depending on the hardware you have installed, the process for installing your PSTN cards will vary. We will discuss installation in general terms, which will apply to all Digium PSTN cards. Other manufacturers tend to provide installation scripts with their hardware, which will automate much of this for you.
The Digium Asterisk Hardware Device Interface, a.k.a. DAHDI (DAW-dee)[73] is the software framework required to enable communication between PSTN cards and Asterisk. Even if you do not have any PSTN hardware, we recommend installing DAHDI since it is a simple, reliable way to get a valid timing source.[74] Complete DAHDI installation instructions can be found in Chapter 3, Installing Asterisk.
Digital telephony was developed by carriers as a way to reduce the cost of long-distance circuits, as well as improve transmission quality. The entire PSTN backbone has been fully digital for many years now. The essence of a digital circuit is the digitization of the audio, but digital trunks also allow for more complex and reliable signaling. Several standards have been developed and deployed, and for each standard there may be regional differences as well.
You can use dahdi_hardware and lsdahdi
to help you determine what telephony hardware your
system contains. You can also use dahdi_genconf modules to build an /etc/asterisk/modules file for you based
on the found hardware.
Primary Rate Interface ISDN (commonly known as PRI) is a protocol designed to run primarily on a DS1 circuit (a T1 or E1, depending on where you are in the world) between a carrier and a customer. PRI uses one of the DS0 channels as a signaling channel (referred to as the D-channel). A typical PRI circuit is therefore broken down into a group of B-channels (the bearer channels that actually carry the calls), and a D-channel for signaling. Although it is most common to find a PRI circuit being carried across a single physical circuit (such as a T1 or E1), it is possible to have a PRI circuit span multiple DS1s, and even to have multiple D-channels.[75]
While there are many different ways to configure PRI circuits, we are hoping to avoid confusing you with all of the options (many of which are obsolete or at least no longer in common use), and instead provide examples of the more common configurations.
When installing telephony hardware, be sure you update the /etc/dahdi/modules file to enable the
appropriate modules for your hardware and then reload DAHDI with
the init script (/etc/init.d/dahdi). You can use the
dahdi_genconf modules command
to generate the modules file for your system as
well.
Most PRI circuits in North America will use a T1 with the following characteristics:
Line code: B8ZS (bipolar with 8-zeros substitution)
Framing: ESF (extended superframe)
You will need to configure
two files. The /etc/dahdi/system.conf file should look
something like this:
loadzone = us defaultzone = us span = 1,1,0,esf,b8zs bchan = 1-23 echocanceller = mg2,1-23 hardhdlc = 24
And the /etc/asterisk/chan_dahdi.conf file should
look like this:
[trunkgroups] [channels] usecallerid = yes hidecallerid = no callwaiting = yes usecallingpres = yes callwaitingcallerid = yes threewaycalling = yes transfer = yes canpark = yes cancallforward = yes callreturn = yes echocancel = yes echocancelwhenbridged = yes relaxdtmf = yes rxgain = 0.0 txgain = 0.0 group = 1 callgroup = 1 pickupgroup = 1 immediate = no switchtype = national ; commonly referred to as NI2 context = from-pstn group = 0 echocancel = yes signalling = pri_cpe channel => 1-23
Some carriers will use Nortel’s DMS switch, which commonly uses the DMS100 protocol instead of
National ISDN 2. In this case you would set the switchtype to DMS100:
switchtype = dms100
Outside of Canada and the US, PRI circuits will be carried on an E1 circuit.
In Europe, an E1 circuit used for PRI will normally have the following characteristics:
Line code: CCS
Framing: HDB3 (high-density bipolar)
The /etc/dahdi/system.conf file might look
something like this:
span = 1,0,0,ccs,hdb3,crc4 bchan = 1-15,17-31 hardhdlc = 16
And the /etc/asterisk/chan_dahdi.conf file should
look something like this:
[trunkgroups] [channels] usecallerid = yes hidecallerid = no callwaiting = yes usecallingpres = yes callwaitingcallerid = yes threewaycalling = yes transfer = yes canpark = yes cancallforward = yes callreturn = yes echocancel = yes echocancelwhenbridged = yes relaxdtmf = yes rxgain = 0.0 txgain = 0.0 group = 1 callgroup = 1 pickupgroup = 1 immediate = no switchtype = qsig context = pri_incoming group = 0 signalling = pri_cpe channel => 1-15,17-31
Basic Rate Interface ISDN (commonly known as BRI, or sometimes even just ISDN) was intended to be the smaller sibling to PRI. BRI only provides two 64K B-channels and a 16K D-channel. The use of BRI has been somewhat limited in North America (we don’t recommend using it for any reason), but in some countries in Europe it is widely used and has almost completely replaced analog.
BRI support under Asterisk will be different depending on the BRI card you are installing. The manufacturer of your BRI card will provide specific installation instructions for its hardware.
When installing telephony
hardware, be sure you update the /etc/dahdi/modules file to enable the
appropriate modules for your hardware and then reload DAHDI with
the init script (/etc/init.d/dahdi). You can use the
dahdi_genconf modules command
to generate the modules file for your system as
well.
The MFC/R2 protocol could be thought of as a precursor to ISDN. It was at first used on analog circuits, but it is now mostly deployed on the same E1 circuits that also carry ISDN-PRI. This protocol is not typically found in Canada, the US, or Western Europe, but it is very popular in some parts of the world (especially Latin America and Asia), mostly because it tends to be a less expensive service offering from the carriers.
There are many different flavors of this protocol, each country having a different regional variant.
The OpenR2 project
provides the libopenr2 library, which needs to be installed on your system in order
for Asterisk to support your R2 circuits. Before installing libopenr2, however, you need to have DAHDI
installed.
The compilation and installation order, therefore, is:
Once OpenR2 has been installed, you can use the r2test application to see a list of variants that are supported:
$r2test -lVariant Code Country AR Argentina BR Brazil CN China CZ Czech Republic CO Colombia EC Ecuador ITU International Telecommunication Union MX Mexico PH Philippines VE Venezuela
For additional information
on configuring R2 support in Asterisk, see the configs/chan_dahdi.conf.sample file
included in the Asterisk source tree (search for “mfcr2”).
Additionally, OpenR2 contains some sample configuration files for
connecting Asterisk to networks in various countries. To read
information about some of the country variants, search the /doc/asterisk folder and refer to the
documents inside the appropriate subdirectory:
$ls doc/asterisk/ar br ec mx ve
As an example, OpenR2
provides a sample configuration for connecting to Telmex or Axtel in
Mexico. We’ll step you through this to give you an idea of the
process. First, you must configure DAHDI by modifying /etc/dahdi/system.conf as shown
here:
loadzone = us defaultzone = us span = 1,1,0,cas,hdb3 cas = 1-15:1101 cas = 17-31:1101 span = 2,1,0,cas,hdb3 cas = 32-46:1101 cas = 48-62:1101
Next, you must configure
Asterisk by modifying /etc/asterisk/chan_dahdi.conf as follows:
signalling = mfcr2 mfcr2_variant = mx mfcr2_get_ani_first = no mfcr2_max_ani = 10 mfcr2_max_dnis = 4 mfcr2_category = national_subscriber mfcr2_mfback_timeout = -1 mfcr2_metering_pulse_timeout = -1 ; this is for debugging purposes mfcr2_logdir = log mfcr2_logging = all ; end debugging configuration channel => 1-15 channel => 17-31
There are many companies producing PSTN cards for
Asterisk. The card will need to have its drivers installed so that
Linux can recognize it (DAHDI ships with these drivers for Digium
cards). From that point, configuration is handled by the Asterisk
module chan_dahdi.
You can use dahdi_hardware and lsdahdi to determine what telephony hardware your system contains.
When installing telephony
hardware, be sure you update the /etc/dahdi/modules file to enable the
appropriate modules for your hardware and then reload DAHDI with the
init script (/etc/init.d/dahdi). You can use the
dahdi_genconf modules command to generate the modules file for your system as
well.
In order to configure an FXO card to work with Asterisk, two files are required.
The first is not an Asterisk
configuration file, and is thus located in the /etc/dahdi folder on your system.[76] This file, system.conf allows you to define some basic parameters, as well as
specify the channels that will be available to your system. Our
example assumes a four-port FXO card, but many different combinations
are possible, depending on your hardware.
loadzone = us ; tonezone defines sounds the interface must produce
; (dialtone, busy signal, ringback, etc.)
defaultzone = us ; define a default tonezone
fxsks = 1-4 ; which channels on the card will have these parameters
Once your card and channels
are known to the operating system, you must configure them for
Asterisk by means of the file /etc/asterisk/chan_dahdi.conf:
[channels]
;
; To apply other options to these channels, put them before "channel".
;
signalling = fxs_ks ; in Asterisk, FXO channels use FXS signaling
; (and yes, FXS channels use FXO signaling)
channel => 1-4 ; apply all the previously defined settings to this channel
In this example, we have told Asterisk that the first four DAHDI channels in the system are FXO ports.
If you are connecting to the PSTN using analog
channels, we need to explain extension s. When calls enter a context without a
specific destination extension (for example, a ringing FXO line from
the PSTN), they are passed to the s extension. (The s stands for “start,” as this is where a
call will start if no extension information was passed with the
call). This extension can also be useful for accepting calls that
have been redirected from other parts of the dialplan. For example,
if we had a list of DID numbers that were all going to the same
place, we might want to point each DID to the s extension, rather than having to code
duplicate dialplan logic for each DID.
Since this is exactly what
we need for our dialplan, let’s begin to fill in the pieces. We will
be performing three actions on the call (answer it, play a sound
file, and hang it up), so our s
extension will need three priorities. We’ll place the three
priorities below [incoming],
because we have decided that all incoming calls should start in this
context[77]:
[incoming] exten => s,1,Answer() same => n,Playback(tt-weasels) same => n,Hangup()
Obviously, you would not normally want to answer a call and then hang up. Typically, an incoming call will either be answered by an automated attendant, or ring directly to a phone (or group of phones).
[72] You would use the exact same card if you wanted to connect a traditional home telephone line to your Asterisk system.
[73] Don’t ask.
[74] There are other ways of getting a timing source, and if you want a really tight system it is possible to run Asterisk without DAHDI, but it’s not something we’re going to cover here.
[75] Sometimes circuits are referenced by the number of B- and D-channels they contain, so a single T1 running the PRI protocol in North America might be referred to as 23B+D, and a dual T1 circuit with a backup D-channel would be a 46B+2D. We’ve even seen PRI referenced as nB+nD, although this can get a little bit pedantic.
[76] In theory, these cards could be used for any software that supports DAHDI; therefore, the basic card configuration is not a part of Asterisk.
[77] There is nothing special about any context name. We could have named this context
[stuff_that_comes_in], and as
long as that was the context assigned in the channel definition in sip.conf,
iax.conf,
chan_dahdi.conf, et al., the channel would
enter the dialplan in that context. Having said that, it is
strongly recommended that you give your contexts names that help
you to understand their purpose. Some good context names might
include [incoming], [local_calls], [long_distance], [sip_telephones], [user_services], [experimental], [remote_locations], and so forth.
Always remember that a context determines how a channel enters
the dialplan, so name accordingly.