SBC TLS and SRTP Configuration Guide: Securing SIP Signaling and Voice Media

SIP signaling travels in plaintext by default. So does the audio. Without encryption, anyone with access to the network path between two endpoints can capture SIP messages, extract call metadata, and reconstruct entire voice conversations from captured RTP packets.
Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP) solve these problems, but they protect different things. TLS encrypts the signaling channel (the SIP messages that set up, modify, and tear down calls). SRTP encrypts the media channel (the actual voice packets). A Session Border Controller (SBC) is the network element that enforces both at the voice network edge.
This guide covers the practical steps for configuring TLS and SRTP on an SBC: how the two protocols depend on each other, where encryption boundaries belong in your network architecture, how to handle mixed environments with legacy equipment, and how to troubleshoot the most common deployment issues.

Why SRTP Must Be Deployed With TLS

It is tempting to treat TLS and SRTP as only complementary. They are not. The security of one depends on the other, and deploying SRTP without TLS creates a false sense of security.
Here is why. The most common SRTP key exchange mechanism, SDP Security Descriptions (SDES, defined in RFC 4568), embeds the encryption keys directly in the SDP body of SIP messages. When an endpoint sends a SIP INVITE to set up an encrypted media session, the SDP offer includes a crypto attribute containing the SRTP key in base64 encoding.
If that SIP INVITE travels over unencrypted UDP or TCP, the SRTP keys are visible to anyone who can capture the signaling traffic. An attacker who intercepts the SIP exchange can extract the keys, then use them to decrypt every SRTP media packet in the session. The voice encryption becomes meaningless.
TLS prevents this by encrypting the entire SIP message, including the SDP body and its crypto attributes. With TLS active, an attacker who captures traffic on the signaling path sees only the encrypted TLS session, not the SIP content or the SRTP keys inside it.
The deployment rule is simple: never deploy SRTP over unencrypted SIP signaling in a production environment. The SBC is the right place to enforce this rule, because it terminates and re-originates both signaling and media at the network edge.

Architecture: Where Encryption Lives in Your Network

A ProSBC operating as a Back-to-Back User Agent (B2BUA) terminates SIP sessions on each side independently. This architecture is critical for encryption because it means the SBC manages two completely separate security contexts: one for each leg of the call.
On the external leg (facing a SIP trunk provider or carrier), the SBC can enforce TLS and SRTP. On the internal leg (facing your IP-PBX, contact center, or endpoint), the SBC can use whatever transport the internal equipment supports. The two legs are independent, each with its own encryption policy.
This creates three practical deployment patterns.

Pattern 1: End-to-End Encryption

Both sides of the SBC support TLS and SRTP. The SBC can operate in SRTP relay mode, passing encrypted media through without decrypting it. This preserves end-to-end encryption and reduces SBC processing load. Signaling on both legs runs over TLS.
This pattern is ideal when both your internal infrastructure and your external peers support modern encryption. It provides the strongest security posture.

Pattern 2: Encryption Bridge

One side supports TLS and SRTP. The other does not. This is the most common real-world deployment scenario where the ProSBC is securing the existing telephony system.
Your SIP trunk provider or Microsoft Teams requires TLS and SRTP. Your legacy IP-PBX only supports UDP and RTP. The SBC sits between them, accepting unencrypted SIP/RTP from the PBX and converting to TLS/SRTP toward the external peer. No forklift upgrade of the PBX is needed.
The SBC performs RTP-to-SRTP conversion on the media path and TLS termination/origination on the signaling path. The internal network remains unencrypted (and should be protected by other network security controls), while all traffic crossing the public internet is fully encrypted.

Pattern 3: Per-Trunk Encryption Policies

Real networks are not uniform. You may have some carrier connections that require TLS and SRTP, others that only support TLS without SRTP, and internal trunks where encryption is unnecessary.
A properly configured SBC allows you to set encryption policy per trunk group (called a Network Access Point, or NAP, in ProSBC terminology). Each trunk independently specifies whether TLS is required, preferred, or disabled, and whether SRTP is required, preferred, or disabled.
This granularity is essential. A global encryption policy forces you to either encrypt everything (breaking legacy connections) or encrypt nothing (leaving external connections exposed). Per-trunk policies let you enforce encryption exactly where it is needed.

