Provisioning Errors In V18 Update 6 RC

[Judako]

Hello everyone,

for the past couple of days we've been getting the following kind of message in our 3cx event log:

Provisioning file /provisioning/1c6ajb5h6iuny3/firmware/yealink//YL0000000000.rom requested by [our IP] could not be generated
Provisioning file /provisioning/1c6ajb5h6iuny3/firmware/yealink//T46S.rom requested by [our IP] could not be generated
Provisioning file /provisioning/1c6ajb5h6iuny3/y000000000000.boot requested by [our IP] could not be generated
Provisioning file /provisioning/1c6ajb5h6iuny3/805ec09dced8.boot requested by [our IP] could not be generated

I'm having trouble understanding what exactly this error message is trying to tell me. Are our IP phones trying to get provisioning files from our 3cx? Can I determine where this whole thing is failing?
We haven't made changes to our office network and firewall.
I also don't really know how this error message could affect us, since we haven't had any issues with calls or phones not provisioning. I made changes to my BLF earlier, forced my IP phone to reprovision and it worked just fine, even got an event log entry saying the provisioning file was created successfully.

 

[JohnS_3CX]

Hi,

You can ignore these messages, this is not a failure or actual issue.

By default, the phones are programmed by Yealink to ask for various files, none of which are needed to work successfully with 3CX. Think of them as optional functions that phones have.

This is not a problem at all, and your functionality is not affected. Update 6 RC has more detailed Event logs, so you are just seeing messages that were not visible in the past, but were still happening in the background.

 

[Judako]

Hi John,

thank you for your reply! I'll be ignoring these warnings then.

Cheers

 

[jasonfz]

We saw this also with Yealink and Fanvil phones. The explanation here makes sense, but it would be nice to see this called out in the release notes or other documentation. I would also suggest that benign events ought not to be classified as warnings or be able to be suppressed if they are "not a failure or actual issue" (that way we can get back to the important work of dealing with failures and actual issues!