12.1.1 Customer-specific configuration of multiple phones
By default, device settings that are not SwyxWare-specific are not taken into account at the automatic provisioning. In this case, these settings must be made by the user on the phone or via the web interface.
With a provisioning file, you can distribute the desired settings (also for SwyxWare) to multiple Yealink phones immediately at provisioning or at a later time.
Settings can be addressed to all Yealink devices, to selected device types, or to individual devices.
As not all combinations of SwyxWare settings and device manufacturer settings can be tested, only standard functions of SwyxWare can be guaranteed.
Test your settings on a single device first and limit yourself to necessary changes. Make sure your information is correct and use only settings that do not affect the functionality of the system.
Test your settings on a single device first and limit yourself to necessary changes. Make sure your information is correct and use only settings that do not affect the functionality of the system.
Customer-specific provisioning file
You can create a file in the format of a typical Yealink provisioning file.
The data in this file supplements or overwrites the SwyxWare settings. Name the file "common.cfg" or "mac.cfg" and upload it to the SwyxWare. Once the file is uploaded, SwyxWare will distribute the new settings to the targeted phones, see 12.1.1.2 Provisioning file upload.
File Format
The file consists of header line(s) and parameter lines. A header controls the application of the subsequent parameters:
Specifications before the first header line have no effect on the phone settings. You can use this area for your comments.
In addition, all lines below the header and beginning with "##" are also considered comment lines.
Here is an example of the file:
##+==================================================+
##| ~~~~~~ e.g.: Network: NB45 ~~~~~~~~~~~~~~~~~~~ |
##| ~~~~~~ e. g.: Provisioning on 28.09.24 ~~~~~~ |
##+==================================================+
##< And here are more comments... >
##--boundary---mode:default---models:T53W
## and here another comment
static.my.parameter1=value1
static.my.parameter2=value2
static.my.parameter3=value3
##--boundary---mode:overwrite---models:T57W,T54W
static.my.parameter1=value1
static.my.parameter2=value2
static.my.parameter3=value3
##--boundary---mode:default---devices:805ec07f962a
static.my.parameter1=value1
static.my.parameter2=value2
static.my.parameter3=value3
|
Header value
|
Explanation
|
|---|---|
|
##--boundary
|
Default start of a header
|
|
---mode:
|
Application mode:
default
The parameters after this header are only added if they have not already been set by SwyxWare.
overwrite
The parameters after this header will be added and may overwrite the possibly existing parameters from SwyxWare.
|
|
---models:
|
Specification of the device type:
---models:T57W
or, to address multiple models:
---models:T54W,T57W
|
|
---devices:
|
MAC address of the device:
---devices:805ec07f962a
or, to address multiple devices:
---devices:805ec07f962a,805ec07f962b
|
It is recommended to use the "---overwrite" application mode only in exceptional cases.
The options "---models:" and "---devices:" cannot be put together in one header.
If neither "---models:" nor "---devices:" is specified, the setting affects all Yealink phones in your network.
If neither "---models:" nor "---devices:" is specified, the setting affects all Yealink phones in your network.
Overlaps in the configuration
If the same parameter is repeated under multiple headers with different values, the value under the most specific header is used for the provisioning phone. This results in the following validity priority:
1 Device-specific header with the lowest number of devices.
##--boundary---mode:default---devices:805ec07f962a
static.my.parameter1=value1
##--boundary---mode:default---devices:805ec07f962a,805ec07f962b
static.my.parameter1=value2
In this case, "value1" is written on device 805ec07f962a, although this device is listed in the other header along with another device.
2. Type-specific header with the lowest number of device types
##--boundary---mode:default---models:T53W,T57W
static.my.parameter1=value1
##--boundary---mode:default---models:T53W
static.my.parameter1=value2
In this case, "value2" is adopted on all T53W devices, although this device type is listed in the other header together with another device type.
3. Header without device or type specification
##--boundary---mode:default
static.my.parameter1=value3
##--boundary---mode:default---models:T53W,T57W
static.my.parameter1=value2
##--boundary---mode:default---devices:805ec07f962a
static.my.parameter1=value1
In this case the device with the MAC address 805ec07f962a receives the value "value1". The device types T53W and T57W receive the value "value 2". All other phones get the value "value3".
The order of the headers and parameters is irrelevant for prioritization. If there are headers with the same applicable device or type number, you should define the headers so that the parameters are uniquely assigned to the phones.