Current Location ：
SIP over TLS and SRTP: Encrypting Signalling and Media
Voice encryption is usually discussed as a single feature and implemented as two independent ones. Signalling encryption and media encryption are configured separately, negotiated separately, and can fail separately. That separation explains most of the confusion around the topic: a system can be encrypting who called whom while transmitting the audio in the clear, or encrypting media while leaving call setup details exposed. Understanding which of the two you have, and where the boundary between them sits, is the difference between a security claim and a security control. This article explains what each mechanism protects, how keying works in practice, what tends to break when encryption is enabled, and how to roll it out without losing calls or recordings.
Two Layers, Two Decisions
Transport Layer Security protects the signalling path: the messages that set up, modify, and end calls. Those messages carry identities, numbers, and addressing, so protecting them prevents passive observation of who is calling whom. Secure Real-time Transport Protocol protects the media path: the actual audio. Enabling one does not enable the other, and a deployment that has only configured one has a large and often unnoticed gap.
| Layer | Mechanism | What it protects | What it does not protect |
|---|---|---|---|
| Signalling | SIP over TLS | Call setup messages, identities, addressing, and dialled information in transit | The audio itself, or anything observable from traffic patterns |
| Media | SRTP | The audio payload of an established call | The existence of the call, its participants, or its timing |
| Keying | Signalled key exchange | Exchange of the material used to protect media | Endpoints that never negotiate protection at all |
What Breaks When You Turn It On
The failures are rarely cryptographic; they are operational. Certificates expire, clocks drift, intermediary devices that inspect or modify signalling can no longer do so, and passive recording that relied on capturing media in the clear stops producing usable audio. None of these are reasons to avoid encryption, but all of them are reasons to plan the change rather than enabling it during a quiet afternoon.
- Certificate validity and trust: endpoints need a trust path to the platform certificate, and expiry becomes a calling outage
- Time accuracy: certificate validation depends on reasonably accurate time, so time drift becomes a registration problem
- Intermediary devices: anything that inspects or rewrites signalling on the path will either fail or force a fallback
- Recording architecture: passive capture of unencrypted media stops working and must be replaced with a supported capture method
- Legacy endpoints: older handsets or gateways may not support modern versions and will silently fall back to unprotected transport
- Mixed environments: a fallback policy that allows unprotected transport will be used by anything that fails to negotiate
Deciding Whether to Allow Fallback
This is the most consequential decision in the design. Allowing fallback means anything that fails to negotiate protection still completes the call, which is good for availability and bad for the security claim. Blocking fallback means unprotected endpoints simply cannot call, which is a genuine improvement in security and a genuine cause of support tickets on the day it is enforced. Most organisations run with fallback allowed during a transition period, inventory what is falling back, remediate those endpoints, and then move to enforced protection. That sequence turns an unknown into a worklist.
Rolling It Out
The safe sequence starts with inventory rather than configuration. Identify every endpoint type, gateway, and carrier handoff that touches the signalling or media path, and confirm what each supports. Deploy certificates and time sources first, because both are prerequisites that fail in confusing ways if added later. Enable protection on a pilot group, confirm calls and recordings still work, measure what is falling back, and only then widen the scope.
Verification should include a call placed from the least capable device in the estate, a recording retrieved end to end, and a call that crosses to the public network through the carrier. Those three cases cover the paths where encryption most often changes behaviour in ways nobody anticipated.
Redstone Approach
Redstone supports encrypted signalling and media deployment on the REX IP-PBX platform and across the NRP handset range, including certificate deployment planning, fallback policy design, and coordination with recording arrangements so compliance capture continues to work. Our teams can inventory your estate, identify what will fall back, and sequence a rollout that does not interrupt live calling. Specific cryptographic configuration and version support are confirmed in writing against your installed equipment and carrier requirements.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
