In light of these issues with testing and development, our programming group put together and added the functionality to apply XSLT stylesheets to XML service objects and return the formatted results of the transformation. With this functionality available, an XSLT stylesheet was created to provide an HTML rendering of Cisco XML objects to make them easily viewable in any web browser.

With XML service objects available in a browser-friendly format, testing can be done quickly and easily through workstations. No need to continually re-work Cisco phone configuration files and reset. Also, by transforming the XML objects into more usable markup; additional functionality has been added to help the objects perform similar to when loaded through a Cisco IP Phone. The most notable function of this nature is the basic masking of input fields with JQuery when rendered through the XSLT sytlesheet.

Further modifications and additions are expected to be made to the XSLT stylesheet as the framework grows. These additions and modifications will be made and the file re-uploaded in place. A copy of the most up to date XSLT stylesheet will be kep attached here as long as it is available.

OBJECT CLASSES:

CiscoXMLService

CiscoIPPhoneMenu
CiscoIPPhoneText
CiscoIPPhoneInput
CiscoIPPhoneDirectory
CiscoIPPhoneImageFile
CiscoIPPhoneGraphicFileMenu
CiscoIPPhoneIconFileMenu
CiscoIPPhoneExecute

* NOTE: not all XML objects are included in the framework as they are not yet supported.

FUNCTION REFERENCE:

CiscoXMLService (abstract)

The base class for all Cisco XML service objects. This is an abstract superclass object only and contains global object functionality. Methods available to CiscoXMLService are inherently available to all other Cisco XML service object classes.

• addSoftKey($name, $url, $position)
  Insert a custom softkey for the current service object pointing to $url in at slot $position and with the button titled $name.
• applyXSLT($file)
  Returns the output of the service object after the XSLT stylesheet $file has been applied.
• toXML()
  Returns the formatted XML output of the current service object. All subclasses implement a custom override method for of this and call this parent method to render any associated softkeys to the object.

CiscoIPPhoneMenu

• __construct()
  Creates new instance of CiscoIPPhoneMenu.
• setTitle($title)
  Specify a title for the current menu.
• setPrompt($prompt)
  Add a prompt message to the current menu.
• addItem($name, $url)
  Adds a new menu item to the current menu point to $url and identified by $name.
• toXML()
  Returns formatted XML for the current menu.

CiscoIPPhoneText

• __construct()
  Creates a new instance of CiscoIPPhoneText.
• setTitle($title)
  Specify a title for the current text block.
• setPrompt($prompt)
  Add a prompt message to the current text block.
• setText($text)
  Insert block of ASCII, $text, into the text object.
• toXML()
  Returns formatted XML for the text object.

CiscoIPPhoneInput

• __construct()
  Creates a new isntance of CiscoIPPhoneInput.
• setTitle($title)
  Specify a title for the current input object.
• setPrompt($prompt)
  Add a prompt message to the input object.
• setURL($url)
  Assign $url as the location to pass the information requested by the input object.
• addItem($name, $param, $default = “”, $mask = “A”)
  Insert an input field into the current input object. The new item will be labelled $name and the value passed with the name $param. A default value can be specified by provided $default. An input mask can be applied by providing $mask as well (see Cisco documentation for valid input mask values).
• toXML()
  Returns formatted XML for the input object.

CiscoIPPhoneDirectory

• __construct()
  Creates a new instance of CiscoIPPhoneDirectory.
• setTitle($title)
  Specify a title for the directory object.
• setPrompt($prompt)
  Add a prompt message to the directory object.
• addItem($name, $number)
  Insert a new directory entry identifed by $name and with a telephone number of $number. If directory entry with the same $name and $number already exists, the item will NOT be added.
• toXML()
  Returns formatted XML for the directory object.

CiscoIPPhoneImageFile

• __construct()
  Creates a new instance of CiscoIPPhoneImageFile.
• setTitle($title)
  Specify a title for the image display object.
• setPrompt($prompt)
  Add a prompt message to the image display object.
• setImageURL($url)
  Specify the location, $url, of the image to display.
• setPosition($x, $y)
  Provide a point of origin for the image display. The top-left corner of the image will be anchored to point ($x, $y) on the services display panel.
• toXML()
  Returns formatted XML for the directory object.

CiscoIPPhoneGraphicFileMenu

• __construct()
  Creates a new instance of CiscoIPPhoneGraphicFileMenu.
• setTitle($title)
  Specify a title for the graphical menu object.
• setPrompt($prompt)
  Add a prompt message to the graphical menu object.
• setImageURL($url)
  Specify the location, $url, of the image file to display as the graphical menu.
• setPosition($x, $y)
  Provide a point of origin for the image display. The top-left corner of the image will be anchored to point ($x, $y) on the services display panel.
