Security & FraudKnowledge baseSession Border Controller · Generic Standard Implementation

Configuring TLS and SRTP for Secure SIP Trunking on Session Border Controllers

by Provider Adminlast verified 2026-07-27

Overview

This guide details the architectural and step-by-step configuration required to enforce Transport Layer Security (TLS) for SIP signaling and Secure Real-time Transport Protocol (SRTP) for media on Session Border Controllers. Readers will learn how Public Key Infrastructure (PKI) integrates into SBC signaling interfaces, how Mutual TLS (mTLS) handshakes are established with ITSPs, and how SDP crypto attributes are negotiated for end-to-end media encryption.

Illustration for Configuring TLS and SRTP for Secure SIP Trunking on Session Border Controllers

Key takeaways

TLS secures the SIP signaling plane (typically port 5061), protecting call metadata, URIs, and authentication headers from interception.
SRTP secures the media plane by encrypting RTP audio/video payloads, using keying material negotiated via SDP (SDES) or DTLS.
Mutual TLS (mTLS) is standard for carrier SIP trunks, requiring both trust anchor (CA) importation and local X.509 certificate presentation.
Cipher suite alignment between the SBC, internal IP-PBX, and external ITSP is essential to prevent handshake negotiation failures.
Media crypto profiles must be explicitly bound to signaling profiles to enforce mandatory SRTP or allow fallback to plain RTP when required.

Prerequisites

Administrative privileges on an enterprise or carrier-grade SBC (e.g., Ribbon, Oracle Acme Packet, or Kamailio/OpenSIPS).
Active PKI environment or commercial CA access to issue modern X.509 certificates with SAN (Subject Alternative Name) entries.
Fundamental understanding of SIP offer/answer models, TCP/UDP networking, and PKI certificate chains.

Guide

