Provisioning problem

[Paul Otter]

Hi,
I'm managing two different Windows PBX's on premise as VM's, one of the systems will auto-provision our Fanvil X4 handsets fine, and the other does nothing.
I'm not sure what changed to stop one of the systems being able to auto-provision, it must have been some time ago.

I suspect it may be one of the following values that is incorrect, but I can't find a list online of what the defaults should be.
That said, I compared both systems, and other than the [MyURL] section, the links are all the same.

WEB_ROOT_EXT	http://[MyURL]:5000/
MYPHONE_LINK_LOCAL	http://[MyURL]:5000/
MYPHONE_LINK_EXT	http://[MyURL]:5000/myphone/MPWebService.asmx
REPORTER_LINK_LOCAL	http://[MyURL]:5000/myphone/MPWebService.asmx
REPORTER_LINK_EXT	http://[MyURL]:5000/Reporter
REPORTER_LINK_EXT_SEC	https://[MyURL]:5001/Reporter
PROVISIONING_LINK_LOCAL	http://[MyURL]:5001/provisioning
PROVISIONING_LINK_EXT	http://[MyURL]:5000/provisioning
MANAGEMENT_LINK_LOCAL	http://[MyURL]:5000/management
MANAGEMENT_LINK_EXT	http://[MyURL]:5000/management
MANAGEMENT_LINK_EXT_SEC	https://[MyURL]:5001/management
WEB_ROOT_LOCAL_SEC	https://[MyURL]:5001/
WEB_ROOT_EXT_SEC	https://[MyURL]:5001/
MYPHONE_LINK_LOCAL_SEC	https://[MyURL]:5001/myphone/MPWebService.asmx
MYPHONE_LINK_EXT_SEC	https://[MyURL]:5001/myphone/MPWebService.asmx
PROVISIONING_LINK_LOCAL_SEC	http://[MyURL]:5001/provisioning
PROVISIONING_LINK_EXT_SEC	http://[MyURL]:5001/provisioning
MANAGEMENT_LINK_EXT_SEC	https://[MyURL]:5001/management
CALLUS_LINK_EXT_SEC	https://[MyURL]:5001/webrtc

I've tried PROVISIONING_LINK_LOCAL on ports 5000 and 5001, and I noticed that changing this value does not update the provisioning link shown in the Extensions -> Phone Provisioning tab.

The link always says http://[MyURL]:5001/provisioning/[MyRandomKey], so I set PROVISIONING_LINK_LOCAL to port 5001 to match

Currently, the only way I can configure a new phone is to paste MAC_ADDRESS.CFG to the end of the provisioning link shown in the Extensions -> Phone Provisioning tab. Download the CFG file, and upload it manually into a phone.

Once configured, clicking the "Reboot" button in the 3cx console "Phones" screen does reboot it, but clicking the "Reprovision" button does not reprovision.
Also, logging into the handsets GUI and clicking the "AutoProvision Now" button does not pull through any changes.

Here's a description of my setup in case it helps.

Each PBX has 2 network cards, a WAN side and a LAN side.
Both WAN addresses are 192.168.0.X and both LAN are 10.10.60.X

All phones are one one of several different address ranges from 10.10.1.0/24 through to 10.10.15.0/24, and also 10.10.200.0/24 which is a dedicated VLAN for VOIP.
Under normal circumstances all phones would be on the 10.10.200.0/24 VLAN, but if staff have to WFH due to Covid, its more difficult to access the phones GUI once on a home LAN if its set to use the 10.10.200.0/24 VLAN.
The issue existed prior to me moving people off the VOIP VLAN.

Our DNS server has records for both external [MyCompany].3cx.co.uk addresses that point to the internal LAN card, so the traffic does not go outbound and then back in again.

The extensions are global, and connected over a VPN (for both systems), which has never been a problem (We've never needed SBC's), but being global makes it difficult to find a reboot window, so the system has been up for a long time.
I'm not sure if that could be relevant.