• addItem($name, $url, $area)
  Add a menu item to the graphical menu object. The $name provided is merely a placeholder and will not be displayed, common practice is to use the title of the current graphical menu object. The menu item will direct the user to $url when selected. The menu item will be selectable by touching the screen area defined by $area, an array of four integers. The first two integers are X1 and Y1; the top left corner of the touch area. The second two integers are X2 and Y2; the bottom right corner of the touch area for the menu item being added.
• toXML()
  Returns formatted XML for the directory object.

CiscoIPPhoneIconFileMenu

• __construct()
  Creates a new instance of CiscoIPPhoneIconFileMenu.
• setTitle($title)
  Specify a title for the icon menu object.
• setPrompt($prompt)
  Add a prompt message to the icon menu object.
• addIcon($url, $index)
  Add an icon item to the icon menu object. The location of the icon image is given by $url. Each icon must also be provided an $index value between 0 and 9. Icon indices are used to associate menu items to icon items.
• addItem($name, $url, $icon)
  Add a menu item to the icon menu object. The menu item will be identified by $name, and direct users to $url when selected. The menu item will display the icon associated to icon item $index.
• toXML()
  Returns formatted XML for the directory object.

CiscoIPPhoneExecute

• __construct()
  Creates a new instance of CiscoIPPhoneExecute.
• addItem($url, $priority = 0)
  Adds an item to be executed by the destined Cisco device. The device will attempt to execute $url and return response codes based on the success or failure of the execution. If a $priority value is not specified, 0 is used to cause the execution to happen immediately. See Cisco documentation for valid priority values.
• toXML()
  Returns formatted XML for the directory object.

The most recent version of the CiscoIPPhone Framework is available at http://www.minded.ca/default/2010-12-29/cisco-xml-services-framework/.

This first release version is currently available without documentation as it is not yet complete.

There are also a few significant changes made to the projects design and the overall organization of the framework. The most significant change brought into the project was added very late in its development. As the objects grew and the framework took its shape, it seemed both natural and imperative to make provisions for the concept of global framework functionality. The idea being to have a space within the framework for functionality and controls less related to individual service objects but still applicable to the framework as a whole.

Another change to note for testers and developers is the option on all service objects to apply an XSLT file directly to service objects to retrieve the formatted results of the transformation. As the more interactive components of the framework were being added, testing processes found it useful to make the XML service objects usable in a web browser. As more and more framework objects were tested, it was deemed relevant enough to be included in the base CiscoXMLService superclass object.

As a result of the inclusion of an XSL transformation function and the thorough testing of all object functions, a robust XSL stylesheet template was created by testers to transform all usable service objects into corresponding, formatted HTML markup. Not all objects could be tested in this way as some rely on the Cisco IP Phone firmware to be run correctly (Execute objects for example). It is the intention of the developers and the testers to make the resulting XSL stylesheet available to the public as well.

INSTALLATION:

To install the framework, unpack the archived file. Copy the ‘CiscoIPPhone‘ folder to the webserver’s PHP include location. NOTE: This framework requires PHP 5.

USAGE:

Once installed in the PHP include directory, add the code:

require_once(‘CiscoIPPhone/Framework.php’);

This will make all of the objects in the framework available.

In addition, with VoIP being so attached to the computing industry as it is to the telephony world; much of hardware is being designed to reflect this. One of the more commonly seen features that takes advantage of this is the presence of a screen. By allowing for enhanced interfaces through screen displays (and touch screens in some cases), many of the devices manufactured support methods of enabling custom application interactions. More subtly, these devices are usually run via firmware; much like computing hardware. By building hardware with this hybrid design of computing technology models and the user accepted interface of the telephone, the industry is quickly shaping what is requested of the market by way of what it provides the market.

The VoIP telephone units made by Cisco Systems support a variety of XML service objects with their firmware. These service objects allow for other applications to interact with the VoIP system at the user level. The phones can be configured with custom links to directories and menus, also made from XML service objects. By creating links to applications that return formated Cisco XML services objects, the phones can directly interact with almost any system or application on a network.

PHP is commonly used to create XML service objects formatted for Cisco endpoint devices. In light of this, a framework for creating service objects was created. This framework is being made available publicly under the Mozilla Public License (MPL) agreement.

Within the context of CiscoIPPhone Framework, each service object is its own object class. At the object level, all objects are implemented via a DOMDocument object. This implies that PHP 5 will be required for the framework to operate. The framework makes use of a basic CiscoXMLService object that defines global functionality such as softkey manipulation and output formatting. All elements in the service objects that are non-singular elements exist as smaller objects. Where service objects may have multiple child elements, an array of child elements is kept. The list is only attached to the service object DOMDocument when an output format is request. Basic duplicate entry prevention is built into the service objects.

The framework is currently being tested to ensure proper functionality. It is expected to be released in the next few days. Please check back soon for download and usage information.

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 ’320x212x12′. The other models (7970, 7975 and Communicator) will look in the ’320x212x16′ 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.