Configuring TLS: Securing SIP Signaling

TLS configuration on an SBC involves four steps: certificate management, listener configuration, per-trunk policy assignment, and optional mutual TLS.

Step 1: Certificate Management

Every TLS connection requires the SBC to present a valid X.509 certificate to its peers. ProSBC sets a default configuration for this parameter. The certificate must meet these requirements:
The certificate’s Common Name (CN) or Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) that external peers use to reach the SBC. If your SBC’s signaling address is sbc.example.com, the certificate must be issued for that domain.
The certificate must be issued by a Certificate Authority (CA) trusted by your peers. For general SIP trunking, certificates from public CAs like DigiCert, Sectigo, or Let’s Encrypt work. However, some service providers may have more strict requirements in this regard, such as for Microsoft Teams Direct Routing: the certificate must be issued by one of the CAs on Microsoft’s published trusted root list.
Install both the SBC public certificate and its private key (as local certificate) and the full CA chain (as trusted certificates) on the SBC. Missing intermediate certificates in certificate chains are one of the most common causes of TLS handshake failures.
Set up a “certificate audit” process. A TLS certificate that expires without renewal will cause immediate call failures on every trunk that uses it. Make sure to conduct regular audits/monitoring to ensure none of the certificates are expired.

Step 2: Enable TLS Listening

Configure the SBC to listen for TLS connections on its signaling interface. Key settings include:
Listening port. The default TLS port for SIP is 5061, but this is fully configurable. If you need to use a different port for operational or security reasons, configure it accordingly. The important thing is that your peers know which port to connect to.
Minimum TLS version. If your SBC supports older versions of TLS, disable TLS 1.0 and TLS 1.1, which have known vulnerabilities. Set TLS 1.2 as the minimum. TLS 1.3 is preferred where both sides support it, as it provides improved security and a faster handshake (one round trip instead of two). ProSBC only allows TLS 1.2 when TLS 1.3 is not used.

Step 3: Set TLS Policies

Set the TLS policy for all trunk group based on the requirements of the peers. For example: TLS (1.3 by default, or 1.2), TCP, or UDP.

Step 4: Mutual TLS (mTLS)

Standard TLS is one-directional: the SBC presents its certificate to the peer, and the peer validates it. The peer does not prove its identity to the SBC (note: the SBC is the client and the peer is the server in this example).
Mutual TLS adds a second validation step. The SBC also requests and validates the peer’s certificate. This prevents unauthorized devices from establishing SIP connections with the SBC, even if they know the correct IP address and port.
mTLS is required for Microsoft Teams Direct Routing and is recommended for carrier interconnects and any environment with regulatory compliance requirements. To configure mTLS, install the trusted CA certificates (or specific peer certificates) on your SBC’s trust store, and configure the trunk to require peer authentication.

Configuring SRTP: Encrypting Voice Media

With TLS securing the signaling channel, you can safely configure SRTP for media encryption. SRTP configuration involves three decisions: key exchange method, RTP-to-SRTP encryption, and SRTP relay behavior.

Step 1: Key Exchange Method

Two key exchange mechanisms are used in practice:
SDES (SDP Security Descriptions, RFC 4568) is the most widely supported method. SRTP keys are exchanged in the crypto attribute of the SDP offer or answer within SIP signaling. SDES is simple to configure and compatible with most SIP endpoints and trunking providers. The critical requirement: SIP signaling must run over TLS when using SDES, because the keys are embedded in the SDP body in plaintext.
DTLS-SRTP exchanges keys via a separate DTLS handshake on the media path, independent of SIP signaling. It is required for WebRTC applications, more complex to configure, and does not depend on SIP signaling for key exchanges. DTLS-SRTP is used primarily for browser-based voice and video applications.
(Note: there are technically other exchange methods called ZRTP and MIKEY but these are not commonly used in the field).
For most SBC deployments involving SIP trunking, carrier peering, and unified communications platforms, SDES over TLS-protected signaling is the standard approach.