The phones are on FW 2.12.1.7297 and the PBX is running 16.0.8.9 (from the Licence line under "Information") or 16.0.9 once you click on the licence button under the "information" header.

I don't currently have Wireshark installed on the server, I suspect that would require a reboot.
Our Activity Log settings are set to "Verbose", with log retention set to 1 day, so maybe I could search for something useful there if I knew what to search for.

Any suggestions appreciated

 

[JohnS_3CX]

Hi Paul,

I see a few potential pain points here:

- You have more than one NIC
- There is a VPN involved
- There are VLANs involved
- There a multiple subnets where phones exist
- You added DNS records but we don't know if they end up at the right interface currently
- You changed values in the parameters sections

I could say take the easy way out, and grab a backup before nuking the system and reinstalling it from the backup. This is is the fast way.

Alternatively, you could spend time troubleshooting, by first returning the fields to their original values (if you kept notes on them), then setting up your system for segregated network and then spending a good amount of time in Wireshark to see what happens when you try to provision a phone.


Your setup is a bit complicated so this is one of the times that I would recommend to contact your 3CX Partner and ask for assistance.

 

[Paul Otter]

Hi John,
I appreciate what your saying, but both systems are subject to all of those parameters (VPN, VLANS, DNS etc), and only one system has the issue.
Everything else is working fine, calls are nice and clear, its all perfect, its just the provisioning that's an issue.

Anyway, I have some progress.
I installed wireshark on my local machine, and set it capturing.
I then hit the "Reprovision" button from the console, and I captured a few packets.

I see a couple of packets that look relevant.

They are both HTTP GET
The first URL is "/provisioning/[MyKey]/f0X4hw1.100.cfg" ( That file is mentioned in Fanvil documentation here)
The other is "/provisioning/[MyKey]/[MyPhoneMAC].cfg"
And the full request URL within that packet does work when copied and pasted into a browser.

So far so good.

But then I get two further packets, with a message within saying "The plain HTTP request was sent to HTTPS port"

I changed PROVISIONING_LINK_LOCAL to begin with HTTPS and re-ran the test, but I still get the same issue.

Does this help identify what I need to change ?

Thank you

Paul

 

[Paul Otter]

Sorry, just to add to that.
I just noticed in the new wireshark scan, that despite me having changed the PROVISIONING_LINK_LOCAL to begin with HTTPS, the "Full Request URI" in the packet still begins with HTTP.
So there must be something different that needs changing to make that "Full Request URI" begin with HTTPS.

Paul

 

[JohnS_3CX]

That does shed some light yes, it seems to imply that your phone made an HTTP request (normally port 5000) but sent it to an HTTPS port (usually 5001).

Provisioning link local cannot use 5001
Provisioning link external cannot use 5000

It may be the result of editing those parameters. HTTP only works for lan connections, otherwise if you try HTTP on the HTTPS port you will get rejected.

 

[Paul Otter]

OK, I changed my values to match what you said, but it still didn't work.
Then I re-downloaded the config from the phones page, and manually configured my phone again.
Then I made a change in our phonebook, and hit the reprovision button, and it now works !
The change I made was instantly replicated on the handset.

It might take me a while to manually update the phones onto a correct config, but at least I'll only have to do it once.

Thank you for your help, much appreciated.
Have a great weekend!

Paul

 

[JMK]

You should confirm the default multicast is happening on your LAN NIC and not the WAN. Typically changing the binding order will fix it. I sometimes see this when dealing with AT&T SIP and two NICS. Many times just restarting the 3CX services will fix it which lets you know that is the issue.

 

[JohnS_3CX]

Hi Paul,

Glad to help! I am a bit worried though that you may have changed certain values away from what the system was designed for, in an attempt to make your setup work. I'm not sure you were aware of the segregated network mode that I mentioned above before undertaking the task.

I think it is worth reinstalling the system to get the original values, and build around that using the segregated network I mentioned. 3CX was designed to work a certain way, so if you don't want to lose your functionality we would recommend against modifying those values, that is not the way to go about doing it.