Provisioning VVX 400 Remotely - V15 on GCP

[Brady Webb]

Hey Everyone,

I'm trying to provision a polycom vvx400 on 5.4.4 with the correct option 66 string and I'm unable to get my phone to download the config file. In the logs for the phone itself it was noted that the server didn't have the mac.cfg file. Has anyone else experienced this? I'm not new to VoIP, but I am new to the 3cx platform. Background is broadsoft based systems so forgive me if there are certain assumptions I'm making.

-Thank you!

 

[StefanW]

Hey Brady,

when you say "remotely" what is your intention? VPN between the phone's network and the PBX?

 

[Brady Webb]

Stefan,

If possible I'd like to have it over the WAN. We have a couple remote offices and don't have site-to-site tunnels setup. Is this a requirement for the provisioning process or is there any way to use the instance hostname for option66 (mycompany.3cx.us) and have the phones grab provisioning files over the WAN?

Thank you!

 

[Saqqara]

No support for Polycom using STUN or SBC as legacy phones with limited functionality.

https://www.3cx.com/sip-phones/polycom-vvx/

Will work with site to site VPN's

 

[Brady Webb]

Saqqara,

I don't have an SBC running at my house where the phone is. I do have a firewall but it's configured to allow sip/http/ftp traffic to the 3cx instance. The unit is configured with a Static IP, not using STUN, would that have a difference on the deployment? and Once the phones are deployed, will they always need to be on the site-to-site vpn or can we provision once and then let them go?

Thank you!

 

[StefanW]

the issue is that VVX devices have not implemented STUN based on RFC, they use something proprietary to make this work and is not compatible with any open std. SIP pbx like 3CX.

So VPN is the way to go in your case

 

[Brady Webb]

So I've managed to get the VPN up, but in the polycom logs I'm seeing that the provisioning server isn't responding. Any clue as to why that would be the case? I made sure in the extension the provisioning interface was set to the LAN IP and not the company.3cx.us interface.

 

[GiannosC_3CX]

Hi Brady,

Did you follow the below links? Are you using the local subnets (RFC1918) at the remote site where the polycom phone is located? Did you allow the Http traffic from the phone to the 3CX phone system and vice versa though the VPN? Did you check the blacklisted IP's in case that the 3CX Phone system blocked the IP phone? Also, is the phone on the supported firmware?

https://www.3cx.com/sip-phones/manually-provision-polycom-soundstation/#h.qhmp4irvlwfm
https://www.3cx.com/sip-phones/polycom-soundpoint-320-321-330-331-335/#h.jmb0bxlvnmbx

 

[Sopock]

They also claim that DST ROOT CA X3 is supported since 5.5.2

With all these other cloud PBXs supporting Polycom phones, you would think it would be doable.

https://www.3cx.com/community/threads/polycom-remote-provisioning.46510

• The deployment of remote phones is greatly simplified by the use of SIP over TLS

Cisco, Polycom and Aastra phones do not support plug and play nor secure HTTPS provisioning with a Let’s encrypt Root CA.

 

[Brady Webb]

@Giannos, yes I had everything configured correctly. I also have a few 410s to test with. @Sopock, I used to run a broadsoft based platform and all I did was remote provision polycoms with Option 66 and a hosted provisioning server. CFG files were created on request as well. It's truly perplexing as to why this functionality isn't there.

 

[NickD_3CX]

Does the phone "pull" any settings after attempting to provision? Just log into the phones interface and check if there are any setting after the provisioning. This should at least tell us if the problem is the provisioning process or registering against the server.

 

[Brady Webb]

Nick,

The phone isn't pulling any of the provisioning info. I can see in the logs on the phone itself that it's not getting a response from the server. My next steps are to remote into the instance itself and modify the Nginx config to allow traffic over the WAN IP. Coincidentally enough if I manually input the line key information, the extension won't register. I'm thinking that this is a firewall issue just based on behavior, but I figured that for a cloud-based instance, SIP and FTP/HTTP traffic would be allowed over the WAN.

 

[cobaltit]

So if you are doing everything stock, you should be able to manually configure the phone to register. You should either see the register or the phone attempt to register. If you don't see either then you put the wrong info in your your IP is blacklisted. I'd whitelist the WAN IP of the site you are testing from.

If you are ok with manually configuring phones then they should just work (make sure you uncheck the box 'Disallow use of extension outside the LAN'.

If you want to actually provision the phone then you would have to make a custom template and modify that. I can confirm that with the latest firmware (v5.6.0.17325) the phone does support LetsEncrypt and will read a config served by 3CX. I'm currently testing the phone via SBC since we are looking to consolidate a 4 location 4 local PBX customer on to one cloud instance.

We have another customer running older IP330's via SPM and now SBC as well.

Haven't tried the phone via STUN but I imagine it would probably work. Not sure about the non-standard STUN reference but that might only imply it doesn't work against 3CX as a STUN server so using another STUN server might work just fine.

 

[NickD_3CX]

The phone isn't pulling any of the provisioning info. I can see in the logs on the phone itself that it's not getting a response from the server. My next steps are to remote into the instance itself and modify the Nginx config to allow traffic over the WAN IP. Coincidentally enough if I manually input the line key information, the extension won't register. I'm thinking that this is a firewall issue just based on behavior, but I figured that for a cloud-based instance, SIP and FTP/HTTP traffic would be allowed over the WAN.

I haven't quite understood if you have setup a site-to-site VPN, but if you have and you are trying to provision the phone over the VPN, then modifying nginx shouldn't be necessary as long as the IP ranges are RFC1918 compliant.
The restrictions we have have put into nginx are to NOT allow any non-HTTPS traffic from public IPs (non RFC1918). This was done for security so I would think twice about modifying nginx to change any of the 2. From a security perspective, its much better to just manually configure the phone if you can do so with a complicated SIP password than change the nginx settings.