CounterPath’s X-Lite softphone has become very popular with the Asterisk commun-ity. It is simple, functional, easy on the eyes, and—most importantly—free.
In this section we will be configuring the X-Lite softphone to connect to Asterisk.
The IP address of the phone is 192.168.1.250, and Asterisk is located at 192.168.1.100.
The X-Lite is available for Microsoft Windows, Mac, and Linux. You can obtain a copy of X-Lite from http://www.counterpath.com/index.php?menu=download.
Now let’s configure our softphone for connecting to our Asterisk box. To configure X-Lite, click on the Settings button, as circled in Figure 4-2.
Select System Settings → SIP Proxy → [Default], which will display the default configu-ration for the softphone. Configure the screen as shown in Figure 4-3.
If you have not already started Asterisk, then start it now (see Chapter 3 for help in-stalling and starting Asterisk). If Asterisk is running in the background, you can reconnect to the CLI by running the following command:
# asterisk -rvvv
‡You can get into assigning complex and unguessable passwords for the phones to use, but unless you are going to input the passwords into each phone manually, you’ll have to pass them their FTP username and password from the DHCP server. Any device that can get on the voice network can get the same information from the DHCP server. We’re not telling you to ignore security; just don’t assume that creating separate passwords for each phone is going to improve security.
Configuring SIP Telephones | 87
You will then be given the Asterisk CLI like so:
*CLI>
If Asterisk was already running before changing the sip.conf as instructed in this chapter, then reload the dialplan and SIP channel with the following two commands:
Settings button
Figure 4-2. X-Lite configuration
Figure 4-3. X-Lite user configuration
*CLI> dialplan reload
*CLI> sip reload
In your X-Lite softphone client, close the Settings windows by clicking the BACK button until the windows are all closed. You should see X-Lite try to register to Asterisk, and if successful, you will see the following at the Asterisk CLI:
-- Registered SIP '1000' at 192.168.1.250 port 5061 expires 3600
You can verify the registration status at any time like so:
*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status 1000/1000 192.168.1.250 D N 5061 OK (63 ms) 1 sip peers [1 online , 0 offline]
More detailed stats of the peer can be shown as follows with sip show peer 1000:
*CLI> sip show peer 1000
* Name : 1000 Secret : <Not set>
MD5Secret : <Not set>
Context : phones Subscr.Cont. : <Not set>
Language : AMA flags : Unknown Transfer mode: open
CallingPres : Presentation Allowed, Not Screened Callgroup :
Pickupgroup : Mailbox : VM Extension : asterisk LastMsgsSent : 32767/65535
ToHost :
Addr->IP : 192.168.1.250 Port 5061 Defaddr->IP : 0.0.0.0 Port 5060 Def. Username: 1000
SIP Options : (none)
Codecs : 0x8000e (gsm|ulaw|alaw|h263) Codec Order : (none)
Auto-Framing: No Status : Unmonitored
Useragent : X-Lite release 1105d Reg. Contact : sip:1000@192.168.1.250:5061
Polycom’s IP 430
A lot of folks say configuring Polycom phones is difficult. From what we can tell, they base this on one of two reasons: 1) The Polycom web-based interface is horrible, or 2) the automatic provisioning process is painful and confusing.
With respect to item 1, we agree. The web interface on the Polycom phones has got to be one of the most annoying web interfaces ever developed for an IP telephone. We don’t use it, and we don’t recommend it.§
So that leaves us with some sort of server-based configuration. Fortunately, in this regard, the Polycom IP phones are superb—so much so that we can pretty much forgive the web interface. Set configurations are stored in files on a server, and each set navigates to the server, downloads the configuration files that are relevant to it, and applies them to itself.
DHCP server
If you cannot control your DHCP server, you may have to manually specify the FTP server information on the phone. This is done by rebooting the set, pressing the setup button before the set begins the load process, and specifying the address of the FTP server in the small boot menu that these phones offer.
Protocol to use for downloading
The Polycom phones are able to download their configuration by one of three proto-cols: TFTP, HTTP, and FTP.
Right off the bat we are going to tell you to avoid TFTP. It is not secure, and the set cannot use date information to determine which versions of various files are the most current. It works, but there are better ways, and we are not going to discuss it further.
Polycom phones can pull their config data using HTTP as well, but it has not proven to be popular, and so we are going to move on.
§Actually, it does serve one useful purpose, which is to allow you to log on to a set via a browser and query its configuration.
FTP is currently the preferred method of allowing Polycom phones to obtain their configuration. It works well, is fairly easy to configure, and is well supported by the community.
FTP
FTP is currently our favorite way to configure Polycom sets. To install it on your CentOS system, the following command will install VSFTPD, the Very Secure FTP Daemon:
# yum -y install vsftpd
Then, in order to lock things down, we need to prevent anonymous logins, with a simple change to the vsftpd config file, /etc/vsftpd/vsftpd.conf:
# anonymous_enable=NO
Restart the server with service vsftpd restart. To ensure that the daemon runs after every reboot, run chkconfig vsftpd on.
Now, we have to create a user account and group for the Polycom sets to use:
# groupadd PlcmSpIp
# useradd PlcmSpIp -g PlcmSpIp -p PlcmSpIp
# passwd PlcmSpIp
Set the password to PlcmSpIp (the default FTP password for Polycom sets). This can be changed, but will then require manual configuration from each set in order to advise them of their nonstandard credentials.‖
For added security, let’s make sure the FTP server keeps that account in a chroot jail:
# echo PlcmSpIp >> /etc/vsftpd/vsftpd.chroot_list
That pretty much does it as far as preparing the operating system to provide the required services to the phones.
The Polycom configuration files
While there seem to be a lot of different files that are needed to make a Polycom set work, they are each fairly easy to understand.
This can best be described as the BIOS and operating system of the phone.
Perhaps there is a more technical explanation, but why make things confusing? The bootROM should not need to be updated regularly, but it is good to keep an eye on the current releases to see if a newer bootROM has features that will be of benefit in your environment. This file will be named bootrom.ld.
The bootROM.
‖You can get into assigning complex and unguessable passwords for the phones to use, but unless you are going to input the passwords into each phone manually, you’ll have to pass them their FTP user name and password from the DHCP server. Any device that can get on the voice network can get the same information from the DHCP server. We’re not telling you to ignore security, just don’t assume that creating separate passwords for each phone is going to improve security.
Configuring SIP Telephones | 91
Since Polycom sets are capable of supporting other VoIP protocols (MGCP is supported, for example), the protocol that this set will employ forms part of the application image that the phone will download and run. If the image on the set is already correct, this file is not actually needed on the FTP server; however, it is common to have this file available to ensure that the most recent version of the protocol is avail-able for the sets to download. You will sometimes receive phones that are not running the latest version, so having the most current image will ensure that all sets are up-to-date.
There is normally only one version of this file on a system, but it can be named anything you want, and there can be as many different versions of this file as are needed. For example, if you had an office where there were two different languages in use, some users might prefer French on their set, and others English. In that case, you’d create a french.sip.conf file and an english.sip.conf file to handle each case. Name this file as you see fit, but pick a name that makes sense so that future administrators have a chance to make sense of your design choices.
This file is very simple and small. It is named to match the MAC address of each phone (so each set will need its own copy of this file) and tells the set what other files it needs to download in order to configure itself. This is the first config file each set will read. In this file will be a reference to the application image this set will use (currently named sip.ld), as well as the names of the XML files that have the parameters for this phone (the .cfg files). A master config file for a set might look some-thing like this:
'<?xml version="1.0" standalone="yes"?>' '<!-- Default Master SIP Configuration File-->'
'<!-- Edit and rename this file to <Ethernet-address>.cfg for each phone.-->' '<!-- $Revision: 1.14 $ $Date: 2005/07/27 18:43:30 $ -->'
'<APPLICATION APP_FILE_PATH="sip.ld"
Note the name of the application file that we want this set to use, and the config files that it will be trying to find and apply.
We recommend giving the phone1.cfg files names that make sense. For example, SET<xxx>.cfg (such as SET201.cfg) to match the extension num-ber of the phone, or FLOOR4CUBE23.cfg, or maybe BOB_SMITHS_IP430_SET.cfg, or whatever seems best to you. What’s the best way to name them? We’re going to answer that question by asking a question. Let’s say you have 100 of these phones.
When you list the contents of the /home/PlcmSpIp folder, how do you want the 100 config files for the sets to appear?
The application image.
The sip.cfg file.
The master config file for each phone.
The set-specific config file.
Settings that are configured directly on the telephone will be stored on the filesystem of the set, and may take precedence over parameters passed in config files.
If you are having any problems applying changes to a set, try reformatting the phone.
This will force the set to accept the parameters contained in the config files.