Step 2: RTP-to-SRTP Conversion

This is one of the most valuable capabilities of an SBC in a mixed encryption environment. When one side of a call supports SRTP and the other does not, the SBC converts between the two:
The SBC receives unencrypted RTP media from the legacy endpoint. It encrypts the media as SRTP and forwards it to the encryption-capable peer. In the reverse direction, it decrypts incoming SRTP and sends RTP to the legacy endpoint.
This conversion happens transparently. Neither endpoint knows the other side uses a different media transport. The SBC handles all key management, encryption, and decryption.
Common use cases for RTP-to-SRTP conversion include connecting a legacy IP-PBX (RTP only) to a SIP trunk provider requiring SRTP, bridging an older contact center platform to Microsoft Teams, and supporting remote users on encrypted connections while the headquarters PBX runs unencrypted internally.

Step 3: SRTP Relay

When both endpoints support SRTP, the SBC can operate in relay mode. It passes the encrypted media through without decrypting and re-encrypting it. This preserves end-to-end media encryption and reduces the SBC’s processing overhead.
SRTP relay is appropriate when both peers negotiate compatible key exchange method and cipher suites and the SBC does not need to inspect or modify media (no transcoding, no recording, no media manipulation required on that call).

Deployment Scenarios

Microsoft Teams Direct Routing

Teams Direct Routing has specific encryption requirements. The SBC must support TLS (mutual TLS with Microsoft’s published CA roots), and all media must use SRTP. The SBC sits between the Teams infrastructure and your PSTN connectivity, handling TLS/SRTP toward Teams and whatever transport your SIP trunk provider supports on the other side.
Key configuration points: install a certificate from a Microsoft-approved CA, configure mTLS on the Teams-facing trunk, set SRTP to required, and enable RTP-to-SRTP conversion if your SIP trunk provider does not support SRTP.

SIP Trunking Provider Peering

Major SIP trunk providers (Bandwidth, Telnyx, Twilio, and others) now support TLS and SRTP. Enable TLS on the carrier-facing trunk and set SRTP to required or preferred depending on the provider’s documentation. Some providers support mTLS; check their configuration guides.

Legacy PBX Integration

Many organizations run IP-PBXs that were deployed before TLS and SRTP were standard. These systems support only UDP/TCP for signaling and RTP for media. The SBC handles encryption conversion without requiring any changes to the PBX.
Configure the PBX-facing trunk with TLS disabled and SRTP disabled. Configure the external-facing trunk with TLS required and SRTP required. The SBC bridges between the two encryption domains.

Remote and Work-From-Home Users

SIP phones and softphones connecting over the public internet should always use TLS and SRTP. Without encryption, a user on a coffee shop Wi-Fi network is transmitting voice calls in cleartext over a shared network.
Configure the access-side trunk to require TLS and SRTP. This protects both the signaling metadata and the voice content from eavesdropping on untrusted networks.

Troubleshooting Common TLS and SRTP Issues

TLS Handshake Failures

Expired certificate is the most common TLS issue. The SBC’s certificate has expired and peers reject the connection. Check certificate expiry dates and renew before expiration.
Untrusted CA occurs when the peer does not trust the CA that issued your certificate. Install your certificate chain (including intermediates) and verify the peer’s trust store includes your CA. For Teams Direct Routing, verify your CA is on Microsoft’s approved list.
FQDN mismatch happens when the certificate’s CN or SAN does not match the hostname the peer uses to connect. The certificate must match the FQDN in the SIP headers, not just the IP address.
TLS version mismatch occurs when your SBC requires TLS 1.2 but the peer only supports TLS 1.0, or the reverse. Check minimum TLS version settings on both sides.

