Mar 3, 2014Articles

My first exposure manual provisioning was trying to prep a batch of phones for deployment in a remote environment. At the time, we couldn’t just plug the phones into the network and get registered and download the latest firmware. I’d had problems with a couple of IP Phones not successfully downloading the UNIStim firmware. The file transfer would begin but eventually the download would fail and the phone would reboot. Fail and reboot. Infinite loop.

I started looking for an alternative and decided to give this TFTP provisioning a try.

The first thing I learned was that there were two types of provisioning files:

  1. System, Zone, Type, Device provisioning.
  2. Type configuration

Provisioning vs Configuration


Provisioning replaces (or supplements) DHCP provisioning. You can find more about what TFTP provisioning can do by referring to the previous blog posts on DHCP provisioning, or refer to the IP Deskphones Fundamentals guide (NN43001-368). The difference between TFTP/HTTP provisioning and DHCP provisioning is that instead of being semi-colon separated the provisioning values are separated by carriage returns. Lastly, TFTP can override DHCP provisioning, but HTTP provisioning cannot. (See the Provisioning Precedence Order outlined in the previous blog post.)


Configuration permits configuration of multiple user features including:

  1. Firmware version & download server
  2. Expansion Module Firmware
  3. User keys
  4. Device configuration (Node & TN)
  5. Backgrounds & screensavers
  6. Custom fonts
  7. Language (associated with customized fonts)
  8. Feature licensing
  9. Dialing plans (SIP only)

For my application, I just needed to download the latest firmware to the phones pre-deployment, so the following provisioning file was sufficient for my needs:




FILENAME 0625C8J.bin




Provisioning precedence

When the IP Phone performs TFTPprovisioning (after obtaining the DHCP provisioning information), it downloads the provisioning file(s) first:

  1. system.prv
  2. {zone}.prv
  3. {type}.prv
  4. {device_mac}.prv

It then applies them in reverse order.

  1. 001365FEF4D4.prv (the filename is derived from the MAC address of the IP Phone) is given the most weight,
  2. 1140e.prv (the filename is derived from the device type) is given the next highest priority,
  3. headqrtr.prv is given the next highest priority, and the filename is derived from the zone= mnemonic from DHCP provisioning or from the TFTP system.prv file.
  4. system.prv is given the lowest priority (but higher priority than either DHCP or HTTPprovisioning).

Once the provisioning files are loaded and processed, the IP Phone will try to load the CFG (configuration) file associated with the IP Phone type (i.e., 1140E phone will request 1140E.CFG.)

TFTP Provisioning & Configuration replaces a number of features that were originally provided by the Nortel Application Gateway 1000/2000 series devices and other Graphical and Text Application Servers (GXAS, XAS).

NodeID and TN provisioning

IP Phones accept a list of Node and TN values associated to particular MAC addresses. The Node and TN values are assigned to a specific IP Phone by the phone recognizing its own MAC address within the list of Node and TN values. Source: IP Deskphones Fundamentals (NN43001-368)

reg=  [  ];


reg=, [,,,];

The following SYSTEM.PRV file content contains examples of various valid string formats. The “reg” item data can also appear in any of the supported .PRV files.


REG= 00:1B:BA:F8:82:0D CS1K S1 123 096-1-22-00;

REG= 00:1B:BA:F8:82:0E CS1K S1 44 096-1-22-01;

REG= 00:1B:BA:F8:82:0F CS1K S1 7777 096-1-22-02;

Automatic provisioning

IP Deskphones Fundamentals May 2011 469

REG= 00:1B:BA:F8:82:1D CS1K S1 7777 096-1-22-03;

REG= 00:1B:BA:F8:82:1E, CS1K,S1,7777,096-1-22-04;

REG= 00:1B:BA:F8:82:1F CS1K S1 7777 096-1-22-05;

REG= 00:1B:BA:F8:82:2D CS1K S1 7777 096-1-22-06;

REG= 00:1B:BA:F8:82:2E CS1K S1 7777 096-1-22-07;

REG= 00:1B:BA:F8:82:2F CS1K S1 7777 096-1-22-08;

