3CX remote phonebook not working after v18 upgrade

[JamieR]

Hello

I’ve been rolling out v18, upgrading various installations from v16.

I’ve found the remote phonebook no longer works for one particular installation – the phones are all Yealink and now the users get “Cannot download remote phonebook”

Upon closer inspection, trying to view the XML in a browser using the link the phones are using (a http:// URL on port 5000) fails with nginx giving me 403 forbidden.

Changing the URL to https:// and port 5001 gives me the correct response and I can then see the phonebook XML without issue. Changing the URL on one test phone then makes the remote phonebook work once again.

The phonebook URL on the phone remains at http:// after a post-v18 upgrade reprovision.

This seems to be a nginx issue, but given it’s bundled with 3CX, I’d rather not start mucking around with the config unless 3CX tell me to.

I’ve got 50+ phones on this particular site so I’m keen not to manually edit the config on each one…

Any advice as to the correct solution here would be appreciated please – should the URL be https://? If so, how do I get each phone to automatically reprovision so it’s correct

I’m using the standard Yealink T4xx template with no custom modifications.

Many thanks

 

[ChrisC_3CX]

Whether the link will be https or http will depend on the provisioning method used. What provisioning method are you using for these devices (Local, STUN, SBC) and what are they actually(on a remote location with an SBC, Local to the PBX, etc)?

Note: You can check the provisioning method under "Users/Extensions >> Edit >> Phone Provisioning >> IP Phone >> Provisioning Method".

 

[JamieR]

Whether the link will be https or http will depend on the provisioning method used. What provisioning method are you using for these devices (Local, STUN, SBC) and what are they actually(on a remote location with an SBC, Local to the PBX, etc)?

Note: You can check the provisioning method under "Users/Extensions >> Edit >> Phone Provisioning >> IP Phone >> Provisioning Method".

They're all local as they're on the same LAN as the phone system

 

[ChrisC_3CX]

What is selected under "Phone Provisioning >> Select Interface"? Is it perhaps the FQDN? If so, it may be that the devices are actually connecting to the PBX via the Public IP instead of the local.

 

[JamieR]

What is selected under "Phone Provisioning >> Select Interface"? Is it perhaps the FQDN? If so, it may be that the devices are actually connecting to the PBX via the Public IP instead of the local.

Hi Chris,

It's the local IP rather than the FQDN, although the FQDN resolves locally internally.

Looking at the web admin panel for one of the phones, the SIP host/server, provisioning URL and phone book directory all use the local IP address rather than the FQDN.

What I do find particularly interesting is why I get 403 / forbidden when trying to access the phonebook on HTTP / port 5000 but it works when I use HTTPS and port 5001.

 

[ChrisC_3CX]

This is indeed strange because If the request is coming in from a local IP then HTTP via port 5000 should've been allowed. Is there anything particular about this setup or network configuration? Is the IP address space used for this network compliant with RFC1819?

Is this a Debian machine originally deployed using the 3CX ISO? Have any modifications to the nginx config been made?

 

[JamieR]

No, unfortunately not - it’s an inherited network with a non standard IP range which could be causing the issue. For instance, local registrations only work with the ‘disallow use of remote extensions’ unticked

Nginx config is stock but I suspect this is what needs to change

It’s also a Windows Server install, not Debian.

 

[ChrisC_3CX]

it’s an inherited network with a non standard IP range which could be causing the issue

Well that indeed is most definitely the cause of this. No doubt it will cause other issues in regards to SIP too so I do recommend looking into how to rectify this configuration if possible.

 

[JamieR]

Well that indeed is most definitely the cause of this. No doubt it will cause other issues in regards to SIP too so I do recommend looking into how to rectify this configuration if possible.

There is a plan long term, but that's unfortunately long term. Thankfully it's been fine for a few years.

Now I'm back in front of a computer, I've modified nginx.conf to allow the local subnet and all works fine.

Many thanks

 

[ChrisC_3CX]

I'm glad you've managed to find a workaround but I do have to mention that modifying configuration files such as the nginx.conf is actually not recommended and will render the 3CX configuration unsupported. That said, the sooner the network configuration is taken care of and 3CX's config is reverted back to defaults the better.