Installing FreeSWITCH is rather straight forward.  I small list of dependencies are required, almost all of which should be available via the update / package manager of the distribution selected for the install.  For the making of this document, and CentOS 5 system was setup.  The systems configuration is based on XML files making the list of required tools to work with FreeSWITCH near non-existent.

First item to take care of prior to beginning the installation is to ensure the system is entirely up to date with current versions of all packages.

yum -y update

Once the system has completed its updates, install the necessary dependencies required by FreeSWITCH.

yum -y install autoconf automake nano libtool gcc-c++ ncurses-devel make expat-devel
yum -y install zlib zlib-devel libjpeg-devel unixODBC-devel openssl-devel
yum -y install gnutls-devel libogg-devel libvorbis-devel curl-devel libtiff-devel

The next step is to download the FreeSWITCH source files and unpack them.

cd /usr/src/
wget http://files.freeswitch.org/freeswitch-1.0.6.tar.gz
tar -xvf freeswitch-1.0.6.tar.gz

Move to the unpacked folder and run the installer’s configuration script.

cd freeswitch-1.0.6
./configure

Once configuration of the installer has started, its break time.  The configuration script took approximately an hour to complete on the 512 MB test system.  After the configuration is complete, run the Makefiles and install.

make
make install

This will complete the install of the FreeSWITCH system binaries. Note the output of the install and its reference to the command ‘make samples‘.  This can be used to generate test configuration files (very handy).  The default location of FreeSWITCH on CentOS systems is /usr/local/freeswitch. Since it is often more convenient to have daemon software registered as a system service in CentOS, it will be done here as well. Move to the folder containing the services scripts, download the script file (or just copy / paste if thats easier) and register the service.

cd /etc/init.d
wget http://minded.ca/files/2010/07/freeswitch
chmod a+x freeswitch

After the script is saved to /etc/init.d/freeswitch and permissions have been changed to allow the file to be executed, the service needs to be registered.

chkconfig --add freeswitch
chkconfig --level 345 freeswitch on

Finally, the service can be started just like any other.

service freeswitch start

Currently the service script for FreeSWITCH starts the service as user ‘root’. If the desire is to run the daemon as a different user, modify the line in the script file (near the top), “FS_USER=${FS_USER-root}“; changing ‘root’ to the user account you wish to run the service as.  This completes the basic installation of the FreeSWITCH software.  Be sure to check the FreeSWITCH wiki for information and examples on configuring the different aspects and features of this excellent software system.

One of the most recent additions to the world of open-source telephony engines is FreeSWITCH.  Originally envisioned as a stable, robust and high-powered switching engine, it has grown through its development to be just that and much more.  Being one of the major players in the open-source telephony landscape, Asterisk has undergone extensive changes since its initial breakout in 1999.  After several years, many developers in the Asterisk community tabled the notion of an Asterisk 2.0 system.  A complete overhaul and re-coding of the Asterisk core was not a well received idea by the greater Asterisk development community and as result the idea was shelved.  With a difference in vision, a small group of developers disengaged from Asterisk development to proceed with a “bottom-up” build of a brand new open-source telephony engine; eventually known as FreeSWITCH.

FreeSWITCH made its debut back in early 2007 and since then has been revised, currently to version 1.0.6.  The most recent version is; by all accounts, one of the most reliable and powerful telephony switching engines available (open-source or not!).  Of the many groups that are testing FreeSWITCH as a replacement for Asterisk (and other popular telephony engines), its most notable advantage is in its raw performance.  Some have touted that a single FreeSWITCH box is capable of replacing a 10-box Asterisk cluster.  With this sort of switching power, FreeSWITCH looks poised to assault the VoIP and switching stages.

The FreeSWITCH engine seemed to gain more and more popularity in 2009 as it moved out of its candidate versions and into official release versions.  Although most that adopted the official release did note its exceptional power and stability, its biggest criticisms remain on the lack of a decent administration GUI and available documentation.  Fast forward a year or so to today; the FreeSWITCH wiki now includes lots of information to assist in setup and configuration, system administrators and developers are posting tips and tricks for use-case issues, and administration GUIs are being developed (most notably FreePBX v3).

