Help with provisioning Yealink phones on iVozProvider 4.3

[Sami]

Hello everyone,

Has anyone successfully managed to provision phones with iVozProvider version 4.3?

I've tried several times to set up provisioning for Yealink phones (T21, T33G, T30P, and other models), but without success. The only log entry I see is:

[18/Jan/2025:03:28:49 -0500] "GET /provision/y000000000124.cfg HTTP/1.1" 200 940 "-" "Yealink SIP-T33G 124.86.0.75 ba:5e:c0:ab:b8:ff"

Additionally, I notice a temporary file being created:
/tmp/provision-template-a1l0Ha

However, nothing happens on the SIP phones.

Does anyone have any advice or know how to resolve this? Thanks in advance!

[Kaian]

Hi everyone,

There are two terminal provisioning steps in ivozprovider:

 - Generic Provision: Done through HTTP, it contains basic information to the model being provisioned and redirect terminals to specific provisoning URL

 - Specific Provision: This is done through HTTPS (for Yealink port 1443) and provides provisioning information for a single terminal identified by its MAC address.

You can find templates for pre-existing models here, or using the Restore default template button.

For yealink:

Generic Provision

   - Is the one that should be served when terminals request y00000000XXXX.cfg files.

   - For example, Yealink T21P requests the file y000000000034.cfg and its generic provisoning configuration should be something like these

 

- You should be able to test this file with a browser. http://your-portal-provisioning-dns/provision/y000000000034.cfg

$ curl http://your-portal-ip-address/provision/y000000000034.cfg
#!version:1.0.0.1
account.1.enable = 1  
account.1.label = Line  

auto_provision.mode = 6  
auto_provision.schedule.periodic_minute = 1  
auto_provision.server.url = https://your-portal-ip-address:1443/provision/t21  
auto_provision.dhcp_option.enable = 0  
auto_provision.pnp_enable = 0  

local_time.time_zone = +1  
local_time.ntp_server1 = es.pool.ntp.org  
local_time.ntp_server2 =  
local_time.interval = 1000  
local_time.summer_time = 2  
local_time.start_time = 1/1/0  
local_time.end_time = 12/31/23  

security.trust_certificates = 0  

Note that the provision server.url for following requests is configured with the specific provisioning URL, so next provision request will be done to that address.

Specific provision

 - Provides data for a single terminal identified by its MAC (you MUST configure mac address in Terminal screen you want to provision)

 - Always done through HTTPS, and validating client certificate (so only terminals can retrieve it).

 - If you want to test this provision with curl or browser you have to edit apache site config to remove SSLVerifyClient in provisioning sites.

Assuming you have created a terminal like this and assigned it to an existing User with an Extension:

And you have removed the Client Certificate Verification in Apache site you should be able to request this terminal data by running following curl:

curl -k https://your-portal-ip-address:1443/provision/t21/001122334455
#!version:1.0.0.1
account.1.user_name = T21SampleTerminal  
account.1.auth_name = T21SampleTerminal  
account.1.password = gH59WI2zw_  
account.1.display_name = UserWithTerminalAssigned  
account.1.label = UserWithTerminalAssigned  
account.1.sip_server_host = your-vpbx-company-domain.com  
account.1.sip_server_port = 5060  

Be sure to restore client certificate verification after testing, for security reasons.
More information about provisioning can be found in documentation

Best Regards,

Kaian

---

De: ivozprovi...@googlegroups.com <ivozprovi...@googlegroups.com> en nombre de Sami <elma5...@gmail.com>
Enviado: lunes, 20 de enero de 2025 17:34
Para: ivozprovider-users <ivozprovi...@googlegroups.com>
Asunto: Help with provisioning Yealink phones on iVozProvider 4.3

 

--
You received this message because you are subscribed to the Google Groups "ivozprovider-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ivozprovider-us...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ivozprovider-users/17505e55-fe1e-4e01-895f-09522c53e47an%40googlegroups.com.

[Sami]

Hello kaian,

First, I want to thank you sincerely for taking the time to respond to my question. I greatly appreciate your help and support.

I’ve run some tests based on your advice and guidance, but unfortunately, the issue still persists. Here are the results of my initial phases:

Phase 1:

ivozprovider-standalone:~# curl http://10.0.127.222/provision/y000000000124.cfg  

                                 #!version:1.0.0.1  
account.1.enable = 1  
account.1.label = Line  

bw.enable = 0  
features.call_park.park_mode = 0  
auto_provision.mode = 6  
auto_provision.schedule.periodic_minute = 60  
auto_provision.server.url = https://10.0.127.222:1443/provision/t33g/$mac.cfg  

