3cx responds with HTTP 403 to Polycom VVX400

[George Ts]

Hello,
My setup includes:
3cx 15.5.6354 on Windows server
and
Polycom VVX 400 IP Phones
My VVX 400 was initially provisioned correctly using extension number 222.
I then deleted ext. 222 on 3cx server and created a new one: ext. 333.
Also attached the new ext. 333 to the same Polycom Device (same MAC under Extension-->Phone Provisioning).
Then restarted the Polycom.
After its reboot the VVX 400 requested via HTTP GET the provisioning files (<MAC>.cfg and <MAC>-config.cfg) but now the 3cx server responds with 403 Forbidden.
Any idea why this happens?

 

[eddv123]

How are you setting these phones up - Option 66. Also where are the phones in relation to the PBX? : https://www.3cx.com/sip-phones/dhcp-option-66/

The phone(s) will request 2 provisioning files, a common config file and mac orientated. Due to the fact these phones are legacy and expected to be used in the local LAN this is why you are seeing the HTTP request. Are you setting these phones up in any method that is not local LAN or VPN ?

 

[sentrianjames]

Have you attempted to both factory reset the Polycom and/or change or at least confirm the authentication username and password for the extension?

403 error leads me to think there is an authentication issue somewhere.

P.S - make sure you've also got the Polycom's updated with the recommended 3CX firmware available on the support site.

 

[George Ts]

Thank you both for getting back.
The phones are provisioned via DHCP Opt. 66 and located on a different subnet than the 3cx server.
Interestingly enough, after the Polycom was factory reset, the configuration succeeded (no more 403, just plain 200OK HTTP responses by the 3cx).
This makes me understand that the issue was on the Polycom side, and I should find out exactly where. Any suggestions until then would be more than welcome.

Sp, the Polycom did not receive the new provisioning after a reboot, but only after a factory reset.
In practice, that means that if a user changes extension number, their Polycoms will not be able to be centrally re-provisioned with the new extension, unless we make a factory reset on their phone.
Not a good thing to realize.

 

[eddv123]

If they are on a separate subnet not a major issue (what I was trying to gauge was whether you were trying to setup via STUN or SBC which you are not so good!).

What I would keep an eye on if it is an authentication issue is the IP Blacklist on 3CX, ensure the phone(s) don't get added.

If your provisioning file is not downloading (and I presume due to the description of your network setup that you have multi-NIC cards on your server) that you have selected the correct interface on the extension(s) you are using.

https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

 

[sentrianjames]

Hmm, that does a bit odd, however, have you followed the instructions, specifically upgrading the device firmware? If not, I'd highly suggest you take a look as this might assist with the behavior you've described. https://www.3cx.com/sip-phones/polycom-vvx/

In saying that however, we run a bunch of Polycom VVX 400-series phones and we don't run into that many issues with them. Again, they are unsupported, so don't be surprised if some things don't work how they should.

 

[George Ts]

Gentlemen, once again thank you very much.
Responses to your questions:
- No, not using STUN or SBC
- Firmware is up to date
- Checked before the factory reset and the Polycom's IP was not blacklisted in the 3cx
- The correct interfaces were used, see no reason why not

As a finding:
I just checked the diffs in the HTTP GET request that the Polycom does after the reboot (failing scenario) and after the factory reset (working scenario).
After the reboot, when it fails, it only requests the <MAC>.cfg file.
This HTTP GET request includes the following:
[HTTP request 1/1]
[Response in frame: 426]
After the factory reset, the VVX 400 starts by asking the exactly same file <MAC>.cfg, with the next two differences in the HTTP GET message:
[HTTP request 1/3]
[Response in frame: 1668]
[Next request in frame: 1854]
In other words, it now also asks for <MAC>-config.cfg and <MAC>-phone.cfg as well.
It seems that based on the provisioning template, the 3cx server "knows" that the Polycom client is expected to ask 3 provisioning files and not only 1. In case the client asks for 1, they get a 403 Forbidden response.
Or at least, this is the only explanation I can give, since - apart from that - the HTTP GETs are exactly the same.
Question now is why the Polycom does not request all 3 files on the first scenario?