Pushing config to Sangoma phones not working

I’ve been searching and I can’t find a previous discussion about this issue, so bare with me.
I have a new FreePBX V14.0.1.4 installation.
I am using all Sangoma s500’s
I have configured the auto-provision and it is working fine. A new phone connects to the server (DHCP 66) and gets the config, first tftp then http.
I am using pjsip as the protocol.
I’m using the endpoint manager that comes included with FreePBX for since I am using Sangoma phones.
In endpoint manager, if I make a change to the default config for those phones and then “save, rebuild and update phones”, the phones don’t update. I have left the phone for up to 1/2 hour and still no update.
If I go into Extension mapping, “force phone to check config” doesn’t work. Force phone to reboot works, but again it doesn’t get the changes.
If I power cycle the phone, it doesn’t get the config change.
However if I do a hard reset of the phone (***x) the phone does get the new configuration.

Somewhere I am missing something important. Any suggestions?

Are the phones on the same subnet as the PBX? I’d guess it’s a NAT issue…maybe the PBX is trying to NAT the traffic when it shouldn’t or not when it should?

I would guess that the initial tftp URI from your DHCP server and provisions itself. In the process of provisioning, the phone receives an invalid provisioning URI and from that point on is not longer able to re-provision. If you log into the phone GUI and browse to Management, Auto Provision and see the URI in the field Config Server Path.

I had issues getting my s500’s to provision, I think it was an issue of me entering the provisioning url wrong. Whenever I set it myself it didnt work so I guess I messed up somewhere. Here is what I did to fix it. Factory reset, then set the provisioning server on the dhcp server, then (I deleted and recreated ) create everything on the freepbx side of things and finally plug the phones in.

Just giving an update on this issue.
This problem was happening on a Sangoma system 40 that I am doing a new setup.
One of the first things I did was run the update from 13 to 14.
During the upgrade there were some issues (I don’t recall what exactly the problem was) that I thought I had resolved.
So when I got to the stage to setup the endpoint manager I started to run into the issues as I posted in the beginning of this thread.
As I was working through the problem, and trying to implement some suggestions I started getting these odd sql errors.
So I decided to start from fresh and did a recovery re-install of the whole system.
I am now into the system config and the endpoint manager is working as it should.
I don’t know if the problems started due to the upgrade to 14 or if there was some other problem.
In any case, I am not going to upgrade the system to 14, at least for now.
I know this probably will not help someone in the future if they have a similar problem. It’s probably not practical for someone to rebuild the system from scratch.
Thanks everyone that answered. It is much appreciated.

The 13 to 14 upgrade is considered experimental and beta still and not something we recommend on a production system yet. We are getting close but its not perfect yet so I would not have done that on a production system

On this page https://www.freepbx.org/downloads/ there is no mention that 14 is still beta. The wording is "Stable"
Also, the upgrade menu on the administration page has a link “13 to 14 upgrade tool” Clicking through it comes to a screen that begins the upgrade process. At no time is “Beta, may not be stable, don’t use on production machines” or similar is displayed.
Perhaps those locations need to have wording updated so that anyone considering doing the upgrade will know that it isn’t ready for live use.

Hi,

As it has already been said in the past,

Are you talking of what Tony described here?

Good luck and have a nice day,

Nick

Again the SNG7 ISO is stable. FreePBX 14 is stable. The only thing that isn’t marked stable is the upgrade script. It states beta on the wiki you are directed to from within FreePBX GUI and states not to run it on production.

Ok, my mistake.
Thankfully it wasn’t on a production machine. A learning experience.
Thanks for the assistance.