First things first, we’ll assume you’ve got a fresh CentOS 5.6 installed with the basest of options – i.e a 1 disc install. This is how I do it, because this will prevent the installer from installing any extra services or modules that you don’t need on an Asterisk box. The first thing you’ll want to do is update your existing system:

yum update

Next we’ll disable SELinux – I’ve never had this do anything good for me on an Asterisk box. Use your favorite editor, open the file /etc/selinux/config and change the option SELINUX= to ‘disabled’.

vi /etc/selinux/config

SELINUX=disabled

After you make this change to SELinux, you’ll need to reboot. This will also give any new kernels that may have been updated with your ‘yum update’ command a chance to be started.

shutdown -r now

Next, we’ll install the needed dependencies to get a minimal install of asterisk running. This is the bare minimum needed to get a working asterisk install. It does not cover any extra modules or any of the new features of Asterisk 1.8. We’ll cover the steps needed to get those installed in a later post.

yum install wget gcc gcc-c++ make perl libxml2-devel ncurses-devel newt-devel openssl-devel kernel-devel

This should download and install several programs and additional dependencies needed to make these programs work. While not needed for the barest of asterisk installs, I am including kernel-devel so that we can install DAHDI, which, even if you don’t have a TDM card installed in your machine, still provides the best timer option for asterisk.

Next, we’ll move on to downloading and installing the actual code needed to make asterisk run. While there are pre-compiled binaries available for asterisk, and asterisk-specific repositories available for yum, I prefer to install asterisk from source. This gives you complete control over the modules you want installed, and allows you to go back and add in any extra modules or customized (or even patched) code you may want at a later date.

First, I always make a specific asterisk directory under /usr/src, that way I know where all of my asterisk related source code files are. Then we’ll download the necessary source code from the asterisk.org download site and extract it.

mkdir /usr/src/asterisk
cd /usr/src/asterisk
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-1.8-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4-current.tar.gz
tar zxvf libpri-1.4-current.tar.gz
tar zxvf dahdi-linux-complete-current.tar.gz
tar zxvf asterisk-1.8-current.tar.gz

First, we’ll install LibPRI and DAHDI. If you don’t have a PRI card installed, don’t worry, installing LibPRI won’t hurt anything. Also, DAHDI is needed if you’ve got any kind of TDM card installed in your system, but even if you don’t, DAHDI still provides a great timing source and is required if you want to use the MeetMe() conference application. In this tutorial I’ll assume we don’t have a TDM card and we’re just using DAHDI as a timing source.

cd /usr/src/asterisk/libpri-1.4.11.5
make
make install
cd /usr/src/asterisk/dahdi-linux-complete-2.4.1.2+2.4.1
make all
make install
make config

Once you’ve got these installed, you’ll need to edit the config files for DAHDI for optimal performance. You’ll find the necessary config files in the directory /etc/dahdi/, and the specific files you’ll want to look through and possibly modify are:

/etc/dahdi/modules
/etc/dahdi/system.conf

Go through the modules file and comment out any hardware you don’t have, to make the DAHDI service load time faster. In our case of no modules, we comment out every option. This will force the system to only load DAHDI for timing purposes.

If you’ve actually got a hardware TDM card installed in the system, the quickest way to get a working system.conf file is to run the command ‘dahdi_genconf’. This will probe your installed hardware and generate a system.conf that applies to your specific hardware. You can then go in and make any carrier specific modifications you may need.

Next, we’ll install asterisk itself. There are a few more steps involved here than in the previous programs we loaded, but the reward is more control over what goes into your asterisk install.

cd /usr/src/asterisk/asterisk-1.8.4
./configure
make menuselect

On this screen, you’ll want to go through and make some specific changes. First, you’ll want to disable the chan_mgcp Channel Driver. This is because it works best with a package we haven’t installed, and unless you specifically need to support MGCP phones, unchecking this won’t hurt your install any. Also, for maximum compatibility, I would recommend using the -WAV version of any sound files you may select. If you’ve got the bandwidth and the space on your machine, I would also recommend downloading any codec-specific versions of the sound files you plan on using. You may also want to disable any non-dahdi timing source in the Resource Modules section (look for res_timing_ and uncheck any that aren’t res_timing_dahdi).

