 Chapter 1 | Asterisk™: The Definitive GuideChapter 2. Asterisk Architecture | Chapter 3 |
Chapter 2. Asterisk Architecture
First things first, but not necessarily in that order.
Asterisk is very different from other, more traditional PBXs, in that the dialplan in Asterisk treats all incoming channels in essentially the same manner.
In a traditional PBX, there is a logical difference between stations (telephone sets) and trunks (resources that connect to the outside world). This means, for example, that you can’t install an external gateway on a station port and route external calls to it without requiring your users to dial the extension number first. Also, the concept of an off-site resource (such as a reception desk) is much more difficult to implement on a traditional PBX, because the system will not allow external resources any access to internal features.[12]
Asterisk, on the other hand, does not have an internal concept of trunks or stations. In Asterisk, everything that comes into or goes out of the system passes through a channel of some sort. There are many different kinds of channels; however, the Asterisk dialplan handles all channels in a similar manner, which means that, for example, an internal user can exist on the end of an external trunk (e.g., a cell phone) and be treated by the dialplan in exactly the same manner as that user would be if she were on an internal extension. Unless you have worked with a traditional PBX, it may not be immediately obvious how powerful and liberating this is. Figure 2-1 illustrates the differences between the two architectures.
Figure 2.1. Asterisk vs. PBX architecture
Modules
Asterisk is built on modules. A module
is a loadable component that provides a specific functionality, such as a
channel driver (for example, chan_sip.so), or a
resource that allows connection to an external technology (such as
func_odbc.so). Asterisk modules are loaded based on
the /etc/asterisk/modules.conf file. We will discuss
the use of many modules in this book. At this point we just want to
introduce the concept of modules, and give you a feel for the types of
modules that are available.
It is actually possible to start Asterisk without any modules at all, although in this state it will not be capable of doing anything. It is useful to understand the modular nature of Asterisk in order to appreciate the architecture.
Note
You can start Asterisk with no modules loaded by default and load each desired module manually from the console, but this is not something that you’d want to put into production; it would only be useful if you were performance-tuning a system where you wanted to eliminate everything not required by your specific application of Asterisk.
The types of modules in Asterisk include the following:
Applications
Bridging modules
Call detail recording (CDR) modules
Channel event logging (CEL) modules
Channel drivers
Codec translators
Format interpreters
Dialplan functions
PBX modules
Resource modules
Addons modules
Test modules
In the following sections we will list each module available within these categories, briefly identify its purpose, and give our opinion on its relative popularity and/or importance (while some modules are proven and deservedly popular, others are quite old, are barely ever used anymore, and are only maintained for the purpose of backward-compatibility). The details of how specific modules work will be covered in various chapters throughout the book, depending on what the module is and what it does. Some modules will be covered thoroughly; others may not be covered at all.
Regarding the Popularity/Status column in the tables that follow, the following list contains our opinions with respect to the meanings we have chosen (your mileage may vary):
- Insignificant
This module is ancient history. If you use it, be aware that you are mostly on your own when it comes to any sort of community support.
- Unreliable
This module is new or experimental, and is not suitable for production.
- Useful
This module is current, maintained, popular, and recommended.
- Usable
This module works but may be incomplete or unpopular, and/or is not recommended by the authors.
- New
This module is quite new, and its completeness and popularity are difficult to gauge at this time.
- Deprecated
This module has been replaced by something that is considered superior.
- Limited
This module has limitations that may make it unsuitable to your requirements.
- Essential
This module is one you’ll never want to be without.
And now, without further ado, let’s take a look at the modules, grouped by module type.
Applications
Dialplan applications are used in
extensions.conf to define the various actions that
can be applied to a call. The
Dial() application, for
example, is responsible for making outgoing connections to external
resources and is arguably the most important dialplan application. The
available applications are listed in Table 2.1, “Dialplan applications”.
Table 2.1. Dialplan applications
| Name | Purpose | Popularity/Status |
|---|---|---|
app_adsiprog
| Loads Analog Display Services Interface (ADSI) scripts into compatible analog phones | Insignificant |
app_alarmreceiver
| Supports receipt of reports from alarm equipment | Insignificant |
app_amd
| Detects answering machines | Unreliable |
app_authenticate
| Compares dual-tone multi-frequency (DTMF) input against a provided string (password) | Useful |
app_cdr
| Writes ad hoc record to CDR | Useful |
app_celgenuserevent
| Generates user-defined events for CEL | New |
app_chanisavail
| Checks the status of a channel | Unreliable |
app_channelredirect
| Forces another channel into a different part of the dialplan | Useful |
app_chanspy
| Allows a channel to listen to audio on another channel | Useful |
app_confbridge
| Provides conferencing (new version) | New—not fully featured yet |
app_controlplayback
| Plays back a prompt and offers fast forward and rewind functions | Useful |
app_dahdibarge
| Allows barging in on a DAHDI channel | Deprecated—see app_chanspy |
app_dahdiras
| Creates a RAS server over a DAHDI channel (no modem emulation) | Insignificant |
app_db
| Used to add/change/delete records in Asterisk’s built-in Berkeley database | Deprecated—see
func_db |
app_dial
| Used to connect channels together (i.e., make phone calls) | Essential |
app_dictate
| Plays back a recording and offers start/stop functions | Useful |
app_directed_pickup
| Answers a call for another extension | Useful |
app_directory
| Presents the list of names from
voicemail.conf | Useful |
app_disa
| Provides dialtone and accepts DTMF input | Useful[a] |
app_dumpchan
| Dumps channel variables to Asterisk command-line interface (CLI) | Useful |
app_echo
| Loops received audio back to source channel | Useful |
app_exec
| Contains
Exec(),
TryExec(), and
ExecIf(); executes
a dialplan application based on conditions | Useful |
app_externalivr
| Controls Asterisk as with an AGI, only asynchronously | Useful |
app_fax
| Provides SendFax() and
ReceiveFax() | Useful[b] |
app_festival
| Enables basic text to speech using Festival TTS engine | Usable |
app_flash
| Performs a hook-switch flash on channels (primarily analog) | Useful |
app_followme
| Performs find me/follow me functionality based on
followme.conf | Useful |
app_forkcdr
| Starts new CDR record on current call | Usable |
app_getcpeid
| Gets the ADSI CPE ID | Insignificant |
app_ices
| Sends audio to an Icecast server | Usable |
app_image
| Transmits an image to supported devices | Limited |
app_ivrdemo
| Sample application for developers | Insignificant |
app_jack
| Works with JACK Audio Connection Kit to share audio between compatible applications | Useful |
app_macro
| Triggers dialplan macros | Deprecated—see
GoSub() |
app_meetme
| Provides multiparty conferencing | Useful—fully featured |
app_milliwatt
| Generates 1004-Hz tone for testing loss on analog circuits | Useful |
app_minivm
| Provides primitive functions to allow you to build your own voicemail application in dialplan | Usable |
app_mixmonitor
| Records both sides of a call and mixes them together | Useful |
app_morsecode
| Generates Morse code | Usable |
app_mp3
| Uses mpg123 to play an MP3 | Insignificant |
app_nbscat
| Streams audio from Network Broadcast Stream (NBS) | Insignificant |
app_originate
| Allows origination of a call | Useful |
app_osplookup
| Performs Open Settlement Protocol (OSP) lookup | Usable |
app_page
| Creates multiple audio connections to specified devices for public address (paging) | Useful |
app_parkandannounce
| Enables automated announcing of parked calls | Usable |
app_playback
| Plays a file to the channel (does not accept input) | Useful |
app_playtones
| Plays pairs of tones of specified frequencies | Useful |
app_privacy
| Requests input of caller’s phone number if no CallerID is received | Insignificant |
app_queue
| Provides Automatic Call Distribution (ACD) | Useful |
app_read
| Requests input of digits from callers and assigns input to a variable | Useful |
app_readexten
| Requests input of digits from callers and passes call to a designated extension and context | Usable |
app_readfile
| Loads contents of a text file into a channel variable | Deprecated—see the FILE() function in
func_env |
app_record
| Records received audio to a file | Useful |
app_rpt
| Provides a method to interface with an audio board for
the app_rpt project | Limited |
app_sayunixtime
| Plays back time in specified format | Useful |
app_senddtmf
| Transmits DTMF to calling party | Useful |
app_sendtext
| Sends a text string to compatible channels | Insignificant |
app_setcallerid
| Sets CallerID on a channel | Deprecated—see
func_callerid |
app_skel
| Sample application for developers | Useful[c] |
app_sms
| Sends SMS message in compatible countries | Limited |
app_softhangup
| Requests hangup of channel | Useful |
app_speech_utils
| Provides utilities relating to speech recognition | Useful[d] |
app_stack
| Provides Gosub(),
GoSubIf(), Return(),
StackPop(), LOCAL(), and
LOCAL_PEEK() | Essential |
app_system
| Executes commands in a Linux shell | Useful |
app_talkdetect
| Similar to app_background, but allows
for any received audio to interrupt playback | Useful |
app_test
| Client/server testing application | Usable |
app_transfer
| Performs a transfer on the current channel | Useful |
app_url
| Passes a URI to the called channel | Limited |
app_userevent
| Generates a custom event in the Asterisk Manager Interface (AMI) | Useful |
app_verbose
| Generates a custom event in the Asterisk CLI | Useful |
app_voicemail
| Provides voicemail | Essential |
app_waitforring
| Waits for a RING signaling event (not to be confused with
RINGING); most likely unnecessary, as only
chan_dahdi with analog channels where ringing
is received (such as an FXO port) generates the RING signaling event | Insignificant |
app_waitforsilence
| Includes WaitForSilence() and
WaitForNoise(); listens to the incoming
channel for a specified number of milliseconds of
noise/silence | Useful |
app_waituntil
| Waits until current Linux epoch matches specified epoch | Useful |
app_while
| Includes While(),
EndWhile(), ExitWhile(),
and ContinueWhile(); provides while-loop
functionality in the
dialplan | Useful |
app_zapateller
| Generates SIT tone to discourage telemarketers | Usable |
[a] The use of (DISA) is considered to be a security risk. [b] Requires a suitable DSP engine to handle encoding/decoding of fax signaling (see Chapter 19, Fax). [c] If you are a developer. [d] Requires an external speech recognition application. | ||
Bridging Modules
Bridging modules are new in Asterisk 1.8: they perform the
actual bridging of channels in the new bridging API. Each provides
different features, which get used in different situations depending on
what a bridge needs. These modules, listed in Table 2.2, “Bridging modules”, are currently only used for (and are
essential to) app_confbridge.
Table 2.2. Bridging modules
Call Detail Recording Modules
The CDR modules, listed in Table 2.3, “Call detail recording modules”, are designed to facilitate as many methods of storing call detail records as possible. You can store CDRs to a file (default), a database, RADIUS, or syslog.
Note
Call detail records are not intended to be used in complex billing applications. If you require more control over billing and call reporting, you will want to look at channel event logging, discussed next. The advantage of CDR is that it just works.
Table 2.3. Call detail recording modules
We will discuss some reporting packages that you may wish to use with CDR in Chapter 25, Web Interfaces.
Channel Event Logging Modules
Channel event logging provides much more powerful control over reporting of call activity. By the same token, it requires more careful planning of your dialplan, and by no means will it work automatically. Asterisk’s CEL modules are listed in Table 2.4, “Channel event logging modules”.
Table 2.4. Channel event logging modules
Channel Drivers
Without channel drivers, Asterisk would have no way to make calls. Each channel driver is specific to the protocol or channel type it supports (SIP, ISDN, etc.). The channel module acts as a gateway to the Asterisk core. Asterisk’s channel drivers are listed in Table 2.5, “Channel drivers”.
Table 2.5. Channel drivers
| Name | Purpose | Popularity/Status |
|---|---|---|
chan_agent
| Provides agent channel for
Queue() | Useful |
|chan_alsa
| Provides connection to Advanced Linux Sound Architecture | Useful |
chan_bridge
| Used internally by the
ConfBridge() application; should not be used
directly | Essential [a] |
chan_console
| Provides connection to portaudio | New |
chan_dahdi
| Provides connection to PSTN cards that use DAHDI channel drivers | Useful |
chan_gtalk
| Provides connection to Google Talk | Usable |
chan_h323
| Provides connection to H.323 endpoints | Deprecated—see chan_ooh323 in Table 2.11, “Addon modules” |
chan_iax2
| Provides connection to IAX2 endpoints | Useful |
chan_jingle
| Provides connection to Jingle-enabled endpoints | Usable |
chan_local
| Provides a mechanism to treat a portion of the dialplan as a channel | Useful |
chan_mgcp
| Media Gateway Control Protocol channel driver | Usable |
chan_misdn
| Provides connection to mISDN supported ISDN cards | Limited |
chan_multicast_rtp
| Provides connection to multicast RTP streams | Useful |
chan_nbs
| Network Broadcast Sound channel driver | Insignificant |
chan_oss
| Open Sound System driver | Useful |
chan_phone
| Linux telephony interface driver (very old) | Insignificant |
chan_sip
| Session Initiation Protocol channel driver | Essential |
chan_skinny
| Cisco Skinny Client Control Protocol (SCCP) channel driver | Usable |
chan_unistim
| Nortel Unistim protocol channel driver | Usable |
chan_usbradio
| Channel driver for CM108 USB cards with radio interface | Usable |
chan_vpb
| Voicetronix channel driver | Insignificant[b] |
[a] If you are using the [b] Some Voicetronix hardware is supported by Zaptel using an addon Zaptel module distributed by Voicetronix. However, Zaptel is no longer supported by Asterisk and this driver has not been ported to DAHDI. | ||
Codec Translators
The codec translators (Table 2.6, “Codec translators”) allow Asterisk to convert audio stream formats between calls. So if a call comes in on a PRI circuit (using G.711) and needs to be passed out a compressed SIP channel (e.g., using G.729, one of many codecs that SIP can handle), the relevant codec translator would perform the conversion.[13]
Note
If a codec (such as G.729) uses a complex encoding algorithm, heavy use of transcoding can place a massive burden on the CPU. Specialized hardware for the decoding/encoding of G.729 is available from hardware manufacturers such as Sangoma and Digium (and likely others).
Table 2.6. Codec translators
| Name | Purpose | Popularity/Status |
|---|---|---|
codec_adpcm
| Adaptive Differential Pulse Coded Modulation codec | Insignificant |
codec_alaw
| A-law PCM codec used all over the world (except Canada/USA) on the PSTN | Essential |
codec_a_mu
| A-law to mu-law direct converter | Useful |
codec_dahdi
| Utilizes proprietary Digium hardware transcoding card | Essential[a] |
codec_g722
| Wideband audio codec | Useful |
codec_g726
| Flavor of ADPCM | Insignificant |
codec_gsm
| Global System for Mobile Communications (GSM) codec | Useful |
codec_ilbc
| Internet Low Bitrate Codec | Insignificant |
codec_lpc10
| Linear Predictive Coding vocoder (extremely low bandwidth) | Insignificant |
codec_resample
| Resamples between 8-bit and 16-bit signed linear | Usable |
codec_speex
| Speex codec | Usable |
codec_ulaw
| Mu-law PCM codec used in Canada/USA on PSTN | Essential |
[a] If you are using a Digium codec transcoder card. | ||
Format Interpreters
Format interpreters (Table 2.7, “Format interpreters”) perform the function of codec translators, but they do their work on files rather than channels. If you have a recording on a menu that has been stored as GSM, a format interpreter would need to be used to play that recording to any channels not using the GSM codec.[14]
If you store a recording in several formats (such as WAV, GSM, etc.), Asterisk will determine the least costly format[15] to use when a channel requires that recording.
Table 2.7. Format interpreters
Dialplan Functions
Dialplan functions, listed in Table 2.8, “Dialplan functions”, complement the dialplan applications (see the section called “Applications”). They provide many useful enhancements to things like string handling, time and date wrangling, and ODBC connectivity.
Table 2.8. Dialplan functions
PBX Modules
The PBX modules are peripheral modules that provide
enhanced control and configuration mechanisms. For example,
pbx_config is the module that loads the traditional
Asterisk dialplan. The currently available PBX modules are listed in
Table 2.9, “PBX modules”.
Table 2.9. PBX modules
| Name | Purpose | Popularity/Status |
|---|---|---|
pbx_ael
| Asterisk Extension Logic (AEL) offers a dialplan scripting language that looks like a modern programming language. | Usable[a] |
pbx_config
| This is the traditional, and most popular,
dialplan language for Asterisk. Without this module, Asterisk
cannot read extensions.conf. | Useful |
pbx_dundi
| Performs data lookups on remote Asterisk systems. | Useful |
pbx_loopback
| Performs something similar to a dialplan include, but in a deprecated manner. | Insignificant[b] |
pbx_lua
| Allows creation of a dialplan using the Lua scripting language. | Useful |
pbx_realtime
| Provides functionality related to the Asterisk Realtime Architecture. | Useful |
pbx_spool
| Provides outgoing spool support relating to Asterisk call files. | Useful |
[a] We have not found too many people using AEL. We suspect this is because most developers will tend to use AGI/AMI if they do not want to use traditional dialplans. [b] We’ve never heard of this being used in production. | ||
Resource Modules
Resource modules integrate Asterisk with external
resources. For example, res_odbc allows Asterisk to
interoperate with ODBC database connections. The currently available
resource modules are listed in Table 2.10, “Resource modules”.
Table 2.10. Resource modules
| Name | Purpose | Popularity/Status |
|---|---|---|
res_adsi
| Provides ADSI | Essential[a] |
res_ael_share
| Provides shared routines for use with
pbx_ael | Essential if you’re using AEL |
res_agi
| Provides Asterisk Gateway Interface | Useful |
res_ais
| Provides distributed message waiting indication (MWI) and device state notifications via an implementation of the AIS standard, such as OpenAIS | Useful |
res_calendar
| Enables base integration to calendaring systems | Useful |
res_calendar_caldav
| Provides CalDAV-specific capabilities | Useful |
res_calendar_exchange
| Provides MS Exchange capabilities | Useful |
res_calendar_icalendar
| Provides Apple/Google iCalendar capabilities | Useful |
res_clialiases
| Creates CLI aliases | Useful |
res_clioriginate
| Originates a call from the CLI | Usable |
res_config_curl
| Pulls configuration information using cURL | Useful |
res_config_ldap
| Pulls configuration information using LDAP | Usable |
res_config_odbc
| Pulls configuration information using ODBC | Useful |
res_config_pgsql
| Pulls configuration information using PostgreSQL | Usable |
res_config_sqlite
| Pulls configuration information using SQLite | Usable |
res_convert
| Uses the CLI to perform file conversions | Usable |
res_crypto
| Provides cryptographic capabilities | Useful |
res_curl
| Provides common subroutines for other cURL modules | Useful |
res_fax
| Provides common subroutines for other fax modules | Useful |
res_fax_spandsp
| Plug-in for fax using the spandsp
package | Useful |
res_http_post
| Provides POST upload support for the Asterisk HTTP server | Usable |
res_jabber
| Provides Jabber/XMPP resources | Useful |
res_limit
| Enables adjusting of system limits on the Asterisk process | Usable |
res_monitor
| Provides call recording resources | Useful |
res_musiconhold
| Provides music on hold (MOH) resources | Essential |
res_mutestream
| Allows muting/unmuting of audio streams | New |
res_odbc
| Provides common subroutines for other ODBC modules | Useful |
res_phoneprov
| Provisions phones from Asterisk HTTP server | New |
res_pktccops
| Provides PacketCable COPS resources | New |
res_realtime
| Provides CLI commands for the Asterisk Realtime Architecture (ARA) | Useful |
res_rtp_asterisk
| Provides RTP | Essential |
res_rtp_multicast
| Provides multicast-RTP | New |
res_security_log
| Enables security logging | New |
res_smdi
| Provides voicemail notification using the SMDI protocol | Limited |
res_snmp
| Provides system status information to an SNMP-managed network | Usable |
res_speech
| Generic speech recognition API | Limited[b] |
res_timing_dahdi
| Provides timing using the DAHDI kernel interface | Useful |
res_timing_kqueue
| Provides timing using a kernel feature in some BSDs, including Mac OS X | New |
res_timing_pthread
| Provides timing using only parts of the standard
pthread API; less efficient but more portable
than other timing modules. | Useful |
res_timing_timerfd
| Provides timing using the timerfd API
provided by newer versions of the Linux kernel | Useful |
[a] While most of the ADSI functionality in Asterisk is never used, the voicemail application uses this resource. [b] Requires a separately licensed product in order to be used. | ||
Addon Modules
Addon modules are community-developed modules with different usage or distribution rights from those of the main code. They are kept in a separate directory and are not compiled and installed by default. To enable these modules, use the menuselect build configuration utility. Currently available addon modules are listed in Table 2.11, “Addon modules”.
Table 2.11. Addon modules
| Name | Purpose | Popularity/Status |
|---|---|---|
app_mysql
| Executes MySQL queries with a dialplan application | Deprecated—see func_odbc |
app_saycountpl
| Says Polish counting words | Deprecated—now integrated in
say.conf |
cdr_mysql
| Logs call detail records to a MySQL database | Usable—we recommend cdr_adaptive_odbc
instead |
chan_mobile
| Enables making and receiving phone calls using cell phones over Bluetooth | Limited[a] |
chan_ooh323
| Enables making and receiving VoIP calls using the H.323 protocol | Usable |
format_mp3
| Allows Asterisk to play MP3 files | Usable |
res_config_mysql
| Uses a MySQL database as a real-time configuration backend | Useful |
[a] While | ||
Test Modules
Test modules are used by the Asterisk development team to validate new code. They are constantly changing and being added to, and are not useful unless you are developing Asterisk software.
If you are an Asterisk developer, however, the Asterisk Test Suite may be of interest to you as you can build automated tests for Asterisk and submit those back to the project, which runs on several different operating systems and types of machines. By expanding the number of tests constantly, the Asterisk project avoids the creation of regressions in code. By submitting your own tests to the project, you can feel more confident in future upgrades.
More information about installing the Asterisk Test Suite is available in this blog post: http://blogs.asterisk.org/2010/04/29/installing-the-asterisk-test-suite/. More information about building tests is available in this document: http://svn.asterisk.org/svn/testsuite/asterisk/trunk/README.txt or you can join the #asterisk-testing channel on the Freenode IRC network.
File Structure
Asterisk is a complex system, composed of many resources. These resources make use of the filesystem in several ways. Since Linux is so flexible in this regard, it is helpful to understand what data is being stored, so that you can understand where you are likely to find a particular bit of stored data (such as voicemail messages or log files).
Configuration Files
The Asterisk configuration files include
extensions.conf, sip.conf,
modules.conf, and dozens of other files that define
parameters for the various channels, resources, modules, and functions
that may be in use.
These files will be found in
/etc/asterisk. You will be working in this folder a
lot as you configure and administer your Asterisk system.
Modules
Asterisk modules are usually installed to the
/usr/lib/asterisk/modules folder. You will not
normally have to interact with this folder; however, it will be
occasionally useful to know where the modules are located. For example,
if you upgrade Asterisk and select different modules during the
menuselect phase of the install, the old
(incompatible) modules from the previous Asterisk version will not be
deleted, and you will get a warning from the install script. Those old
files will need to be deleted from the modules
folder. This can be done either manually or with the
“uninstall” make (make uninstall) target.
The Resource Library
There are several resources that require external data
sources. For example, music on hold (MOH) can’t happen unless you have
some music to play. System prompts also need to be stored somewhere on
the hard drive. The /var/lib/asterisk folder is
where system prompts, AGI scripts, music on hold, and other resource
files are stored.
The Spool
The spool is where Linux stores files that are going to change frequently, or will be processed by other processes at a later time. For example, under Linux print jobs and pending emails are normally written to the spool until they are processed.
For Asterisk, the spool is used to store transient items such as voice messages, call recordings,[16] call files, and so forth.
The Asterisk spool will be found under
the /var/spool/asterisk directory.
Logging
Asterisk is capable of generating several different kinds
of log files. The /var/log/asterisk folder is where
things such as call detail records (CDRs), channel events from CEL,
debug logs, queue logs, messages, errors, and other output are
written.
This folder will be extremely important for any troubleshooting efforts you undertake. We will talk more about how to make use of Asterisk logs in Chapter 24, System Monitoring and Logging.
The Dialplan
The dialplan is the heart of Asterisk. All channels that arrive in the system will be passed through the dialplan, which contains the call-flow script that determines how the incoming calls are handled.
A dialplan can be written in one of three ways:
Using traditional Asterisk dialplan syntax in
/etc/asterisk/extensions.confUsing asterisk Extension Logic (AEL) in
/etc/asterisk/extensions.aelUsing LUA in
/etc/asterisk/extensions.lua
Later in this book, we’ll have devoted several chapters to the subject of how to write a dialplan using traditional dialplan syntax (by far the most popular choice). Once you learn this language, it should be fairly easy to transition to AEL or LUA, should you desire.
Hardware
Asterisk is capable of communicating with a vast number of different technologies. In general, these connections are made across a network connection; however, connections to more traditional telecom technologies, such as the PSTN, require specific hardware.
Many companies produce this hardware, such as Digium (the sponsor, owner, and primary developer of Asterisk), Sangoma, Rhino, OpenVox, Pika, Voicetronix, Junghanns, Dialogic, Xorcom, beroNet, and many others. The authors prefer cards from Digium and Sangoma; however, the products offered by other Asterisk hardware manufacturers may be more suitable to your requirements.
The most popular hardware for Asterisk is generally designed to work through the Digium Asterisk Hardware Device Interface (known as DAHDI). These cards will all have different installation requirements and different file locations.
In Chapter 7, Outside Connectivity, we will discuss DAHDI in more detail; however, we will limit our discussion to DAHDI only. You will need to refer to the specific documentation provided by the manufacturers of any cards you install for details on those cards.
Asterisk Versioning
The Asterisk release methodology has gone through a couple of iterations over the last few years, and this section is designed to help you understand what the version numbers mean. Of particular relevance is the change in versioning that happened with the 1.6.x series of releases, which followed a different numbering logic than all other Asterisk releases (1.0 to 1.8 and onward for the foreseeable future).
Previous Release Methodologies
When we had just Asterisk 1.2 and 1.4, all new development was carried out in trunk (it still is), and only bug fixes went into the 1.2 and 1.4 branches. The Asterisk 1.2 branch has been marked as EOL (End of Life), and is no longer receiving bug fixes or security updates. Prior to the 1.6.x branches, bug fixes were carried out only in trunk and in the 1.4 branch.
Because all new development was done in trunk, until the 1.6 branch was created people were unable to get access to the new features and functionality. This isn’t to say the new functionality wasn’t available, but with all the changes that can happen in trunk, running a production server based on it requires a very Asterisk-savvy (and C code–savvy) administrator.
To try to relieve the pressure on administrators, and to enable faster access to new features (in the time frame of months, and not years), a new methodology was created. Branches in 1.6 would actually be marked as 1.6.0, 1.6.1, 1.6.2, etc., with the third number increasing by one each time a new feature release was created. The goal was to provide new feature releases every 3–4 months (which would be branched from trunk), providing a shorter and clearer upgrade path for administrators. If you needed a new feature, you’d only have to wait a few months and could then upgrade to the next branch.
Tags from these branches look like this:
1.6.0.1 -- 1.6.0.2 -- 1.6.0.3 -- 1.6.0.4 -- etc.
1.6.1.1 -- 1.6.1.2 -- 1.6.1.3 -- 1.6.1.4 -- etc.
1.6.2.1 -- 1.6.2.2 -- 1.6.2.3 -- 1.6.2.4 -- etc.
Figure 2.2, “The Asterisk 1.6.x release process” gives a visual representation of the branching and tagging process in relation to Asterisk trunk.
Figure 2.2. The Asterisk 1.6.x release process
So, so far we have branches, which are 1.2, 1.4, 1.6.0, 1.6.1, and 1.6.2 (there is no 1.6 branch). Within each of those branches, we create tags (releases), which look like 1.2.14, 1.4.30, 1.6.0.12, 1.6.1.12, and 1.6.2.15.
Unfortunately, it ended up not working out that 1.6.x branches were created from trunk every 3–4 months: the development process has led to a minimum release time of 6–8 months. Not only that, but the 1.6.x numbering methodology adds problems of its own. People got confused as to what version to run, and that the 1.6.0, 1.6.1, and 1.6.2 branches were all separate major version upgrades. When you increase the number from 1.2 to 1.4, and then to 1.8, it is obvious that those are distinct branches and major version changes. With 1.6.0, 1.6.1, and 1.6.2, it is less obvious.
The New Release Methodology
The development team learned a lot of things during the 1.6.x releases. The idea surrounding the releases was noble, but the implementation ended up being flawed when put into real use. So, with Asterisk 1.8, the methodology has changed again, and will look a lot more like that used in the 1.2 and 1.4 releases.
While the development team still wants to provide access to new features and core changes on a more regular basis (every 12 months being the goal), there is recognition that it is also good to provide long-term support to a stable, popular version of Asterisk. You can think of the Asterisk 1.4 branch as being a long-term support (LTS) version. The 1.6.0, 1.6.1, and 1.6.2 branches can be thought of as feature releases that continue to receive bug fixes after release, but are supported for a shorter period of time (about a year). The new LTS version is Asterisk 1.8 (what this book is based on); it will receive bug fixes for four years and an additional year of security releases after that, providing five years of support from the Digium development team.
During the long-term support phase of Asterisk 1.8, additional branches will be created on a semi-regular basis as feature releases. These will be tagged as versions 1.10, 1.12, and 1.14, respectively. Each of these branches will receive bug fixes for a period of one year, and security releases will continue to be made for an additional year before the branches are marked as EOL.
The current statuses of all Asterisk branches, their release dates, when they will go into security release–only mode, and when they will reach EOL status are all documented on the Asterisk wiki at https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.
Conclusion
Asterisk is composed of many different technologies, most of which are complicated in their own right. As such, the understanding of Asterisk architecture can be overwhelming. Still, the reality is that Asterisk is well-designed for what it does and, in our opinion, has achieved remarkable balance between flexibility and complexity.
[12] To be fair, many traditional PBXs do offer this sort of functionality. However, it is generally kludgy, limited in features, and requires complex, proprietary software to be installed in the PBX (such as vendor-specific protocol extensions).
[13] More information about what codecs are and how they work is available in the section called “Codecs”.
[14] It is partly for this reason that we do not recommend the default GSM format for system recordings. WAV recordings will sound better and use less CPU.
[15] Some codecs can impose a significant load on the CPU, such that a system that could support several hundred channels without transcoding might only be able to handle a few dozen when transcoding is in use.
[16] Not call detail records (CDRs), but rather audio recordings of
calls generated by the MixMonitor() and related
applications.
| Chapter 1 | Asterisk™: The Definitive GuideChapter 2. Asterisk Architecture | Chapter 3 |
View 1 comment
