Provisioning for Polycom Soundpoint IP 320/330 phones

Overview

SARK UCS/MVP has an extensible provisioning system. This provides two benefits. Firstly, it allows users to edit and add their own provisioning parameters to configuration files. Secondly, it allows users to create configuration files for any unsupported phone provided the configuration files are in plain text. We have used this basic system to build a provisioning sub-system for the Polycom Soundpoint range of SIP phones. However the nature of the Polycom provisioning regime has necessitated some slight changes and these are detailed below.

Polycom Soundpoint IP320/330

SARK UCS/MVP has initial provisioning support for these two units. We believe that the support will work for all current Polycom phones but NOT with older versions (such as the IP300).

Extension definition for the Polycoms is identical to other supported phones. Simply choose "Polycom IP320/330" from the device dropdown when creating the extension. Provisioning thereafter is entirely automatic. However, in order to set up Polycom provisioning there is a small amount of work for the user to do.

Installing Polycom provisioning

The polycom units retrieve their boot and firmware information from the tftp-server. In order to have provisioning work correctly you must save these files manually into /tftpboot on your SARK box. The Polycom provisioning files (at least in our case) arrive in 2 zip folders called "BootRom" and "spip-ssip". Unzip the entire contents of both folders straight into tftpboot. There is a bewildering array of files but you can simply ignore most of them. All of the Bootrom files end in ".ld", while the spip-ssip files end mostly in either ".ld" or ".cfg". One of the spip-ssip files is called "sip.cfg" and this will conflict with a file already present on /tftpboot. Simply overwrite the old file with this new one.

Install sail-664

Download SAIL-664 (or later) from the download server and install it in the normal way. SAIL will install (among other things) 1 new device and 1 new descriptor in IP Devices. The new device is called "Polycom IP320/330" and the new descriptor is called "polycom-locals".

Defining an extension.

Define your extension in the normal way.

SARK UCS/MVP will automatically generate the necessary provisioning files and save them on /tftpboot for you and the phone will appear in the extension list like any other. - see extn 4117 in the screen below...

Once you've committed your new extension, your Polycom unit can be plugged into the network and rebooted. It should come straight on-line and register to the SARK/SAIL box. You can also proxy to the polycom browser from the extension main panel, just as you can with most other SIP phones...

So what is different about Polycom provisioning?

Not much really, except in the sheer volume of data which gets sent to the phone each time it boots. Unlike its competitors, the Polycom does not have a "default" state in its firmware. All of its settinsg (and therer are a LOT of settings on the Polycom), get loaded at boot time (this is not strictly true, the phone will attempt to come up with the settings it has if the relevant files aren't available). The "default" settings are held externally on the tftp server, primarily in two large xml files called sip.cfg and phone.cfg. The idea is that the user NEVER modifies these two reference files. Instead, each phone loads the two reference sets and then loads a much smaller set of xml override files which modify the reference templates. These override files are usually very small containing just the data which makes the phone unique.

The load sequence

Initially, the phone loads its bootrom from the tftp server. Next it loads the specific phone file {mac-address}.cfg (this is created by SAIL). {mac}.cfg is a very small file which tells the phone what else it needs to load. Here is a typical example...

<?xml version="1.0" standalone="yes"?>
<!-- $Revision: 1.2 $  $Date: 2008/09/17 18:52:21 $ -->
<APPLICATION APP_FILE_PATH="sip.ld" CONFIG_FILES="0004f215899a-phone.cfg, polycom-locals.cfg, phone1.cfg, sip.cfg" 
MISC_FILES="" LOG_FILE_DIRECTORY="" OVERRIDES_DIRECTORY="" CONTACTS_DIRECTORY=""/>

You can see that the xml directs the loader to load 0004f215899a-phone.cfg, polycom-locals.cfg, phone1.cfg, and sip.cfg. The last two are the big reference,or default files. {mac-address}-phone.cfg is generated automatically by SAIL and it contains things like extension number, auth-id, password and so on; things which are unique to each phone. Here is an example..

["$mac-phone.cfg"
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- $Revision: 1.2 $  $Date: 2008/09/17 18:52:21 $ -->

<phone4117> 
  <reg 
      reg.1.displayName="polytest" 
      reg.1.address="4117" 
      reg.1.label="4117" 
      reg.1.auth.userId="4117"
      reg.1.auth.password="aUnxCpSR"/> 
  <reg
</phone4117>

Similarly, polycom-locals.cfg is also generated by SAIL and it contains local information, such as where the SARK/SAIL server is on the network, time settings and so on. In other words, it holds data which is used by every phone but is unique to this installation. Here is an example, notice the use of SAIL substitutional variable $localip. You can freely use SAIL variables throughout the xml and these will be substituted with the correct value at commit time.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

<!-- Our local phone system common configuration in this file --> 
<localcfg> 
 <server voIpProt.server.1.address="$localip"/> 
 <SIP> 
   <outboundProxy voIpProt.SIP.outboundProxy.address="$localip"/> 
 </SIP> 
 <voice> 
   <volume voice.volume.persist.handset="1" 
     voice.volume.persist.headset="1"/> 
 </voice> 
 <TCP_IP> 
   <SNTP tcpIpApp.sntp.resyncPeriod="86400" tcpIpApp.sntp.address="pool.ntp.org" tcpIpApp.sntp.address.overrideDHCP="0" tcpIpApp.sntp.gmtOffset="" tcpIpApp.sntp.gmtOffset.overrideDHCP="0" tcpIpApp.sntp.daylightSavings.enable="1" 
tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.month="3" 
tcpIpApp.sntp.daylightSavings.start.date="8" tcpIpApp.sntp.daylightSavings.start.time="2" 
tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="0" 
tcpIpApp.sntp.daylightSavings.stop.month="11" tcpIpApp.sntp.daylightSavings.stop.date="1" 
tcpIpApp.sntp.daylightSavings.stop.time="2" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1" 
tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="0"/>
 </TCP_IP> 
<localcfg>

Modifying what we've done

You can freely modify our choices by changing the templates in IP-Devices. There are only two; the IP 3220/330 device definition and the descriptor polycom-locals.cfg. In this way you can set your templates to suit your site and geography. Definition, roll-out and maintenance of the phones then becomes relatively trvial.