Snom D785 Can't Provision With RPS

[iamtheari]

We just received our Snom D785 phones. The in-office ones provisioned easily with 3CX. That was fun and easy. But the one that I am trying to set up with RPS isn't getting anywhere. I've updated the firmware to the latest supported version, reset to factory settings, etc. I provision it for the extension. The 3CX dashboard says "RPS request for Snom D785 IP Phone of User Name (ext) delivered successfully."

When the boots up, it seems to get the provisioning data from Snom's server. In the phone's web interface, I get the "secure connection failed" message because my certificate is not recognized. I log into the phone's web interface and make an exception for the certificate. I note that Setup -> Advanced -> Update -> Setting URL is set to my 3CX PBX address, https://fqdn:5001/rps/cfg{mac}. Clearly, the phone at some point is trying to talk to my 3CX.

But when the certificate is in the exceptions list and the phone boots up, it asks to choose a language, time zone, and region for tones. Then it says "Welcome! Press a key to log on." I press a key and it asks for an account. I put in the extension and hit the checkmark key, then it has a blank entry for registrar. That seems to me to say that it's not getting something back from my 3CX. Rebooting the phone again, I get the "Press a key to log on" but below that it says "redirection Provisioning in progress" for about 5 minutes. Then it changes to "pnp Provisioning in progress" for a few minutes. Then it leaves me with the "Press a key to log on" screen. And when I try to log in, it still has nothing in for registrar. I get warnings for the HTTP and Admin passwords not being set, but no other information on the phone that I can see.

My firewall at the office connects the following ports to the 3CX server:
TCP: 5000, 5001, 5090
UDP: 5060, 5061, 5062, 5090, 9000-10999

Audio on the iOS and Windows apps works fine. I can view the web interface on https port 5001 and use the webclient for calls.

Any ideas what I'm missing on provisioning this phone?

 

[AWS2P]

you need to enter extension and VM pin from same extension to log the phone

on which location do you try to provision the phones? on the same LAN where the PBX is or on remote location where the phones needs to be used?

 

[iamtheari]

you need to enter extension and VM pin from same extension to log the phone

on which location do you try to provision the phones? on the same LAN where the PBX is or on remote location where the phones needs to be used?

I am provisioning this remote extension remotely. I provisioned the local ones locally.

All documentation I find says that I'm supposed to log into the newly provisioned remote phone with my extension number and voicemail PIN. However, this one doesn't ask for a password. It asks for my registrar first. If I put my FQDN in and then put in the voicemail PIN, the end result is "not registered: <extension>@<FQDN>.

I am looking in the phone's web interface log file now. As an aside, I do think it's odd that my certificate wasn't trusted, as it is signed by GoDaddy which should be trusted everywhere. Moving on, though, there are various messages like this:

Apr 10 22:59:14.473 [ALERT ] WEBCLIENT: request https://MYFQDN:5001/rps/cfgMYMAC failed due to no response from server (Success) for con_id:1; waiting to timeout so we can resend with BOTV
Apr 10 22:59:19.910 [ALERT ] WEBCLIENT: request https://MYFQDN:5001/rps/cfgMYMAC stopped due to no response from server for con_id:1; resending with timeout 10970 ms

I don't know if 3CX has any logs of HTTPS errors that might help debug these messages.

 

[AWS2P]

normally provisioning is coming alone and you just need to give credentials to connect.
Is this phone alone on this remote site?
did you follow 3CX doc to use a static ip for the phone, a sip port , a rtp range port, nat rules on remote location firewall, settings on extension with sip and rtp range for phone macadress

Try to do a factory reset and restart from scratch

 

[iamtheari]

normally provisioning is coming alone and you just need to give credentials to connect.
Is this phone alone on this remote site?
did you follow 3CX doc to use a static ip for the phone, a sip port , a rtp range port, nat rules on remote location firewall, settings on extension with sip and rtp range for phone macadress

Try to do a factory reset and restart from scratch