SRTP Negotiation Failures

Cipher suite mismatch happens when the SBC offers a single key exchange method but the peer only supports a different suite. Review crypto suite configuration on both sides.
Missing crypto attribute occurs when the remote endpoint does not include a crypto attribute in its SDP. It may not support SRTP, or SRTP may not be enabled on its side. If the trunk is set to SRTP required, the call will fail.
SRTP offered but rejected happens when the peer includes crypto attributes in the offer but the SBC’s response removes them, or vice versa. Check that SRTP is enabled on the correct trunk and that the enforcement mode is not set to disabled.

One-Way Audio After Enabling SRTP

This could be caused by a variety of things, including an interoperability problem with SRTP implementations, an SRTP negotiation issue via SIP/SDP, or it could be a simple network issue. When SRTP is enabled, media may use different ports or different transport characteristics. Check that firewalls between the SBC and endpoints allow the SRTP media ports. Verify NAT configuration is not rewriting SRTP packet headers. Use packet capture to confirm media is flowing in both directions.

Certificate Renewal Disruptions

Replacing a certificate on a production SBC can cause brief service interruptions if not handled carefully. Best practice: upload the new certificate alongside the existing one, verify TLS handshakes succeed with the new certificate in a test environment, then switch the production SBC to the new certificate during a maintenance window.

Diagnostic Tools

SIP trace captures (showing full SIP message content, including SDP crypto attributes) and live packet capture (equivalent to Wireshark on the SBC itself) are the primary tools. Use SIP traces to verify that TLS sessions are established, that SDP includes crypto attributes, and that SRTP is successfully negotiated in the SDP answer.

Best Practices Checklist

Following these practices will help ensure your TLS and SRTP deployment is secure, maintainable, and resilient.

1. Deploy TLS before SRTP.Secure the signaling channel first to protect SRTP key exchange.
2. Use TLS 1.2 or higher.Disable TLS 1.0 and 1.1 on all trunks.
3. Enforce encryption on all external-facing trunks.Any traffic crossing the public internet should use TLS and SRTP.
4. Configure per-trunk policies.Different trunks have different requirements.
5. Set reminders to check certificate expiries.30-day and 7-day warnings.
6. Use mTLS for carrier peering.One-way TLS is not sufficient for high-security connections.
7. Enable RTP-to-SRTP conversion for legacy integration.Do not leave legacy endpoints as a reason to skip SRTP on external trunks.
8. Test with packet captures.After enabling encryption, verify with a capture that signaling is TLS-encrypted and that media payloads show as encrypted SRTP.
9. Document per-trunk encryption policy.Maintain a matrix of which trunks use TLS, SRTP, mTLS, and which key exchange method. This documentation is essential for compliance audits.
10. Review cipher suites regularly.Cryptographic standards evolve. Make sure to update your stack, read release notes, and deprecate weak algorithms as guidance changes.

What to Look for in an SBC for Encryption

Not all SBCs handle encryption the same way. If you are evaluating an SBC for a deployment that requires TLS and SRTP, look for these capabilities:

Per-Trunk TLS and SRTP Policies

The SBC must allow you to configure encryption independently on each trunk group. Global-only settings do not work in real networks with mixed requirements.

RTP-to-SRTP Conversion

Without this capability, you cannot encrypt media for legacy endpoints. This single capability often determines whether a migration to encrypted voice is possible without replacing existing infrastructure.

SRTP Relay

For end-to-end encryption scenarios, the SBC should be able to pass encrypted media through without decrypting it.

B2BUA Architecture

Full SIP termination and re-origination on each leg enables independent encryption contexts. SIP proxy-based SBCs cannot provide the same level of encryption control.

Configurable TLS Settings

Ports, cipher suites, TLS versions, and certificate management should all be configurable, not hardcoded.

Built-in Diagnostic Tools

Live packet capture and SIP trace capabilities on the SBC itself are essential for troubleshooting encryption issues without deploying external monitoring infrastructure.

Frequently Asked Questions