Yealink is our go to vendor for telephony hardware, mainly due to its ease and variety of configurability. But recently have been tasked with adding a Polycom VVX250 to the system for a charity to use.
While the setup between different manufacturers normally follows the same general path. This is a journey of how Polycom interprets it…
Factory Booting
As these are inerited devices, they were pre-configured to another system and default passwords changed. Luckily (For us anyway) Poly’s implementation still allows a phone to be factory reset even if preconfigured.
To factory set a Poly VVX250:
- Reboot or power on phone.
- At the “starting application…” screen, press the cancel button.
- It will now start a countdown, during this press and hold 1, 3 and 5 on the dialpad, it will now prompt for a password.
- Enter the device MAC address as the password.
- Press okay, it should notify that the device is factory reset.
Zero Touch Provisioning
A feature many manufacturers have is a auto-provision or zero touch provisioning system. As these are going to be the only Poly’s on the system there would be little gain in investing in their service.
To the rescue will be DHCP options, mainly opt. 66 for Boot Server, where we will steer an unprovisioned device to the phone system.
Here, add DHCP option 66 to your DHCP server, and add an ASCII value of the address of you phone server, complete with any authentication string.
Configuration
While Yealink’s are pretty usable out of the box, Polycom’s require a bit more fettling to get into a working state.
A lot of this fettling is required via the config files it attempts to pull from the provisioning server. Starting with:
Firmware:
Firmware loaded on the phone dictates what files a phone will request from a provisioning server, which I’ve found causes issues when a mismatch of device firmware levels are introduced to a system.
Therefore a a matching firmware level server/client side is required. For this example I used an older 6.1.0.6163 fw that was compatible with our system.
Config Files:
Our system, like many modern PBX’s generate a config file on the fly, negating the need to store all config files individually.
In this case, while the {MAC}.cfg file can be auto-generated, the site.cfg (system level config) file is not and so has to be manually edited. The connotations of this in a multi-tenant environment means that a lot of customisations are not available, such as wallpapers and even directories.
Dial Plan:
As discovered during testing, a clean Poly device will include a US specific dialplan as default. This causes issues with both UK PSTN calls and local extension calls, sending the call after on 2 digits dialled.
Therefore a new dial plan has to be created and added manually to site.cfg. This was my interpretation:
999 emergency
1xxT emergency, 3 digit NSN
[1-8]xxxT pbx extensions
*xxT pbx star codes
*xxxT pbx star codes
116xxx 6 digit (excl directory enq)
08[04]xxxxT 7 digit NSN
0[18]xxxxxxxT 9 digit NSN
0[12358]xxxxxxxx 10 digit NSN landline
07[1-9]xxxxxxx 10 digit NSN mobile (excl personal numbering)
00x.T International
This translated into the the following strings for the Polycom:
Polycom dialplan string:
999|1xxT|[1-8]xxxT|xxT|xxxT|116xxx|08[04]xxxxT|0[18]xxxxxxxxT|0[12358]xxxxxxxxx|07[1-9]xxxxxxxx|00x.T
Polycom dial timeout string:
3|3|3|3|3|3|3
Testing
With the above configuration the Poly VVX250 performs as a budget phone normally would.
A small issue I think customers would fall prey to is the “URL” labelled button that appears when number input is required (calling / transferring), when pressed it changed the dial pad into T9 input and would imagine being confusing if the URL press was unintentional.
Apart from that, the lack of customisation options in a multi-tenant environment and the cost of the phone compared with its usable feature set would likely rule it out as a product to offer for our platform.