section #1
Architectural Overview of Secure SIP Trunking Secure SIP trunking segregates security enforcement into two distinct layers: the control plane (signaling) and the data plane (media). The control plane utilizes Transport Layer Security (TLS) over TCP (typically port 5061) to create an encrypted tunnel that protects SIP method headers, credentials, and Session Description Protocol (SDP) payloads. The data plane utilizes Secure Real-time Transport Protocol (SRTP) over UDP to encrypt digitized voice streams. Because the SBC sits at the network boundary, it often acts as a security boundary perform back-to-back user agent (B2BUA) functions—decrypting signaling/media on the untrusted WAN side and either re-encrypting or offloading it to the internal LAN side.
section #2
PKI Preparation and Certificate Chain Management Before establishing a TLS connection, the SBC must be configured with a valid Public Key Infrastructure (PKI) identity. This process requires generating a 2048-bit or 4096-bit RSA (or ECC) Key Pair and a Certificate Signing Request (CSR) on the SBC. The CSR is signed by a mutually trusted Certificate Authority (CA). Once issued, the server certificate, intermediate CAs, and root CAs must be imported into the SBC's TLS trust store. For Mutual TLS (mTLS), which is standard for B2B carrier trunks, the SBC validates the ITSP's certificate against its trusted CA store while simultaneously presenting its own client certificate during the TLS ServerHello/ClientCertificate exchange.
```
# Example: Verifying an SBC certificate chain and private key match via OpenSSL
openssl x509 -noout -modulus -in sbc_cert.crt | openssl md5
openssl rsa -noout -modulus -in sbc_private.key | openssl md5

# Inspecting CA store bundle compatibility
openssl verify -CAfile ca_bundle.crt sbc_cert.crt
```
section #3
Configuring the SBC TLS Signaling Profile To enable TLS signaling, you must define a TLS Profile on the SBC that references the local device certificate, the private key, and the trusted CA bundle. Security best practices dictate disabling deprecated protocols (SSLv2, SSLv3, TLS 1.0, and TLS 1.1) and explicitly configuring TLS 1.2 or TLS 1.3. Additionally, strong cipher suites supporting Forward Secrecy (ECDHE) should be prioritized. Once defined, the TLS profile is bound to a SIP Signaling Interface listening on TCP port 5061, and peer profiles are updated to mandate TLS for outbound trunking destinations.
```
SBC-TLS-Profile-Config (Conceptual Syntax):
  Profile Name: Secure_ITSP_TLS_Profile
  TLS Version Min: TLSv1.2
  TLS Version Max: TLSv1.3
  Cipher Suites: 
    - ECDHE-RSA-AES128-GCM-SHA256
    - ECDHE-RSA-AES256-GCM-SHA384
  Certificate Context: Local_SBC_Identity_2026
  Trusted CA List: ITSP_Root_And_Intermediate_Bundle
  Client Authentication: Required (mTLS Enabled)
  DH Minimal Key Size: 2048
```
section #4
Negotiating SRTP via SDP Crypto Attributes (SDES) When using Session Description Protocol Security Descriptions (SDES - RFC 4568), keying material for SRTP is exchanged directly within the SDP body of the SIP INVITE and 200 OK messages. Because the SIP signaling layer is already encrypted via TLS, exchanging cleartext media master keys in the SDP `a=crypto` lines is considered secure. The SBC must be configured with a Media Crypto Profile that defines acceptable SRTP suites, such as `AES_CM_128_HMAC_SHA1_80` or `AEAD_AES_128_GCM`. The SBC injects these attributes into outbound offers and validates them on inbound answers.
```
v=0
o=SBC 102938 102938 IN IP4 192.0.2.10
s=Secure Call
c=IN IP4 192.0.2.10
t=0 0
m=audio 35002 RTP/SAVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:W1dIZ3A2T3pScmR3OThGN213S3ZwNm13e2p3S3Zw|2^20|1:32
```
section #5
Alternative Key Exchange: DTLS-SRTP Strategy In scenarios involving WebRTC gateways, direct edge endpoints, or security policies prohibiting inline key exchange via SDES, DTLS-SRTP (RFC 5764) is implemented. Under DTLS-SRTP, the SIP SDP contains an `a=fingerprint` attribute representing the hash of the endpoint's X.509 certificate, while the actual SRTP key exchange happens out-of-band over UDP pseudo-random handshakes after the media path is opened. The SBC must support media-level DTLS passthrough or DTLS termination/re-encryption depending on whether media transrouting or transcoding is required.
```
v=0
o=SBC 48201 48201 IN IP4 192.0.2.10
s=DTLS-SRTP Call
c=IN IP4 192.0.2.10
t=0 0
m=audio 40000 UDP/TLS/RTP/SAVPF 111 101
a=rtpmap:111 opus/48000/2
a=fingerprint:sha-256 4A:AD:B9:B1:3F:24:18:28:CF:99:A8:72:01:A2:30:26:07:D2:C3:98:C3:A2:52:8A:CE:24:0E:6E:9B:F7:71:03
a=setup:actpass
```
section #6
Media Profile Binding and Encryption Fallback Rules A critical SBC configuration step is defining how the SBC handles encrypted-to-unencrypted transitions. When bridging a secure external trunk (TLS/SRTP) to an legacy internal PBX (UDP/RTP), the SBC acts as a media and signaling gateway. The media profile must be configured to dictate strict enforcement or flexible interworking. Strict mode rejects calls if SRTP negotiation fails (e.g., returning a `488 Not Acceptable Here` response), whereas interworking mode dynamically translates `RTP/SAVP` on the WAN interface to `RTP/AVP` on the LAN interface.
section #7
Validation, Verification, and Operational Diagnostics Validating a secure SIP trunk configuration requires analyzing both signaling handshakes and media streams. Troubleshooting TLS failures typically involves capturing traffic on port 5061 using tools like Wireshark and filtering for `tls.handshake`. Common issues include certificate untrust errors (`unknown ca`), hostname mismatches in the Subject Alternative Name (SAN), or mismatched cipher suites. For SRTP diagnostics, engineers should inspect the SBC's active call tables to confirm packet counts on SAVP streams and verify that unencrypted media is not leaking onto untrusted networks.
```
# Capture TLS signaling and SRTP traffic on SBC Linux shell
tcpdump -i eth0 -nn -s 0 -w sbc_security_trace.pcap 'port 5061 or (portrange 30000-40000)'

# OpenSSL test command to verify remote ITSP TLS listener and certificate
openssl s_client -connect trunking.itsp-example.com:5061 -tls1_2 -showcerts
```

Configuring TLS and SRTP for Secure SIP Trunking on Session Border Controllers

Overview

Key takeaways

Prerequisites

Guide

Further reading