Now that we’ve got everything we need selected, tab your way over to the ‘Save & Exit’ button and we’ll move on to the next steps, compiling and installing. These steps will take some time (up to five-ten minutes, depending on your system and the number of cores you have installed), so sit back and relax.

make
make install

Now that we’ve got the asterisk core installed, let’s install the sample configuration files and system init files. You can skip this step if you’ve got an existing asterisk install and you were just upgrading, but for clean installs, this step is almost necessary.

make samples
make config

Next, we’ll test our Asterisk install by launching Asterisk from the command line and reviewing the resulting logs that are displayed on-screen for any errors.

service dahdi start
asterisk -cvvvv

If everything looks good, go ahead and exit out of our Asterisk test environment (using the asterisk command “core stop now”).

And finally let’s enable DAHDI and Asterisk to start at system boot time.

chkconfig dahdi on
chkconfig asterisk on

Now either reboot your system or just simply start asterisk using the command ‘service asterisk start’, and away you go! If you come up with any compile-time errors or run-time errors, or just plain have any questions, please feel free to post them in the comments below and I’ll do my best to try and answer them quickly!

I realize it’s been a long time since my last post, and I apologize for that. But I’m setting a schedule for myself, and I’ve already got a few topics planned. If there’s anything you’d like me to cover, please feel free to leave me a comment on this post, or send me an email.

Also, SelbyTech has gone social! We are now on Twitter and Facebook, and as always, we have RSS feeds to keep you up to date on the latest happenings around here!

First things first, I want to point out, if you’re not careful when you’re setting up your iptables settings, there’s a very real possibility of blocking all remote access to your server.  If you’re working on your server remotely, be very careful, and be sure to read all of this article before proceeding!

First, let’s make sure we’ve already got iptables installed on our box.  It should be installed by default on most CentOS 4.x and 5.x installs.

# rpm -q iptables
iptables-1.3.5-5.3.el5_4.1

# lsmod | grep ip_tables
ip_tables              17029  1 iptable_filter
x_tables               17349  5 xt_state,ip_tables,ip6t_REJECT,xt_tcpudp,ip6_tables

With that out of the way, we can look at how iptables is currently setup, using the “iptables -L” command.  The following should be the default rules on a fresh CentOS 5.4 install.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     esp  --  anywhere             anywhere
ACCEPT     ah   --  anywhere             anywhere
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

If for some reason iptables isn’t running yet, you can enable it by running

# system-config-securitylevel

Now, the defaults are fine and good for defaults, but they aren’t really what we’re looking for.  So at this point we’re going to clear them out, and setup a very basic default set of access rules.  I like to use the basic ruleset from the CentOS wiki, located here.

# iptables -P INPUT ACCEPT
# iptables -F
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT

Let’s take a look at what we did here:

iptables -P INPUT ACCEPT – This sets the default policy on the input chain to ACCEPT, so we don’t lock ourselves out if we’re connected remotely via ssh.

iptables -F – This is the command to flush the current rule set and only use the defaults (which we just set to ACCEPT on inbound connections, which gives us a blank slate to work with without locking us out of our own box).

iptables -A INPUT -i lo -j ACCEPT – This is a simple rule to allow all access from the loopback adapter.  The -A switch means we’re Appending a new rule to the chain.  -i means this rule has to do with all traffic flowing through a network interface (in this case, the lo, or loopback, interface).  -j means to Jump to the ACCEPT action.  A lot of applications expect to be able to talk with the loopback adapter, so be sure to include this rule.

iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT – You should already recognize some parts of this line.  What’s new here is the -m switch, which we use to load a module (in this case, the ‘state’ module). The state module is able to examine the state of a packet and determine if it is NEW, ESTABLISHED or RELATED. NEW refers to incoming packets that are new incoming connections that weren’t initiated by the host system. ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to an already established connection.

iptables -A INPUT -p tcp –dport 22 -j ACCEPT – This rule is a very important rule, at least it’s important if you’re connecting remotely!  This rule is appended to the INPUT chain and says that any packets coming in on the tcp protocol (-p), on port 22 (–dport 22), should be accepted.  Port 22 is of course the default ssh port.  If you’ve changed your ssh port in your sshd_config, you would of course alter this line accordingly.

