Why SIP trunks fail over TLS version mismatches
A trunk that worked for years suddenly stops registering, and nothing on either side looks broken. Very often the cause is a TLS version that one side no longer accepts.
A trunk that just quietly refuses to register
SIP over TLS (usually port 5061) wraps your signaling in an encrypted tunnel before any SIP message is sent. If the two ends cannot agree on a TLS version, the handshake dies before the first REGISTER or INVITE ever leaves the box. There is no SIP error to read, because SIP never started.
A short, necessary timeline
- TLS 1.0 and 1.1: old, weak, and formally deprecated in 2021. Many carriers and cloud platforms have switched them off.
- TLS 1.2 (2008): the long-running workhorse, and still the minimum most carriers and platforms accept.
- TLS 1.3 (2018): faster handshake and a smaller set of strong ciphers. Support on SBCs and PBXs is growing but still uneven.
Why carriers enforce a minimum version
Signaling carries phone numbers, credentials and routing data. Carriers and platforms such as Teams Direct Routing raise their minimum TLS version to meet security standards, and they do it on their schedule, not yours. An SBC that was last updated years ago may simply not speak the new minimum.
Why the failure looks like something else entirely
Because the handshake fails first, the symptoms look like a network or firewall problem: registration timeouts, a trunk shown as down, calls that never ring. People spend days checking ports and credentials when the real fix is enabling TLS 1.2 on the SBC, or updating its firmware. Compare this with ordinary SIP errors, which at least give you a response code to search for.
Test which TLS versions your SBC accepts
From any machine with OpenSSL, force each version in turn. The one that fails to complete a handshake is your mismatch.
openssl s_client -connect yoursbc.example.com:5061 -tls1_2
openssl s_client -connect yoursbc.example.com:5061 -tls1_3