"The best business telephones in the world."

I noticed this old thread, but this is actually still an issue.

Or better said; the issue seems to have become worse since newer firmware was released.

And now I do see an issue with "Mass Deployment" because the time-out to fail-over to DHCP provisioning is now 5 minutes. 

It used to be just a couple of seconds, but with the newer firmware it now takes lots longer. And when you are a technician attempting to configure a new phone, it is not acceptable to wait 5 minutes!

Attach is the full log file of my Snom D375 running 10.1.42.14 firmware, which clearly shows whats happening.

And here below are some important notifications taken from that log-file:

Mar 3 15:41:00.789 [NOTICE] PHN: Fetching URL: http://provisioning.snom.com:80/snomD375/snomD375.htm

Mar 3 15:41:05.453 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 9098 ms

Mar 3 15:41:09.893 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:41:14.556 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 18196 ms

Mar 3 15:41:23.553 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:41:32.753 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 36392 ms

Mar 3 15:41:41.753 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:42:09.153 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 72784 ms

Mar 3 15:42:18.183 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:43:21.984 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 145568 ms

Mar 3 15:43:30.983 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:45:47.562 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm stopped due to no response from server for con_id:1; resending with timeout 291136 ms

Mar 3 15:45:56.563 [ALERT ] WEBCLIENT: request http://provisioning.snom.com:80/snomD375/snomD375.htm failed due to no response from server (Connection timed out) for con_id:1; waiting to timeout so we can resend with BOTV

Mar 3 15:46:00.802 [NOTICE] PHN: SetProvisioningDone

Mar 3 15:46:00.803 [NOTICE] PHN: Skipping prio 2 setting server, type pnp, url: ><

Mar 3 15:46:00.803 [NOTICE] PHN: Setting server prio 3, type dhcp, url: >http://pbx.example.net/configs/snom/scripts/device-init.php?mac=%7Bmac%7D<

Mar 3 15:46:00.803 [NOTICE] PHN: SetProvisioningActive

So, at 15:41h the phone tries to contact the SRAPS server, but it keeps retrying until 15:46h when finally it gives up and attempts to contact our own provisioning server. 

Does anyone have a proper solution?

Hi,

I have the same problem! Provisioning via DHCP-provided server is working, but it would be great if the timeout could be reduced - maybe by another DHCP-option?

At least this only occurs at the very first provisioning after resetting a phone. Afterwards the mentioned setting "provisioning_order" solves this.

Best regards

Johannes

We have exactly the same problem. How to make the first time provisioning faster? It would be even better to skip redirection in default settings and change provisioning order to "pnp:stop dhcp:stop tr69:stop redirection:stop" or something else. Is it possible to get this done via any DHCP Option or SIP PnP?