With its performance capabilities being tested to extremes and in real implementations, FreeSWITCH is impressing its users at every turn.  Now with other development communities working on its user-ended shortcomings, the FreeSWITCH engine will is setting itself up to be a major player in telephony universe.

Related Links:

http://freeswitch.org

http://ostatic.com/blog/freeswitch-poised-to-shake-up-the-open-source-voip-scene

http://www.zdnet.com/blog/greenfield/open-source-voip-asterisk-or-freeswitch/233

The first version(s) of the module are planned to have very limited and basic functionality.  A new feature request ticket was created in the FreePBX Trac system (Ticket #1032) several years ago and to date does not seem to have been addressed.  Having a need for this functionality ourselves, it seemed prudent to take on this smaller application prior to moving forward with the Cisco phone project.

In accordance with the feature request ticket, the aim of the module is to provide two basic interaction and a viewer.  The interaction being the ability to add a file and to delete a file.  Further planning has already started for expansion of the module to include more extensive file operations and folder control.

TFTP Manager in FreePBX v2.X:

A big thanks to the folks at abeautifulsite.net and to Cory LaViska for creating the very elegant PHP File Tree object used by the viewer.

In addition to addressing the needs of the logged ticket with FreePBX for version 2.X, our TFTP module is being developed for version 3 of FreePBX as well.  We are planning to commit both modules to the FreePBX repository once all functionality is stable.

IMPORTANT: Ensure the TFTP server has been installed with its root folder as /tftpboot.  Provide the webserver write access to the /tftpboot folder as well.

Development of the TFTP Manager module for blue.box (formerly FreePBX v3) has resumed with the initial release of the blue.box software from 2600hz.org.

One of the more user-facing features of these market topping devices is the ability to apply custom backgrounds.  Granted, the concept is simple and merely aesthetic; but having the option to apply a custom background can provide a sense of personalization to make a piece of technology feel less foreign.  However, this is not about the psychology of implementation choices.  The following contains helpful information and some useful tips on creating custom backgrounds for the Cisco IP Phones.  A free download pack of background samples has been included as well (package includes 8 background images, associated thumbnails, an XML definition file and README instruction file).  Installation follows the same process described below.

NOTE: The 7945, 7965, 7975, 7970, and Communicator have been tested with SIP firmware and are confirmed as able to support this function.

TFTP Folders:

The first step is to prepare the folder structure on the TFTP server that is providing the Cisco IP Phones with their configuration files.  In the root of the TFTP servers directory, create a folder named ‘Desktops’ (case sensitive).  The 7945 and 7965 models will look for their background images and XML file in a sub-folder of Desktops called ‘320×212x12′. The other models (7970, 7975 and Communicator) will look in the ‘320×212x16′ subfolder of Desktops.  All background images, thumbnails and the XML file defining the backgrounds will ball be placed in these sub-folders.

Images:

All background images must be properly sized to avoid distortion during display.  The Cisco IP Phone firmware (SCCP and SIP) will adjust the image to best fit the display and its color depth.  As the folder names suggest, the standard size for background images on the Cisco IP Phones is 320 pixels wide by 212 pixels tall.  The last number in the folder names (12 or 16) is the color depth that the phone supports.  Testing shows that the firmware can adjust the color depth to suit the display.

Thumbnails:

When selecting the background on the phone, a list of thumbnails are presented to choose from.  These thumbnail images must be uploaded as separate image files, again sized properly to avoid display distortion.  The thumbnail size is 80 pixels wide by 53 pixels tall.  As with the full images, the color depth will be adjusted by the phones firmware to suit the display.

XML Definition:

Finally, an XML file is used to define the available backgrounds and associate them with their provided thumbnail images.  The file must be called List.xml (case sensitive).  Fortunately, it is rather straight forward.  Each XML node defines a background and has two properties, one for the background image location and one for the thumbnail image location.  Ensure that the folder name is entered in the XML definitions match the folder name that the XML file and images are placed in.  Here is an example of the XML file:

<CiscoIPPhoneImageList>
     <ImageItem Image="TFTP:Desktops/320x212x16/001-TN.png"
                  URL="TFTP:Desktops/320x212x16/001.png"/>
     <ImageItem Image="TFTP:Desktops/320x212x16/002-TN.png"
                  URL="TFTP:Desktops/320x212x16/002.png"/>
</CiscoIPPhoneImageList>

In each node, the Image property specifies the TFTP location of the thumbnail image and the URL property specifies the full background image.  The location of the XML file does not need to be specified in the configuration file, the phones will locate List.xml if it exists within the phones supported background folder (along with the images).

After placing all files in the correct folders and upload the folders to the TFTP server with the phone configuration files, the phones will be able to access the newly added backgrounds.  No reset is required as the List.xml file gets pulled each time the background switching options are selected by the user.

Background Images Gallery:

Another beneficial feature that the Smoothwall OS offers is the ability to monitor several aspects of network use from many network locations.  This sort of information can be of great use to networking techs for things like traffic optimization and determining system availability requirements.  With this in mind, the initial version of the Smoothwall object being planned will be centered on statistics collection.

This coding project is being designed with public release in mind.  It can be expected to be seen on our website in the coming weeks.

One of the next major steps in the development will be the ability to upload new service scripts into the module rather than by manual upload.  As mentioned in the previous post on this project, we are looking to have a user portal; hopefully integrated with FreePBX v3 that will allow users to change their passwords.  Currently the system does support multi-phone login to a single user profile.  A remote logout function to remove a phones attachment to a user profile through the portal is also being planned.

Here is an example service that was built by Minded for keeping an eye on email as well as weather conditions, both current and future.  The email information used to check for messages and the location to look up weather for are both supplied by the profile that the phone is currently logged into.
(we are aware of the crappy purple background, this is just the default background color for the ‘Services’ panels on the Communicator. Its honestly entirely Cisco’s fault! I swear.)

In setting up the module to be able to handle the various XML Services that could be used, we’ve also run into the idea of including support for directory XML objects as well.  At this point in the project the directories can be handled as if they were an XML services although the option has been tabled to add more specific support for directories and advanced organization of them.  Add a module for the directories support is also a possibility.

For the creation of this guide, an AsteriskNOW v1.5 turn-key installation server system was used. This makes use of the Asterisk 1.4 server as its backend. Installation of all major and required components is included as well as a common web interface for administering the system, FreePBX. The local extensions for any given server are all basic SIP device connections with no special configurations.

As with most system implementations, a design will be required as a starting point. When determining the layout of the VoIP network to be constructed, it is often suggested that a dial plan be considered as well. A conscious dial plan design will make the rest of the implementation much easier. The most common that results is that each physical location will end up with distinct extension subsets (e.g. Location A get extension 3XXX, Location B gets extensions 4XXX, and Location C gets extensions 5XXX). Maintaining inter-server dial patterns is much easier with this sort of design, although it is not required. This guide assumes the layout of the VoIP network will be configured as follows:

Master Server:

Hostname: master.voip.domain.ext
Extensions: 2XXX

Slave 1:

Hostname: slave01.voip.domain.ext
Extensions: 3XXX

Slave 2:

Hostname: slave02.voip.domain.ext
Extensions: 4XXX

The reasons for organizing any particular VoIP network in any particular way will usually be simply the preference of the person(s) that are building the system. The more organized and structured things are, the less difficult they will be to maintain later.

The first step is to setup all 3 servers for individual use. All 3 servers need to function independently. Completely install the Asterisk server system on each machine, and then ensure it is able to add an extension or 2 and make calls internally between extensions. Don’t forget the extension layout and dial plan that was created earlier. Its also a good idea to test that each server can connect to an external DID provider and make calls to an external phone network. If a DID provider is not available it is not absolutely to test this at this point on all servers as only the master server will require this type of connection.

Once all three machines have been configured as stand-alone servers, we are able to setup the trunk connections between the servers.  All of the servers in the network will require knowledge of each other in order to direct calls to the correct location(s).

Trunks on master.voip.domain.ext in iax_custom.conf:

register => master:IAXpa$$@slave01.voip.domain.ext
register => master:IAXpa$$@slave02.voip.domain.ext

[slave1] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

[slave2] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

Trunks on slave01.voip.domain.ext in iax_custom.conf:

register => slave1:IAXpa$$@master.voip.domain.ext
register => slave1:IAXpa$$@slave02.voip.domain.ext

[master] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

[slave2] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

Trunks on slave02.voip.domain.ext in iax_custom.conf:

register => slave2:IAXpa$$@master.voip.domain.ext
register => slave2:IAXpa$$@slave01.voip.domain.ext

[master] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

[slave1] ; peer name
type=friend
host=dynamic
trunk=yes
nat=yes
secret=IAXpa$$
context=from-internal

This trunking setup provides every asterisk server with direct knowledge of every other server within the network.  Save these settings in each server and reload asterisk on each server to have all the trunk connections established.  This can be verified by typing ‘iax2 show peers‘ into the asterisk CLI.  Once the trunks have been established, dial patterns need to be added to direct calls from one location to another where appropriate.

As indicated before, this example will assume that all extensions on master.voip.domain.ext are in the 2XXX range, slave01.voip.domain.ext in the 3XXX range, and slave02.voip.domain.ext in the 4XXX range.

Dial patterns on master.voip.domain.ext in extensions_custom.conf:

exten => _3XXX,1,Dial(IAX2/slave1/${EXTEN})
exten => _4XXX,1,Dial(IAX2/slave2/${EXTEN})

Dial patterns on slave01.voip.domain.ext in extensions_custom.conf:

exten => _2XXX,1,Dial(IAX2/master/${EXTEN})
exten => _4XXX,1,Dial(IAX2/slave2/${EXTEN})

Dial patterns on slave02.voip.domain.ext in extensions_custom.conf:

exten => _2XXX,1,Dial(IAX2/master/${EXTEN})
exten => _3XXX,1,Dial(IAX2/slave1/${EXTEN})

After adding the dial patterns and reloading the asterisk servers one last time, calling an extension on any server from any other server should no complete the call.

Lastly, a few notes about this type of setup.  The IAX2 trunks are bi-directional and make use of the “friend” type instead of the “user/peer” model.  This was chosen due to simplicity of setup and troubleshooting.  The trunks are all entered with the option ‘nat=yes’, this is not required if all servers are on the same LAN.  Also, all servers within the network deliver calls to each other from the ‘from-internal’ context.  This allows each server to treat calls from other servers as if they come from an internal extension.  If necessary this can be changed in the trunk settings, however, a dialing macro will be needed to accommodate the change.  Finally, in the configuration explained here, only server-to-server calling has been setup.  Removing the common “_9|.” dial pattern (for outbounds calls) and adding one for “_9.” (no ‘|’)  that directs the slave server to Dial(IAX2/master/${EXTEN}) will redirect outbound calls to the master server without removing the leading 9.  Maintaining the leading 9 will direct the master server to place the call as an outbound call.

This lead us to our next development project.  We are currently working on creating FreePBX modules for administration of extended Cisco IP Phone functionality.  Our starting point has been the XML services that can be used by these phones and integrating them with customized user profiles.  Currently the module will contain two components, ‘User Profiles’ and ‘XML Services’.

The ‘User Profiles’ module will be for exactly what everyone things, managing user profiles and their associated customizations.  These user profiles can be expanded to include other data for custom services and more advanced functionality.  Here are a couple screenshots of the ‘User Profiles’ component:

Show User Profiles:

Add User Profile:

Also included in this module is the ‘XML Services’ component.  Again, as expected this part of the module will allow for administration of installed Cisco XML Service scripts.  Service scripts are added to the “services” folder in the module on the server.  Once added to the server, the service can be added and filename of the service specified.  Once added, services can be previewed as they would appear on the Cisco IP Phone screens as well.  Here are some screenshots of the ‘XML Services’ component:

Show XML Services:

Add XML Service:

*NOTE*:  Announcements about FreePBX v3 have indicated that it will have a user portal as well as an administration portal.  With this in mind we will look to make our module(s) FreePBX v3 compatible, incorporating user-level profile management and other extended customization of XML services used.

The services are built by directing the phones to any of a number of predefined XML objects.  The objects have a wide range of abilities from regular text display to masked input fields all the way to image display.  Furthermore, the XML object creation is no limited to static XML files.  The resulting power lies in the ability to call scripts that dynamically generate Cisco ‘friendly’ XML objects.  Additionally, the phones provide unique headers as part of their HTTP requests that contain information specific to the phone making the call.  This includes information such as the phone model and screen size.  As sent by the phones, these unique headers will be as follows (according to current Cisco documentation):

• x-CiscoIPPhoneModelName
• x-CiscoIPPhoneDisplay
• x-CiscoIPPhoneSDKVersion

Many scripting languages may modify these for accessibility.  A commonly seen example of this is PHP, where the headers are accepted into the global $_SERVER array variable.  Each header is put into all uppercase letters and an ‘HTTP_’ prefix is added to specify that they were sent with the HTTP headers.

The model names provided by the phones will be the Cisco model information, similar to format of ‘CP-7960G’.  Some models are capable of functionality that other models are not.  This may be useful to the programmer, although this header is more commonly used for determining if the request came from a Cisco IP Phone or not simply by its presence.

A very useful header to most programmers of Cisco XML services will be the x-CiscoIPPhoneDisplay header.  This header includes 4 pieces of information about the phones display, all comma seperated.  The first two numbers are the width and height of the available screen size in pixels.  The high resolution color screen Cisco phones usually have a size around 298×156.  The 3rd number provided is the color depth available.  The color displays will have a depth of either 12 or 16 depending on the model.  Lastly, a ‘C’ or ‘G’ is given to indicate a Color or Greyscale display.  With image displays being one of the most useful display services available, this information can be invaluable to the image creation script(s).

Last in the list of transmitted headers is the SDK Version.  As indicated before, the functionality available to a phone can be determined by its model name, however a more robust and effective way to determine this is with the SDK Version.  It is possible that newer firmwares for any particular phone will support a different version of the SDK.  As a result, the SDK version is a better determining factor for supported functionality.

As with most application development, it is important to check the Cisco IP Phone documentation that is available on their website.  A complete list of usable XML service objects can be found there.  In addition, many extra useful features are explained including items like customized softkeys, internal URI functions and more.

Here are some freely available Cisco XML services provided by Minded:   (services will redirect browser requests)

• Simple Web Browser: http://minded.ca/cisco/browser.php

**NOTE**: We are currently looking for suggestions on XML services to create and make available to the public where possible.  Please comment with your suggestions!

This service relies on the destination locations being capable of both detecting a Cisco IP Phone request and serving Cisco XML objects in response to these requests.  Detection of a Cisco IP Phone request via HTTP can be easily done by either the user agent of the request or by analyzing the incoming header information.  The phones make use of the ‘Allegro‘ user agent as well as sending unique Cisco HTTP headers.  The headers all begin with x-CiscoIPPhone_____. The three that noted in the Cisco documentation are the x-CiscoIPPhoneModelName, x-CiscoIPPhoneDisplay, and x-CiscoIPPhoneSDKVersion.  Creation of an XML object to respond with will depend on the nature of the site and the content it will serve the phone(s).

The browser will accept a single query string variable, url.  Specifying a url variable in the query string will forward the phone to ‘http://’+url.  No specification will bring up the “URL:” prompt and request an address to go to from the user in ASCII format.

To add this service to your Cisco IP Phone, add the following code to your services menu XML file:

<MenuItem>
   <Name>Web Browser</Name>
   <URL>http://minded.ca/cisco/browser.php</URL>
 </MenuItem>

Or add a ‘Services’ function line with the following URL:

http://minded.ca/cisco/browser.php