Nova Wholesale BridgeVoice encryption gets discussed as though it is one setting. It is actually two separate things protecting two separate parts of a call, and knowing which is which makes the vendor conversation much shorter.
A call is two streams, not one
Signalling is the negotiation. It carries who is calling whom, when the call starts and ends, and the details needed to set up the audio. It is SIP, and it is text.
Media is the audio itself. It is RTP, and it travels separately from the signalling, often by a different path.
Encrypting one does not encrypt the other. This is the single most useful thing to understand here, because “we support TLS” is a statement about signalling only.
TLS protects the signalling
SIP over TLS is the same technology as HTTPS, applied to call setup. Without it, signalling travels in plain text and anyone positioned on the path can read:
- Who called whom, and when
- How long the call lasted
- Your account identifiers
- Enough detail to attempt call hijacking or registration theft
That last point is the practical one. Unencrypted SIP credentials on a hostile network are a route to toll fraud, which is a bill rather than a privacy problem.
TLS does not encrypt the audio. A call with TLS signalling and unencrypted media means nobody can see who you called, but the conversation itself is still readable to anyone on the media path.
SRTP protects the audio
SRTP encrypts the media stream. Without it, captured RTP packets can be reassembled into an audio file with freely available tools. This is not exotic.
The keys for SRTP are usually exchanged during signalling, which is why the two belong together: SRTP negotiated over unencrypted SIP means the encryption keys travel in the clear, and the encryption is theatre.
TLS and SRTP go together. Either alone leaves a real gap.
What this does not protect against
Worth being clear, because encryption gets oversold:
- It is hop-by-hop, not end-to-end. Your provider decrypts and re-encrypts to route the call. They can hear it. Encryption protects the call in transit against third parties, not against the people carrying it.
- The far end is out of your control. If the person you called is on an unencrypted connection, that leg is unencrypted. You secure your side.
- The endpoints are still endpoints. A compromised handset or softphone defeats all of it.
- Metadata still exists. Your provider records who called whom. That is what a CDR is, and it is required for billing and lawful requests.
Questions worth asking a provider
- Do you support TLS for signalling and SRTP for media, or only one? If the answer stops at TLS, ask directly about media.
- Is it available on my plan, or is it an upgrade? Some providers gate it.
- What happens if the far end does not support SRTP? Does the call fall back to unencrypted, and will you be told? Silent downgrade is worse than refusal if you have a compliance obligation.
- Which TLS versions? Anything still permitting TLS 1.0 or 1.1 is not being maintained.
- Does my PBX or handset support both? Frequently the limitation is at your end rather than the carrier’s.
Do you need it?
Not every business does, and pretending otherwise is unhelpful.
Strong case: you handle health, financial or legal information; you operate under a regime that requires encryption in transit; your calls traverse networks you do not control, such as remote workers on home or public connections; you have had a security review that asked the question.
Weaker case: an office with a controlled network, a private connection to the carrier, and no sector-specific obligation. Encryption is still a reasonable default, but it is not the biggest thing on your risk register.
The cost is usually small, and there is a slight processing overhead on the endpoints. For most businesses, turning it on and forgetting about it is the right call.
Ask us the five questions
We support TLS and SRTP on trunks that want them, and we will tell you plainly whether your handsets and PBX can do the same. Ask the awkward version of these questions and we will answer them specifically rather than generally.