A confession from inside a Tier-1 voice provider's NOC, paraphrased only slightly: "We turned on TLS. We offer it as a service. But if a customer doesn't want it, we have a toggle right here. And honestly — if we turn it off, it's a lot easier for everybody."
That's not a hypothetical. That's the operational reality at networks serving tens of millions of subscribers. The marketing pages list TLS and SRTP as features. The provisioning UI lets you turn them on. But across the industry, voice encryption is one of the most quietly-toggled-off capabilities in modern UC — and it isn't because engineers don't care about security. It's because of an architectural choice made when SBCs were the most expensive piece of the network and nobody was being audited.
Every voice network is selling the same product to two customers with completely different definitions of success.
The person on the call wants one thing: the call goes through. Transfers work. Hold music plays. The IVR doesn't drop the bridge. They do not care, in any operational sense, whether their RTP is encrypted.
The security or compliance lead at the same enterprise wants something else entirely. They want the media leg encrypted in transit, the signaling leg encrypted in transit, and a defensible audit trail proving both. They do not particularly care whether the call goes through, because if it doesn't, that's a different team's problem.
When TLS/SRTP interacts badly with a call transfer, a media swap, a recording integration, a fax fallback, or a sloppy SDP renegotiation — and at scale, it always interacts badly with at least one of those — the toggle gets flipped. The first customer is satisfied immediately. The second customer never finds out, because nobody is auditing the configuration state of every endpoint every day.
A network with a TLS/SRTP toggle is a network where TLS/SRTP, in practice, depends on whether anyone has recently filed a ticket.
The toggle exists because of testing economics. A large voice provider runs dozens of distinct call scenarios across the network on any given day: attended transfer, blind transfer, media swap mid-call, recording with CALEA capture, IVR-to-agent handoff, conference bridge, fax fallback, emergency calls, voicemail deposit. Every one of those scenarios has to behave correctly with TLS/SRTP on, with TLS/SRTP off, and across multiple PSTN gateways belonging to different upstream providers. The combinatorics get expensive quickly.
When a defect surfaces — for example, a sequence-number mismatch during media renegotiation that drops one in fifty transferred calls — fixing it in a core network element means risking regression on a hundred other scenarios. The change-control conversation goes the way it always goes. The change gets deferred. The toggle gets documented as a workaround. The toggle gets used.
That's not laziness. That's a rational response to a network design that didn't put encryption in the right place.
The right place is the edge of the network, and only the edge.
If TLS/SRTP only ever lives between the SBC and the phone — and the SBC always terminates encryption, transcodes media, and reissues fresh RTP into the core with every sequence number and timestamp regenerated — then nothing inside the core network ever has to know encryption exists. Recording integrations work the same. CALEA capture works the same. Call transfers work the same. Mid-call SDP renegotiations don't break, because the renegotiation only ever touches the SBC and the endpoint.
The toggle disappears, because there is nothing left to toggle.
This isn't theoretical. It's the architecture you would design today if you were starting from scratch. It's also not free. An SBC that handled 50,000 concurrent calls in pass-through mode handles closer to 12,000 when it transcodes every leg at the edge. You pay for that capacity in CPU, in licenses, hardware, and rack units. A single edge-transcoding SBC cluster — every subscriber terminates against them, every core-side leg is plain RTP — could cost more on day one than the topology most large providers actually built.
It would have been worth it. The cost difference is real, but it is small compared to the operational cost of running a network where your security feature is conditional on whether the support team felt patient that afternoon.
Across the 700-plus cloud communication providers ECG benchmarked, the relationship between provider size and TLS/SRTP support runs in the wrong direction. Larger providers are far more likely to claim the feature. Smaller providers are far less likely to advertise it at all.
That gap is backwards. A small provider has fewer call scenarios to regression-test, fewer PSTN gateways to validate against, fewer customer-specific call flows to break. They can pick a clean SBC architecture without ripping anything out. TLS/SRTP, on a small network, is genuinely not that hard.
What it is, for a small provider, is a procurement gate. Any enterprise with HIPAA, SOC 2, PCI-DSS, FedRAMP, or any other audited security framework is going to disqualify a provider that can't demonstrate encrypted media — even if the local relationship is good and the price is right. Procurement will not bend on this. So a small provider that ships TLS/SRTP correctly is competing for a class of customers that the rest of its size cohort can't reach at all.
For a large provider, the question is harder. It's whether the architecture team is willing to admit that a five-year-old SBC topology decision was wrong, and whether finance is willing to fund the rebuild. Most won't. The toggle stays.
ECG works with voice providers on the parts of the network that don't make it into the marketing pages. "Toggle problems" — TLS/SRTP, STIR/SHAKEN signing rates, automatic E911 location updates, CALEA delivery completeness — all live there. If the gap between your documented capability and your deployed reality is wider than you'd want a regulator to see, that's the engagement we do.