Phones always reboot when applying new config via provisioning

[avayax]

I am using Yealink T23G phones with FreePBX distro and its endpoint manager for provisioning.
Endpoint manager tells the phones to check for config updates and when they do, they always reboot.
For most changes to take effect, a reboot would not be necessary. A reboot is quite inconvenient for an administrator and for a user too.

Could you please add in a future firmware release for the phone to not reboot when updates are pushed?
That is related to how the phone handles a sip notify for check config.

Other manufacturers of IP phones (like Sangoma) don't require a reboot when the phone checks for updates: http://community.freepbx.org/t/update-co...boot/38507

[Peter_Yealink]

Hell Dear,

As some configurations, for example LLDP, VPN... only take effect after a reboot, so in this case phone will reboot while provisioning. Could you please send us your provision configuration file so we can check what configuration change cause the reboot? you can send the file to my email directly: peter@yealink.com

And also if the notify include reboot=true, phone will be forced to reboot immediately.

Many thanks.

B.R,
Peter

[avayax]

(12-14-2016 10:53 AM)Peter Wrote:  Hell Dear,

As some configurations, for example LLDP, VPN... only take effect after a reboot, so in this case phone will reboot while provisioning. Could you please send us your provision configuration file so we can check what configuration change cause the reboot? you can send the file to my email directly: peter@yealink.com

And also if the notify include reboot=true, phone will be forced to reboot immediately.

Many thanks.

B.R,
Peter

Hi Peter,

I just checked, FreePBX endpoint manager is indeed sending a reboot=true notify message, which causes the reboot.

What SIP notify message has to be sent to the phone for it to sync the new config?
Is a "check-sync" enough?
Sangoma is saying that they had to set it up that way, otherwise Yealink phones would not take config correctly.
Did you change this recently?
Sangoma is saying: "That would be something new they added then as it always required a reboot before as things would not update correct like if you removed a button it would not remove it." http://community.freepbx.org/t/update-co...ot/38507/5

Really destroying SIP dialog '555368ab5767faf24a15fe4c0cd7fd6d@10.1.1.178:5060' Method: OPTIONS
Scheduling destruction of SIP dialog '4d3b92733e9995e115eedde23e7481de@10.1.1.178:5060' in 32000 ms (Method: NOTIFY)
Reliably Transmitting (NAT) to 10.124.193.26:5060:
NOTIFY sip:5314@10.124.193.26:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.178:5060;branch=z9hG4bK315410bd;rport
Max-Forwards: 70
From: "Unknown" ;tag=as1249226e
To:
Contact:
Call-ID: 4d3b92733e9995e115eedde23e7481de@10.1.1.178:5060
CSeq: 102 NOTIFY
User-Agent: FPBX-13.0.190.7(11.22.0)
Date: Thu, 15 Dec 2016 01:32:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Subscription-State: terminated
Event: check-sync;reboot=true
Content-Length: 0

[jolouis]

(12-15-2016 01:43 AM)avayax Wrote:  Is a "check-sync" enough?
Sangoma is saying that they had to set it up that way, otherwise Yealink phones would not take config correctly.
Did you change this recently?
Sangoma is saying: "That would be something new they added then as it always required a reboot before as things would not update correct like if you removed a button it would not remove it." http://community.freepbx.org/t/update-co...ot/38507/5

Not sure what firmware or phones the FreePBX guys were testing with (or when), but in my experience that hasn't been the case since... at least 4 years ago? Firmware V.70 introduced the ability for provisioning to take effect without causing a reboot for most things (the exceptions were noted by Peter above), never had a problem with a button failing to update...

For completeness I should mention that we don't use the FPBX EPM as it was a broken bloated ugly mess back when we first started doing our Yealink stuff, so we built our own provision handling system, but that should have no impact on how the resync actually works/is triggered.

The notify message we use is "check-sync; reboot=false"