iptables -P INPUT DROP – Remember our first rule?  When we set the default policy for the INPUT chain to ACCEPT?  This line changes the default policy for the INPUT chain back to DROP, which is what is required if you want to actually block traffic coming into your server.  If you correctly set the previous line to allow ssh traffic, you shouldn’t lock yourself out at this point.

iptables -P FORWARD DROP – This rule is pretty much the same as the previous one, except that we’re setting the default policy for the FORWARD chain, which handles traffic flowing through our system from one interface to another (i.e if you’re using your server as a router, which in this case we’re not).

iptables -P OUTPUT ACCEPT – And finally, this rule allows all traffic to flow outwards from your server.

Now that we’ve got these new rules, we should save them so that they’re applied the next time we restart the iptables service.

# iptables-save

or

# service iptables save

If you want to learn more about iptables and the various switches available to you, I recommend you read the IPTables How-To on the CentOS wiki I linked to earlier.  There’s a lot of useful information there.

Now, if you want to run asterisk on your server that you’ve got protected with IPTables, you’ll need to setup a few specific rules.  Let’s go over those here:

# iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 4000:4999 -j ACCEPT
# iptables -A INPUT -p udp -m udp --dport 4569 -j ACCEPT
# iptables -A INPUT -p tcp -m tcp --dport 5038 -j ACCEPT

Let’s take a look at what we’re doing here:

iptables -A INPUT -p udp -m udp –dport 5060 -j ACCEPT – This rule and the next are needed if you have SIP endpoints or a SIP connection to your ITSP.  UDP port 5060 is the port used for SIP traffic.  If you don’t want to accept SIP traffic from anyone, anywhere, you can further restrict this line by adding source IP addresses or networks with the -s switch:

# iptables -A INPUT -p udp -m udp -s 172.19.240.24 --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp -s 172.23.129.58 --dport 5060 -j ACCEPT
# iptables -A INPUT -p udp -m udp -s 172.36.15.0/24 --dport 5060 -j ACCEPT

iptables -A INPUT -p udp -m udp –dport 10000:20000 -j ACCEPT – This rule goes hand in hand with the previous rule.  This is the rule that allows RTP traffic.  By default, asterisk uses a large range of rtp ports to establish rtp connections, and you have to set a large range of udp ports as well.  If you’re uncomfortable with this idea, you can trim down on the number of ports used for your RTP traffic in asterisk’s /etc/asterisk/rtp.conf file.

# cat /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=10050

# iptables -A INPUT -p udp -m udp --dport 10000:10050 -j ACCEPT

A good rule of thumb is to have 4 ports per concurrent call you plan on having flow through your system, plus 10% for breathing room.  So if you plan on having at most 10 concurrent calls on your system at any time, configure asterisk to use 44 ports (10 calls x 4 ports = 40, 40 * 1.10 = 44).  Be sure the range in your firewall matches the range in your rtp.conf file.

iptables -A INPUT -p udp -m udp –dport 4000:4999 -j ACCEPT – This rule is used to allow udptl traffic, which is a T.38 transport protocol.  If you don’t plan on doing faxing, you can skip this rule.  I don’t have any handy rules of thumb for the number of udptl ports used per T.38 fax, so you may want to leave this rule at it’s default.  You can try changing it down, but until I hear otherwise from the folks at Digium, I’ll leave the defaults as the recommended.

iptables -A INPUT -p udp -m udp –dport 4569 -j ACCEPT – This rule is for IAX2 connections.  IAX2 is another VoIP protocol, much like SIP.  Unlike SIP, it only needs one port open on your firewall for both control traffic and audio / data traffic.  You don’t need to open any ranges of ports to allow multiple concurrent calls using IAX2 either, as it’s all handled through the one port.  If you plan on making any IAX2 connections through your firewall, be sure to open this port.

iptables -A INPUT -p tcp –dport 5038 -j ACCEPT – This rule is to allow connections to the Asterisk Manager Interface, or AMI.  If you’re not accessing AMI remotely, you should leave this rule off your firewall.

Now that you’ve got your rules in place, go ahead and test your system.  If everything seems to be working properly, save your new rules to your iptables config by running one of the following commands:

# iptables-save

or

# service itpables save

And that’s it!  You should be all set now.  If you have any questions, please feel free to leave a comment below.