auto_provision.dhcp_option.enable = 0  
auto_provision.pnp_enable = 0  
local_time.time_zone = +1  
local_time.ntp_server1 = es.pool.ntp.org  
local_time.ntp_server2 =  
local_time.interval = 1000  
local_time.summer_time = 2  
local_time.start_time = 1/1/0  
local_time.end_time = 12/31/23  
security.trust_certificates = 0  

auto_provision.force_reboot = 1  

Phase 2:

curl -k https://10.0.127.222:1443/provision/t30p/805ec0eb68ff  
curl: (35) OpenSSL/3.0.15: error:0A000438:SSL routines::tlsv1 alert internal error  

Unfortunately, despite the configuration appearing to work perfectly with version 2.3, nothing happens on the phones when using version 4.3.

It seems there’s an SSL-related issue in the second phase, but even with this, the phones do not respond to provisioning. Do you have any additional suggestions or insights?

Thank you again for your incredible support!

[Kaian]

Hi!

If you want to test with curl, edit your apache site for provisioning (/etc/apache2/sites-enabled/030-ivozprovider-prov.conf) and comment following lines:

<VirtualHost *:1443>
   LogLevel warn
   CustomLog "|/usr/bin/logger -tprov_yealink -plocal6.notice" combined
   ErrorLog  "|/usr/bin/logger -tprov_yealink -plocal6.err"

   # Enable/Disable SSL for this virtual host.
   SSLEngine on
    # SSLProtocol TLSv1
    # SSLCipherSuite AES256-SHA:HIGH:MEDIUM:!aNULL:!MD5:!RC4
   SSLCertificateFile    /etc/ssl/certs/yealink.crt
   SSLCertificateKeyFile /etc/ssl/private/yealink.key

    # SSLVerifyClient require
    # SSLVerifyDepth 3
    # SSLCACertificateFile /etc/ssl/ca/Yealink_Equipment_Issuing_CA.crt
    # SSLOptions +StdEnvVars +ExportCertData

</VirtualHost>

That will remove client validation and enforced tls1 protocol.
Also note that according to your configuration, the specific provisioning request should end with .cfg

    auto_provision.server.url = https://10.0.127.222:1443/provision/t33g/$mac.cfg

So the curl should be something like

    curl -k https://10.0.127.222:1443/provision/t30p/805ec0eb68ff.cfg

So note that the terminal with that mac must have the proper model and be assigned to a user with extension.

Regards

[Airsay]

Hi Kaian,

In my case, I am using a T53W. And I have the provisioning url in the generic pattern set to:

auto_provision.server.url = https://10.10.10.100:1443/provision/t53w

Would this be correct? I'm asking because my test phone doesn't download the specific pattern cfg.

Should it be the above? Or should it be:

auto_provision.server.url = https://10.10.10.100:1443/provision/t53w/$mac.cfg?

Also Yealink seems to have changed that parameter from auto_provision.server.url  to static.auto_provision.server.url . Should I update it to this new one?

Also for the specific pattern, it is set to {mac} by default. Should it be updated to {mac}.cfg? To $mac? To $mac.cfg?

Should the files be set to use the updated field names (that includes static.xxx} or keep the fields to the that the default templates use?

Thank you for the support as always. 

Regards 

[Kaian]

Hi,

> auto_provision.server.url = https://10.10.10.100:1443/provision/t53w

> Would this be correct? I'm asking because my test phone doesn't download the specific pattern cfg.

Check apache logs. Ensure your phone is making that request (it will probably append its mac to that URL).

If no request is logged, do some network captures. I'm not sure if yealink phones provision to URLs with invalid certificates (p.e. with ip address in the URL).

> Should it be the above? Or should it be: 

> auto_provision.server.url = https://10.10.10.100:1443/provision/t53w/$mac.cfg?

I think both will work, because phones tries the configured URL appending different files, one of them is usually macaddress.cfg.

> Also Yealink seems to have changed that parameter from auto_provision.server.url  to static.auto_provision.server.url . Should I update it to this new one?

You can edit the provision templates to fulfil your needs. Feel free to update to match your firmware provisioning settings.

> Also for the specific pattern, it is set to {mac} by default. Should it be updated to {mac}.cfg? To $mac? To $mac.cfg?

If you are using 4.3.0 or 4.4.0 we have changed how terminal provisioning templates are served and we no longer use that field IIRC.

The new implementation just tries to get mac address from the URL and match a Terminal with that address, then serve the specific template for that Terminal's model.

> Should the files be set to use the updated field names (that includes static.xxx} or keep the fields to the that the default templates use?

Not sure what you mean. Most probably you can include new and old fields and your terminal will ignore any setting that does not understand, but without testing I can not say for sure.

We have never used a T53W so I can not suggest any working template.

Best regards!