I've done approximately 20 factory resets and restarts.

The phone is the only one at my present location. I am testing it before I send it in the mail to the user, who is at a location where I do not have access to the router. My goal is for it to be a plug-and-play replacement for the user's prior VOIP phone that has been talking to our non-SIP PBX for many years.

The URL that the phone can't get works fine on the web browser on my computer at the same location as the phone. When I try to load the URL https://FDQN:5001/rps/cfgMYMAC the browser puts up a username/password dialogue, I put in the extension number and voicemail PIN, and the configuration file downloads for me. The phone just can't seem to negotiate the TLS connection with the 3CX server.

I uploaded the settings file to the phone. It did work and I can make and receive calls between it and another extension on my iPhone. So it seems like this isn't a network routing, firewall, or NAT problem.

The phone takes forever to boot up because it tries to access the provisioning files from my server each time. The same errors show up in the log as when trying to provision it. The relevant log excerpt is below. It seems to be a problem with the phone disliking my SSL certificate.

Apr 10 23:54:36.145 [DEBUG2] TLS: 0x1450dd8 SSL_connect/0 SSLv3 read server hello A (0)
Apr 10 23:54:36.148 [ERROR ] TLS: Error 20 at depth 0: unable to get local issuer certificate
Apr 10 23:54:36.148 [ERROR ] TLS: Cert s: /OU=Domain Control Validated/CN=MYFQDN
Apr 10 23:54:36.148 [ERROR ] TLS: Cert i: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
Apr 10 23:54:36.152 [DEBUG1] TLS: Found trusted cert, fingerprint f030ca581112737cefd6cf14773ac1af3f6cca93
Apr 10 23:54:36.152 [DEBUG1] TLS: Continue with cert due to explicit trust
Apr 10 23:54:36.153 [ERROR ] TLS: Error 21 at depth 0: unable to verify the first certificate
Apr 10 23:54:36.153 [ERROR ] TLS: Cert s: /OU=Domain Control Validated/CN=MYFQDN
Apr 10 23:54:36.153 [ERROR ] TLS: Cert i: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
Apr 10 23:54:36.153 [DEBUG1] TLS: 0x1450dd8 SSL Alert write/21:fatal:unknown CA
Apr 10 23:54:36.153 [DEBUG2] TLS: 0x1450dd8 SSL_connect/21 error in error
Apr 10 23:54:36.153 [DEBUG2] TLS: 0x1450dd8 SSL_connect/21 error in error
Apr 10 23:54:36.154 [ERROR ] TLS: OSSL error (GetDecryptedInput ssl error): code 336134278, error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Apr 10 23:54:36.154 [DEBUG2] TLS: 0x1450dd8 SSL_connect/21 error in error
Apr 10 23:54:36.154 [ERROR ] TLS: OSSL error (GetDecryptedInput ssl error): code 336085247, error:140840FF:SSL routines:ssl3_connect:unknown state

Note the "fatal:unknown CA" error. That's a pretty weird one, and frankly I was a little surprised that my certificate wasn't trusted to begin with because it was issued by GoDaddy. All the browsers I've used to access the 3CX PBX admin console and webclient have been happy with the certificate. But maybe the snom phone has something against it. I wish I could find some kind of a log on the 3CX server to help debug this. But both /var/log/nginx/error.log and access.log are empty.

 

[iamtheari]

I discovered the solution. While my SSL certificate was being trusted by some browsers, others didn't like it. That included the snom phone's internal web client. The solution was to append the GoDaddy intermediate certificate to the certificate file in the nginx configuration in the 3CX server. Now the phone boots up, provisions, gets the 3CX logo, and seems to work great.

Thanks for the help and tips along the way. I hope this post helps someone in the future who runs into a similar issue.

 

[cobaltit]

Yet another reason to stick with the 3CX FQDN and certificate. I don't know why people like making extra work for themselves. But at least you figured it out and posted a solution.