Next week we’ll cover using Fail2Ban along with IPTables to secure your asterisk server from malicious and costly attacks.

After looking around for a while, I noticed something – there’s some documentation out there, but not a lot, on how to do a fresh install / setup of the latest version of Asterisk (1.6.2) on the latest version of CentOS (5.4). So I thought I’d go ahead and go through the process myself and then post the steps I used. So let’s get started…

First things first, the server. I ordered a new dedicated server from my webhost that was running the latest 32-bit version of CentOS 5.4. I had nothing else installed on it, this was just a base vanilla server install. The first thing I did once I had access to the server was to install the latest versions of all installed software:

# yum update

A lot of guides out there use the -y switch with yum to auto-install whatever is found to be updated. You can do this if you like, however, I personally prefer to have to manually select Yes before I do the updates. That all comes down to personal preference.

Next, we need to install all of Asterisk’s dependencies. These are programs that are required to be installed before you can compile asterisk. This is the list I use, it includes the source compilers, some needed development libraries, as well as some dependencies for various asterisk modules I like to load.

# yum install gcc gcc-c++ make openssl-devel newt-devel ncurses-devel libtermcap-devel libxml2-devel kernel-devel perl curl curl-devel

Also, if you have a PAE-based kernel (like I do), which is becoming more and more common these days, you’ll need to load the PAE kernel headers:

# yum install kernel-PAE-devel

If you’re not sure if you have a PAE kernel, you can check using the “uname -r” command:

# uname -r
2.6.18-164.10.1.el5PAE

Next, we’ll install a MySQL database server to handle our CDR (call detail records) storage, and also to prepare the way for using the Asterisk Realtime Architecture (the ability to store our configuration parameters in a database as opposed to flat files). You can safely skip this step if you feel you’ll never make that transition, but it doesn’t hurt anything to go ahead and get this setup now as opposed to later.

# yum install libtool-ltdl libtool-ltdl-devel unixODBC-devel mysql mysql-devel mysql-server mysql-connector-odbc

Now, we’ve got all of the dependencies installed. It’s time to go ahead and get into the meat of the install. We’ll start by creating a new directory under /usr/src to keep everything nice and tidy. Then we’ll download all of the sources we’re going to need for this install.

# cd /usr/src
# mkdir asterisk
# cd asterisk
# wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.2.0.tar.gz
# wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-addons-1.6.2.0.tar.gz
# wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz
# wget http://downloads.digium.com/pub/libpri/libpri-1.4-current.tar.gz
# tar zxvf asterisk-1.6.2.0.tar.gz
# tar zxvf asterisk-addons-1.6.2.0.tar.gz
# tar zxvf dahdi-linux-complete-current.tar.gz
# tar zxvf libpri-1.4-current.tar.gz

First, we’ll install LibPRI. LibPRI is a library used by TDM cards (T1 / E1 cards, etc). Even if you don’t have one of these cards, it’s safe to install LibPRI – it won’t have any negative effects on your system.

# cd /usr/src/asterisk/libpri-1.4.10.2
# make clean
# make
# make install

Next, we’ll install DAHDI. DAHDI means “Digium Asterisk Hardware Device Interface”, it’s pronounced “Daddy”, and it’s the replacement of the old Zaptel driver stack. DAHDI is the set of linux kernel modules and also a set of tools for interfacing with TDM cards. More importantly, DAHDI provides timing to several asterisk components, such as the MeetMe application as well as Music on Hold. If you don’t have a proper timing source installed, you’ll notice lots of stuttering pauses in any kind of audio playback (Music on Hold, IVR prompts, voicemail greetings) from asterisk. If you don’t have any TDM hardware installed in your server, DAHDI also provides a “dummy” driver that will provide a timing source to asterisk.

Now, starting with Asterisk 1.6.1, Digium introduced new internal timing options that can be used in place of the DAHDI timer, however, these are only available on systems running the latest kernels (2.6.25+) in the case of res_timing_timerfd, or on lightly loaded systems, as is the case with res_timing_pthread. If you would rather use one of these options instead of the DAHDI dummy driver, you may skip this step – just be sure to select one of the above mentioned res_timing resouces when you build asterisk later. IMPORTANT NOTE – if you do have a TDM card installed in your system, you may not skip this step!

