Upgraded from v14.x to v15.5 - Polycom Phones won't provision

[Ron Cawthon]

We upgraded our system last week to v15.5 and now our Polycom phones will not provision or register after manual phone configuration. The following steps have been followed:

1. Download latest Polycom files
2. Verify DHCP Option 66 configured for http://***.***.***.***:5000/provisioning/***********
3. Factory Reset Phone
4. Update the Firmware to 4.0.10.0689
5. Boot Block 3.0.2.0024
6. Updater 5.0.10.0028
7. Configure Phone in 3CX
8. Reboot phone

Phone loads to the default factory screen (SoundPointIP). It has the correct Boot server url. Important to note that the phones are connecting over a VPN to the phone system. The network configuration worked perfectly on v14.x for approximately 150 phones which all connect over VPN tunnels. Furthermore, most phones are working fine however if they need to update their configuration for some reason they will not configure.

 

[CCAdmin]

Have you tried "https" on your provisioning?
You'll also need to change the port to either 5001 or 443, depending on your configuration.

 

[Ron Cawthon]

Are you suggesting setting the DHCP option 66 to https:// and port 5001?

 

[CCAdmin]

Correct, depending upon whether your PBX is setup for 5001 or 443.

You should be able to tell whether the provisioning is using HTTPS by opening a user extension, go to the phone provisioning tab, select the phone vs 3CX client, then look under the provisioning section below. They used to put the provisioning link on the dashboard, but now it's under the user extension.

 

[Saqqara]

What happens if you try and provision the phone manually.

According to https://www.3cx.com/sip-phones/polycom-vvx/ , provisioning is on port 5000(probably down to phones not trusting the ssl certificates)

Also make sure the IP address range has not been blacklisted

 

[Ron Cawthon]

Thank you for your replies.

The phones, we have tried http and https. The link provided in the management console is, http://IP:5000/provisioning/UniqID. All other phones are provisioning fine. For Instance, a brand new Yealink T42G configured without issue.

 

[cobaltit]

HTTPS won't work as the Polycom's don't have the LE cert in that firmware and the console will never tell you to use HTTPS because the phones are not currently supported in STUN/SBC scenarios where you would be required to use HTTPS. You haven't mentioned whether you have a routed or NAT'd VPN. I would confirm your remote network isn't blacklisted and add it to the whitelist if you haven't already (PS, delete the blacklist if there and then add the whitelist. Editing the existing blacklist and then changing it to whitelist doesn't work right). Also, did the phones work before you factory defaulted them? If you just upgraded 3CX only then the phones should have worked just fine. Lastly I would confirm you can pull the config files from a browser on the VPN subnet to rule out firewall/network issues.

 

[Ron Cawthon]

We are not having any blacklist issues. The phone system is located at our data center where all remote locations have a VPN back to the center. The Polycom VVX and Yealink phones provision just fine which leads me to believe there is something we are missing to get the older phones to provision correctly.

To answer your other questions, ALL the Polycom phones provisioned fine prior to the upgrade to v15 and function as provisioned. The issue didn't come apparent until about week later when a couple phones lost their configuration. It is also important to note that we have about another 75 to 100 phones that are working fine on the older 4.0.7 or 3.x.x firmware depending on the model of the phone. As for the site generating the mac.cfg file, that seems to work however I am not sure how to test the mac-config.cfg creation. Do you have the steps to test that portion?

One item we read was that Multicast may need to be enabled over the network. We could get a maintenance window to enable multicast however we don't believe that is an issue since these phones have worked fine for 4 to 5 year with no issues. The only change was the upgrade to v15.

Thanks again for everyone's assistance helping work towards a resolution.

 

[Ron Cawthon]

Well now we have about 20 phones that have lost their configuration this morning that were working on Friday. Nothing change over the weekend which makes this seem like a very odd situation.

 

[cobaltit]

Any chance you have any other DHCP options on the affected subnets, like option 43?

 

[Ron Cawthon]

We currently have Option 3 (Router), 15 (DNS Name), 6 (DNS Servers), 42 (NTP Servers) and 66.

 

[Ron Cawthon]

Update: Updating the firmware using the Web UI to 4.0.13.xxxx resolved the issue after a reboot. Any idea why 3CX is recommending 4.0.10.xxxx as the supported version?