CEPM not updating BLF labels

FreePBX Distory
FreePBX 12-0.76.4
Asterisk 11.21.2

Following the example given at:

[http://wiki.freepbx.org/display/FPG/EPM-Admin+User+Guide#EPM-AdminUserGuide-ConfiguringLineButtons ]

I changed the text in several BLF labels. I then saved the changes by pressing the Save Model button. I returned to the snom template page and pressed the button Save and Rebuild Configs. There does not seem to be an option to save, rebuild and update the phones. I am unable to locate any ‘drop down’ menu of asny sort connected to the template page. I have found a button with the update option on the extension mapping sub window. But pushing that seems to have no apparent effect. How does one push the label updates to the phones and get the changes to display in the BLF?

I have been at this problem for several days now. As far as I can determine from running find / -type f | xargs grep '<known label string>' against the FreePBX box no configuration files are written when I select all of the extensions, choose the <Save and Rebuild> option, and then press <Use Selected>. The application takes some time to return and the ‘need rebuilding’ color on all of the extensions turns to green if they were brown before. But I cannot find any output.

Nothing new shows up in /tftpboot because none of the file dates change. And, as described above, I cannot find any file on the system, other than the database itself, which contains the label string I have configured. Is there somewhere else that one is supposed to rebuild the extension configuration? Where does the file go? What is its name?

FreePBX 12 is not supported anymore. I suggest you upgrade to FreePBX 13 and test.

I waited until this weekend to perform the upgrade and discover that according to the FreePBX distro I have the latest version.

yum update
Loaded plugins: downloadonly, etckeeper, fastestmirror, kmod, priorities
Determining fastest mirrors
base                                                           | 2.0 kB     00:00     
extras                                                         | 1.3 kB     00:00     
pbx                                                            | 1.3 kB     00:00     
pbx/primary                                                    | 1.0 MB     00:00     
pbx                                                                         4261/4261
schmooze-commercial                                            | 1.3 kB     00:00     
updates                                                        | 1.3 kB     00:00     
Setting up Update Process
No Packages marked for Update
[[email protected] ~ (master #)]# /usr/sbin/sysadmin_update_system
    [status] => error
    [data] => SimpleXMLElement Object
            [0] => This system is up to date.


Either that or the update script has a bug. In either case I am not prepared to risk disabling my phone system trying to figure this out on my own. We have the commercial sysadmin module which was purchased to deal with this very issue.

Is there a problem with the commercial sysadmin module?

Are there any suggestions on how to proceed?

I believe updates from FreePBX 12 to 13 on the FreePBX distro have to be done manually running this:

FreePBX Distro 6.12.65-100 This will take your 6.12.65 version system to a 10.13.66-1 version and track. Please note 10.13.66 is the Current STABLE and 6.12.65 will be End of Life 12-31-15


re: http://wiki.freepbx.org/display/PPS/FreePBX-Distro-6.12.65

Good luck and have a nice day!


PS: I will try to find where it was mentioned…

Thanks. I was following the instructions on the upgrades site which says that if one has the commercial sysadmin module, which we do, then one runs the provided script /usr/sbin/sysadmin_update_system. When i tried to get the script using the upgrade script linked by the upgrades site then I get a certificate error.

 wget https://upgrades.freepbxdistro.org/stable/10.13.66/upgrade-10.13.66-1.sh
--2016-11-26 13:51:41--  https://upgrades.freepbxdistro.org/stable/10.13.66/upgrade-10.13.66-1.sh
Resolving upgrades.freepbxdistro.org...
Connecting to upgrades.freepbxdistro.org||:443... connected.
ERROR: no certificate subject alternative name matches
        requested host name `upgrades.freepbxdistro.org'.
To connect to upgrades.freepbxdistro.org insecurely, use `--no-check-certificate'.

So, I checked the certificate that AI get from https://upgrades.freepbx.org and see this:

E = [email protected]
CN = *.freepbxdistro.org
O = Robin Thomas
L = Gladstone
ST = Queensland
C = AU

Subject Alt_Name
Not Critical
DNS Name: *.freepbxdistro.org
DNS Name: freepbxdistro.org

This is likely the bug wget has with wildcard certificates that RH has been unable, or unwilling, to fix since 2013. In case someone else runs into it I thought that I would mention it here. I downloaded the upgrade script without the certificate check. The upgrade script is running now.

Well, the upgrade completed. And this system rebooted. And FreePBX starts. And all of the modules are updated. And our phones now all have a fast busy when one lifts the handset. Wonderful. And they report both provision failed and not registered. So, I wonder what changed?

Is the firewall active?

That’s something new in FreePBX 13 and if not correctly configured it could cause trouble…

Good luck and have a nice day!


First of all. Thank you for your help. It is appreciated.

Second, yes I think that maybe the firewall is the problem. It never properly completed its setup and I inferred from that that it had not started. That may have been my mistake. However, the dashboard says it is not running. Is there any other way to see if it is causing this problem?

No. Not the firewall. We use tls on our snom phones. But after the upgrade we see this in the log files:

[2016-11-26 20:46:49] ERROR[17899] chan_sip.c: 'TLS' is not a valid transport for '41717'. we only use 'UDP'! ending call.

We had set and still have these settings on SIP


Why are these not in effect following the FreePBX update?

I discovered that the sip configuration files generated by FPBX-13 are ignoring the manually added tls configuration variables contained in custom configuration carried over from v12 but continue to show them in the sip configuration module nonetheless. I ended up having to manually add the server key and certificate together with the CA chain through the certificate manager module, set the appropriate options in sip configure and apply the changes. Now all the phones appear to connect to the server. I am not on site so I cannot be certain that they work but the logs seem to indicate so.

However, I am seeing these messages:

[ 2016-11-27 11:42:27] ERROR[28272] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:27] ERROR[28272] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:27] ERROR[28271] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:27] ERROR[28271] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:27] ERROR[28273] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:27] ERROR[28273] tcptls.c: Unable to connect SIP socket to Connection refused
[2016-11-27 11:42:34] VERBOSE[28274] chan_sip.c: – Registered SIP ‘41718’ at
[2016-11-27 11:42:34] VERBOSE[28274] chan_sip.c: – Registered SIP ‘41718’ at
[2016-11-27 11:42:34] NOTICE[28274] chan_sip.c: Peer ‘41718’ is now Reachable. (14ms / 2000ms)
[2016-11-27 11:42:34] NOTICE[28274] chan_sip.c: Peer ‘41718’ is now Reachable. (14ms / 2000ms)

Which I infer are harmless as the phone eventually registers. I would like to know if there is some setting that I can use to eliminate the presumable spurious error messages that presage the successful connection.

Also I see this after the system has been up for some time:

cptls.c: Unable to connect SIP socket to
chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data

I searched for this and could only find references to either timeout conditions or the effects of running two instance of Asterisk. I checked for the latter condition and assured myself that there was in fact only one instance running. This leaves the timeout issue.

Are these messages indicative of a serious problem? How can the underlying condition be eliminated?