# cd /usr/src/asterisk/dahdi-linux-complete-2.2.1-rc2+2.2.1-rc2/
# make all
# make install
# make config

Now that you’ve installed DAHDI, you need to configure it. You do that by editing the following files, based on your situation. The files themselves contain lots of documentation, so I won’t go over that in much detail here, except to say this – if you have no TDM cards and are only installing DAHDI for the dummy timing source, you can comment out every driver referenced in the modules file. I prefer to use vi, you can use whichever editor is your favorite. If you’re new to linux, I would suggest using nano with the -w switch.

# vi /etc/dahdi/modules
# vi /etc/dahdi/system.conf

Now that we’ve got DAHDI configured the way we need for our system, we need to set it to start at boot time, and then we need to start it.

# chkconfig dahdi on
# service dahdi start

Next, let’s setup our MySQL database for CDR storage. I’ll make another post detailing the settings needed for Asterisk Realtime later. Be sure to run the mysql_secure_installation script after you start MySQL in order to set up a root password to protect your SQL databases!

# chkconfig mysqld on
# service mysqld start
# /usr/bin/mysql_secure_installation
# mysql -p

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
CREATE DATABASE `asterisk` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE `asterisk`;

CREATE TABLE IF NOT EXISTS `cdr` (
`recid` mediumint(8) unsigned NOT NULL auto_increment COMMENT 'Record ID',
`calldate` datetime NOT NULL default '0000-00-00 00:00:00',
`clid` varchar(80) NOT NULL default '',
`src` varchar(80) NOT NULL default '',
`dst` varchar(80) NOT NULL default '',
`dcontext` varchar(80) NOT NULL default '',
`channel` varchar(80) NOT NULL default '',
`dstchannel` varchar(80) NOT NULL default '',
`lastapp` varchar(80) NOT NULL default '',
`lastdata` varchar(80) NOT NULL default '',
`duration` int(11) NOT NULL default '0',
`billsec` int(11) NOT NULL default '0',
`disposition` varchar(45) NOT NULL default '',
`amaflags` int(11) NOT NULL default '0',
`accountcode` varchar(20) NOT NULL default '',
`uniqueid` varchar(32) NOT NULL default '',
`userfield` varchar(255) NOT NULL default '',
PRIMARY KEY  (`recid`),
KEY `calldate` (`calldate`),
KEY `dst` (`dst`),
KEY `accountcode` (`accountcode`),
KEY `src` (`src`),
KEY `disposition` (`disposition`),
KEY `uniqueid` (`uniqueid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

CREATE USER 'asterisk'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT FILE ON * . * TO 'asterisk'@'localhost' IDENTIFIED BY 'PASSWORD' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
GRANT INSERT ON `asterisk`.`cdr` TO 'asterisk'@'localhost';

Be sure to set your own password for the asterisk user (where I used ‘PASSWORD’ in the above block).

Now, we’ve got all the prerequisites installed. Let’s install Asterisk!

# cd /usr/src/asterisk/asterisk-1.6.2.0/
# make clean
# ./configure
# make menuselect

This is where you select all of the modules, applications, resource modules, codecs, sound pacakges, etc, that you want installed with Asterisk. Take a little time to go through the new menu system (much improved over the 1.4 branch) and select the options you want. Move through menus using the up and down arrow keys, go to the options pane using tab, move up and down through the options and select items using the enter key, and then when you’re ready to save your selections, tab to the “Save and Exit” button and press enter again. It’s really that simple! After you’ve finished with your selections, move on to the next step:

# make
# make install
# make samples
# make config
# chkconfig asterisk on

Next, we need to verify that asterisk installed correctly. We do this by manually starting asterisk from the command line. If everything starts up and there’s not too many errors or warrnings, we’re good to go:

# asterisk -vvvvc
*CLI> core stop now

Next, we need to install some of the options from the Asterisk-Addons download. Asterisk-addons contains additional applications, channel drivers, and resource modules that are useful for asterisk but not necessary. We’re going to install the mysql cdr addons for asterisk.

# cd /usr/src/asterisk/asterisk-addons-1.6.2.0
# make clean
# ./configure
# make menuselect

At this point, be sure to select at least the following items:

• Applications – app_addon_sql_mysql
• Call Detail Recording – cdr_addon_mysql
• Resource Modules – res_config_mysql

After you’ve got those selected, save and exit. Then proceed with the following steps:

# make
# make install
# make samples

Once we’ve got that done, we need to edit the cdr_mysql.conf file to enter the mysql username and password, database, and table we setup earlier. What’s listed below should be all we need in this file, if there’s anything else in there, either comment it out or delete it.

# vi /etc/asterisk/cdr_mysql.conf
[global]
hostname=localhost
dbname=asterisk
table=cdr
password=PASSWORD
user=asterisk
port=3306
sock=/var/lib/mysql/mysql.sock
userfield=1
loguniqueid=yes

And that’s it! You should read through several of the key configuration files in order to learn what’s changed, and also how to customize Asterisk for your installation. The files to look into would be:

/etc/asterisk/asterisk.conf
/etc/asterisk/extensions.ael
/etc/asterisk/extensions.conf
/etc/asterisk/sip.conf
/etc/asterisk/iax.conf
/etc/asterisk/voicemail.conf
/etc/asterisk/users.conf

If you have any questions or run into any trouble, please feel free to leave a comment and I’ll help out where I can.

First, let’s take a look at the file itself.

ddns-update-style none;

option domain-name "example.com";
option domain-name-servers 10.10.11.254;

default-lease-time 600;
max-lease-time 7200;

authoritative;

log-facility local7;

All of this is really basic stuff, and you can set these settings based on your specific network needs.  This is where it starts getting good:

class "cisco7960"
{
match if substring (option vendor-class-identifier,0,36) = "Cisco IP Phone 7960";
option tftp-server-name "10.10.11.254";
}

Here we’re defining a special class that will receive parameters that override the default.  As you can see, this class is for our Cisco 7960′s, and we’re matching based on the vendor-class-identifier, which is part of the DHCP REQUEST packet that the phone sends out onto the network when it first looks for an address.  More on how to find this information in a minute.

class "cisco7961"
{
match if substring (option vendor-class-identifier,0,36) = "Cisco Systems, Inc. IP Phone CP-7961";
option tftp-server-name "10.10.10.1";
}

This is the vendor-class-identifier string for a Cisco 7961.

class "polycom"
{
match if substring (hardware,0,10) = "1:00:04:f2";
option tftp-server-name "10.10.10.1";
}

Now, we won’t actually use this polycom class for anything in our setup, I just wanted to show how you can also match classes based on the phone’s MAC address, not just the vendor identifier string.

Below, we’ll look at the default settings for any device requesting an IP address on this vlan:

subnet 10.10.10.0 netmask 255.255.254.0 {
option subnet-mask 255.255.254.0;
option routers 10.10.10.1;
option domain-name-servers 10.10.10.1;
option ntp-servers 10.10.10.1;
option time-offset -21600;
allow bootp;
range 10.10.10.50 10.10.10.200;
range dynamic-bootp 10.10.10.201 10.10.10.254;

Now, we’ll add in the pool definitions that will match based on the classes we defined earlier.  This is still a part of the subnet declaration we started in the last section.

pool {
range 10.10.11.25 10.10.11.149;
allow members of "cisco7961";
}
pool {
range 10.10.11.150 10.10.11.225;
allow members of "cisco7960";
}

And lastly, we’ve got static leases for specific phones, based on their MAC addresses.  I realize I wasn’t really talking about how to do this in the current article, but it’s something I always have to look up how to do, so I figured it wouldn’t hurt to add it into the post.

host conf2570 {
hardware ethernet 00:04:f2:e1:cf:a5;
fixed-address 10.10.10.204;
}
host conf2571 {
hardware ethernet 00:04:f2:e1:8d:2e;
fixed-address 10.10.10.209;
}
}

And that’s the end of the file.  Now, I mentioned earlier that I’d explain how to find the vendor-class-identifier string for a new phone as it sends out it’s DHCP REQUEST packets.  Here’s what you need to do.  From the shell on your dhcpd server, run the following command while you’re booting your phone:

root@server [~]# tcpdump -lenv -s 1500 port bootps or port bootpc -i eth1

If you don’t want to flood your screen, you can pipe it to a log file by adding ” > logfile.txt” to the end of the above line.  This is the type of output you should expect to see, I’ve highlighed the important information to watch for:

16:19:44.691011 00:26:0b:5d:0f:48 > 00:22:19:22:db:c6, ethertype IPv4 (0x0800), length 590: (tos 0x60, ttl  64, id 53013, offset 0, flags [none], proto: UDP (17), length: 576) 10.10.11.146.bootpc > 10.10.10.1.bootps: BOOTP/DHCP, Request from 00:26:0b:5d:0f:48, length: 548, xid:0x7ba0, flags: [none]
Client IP: 10.10.11.146
Client Ethernet Address: 00:26:0b:5d:0f:48
Vendor-rfc1048:
DHCP:REQUEST
CID:[ether]00:26:0b:5d:0f:48
HN:"SEP00260B5D0F48"
 VC:"Cisco Systems, Inc. IP Phone CP-7961G^@"
PR:SM+TFTP+NS+DG+DN+T150+AT

You can pull a lot of data from these tcpdumps, and find whatever unique characteristics you want to create your pools.  But these ones I’ve given you should get your started on the right path for now.  If you have any questions, feel free to leave a comment, or you can contact me!

First, you’ll need a SMARTnet license that covers the phone. These cost about US $10.00 from CDW. Be prepared to go round and round with CDW support while they attempt to process your request. It took about two weeks once I purchased my contract to the time it was actually activated with Cisco. You need this license in order to legally download the latest SIP firmware from Cisco’s site.

Once you’ve got everything downloaded, you need to extract the following files into the root folder of your tftp server:

apps41.8-5-2TH1-9.sbn
cnu41.8-5-2TH1-9.sbn
cvm41sip.8-5-2TH1-9.sbn
dsp41.8-5-2TH1-9.sbn
jar41sip.8-5-2TH1-9.sbn
SIP41.8-5-2S.loads
term41.default.loads
term61.default.loads

Next, you’ll need to add two new files to your tftp folder:

XMLDefault.cnf.xml
SEP[_MAC-ADDR_].cnf.xml

I’ve included links to my XMLDefault.cnf.xml file that you can use as well as a sample SEP[_MAC-ADDR_].cnf.xml file that you can use. Remember to replace the [_MAC-ADDR_] with the actual MAC address of your phone (in all caps). In the example file, wherever you see words like _USER_ or _PASSWD_, replace those fields with the actual username or password you’re using from your /etc/asterisk/sip.conf file.

Speaking of that sip.conf file, let’s look at the proper way to configure it for one of these phones. The key issue with these phones and asterisk is that they WILL NOT WORK if you have “nat=yes” anywhere in your sip definition for that phone. This is because the Cisco 79×1 phones send their SIP traffic from a very high source port, however they will only accept responses from port 5060 (or whatever you’ve defined in the .cnf.xml file). Asterisk, however, will try to send it’s responses back on the source port that traffic arrived on if “nat=yes” is set. Instead, be sure to use “nat=no”. Here’s an example from my server:

[_USER_]
type=friend
secret=_PASSWD_
username=_USER_
context=phones
nat=no
canreinvite=no
host=dynamic
callerid="Warren Selby" <_EXT_>
mailbox=_MBOX_

Once you’ve got all the files loaded and ready to go, you need to reconfigure the TFTP server setting on your phone itself. Boot the phone and press your Settings button (the one with the checkmark on it). Go to Network Configuration, and then go to IPv4 Configuration. Scroll down until you find the option “Alternate TFTP” and set this to “Yes” (if your settings are locked, press **# and wait a few seconds to unlock them). Once you’ve changed this to yes, change your TFTP Server 1 setting to the IP address of your TFTP server. Once you’ve validated your settings, click Save, and then exit back to the main Settings menu. You can then reboot your phone by pressing **#** quickly from the settings menu and waiting.

As the phone reboots, you should hold down the # key until the line buttons flash. Once they begin to flash, press 1,2,3,4,5,6,7,8,9,*,0,#, which should make your phone reboot again and check for firmware updates. Allow this process to run on it’s own for about 10-15 minutes. Once it’s successfully been reflashed to the latest SIP firmware, it should attempt to automatically download the SEP[_MAC-ADDR_].cnf.xml file you configured earlier. If everything’s been setup correctly, your phone should register with your server and you’ll be good to go!

Let me know if you have any questions or run into any other issues, leave a comment and I’ll help where I can!

First of all, the Digium folks did a great job this year on gathering speakers, developing content, and they certainly know how to have a good time!  On Wednesday, I mostly stayed on the Cloud track, and other than one presentation that I think was aimed at the wrong audience, I learned quite a few things.  The Xen talk given by Saghul certainly gave me quite a few ideas, including a great idea on virtualized hosted PBX systems.

Wednesday night, I hooked up with the crew from Digium and had a blast!  From celebrating Steve’s birthday at Margaritaville to watching multiple Digium employees (try to) ride a mechanical bull (video coming soon, check back for updates!), these guys know how to have a good time!

Thursday I floated between the Commerce tracks and the Tech Talks.  The Intuit Innovations presentation on the Asterisk cluster they built for the American Army in Iraq was one that seemed to impress everyone in the room.  Entertaining and informative, Dr. Daniel Ali Aman was one of my favorite speakers at the entire event!

All-in-all, I’ve had a great time these past few days.  I’ve made quite a few contacts, picked up a lot of product literature from the exhibition hall, and learned some new things all at the same time.  Thanks Digium for a successful Astricon 2009, and here’s looking forward to Astricon 2010!

I like the new look, what do you think about it?

New look for asterisk.org

First, I decided to install atftpd, an advanced tftp server that could run on multiple interfaces on the same machine. Before you can install atftpd, you need to uninstall the base tftpd that comes with CentOS. Using yum, this is rather simple:

# yum remove tftpd-server

This clears the way for us to install atftpd.

# yum install atftpd-server

Once we’ve got that installed, now we need to configure it. By default, yum installs atftpd-server as an xinetd service (this is why we had to remove the tftpd-server package that comes with CentOS). Open the file /etc/xinetd.d/tftp and replace it’s contents with the following, adjusting the IP address and directories for your purposes, of course:

service tftp
{
disable = no
bind                    = 10.10.11.254
socket_type             = dgram
protocol                = udp
wait                    = yes
user                    = root
server                  = /usr/sbin/in.tftpd
server_args             = --logfile /var/log/atftpd_primary.log /home/tftpboot/primary
per_source              = 11
cps                     = 100 2
flags                   = IPv4
}
service tftp
{
disable = no
bind                    = 10.10.10.1
socket_type             = dgram
protocol                = udp
wait                    = yes
user                    = root
server                  = /usr/sbin/in.tftpd
server_args             = --logfile /var/log/atftpd_secondary.log /home/tftpboot/secondary
per_source              = 11
cps                     = 100 2
flags                   = IPv4
}

Once you’ve got this configured, restart your xinetd server and you’re good to go!

# service xinetd restart

In comes the idea of Virtual Network Interfaces, or assigning multiple IP addresses to the same physical interface. On Windows this is a pretty simple task, you just right-click the network interface, go to properties, go to the TCP/IP properties for your interface and then click Advanced – you’ll be given the option to add additional IP’s on the first screen. On a console-based Linux server, the approach is different, but still rather simple. In my example, the client was running a CentOS 5.3 server, but this will apply across many different Linux variants.

First you need to copy the file /etc/sysconfig/network-scripts/ifconfig-eth0 to /etc/sysconfig/network-scripts/ifconfig-eth0:1.

# cd /etc/sysconfig/network-scripts/
# cp ifconfig-eth0 ifconfig-eth0:1

Next, you need to open the new file (/etc/sysconfig/network-scripts/ifconfig-eth0:1) and change the #FILE, DEVICE, and IPADDR settings:

# File: ifcfg-eth0:1
DEVICE=eth0:1
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.10.11.254
NETMASK=255.255.255.0
BROADCAST=10.10.11.255
NETWORK=10.10.11.0
HWADDR=00:80:48:8A:33:A3

Finally, you’ll need to restart your network service. Don’t worry if you’re doing this remotely, as long as you haven’t changed the settings for your original network file, you’re interface should come back up within a few seconds. Your terminal session may hang while the NIC reloads itself, but after that it will come back just fine.

# service network restart

That’s it!  If you’re consolidating two servers, like I was, you’ll want to make sure you take the old server off the network before you restart your network service or else you’ll have an IP address conflict on your hands, and nobody wants that!