Yealink Forums
Boot files and wildcards? - Printable Version

+- Yealink Forums (
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: Auto Provisioning (/forumdisplay.php?fid=14)
+--- Thread: Boot files and wildcards? (/showthread.php?tid=43205)

Boot files and wildcards? - starion - 09-23-2019 04:15 AM

I'm fairly new to auto provisioning so if I'm asking a dumb question, I apologize in advance.

I have two config files, one for our T23G phones in general, and then MAC config files that contains the SIP login information for specific phones.

I have found that you have to specify the MAC config files one by one in the boot file or they won't load. It seems a bit clunky that on top of generating unique MAC config files, one must also add the reference to it in the boot file.

Seems like there should be a way to tell the boot file to load every .cfg file it finds in a directory. I didn't see anything in the documentation.

Maybe include:config </MACCONFIGS/*.cfg> or some such thing.

RE: Boot files and wildcards? - jolouis - 09-23-2019 04:03 PM

Not sure if this specifically helps you as I'm not certain how your provisioning is structured, but we use:


include:config <y000-$PN.cfg>
include:config <$MAC.cfg>

This is a rough emulation of the older style provisioning where the phone would request first a generic "model" level config, and then an additional MAC specific one. In this case, the phone automatically substitues $PN for the model number, and $MAC for its own mac. On our provisioning server we have it configured to send this specific file to any device that requests anything that ends in .boot. That way we don't have to generate tons of redundant files.

For example, a T23G with mac 805ec0124567 booting will be served:

On our server we solved the "wildcard" you are looking for by having the server concat all the files in the given folder together into the merged cfg. Sure it would be slightly cleaner if the phones pulled everything from a folder, but in our case that wouldn't achieve anything as we like to have the server generate/populate data into the templates as it spits them out into cfg files.

That's how we do it anyway.