REG= 00:1B:BA:F8:82:3D CS1K S1 7777 096-1-22-09;

reg= 00 1B BA F8 82 3E CS1K S1 7777 096-1-22-10;

reg= 001BbaF8823f Cs1k s1 8972 61 0;

reg= 00-1b-Ba-f8-82-4d cs1k S1 3434 96 00 01 11;

Provisioning with HTTP

The Provisioning IP address must be configured with “http://” preceding the IP address to enable HTTP provisioning. Alternately, the IP Phone can be provisioned with using DHCP Option 66 (TFTP Server Name) and use a string prefixed with “http://” and the HTTP server name. The IP Phone then connects to an HTTP server and retrieves the provisioning and configuration files using HTTP protocol instead of TFTP protocol.


A few fun things you can do with TFTP provisioning include:

Setting Node & TN for each phone

Prevent users from re-numbering their IP Phone, simplify deployment of new sets, increase security of IP phoneset deployment, prevent accidental loss of configuration information.

Need to swap two IP Phones? Swap the MAC address configurations in the provisioning file, then reboot each phone using the isetReset command in the Signaling Server. No more problems with duplicate TN assignments or improper operation by end users!

Increase IP Firmware distribution speed & distribute the load

Signaling Servers can only process approximately fifty (50) Firmware upgrade requests simultaneously. Additionally, IP Phones separated from a SS by a WAN can suffer problems when attempting to pull down firmware, either because of network throughput issues or because of access (firwall or VPN access control) issues.

By distributing the firmware upgrade load to a TFTP or HTTP server, and by placing those TFTP servers in geographical proximity to the IP Phones you can increase the number of phones that can be served simultaneously as well as reduce the potential issues from network congestion.

Reduce firmware deployment time from hours to only 8 minutes! You can get a rough estimate of how long it will take to upgrade firmware for a site by taking the total number of sets that need to be upgraded, divide that by 50, then multiply that by 8. If you have 450 sets, it will take you at least (450/50 = 9 * 8 equals) 72 minutes. By moving firmware download off the Signaling Server to a TFTP server, and thus increasing how many IP Phones can be simultaneously served, you dramatically increase your bootup/recovery times.

Provide device specific configurations

Have a group of users who need a higher quality of service than the average user— configure better DSCP values via TFTP/HTTP provisioning to override the default values assigned by DHCP or UNIStim.

Remotely enable SSH access & logging

Simplify and secure diagnostics by only enabling SSH access and logging for each device when necessary!

IP Set Branding & advertisements (Screensavers)

Put your company logo (up to 320×240) on your phones as a screensaver, like you might see on TV. Put other useful information (support numbers, tips, etc.) in the rotation to give the feature a functional purpose. And for hotel environments, put advertisements on the IP Phones to shape guest behavior.


External reference

I originally posted a lot of this information on my personal blog in Jan 2012.

Download maximums

At least 5 sessions are allowed, but up to 50 sessions are allowed if certain conditions are met. Download sessions are started every 5 seconds, so long as resources are available. Signaling Server IP Line Applications Fundamentals (NN43001-125), “Download maximums” and “Maintenance mode” sections cover the resource criteria in more detail. TFTP Provisioning provides a way to work around the session limit, speeding recovery times when new firmware is being deployed.

IP Phone applicability

Also, according to Nortel Bulletin P-2008-0102, TFTP/HTTP provisioning is not supported on the 2001/2002/2004 series IP Phones. The latest IP Deskphones Fundamentals guide (NN430001-368) states that beginning with UNIStim 3.1, provisioning file support is only applicable to the following phonesets:

  • Avaya 2007 IP Deskphone
  • Avaya 1210/1220/1230 IP Deskphone
  • Avaya 1110/1120/1140/1150/1165 IP Deskphone

Commenting your provisioning files

PRV files support both /* */ and # commenting methods. All text contained between /* and */ is treated as a comment. All text following a # is treated as a comment. To ensure that your provisioning files are readable to other staff, or just to help you remember what you did and why, always comment your files. The small increase in file size (and download times) is well worth the increase in readability.

Share This