Boot and Provision Sequences (Polycom)

The behavior of a Polycom phone when powering on is helpful while troubleshooting a phone to understand what it is doing during startup. When the phone powers up, it runs through the bootloader (boot sequence), checking its current firmware. It then starts the SIP application and gets its configuration (provision sequence).

Polycom boot sequence

Following is the Polycom boot sequence:

• Phone powers up and does CDP/LLDP VLAN discovery

  • Troubleshoot using packet capture

  • If the switch returns a response, it uses that VLAN

• Runs through the DHCP discovery

  • Troubleshoot using packet capture, syslog, or bootlog

  • DHCP must return

    • IP Address

    • Option 1:Subnet Mask

    • Option 6: DNS server(s) - These servers must be able to resolve the name of the CIC server (short name + option 15). If using switchover, they must also be able to resolve SRV entries for the phone's domain.

  • DHCP should return

    • Option 3: Router - used when the phone needs to contact any resources not within its subnet.

    • Option 15: Domain Name - used for DNS A Record lookup.

    • Option 160: Custom Provisioning Server - The phone defaults to Custom + Opt 66 with Custom defined as 160. It checks for a provisioning server in Option 160 of the DHCP response first, then falls back to Option 66.

      • If 160 or 66 isn't set:

      • If a boot server value resides in flash memory and the value is not 0.0.0.0, it uses the value in flash memory.

      • Otherwise, the phone sends out a DHCP INFORM query.

      • If it fails, it reports on the screen that it Failed to contact boot server.

  • DHCP may return

    • Option 4/42: Time Server(s) - defined so that the phone can do SNTP queries to determine time. If you defined this option in the Configuration files generated from IA, these DHCP Options are optional.

    • Option 2: Time Server Offset - If you have your time server derived from the Option 4 or 42 values, you must also define the offset.

• Phone asks for model-specific bootrom.ld (example /2345-12500-001.bootrom.ld)

  If it has a different version, it downloads and saves the new version; and then reboots

• Phone asks for <MAC>.cfg (example: /0004f218dece.cfg)

  • This file contains a list of files that the phone should request to obtain configuration

  • If there is no managed phone with this MAC address

    • Provision Server creates a provisional station

    • <MAC>.cfg populates with provisional configuration file names

• Phone asks for model-specific sip.ld (example /2345-12500-001.sip.ld)

  If it has a different version, it downloads and saves the new version; and then reboots.

Provision sequence

• Phone starts the SIP application and query DHCP again

• Phone asks for model-specific bootrom.ld again

• Phone asks for <MAC>.cfg again

• Phone asks for model-specific sip.ld again

• Phone asks for the files from <MAC>.cfg in order, generally:

  • /server/cert/ca.cfg - CIC certificate authority for use with TLS connections

  • /phone/<guid>.cfg - custom configuration for that managed phone

  • /proxy/<registration_group>.cfg - registration information for the phone's registration group

  • /server/xic.cfg - dialplan and feature-specific configuration

  • /phone1.cfg - Polycom-default configuration

  • /sip.cfg - Polycom-default configuration

  • /overrides/<MAC>-phone.cfg - phone-specific configuration that a user changed from the phone's user interface

• Phone asks for default files; it's possible that these files are not available

  • /<MAC>-license.cfg - phone-specific license

  • /contacts/<MAC>-directory.xml - contacts directory

• Phone REGISTERS with the CIC server

You can verify proper provisioning and registration using either a Wireshark capture, or the combination of Provision Server and SIPEngine logs.

Precedence example

Polycom phones give precedence to whatever configuration file it acquires first; therefore, any configuration received in server/xic.cfg overrides configuration received in sip.cfg.

As an example, say that a phone has the CUSTOM::config_files attribute set to config_me.cfg. Assuming that the file exists, the phone requests this config_me.cfg immediately before it requests phone1.cfg. The contents of config_me.cfg are:

<?xml version="1.0" standalone="yes"?>
<mb>
<idleDisplay>
<home mb.idleDisplay.home="http://www.inin.com"/>
<refresh mb.idleDisplay.refresh="4"/>
</idleDisplay>
reg.1.address="blahblahblah"
</mb>

The phone ignores the reg.1.address attribute configuration, since it receives it before this file in phone/<guid>.cfg. However, the phone doesn't receive the other two attributes until "sip.cfg", so the phone applies these two attributes accordingly.

Phone simulator

A quick way to check what configuration passes to a phone is to use PhoneSim.exe, a PureConnect tool that simulates the provisioning requests for managed IP phones. The tool is available on the CIC Utilities and Downloads page on the Product Information site at https://extranet.inin.com/products/cic/Pages/Utilities-Downloads.aspx. All the configuration attributes display and allow filtering by file, attribute name, or attribute value. The system saves the configuration files that the provisioning server passes in the specified output directory.

This tool applies configuration settings according to file precedence. To determine whether the system applies a specific attribute from the proper file, see the filename associated to that file.