Abstract
We present a fixed-point algorithm for reducing a large set of configuration lines to a minimal working configuration. A minimal working configuration is the smallest set of configuration lines that allow an application to provide a predefined level of service. We apply our algorithm to the Asterisk voice-over-IP server using a baseline of one SIP and one analog phone connection. Using the algorithm, we are able to reduce a configuration with more than eighty files and 12, 000 lines of configuration to a simpler system containing only four files and fifty-six lines. The algorithm finds a local minimum configuration which, in practice, is usually the smallest working configuration set. Reducing the number of lines of configuration makes teaching and training easier and also makes it easier to customize a server to provide exactly the desired functionality without introducing security flaws.
Introduction
Asterisk is an open source telephony platform, originally designed for the Linux operating system; “It allows different types of IP telephony hardware, middleware, and software to interface with each other consistently” [1]. Asterisk, like many phone systems, can be customized to provide an enormous number of capabilities and functions such as voicemail, hosted conferencing, call queuing, music on hold, and call parking [2]. Asterisk provides a plug-in architecture that allows for the development of new features. This means that a programmer can easily write code that interfaces Asterisk with other applications and devices. A default installation of Asterisk enables an enormous number of applications and features. This makes configuring Asterisk an overwhelming task, especially for a new system administrator. The size and complexity of the configuration files makes it very difficult for the administrator to fully understand which features are enabled or currently in use. This can lead to misconfiguration of the server or security issues. It also makes training or teaching asterisk management extremely difficult.
In this paper, we present a minimal working Asterisk configuration for a network with one SIP channel and one Dahdi channel. A minimal configuration is “a system that has only essential hardware components and contains the smallest assortment of hardware and software components required to carry out a particular data-processing function” [3]. This minimal configuration lowers the barrier for entry-level users and makes it easier to discover which features Asterisk offers. It allows more detailed troubleshooting and customization of the server and allows teachers to describe the essentials of Asterisk without expanding on every feature Asterisk provides.
In addition to providing service to hardware phones, Asterisk supports several voice over IP protocols including SIP/RTP and IAX. SIP (Session Initiation Protocol) is an algorithm which takes care of the setup and tear-down of calls and renegotiation of any lost connections during a call. SIP does not carry media, but relies on RTP (Real-time Transport Protocol) to transfer voice and other data [4]. SIP is often used in VoIP telephony and can be used by either hard or soft phones. A hard phone is a physical device attached to the telephony server. A soft phone is a software program that provides telephone functionality on a non-telephone device, such as a PC or PDA. In our research, we used both a hard phone and a soft phone. IAX (Inter Asterisk eXchange) is an alternative to SIP. Like SIP, IAX is used to set up a connection between two users. IAX was created to minimize bandwidth and add extra security to a VoIP system. IAX is an open-source protocol used by Asterisk servers, but not supported by many other devices. It is also not standardized. For these reasons, we chose to use SIP in our research.
Figure 1: chan_dahdi.conf
[trunkgroups]
[channel]
usecallerid=yes
hidecallerid=no
callwaiting=on
threewaycalling=yes
transfer=yes
echocancel=yes
echotraining=yes
immediate=no
context=internal
signaling=fxo_ks
channel => 1
context=incoming
signaling=fxs_ks
channels => 2
Figure 2 gives the contents of the file “sip.conf”. This file implements a basic configuration for enabling SIP connections from remote hosts. Clients can connect using soft-phone applications such as “Ekiga” or “Twinkle”. Asterisk also provides support for “Skype”, but that requires additional configuration, since Skype uses a proprietary communications protocol.
Figure 2: sip.conf
[general]
context=default
srvlookup=yes
[me1]
type=friend
secret=PASSWORD
qualify=yes
nat=no
host=dynamic
canreinvite=no
context=internal
Figure 2 also provides a graphical illustration of a SIP connection. A call is initiated by the caller, who first talks to a proxy server. The proxy server then passes the invitation to another server connected to the callee’s phone device. Once the callee accepts the invitation, communication takes place directly between the caller and the callee. The conversation is terminated by transmission of a “hangup” or “BYE” message from the caller to the callee.
Figure 3 shows the initial contents of the file “extension.conf” which contains the default dial plan for our installation. The dial plan maps “extensions” to both the hard phone and soft phone and provides access to other features such as voice-mail.
Figure 3: extension.conf
[incoming]
exten => 101,1,Dial(SIP/me1)
This configuration produces the architecture given in Figure 4.
Figure 4: Network Architecture
Testing
Many SIP phones are multi-line phones which can accept multiple incoming calls at the same time. To test our SIP phones we performed the echo test application by dialing 611 and by making calls from the phone to itself. Because SIP phones are multi-line the call will loop back from the Asterisk server and onto line two of the client. After successfully testing the Asterisk network by performing different test calls, we began to disassemble the Asterisk software to find the minimum configuration needed to successfully run a basic Asterisk network. Figure 5 shows the algorithm that we designed to reach a fixed point of operation.
Figure 5: Fixed point algorithm
Let S be a queue initially containing all configuration files.
For each file f at the head of S:
- Remove f from the queue.
- If S-{f} is not a working configuration, add f to the queue’s tail.
Repeat until S reaches a fixed point.
Let L be the set of all configuration lines of any file in S.
For each line l in L:
- If L − {l} is a working configuration, let L = L − {l}.
Repeat until L reaches a fixed point.
The algorithm first breaks down an Asterisk configuration file by file. For each file in the initial configuration, we attempted to remove the file by moving it to a folder outside of the Asterisk configuration directory. Each time we moved a file, we performed a series of tests to ensure that the server provided dial tone and ring tone, and that a connection could be made between the hard phone and the soft phone. If the tests succeeded, the file could be permanently removed from the Asterisk configuration. However, if a test failed, the file would be restored to the configuration directory.
One of the complexities of an Asterisk configuration is that there can be dependencies between configuration files. In order to account for the possibility that removing a subsequent file could enable removal of the current file, we had to process each file multiple times. To do this, we performed several passes over the configuration directory, stopping only when we reached a fixed point (a point where no files could be removed). After arriving at a fixed point with respect to the number of configuration files, the algorithm analyzes the contests of each file. We reduce the size of each file by following a similar fixed point algorithm, but applied to lines of configuration, rather than to files. As before, we commented out a line and performed basic tests. If all tests passed, we would delete the line. If a test failed, we would uncomment the line and continue. As before, we accounted for dependencies by performing passes until a fixed point was reached. This allowed us to find a local minimum consisting of the files and specific lines of configuration needed to run a basic Asterisk network with one SIP and one DAHDI channel.
Figures 6.1 and 6.2 give a less abstract description of our algorithm.
Figure 6.1: Fixed-point algorithm for files
- Move a file from /etc/asterisk to a backup directory
- Restart Asterisk
- Call the DAHDI phone from the SIP phone
- Test for connection, sound from both users, ringing, and dial tone
- Repeat step 4, but with the call direction reversed
- If steps 4 or 5 fail, restore the file to /etc/asterisk.
- Repeat steps 1-5 with the next file in the directory.
- Repeat until no changes are made to the Asterisk configuration directory.
Figure 6.1 illustrates how we reached a fixed point with respect to the necessary files. Figure 6.2 illustrates how we reached a fixed point with respect to lines of configuration.
Figure 6.2: Fixed-point algorithm for lines
- Delete a line of configuration
- Restart Asterisk
- Call DAHDI hard phone from the SIP phone
- Test for connection, sound from both users, ringing, and dial tone
- Repeat step 4, but calling the SIP phone from the DAHDI hard phone
- If steps 4 and 5 fail, return deleted code to the file
- Repeat steps 1-5 for the next line of code
- Repeat until all files have been processed and a fixed point is reached
Data
When Asterisk is first distributed on a Linux system it comes pre-configured with dozens of files and thousands lines of configuration. Figure 7 gives a table describing the size of a standard Asterisk installation on four different distributions of the Linux operating system. The table lists both the number of files in the configuration as well as the total number of lines of configuration from all configuration files.
Figure 7:
The numbers for Arch Linux also reflect the size of a standard installation using the Asterisk source archives.
Using the fixed point algorithm, we are able to reduce the size of the configuration on all four distributions from dozens of files to only four files and the number of configuration lines from thousands to only thirty lines.
The four necessary files were:
- chan_dahdi.conf
- extensions.conf
- modules.conf
- sip.conf
Figure 8 shows the minimal number of lines needed in the “chan_dahdi.conf” file to establish a working configuration with one hard-phone using a DAHDI connection. The file contains only three lines.
Figure 8: chan dahdi.conf
[channels]
[phone-1]
dahdichan = 1
The file “sip.conf” shown in Figure 9 has only six lines. It defines one SIP channel and assigns it a username, password, and context. The context is used in the “extensions.conf” file to map the SIP user account to a dialable extension.
Figure 9: sip.conf
[me1]
type=friend
username=me1
secret=PASSWORD
host=dynamic
context=house
The “extensions.conf” file in figure 10 configures a dial plan for the SIP and Dahdi phones which allows users to call each other and to perform an echo test from each phone. This file has only seventeen lines of configuration, but could be easily extended to define extra features such as voicemail, and conference calling.
Figure 10: extensions.conf
[general]
static=yes
writeprotect=no
[house]
exten => 101,1,Dial(SIP/me1)
exten => 102,1,Dial(dahdi/1)
include => demo
[demo]
exten => 600,1,Playback(demo-echotest)
exten => 600,n,Echo
exten => 600,n,Playback(demo-echodone)
exten => 600,n,Goto(s,1)
[default]
exten => 777,1,Dial(SIP/me1)
include => demo
The file “modules.conf shown in figure 11 controls the loading of the other three configuration files. We were able to reduce this file to only two lines by taking advantage of Asterisk’s “autoload” option, which allows the server to load configuration files on-the-fly as needed.
Figure 11: modules.conf
[modules]
autoload=yes
Conclusion
Finding a minimal configuration is useful not only for allowing new users to easily learn Asterisk, but also for making the configuration file manageable. This greatly improves a system administrator’s ability to debug and optimize Asterisk settings and customize an Asterisk installation for a site’s particular needs. In this work, we described an algorithm for finding a fixed point of configuration which determines the smallest working configuration that provides a given feature set. We found that a minimal installation which provides one SIP and one DAHDI connection requires only four files and thirty lines of configuration.
This work could be extended in several interesting ways. It would be interesting to find minimal configurations for more complex systems with features such as voicemail or a busy signal. We would also like to look at packaging a minimal configuration for distribution and creating a modular system for extending the configuration in small, easy steps.
Bibliography
[1] Nasser, Manesh . “ Asterisk: A Non-Technical Overview.” [Online] Available www.asteriskportal.nl/downloads/asterisk–non–technical-review.pdf
[2]Jim Van Meggelen, Leif Madsen, Jared Smith,Tolman Creek Design, Joe Wizda ,Karen Montgomery, David Futato, Robert Romano, Jessamyn Read. Asterisk™: The Future of Telephony :O’Reilly Publishing, 2005.
[3] McGraw-Hill Companies. “Dictionary.” [Online] Available http://www.accessscience.com/overflow.aspx?searchStr=Computer+system&stype=4&term=Computer+system&rootID=791689&p=7
[4] Asterisk.name. “Asterisk The Open Source VoIP PBX” [Online] Available http://www.asterisk.name/configuring-sip.html