I usually test VOIP systems with my Cisco SPA502 desktop IP phone. It is a stable, good quality device, a bit maybe old, but it always worked stably. It caused me a bit of a headache lately. I have found that my VOIP account that is set up and working well so far is not registering, and my extension cannot be connected.
I use TLS transport for security, so the signaling system travels on the network in at least a reliable, encrypted way. By setting the device to UDP for the duration of a test, the problem was eliminated, my extension came to life anyway.
From the phone side network separation would have made it a little bit harder to log and test because the IP phone is in a separate voice VLAN and I couldn’t simply hang a syslog server inthere, so I started investigating the problem from the server side first. On the Asterisk PBX where this extension is connected, I came across messages like this in the log on the server side:
[2020-07-16 22:54:50] ERROR tcptls.c: Problem setting up ssl connection with peer '126.96.36.199:5069': error:00000001:lib(0):func(0):reason(1), Internal SSL error [2020-07-16 22:54:50] WARNING tcptls.c: FILE * open failed from peer '188.8.131.52:5069'!
I moled the internet looking for the solution to see how the community solved similar problems, who had already encountered a similar one, but as such a multitude, I now came across illogical solutions that randomly modified the TLS settings in the configuration. Even though I don’t believe in trying, I tried a few myself, but these certainly didn’t solve the problem. After that, I used engineering methods to solve the problem. I suspected everything, old firmware, too new OpenSSL. I wouldn’t bore anyone with the steps and conclusions of the solution, but the result was that my Cisco SPA502 - and probably at least the entire SPA500 series, if not the other Cisco IP phone s are also affected - does not include Let’s Encrypt root CA that I used for testing at the time as a trusted certification authority, and encryption will fail early in the handshake phase.
The solution is to use a certificate whose root CA is in the device's trusted list. For a Cisco device, as far as I know, there is simply no way to specify an external CA as trusted, or at least not with some homemade DIY methods. I tested the settings with a Windows softphone and Yealink phones and the same setup was not a problem on those. Cisco allegedly had a Trusted Certificate Authority list, but I could not find an accurate and up-to-date list for it.
This isn’t a marketing page, so I’m not writing a specific certificate issuer here, but the problem can be solved for roughly $ 10 a year.