What Is SIP TLS?
SIP TLS (SIP over TLS) encrypts SIP signaling using the Transport Layer Security protocol. Standard SIP signaling is transmitted in plaintext over UDP/TCP by default, meaning anyone on the network can intercept and read SIP messages using packet capture tools (such as Wireshark), including sensitive information like caller, callee, and call timestamps.
SIP over TLS uses the standard TLS handshake process to establish an encrypted channel, ensuring that SIP signaling cannot be eavesdropped on or tampered with during transmission. SIP TLS uses port 5061 by default (instead of standard SIP port 5060), and its specification is defined in RFC 3261, Section 26.
Core Functions of SIP TLS
- Signaling Encryption: Encrypts all SIP requests and responses, including INVITE, REGISTER, BYE, and more
- Identity Verification: Validates server identity through X.509 digital certificates, preventing man-in-the-middle attacks
- Integrity Protection: Uses HMAC message authentication codes to ensure signaling data has not been tampered with
- Forward Secrecy: When using ECDHE key exchange algorithms, even if the server private key is compromised, historical call records cannot be decrypted
TLS Handshake Process (SIP Scenario)
- SIP client connects to the server's port 5061 via TCP
- Client sends ClientHello with supported TLS versions and cipher suite list
- Server responds with ServerHello, digital certificate, and key exchange parameters
- Client verifies server certificate (checks CA chain, validity period, domain name matching)
- Both parties negotiate and generate a session key (symmetric encryption key)
- All subsequent SIP messages are transmitted through this encrypted channel
What Is SRTP?
SRTP (Secure Real-time Transport Protocol) is a protocol that provides encryption and authentication for RTP media streams, defined in RFC 3711. RTP is the protocol that carries actual voice data in VoIP calls. Without RTP encryption, attackers can directly listen to call content through network sniffing.
SRTP adds the following security mechanisms on top of RTP:
- Encryption: Uses AES (Advanced Encryption Standard) to encrypt RTP payloads, supporting AES-CTR (Counter Mode) and AES-F8 modes
- Message Authentication: Uses HMAC-SHA1 algorithm for integrity verification of RTP headers and payloads, preventing data tampering
- Replay Protection: Prevents replay attacks through sequence number mechanisms (ROC + SEQ)
SRTP Encryption Overhead
| Item | RTP (Unencrypted) | SRTP (Encrypted) |
|---|---|---|
| Extra Header Bytes | 0 | 4 bytes (auth tag) |
| Encryption Latency | 0 | < 0.5ms |
| CPU Overhead | Low | Low (AES-NI hardware acceleration) |
| Bandwidth Increase | 0% | Approx. 0.5%-1% |
Key Concept: SRTP encrypts the voice media stream (call content), while SIP TLS encrypts the signaling (who is calling whom and call control commands). The two are complementary and both are necessary for a complete VoIP security solution.
TLS vs SRTP Differences
Many people confuse SIP TLS and SRTP, but they protect different aspects of VoIP communication. The table below compares their differences in detail:
| Aspect | SIP TLS | SRTP |
|---|---|---|
| Protects | SIP Signaling | RTP Media Stream |
| Encrypts | Call control messages (INVITE, BYE, etc.) | Voice data (call content) |
| Default Port | 5061 | No fixed port (dynamically negotiated) |
| Encryption Algorithm | TLS cipher suites (AES-GCM, ChaCha20, etc.) | AES-CTR + HMAC-SHA1 |
| Key Source | TLS handshake negotiation | DTLS-SRTP or SDES negotiation |
| Prevents Eavesdropping Of | Phone numbers, call times, SDP info | Voice/video content |
| Anti-Tampering | Yes (TLS MAC) | Yes (HMAC-SHA1) |
| Defined By | RFC 3261 | RFC 3711 |
In short: TLS protects "who is calling whom," while SRTP protects "what was said." Complete VoIP security requires enabling both.
Certificate Configuration
SIP TLS requires X.509 digital certificates to verify server identity. Configuring certificates is a prerequisite for enabling SIP TLS.
Certificate Types
| Certificate Type | Use Case | Cost | Trust Level |
|---|---|---|---|
| Let's Encrypt Free Certificate | Production (recommended) | Free | Trusted |
| Commercial SSL Certificate | Enterprise production | Paid | Trusted |
| Self-Signed Certificate | Testing/development only | Free | Untrusted (manual trust required) |
Required Certificate Files
- CA Certificate (ca.crt): The certificate authority's root certificate, used to verify the certificate chain
- Server Certificate (server.crt): Digital certificate containing the server's domain name/IP
- Private Key (server.key): The private key paired with the certificate, must be kept strictly confidential
Obtaining Certificates with Let's Encrypt
Generating a Self-Signed Certificate (for Testing)
Key Exchange Mechanisms
SRTP encryption keys do not appear out of thin air; they must be negotiated securely during call setup. There are two mainstream SRTP key exchange methods:
1. DTLS-SRTP
DTLS-SRTP (Datagram Transport Layer Security for SRTP) is the currently recommended key exchange method, and is mandatory in WebRTC. It negotiates SRTP keys through a DTLS handshake on the RTP channel, providing forward secrecy.
- UDP-based TLS handshake designed for real-time media
- Supports Perfect Forward Secrecy
- Mandatory for WebRTC
- Keys negotiated on the media channel, independent of the signaling channel
2. SDES (SDP Security Descriptions)
SDES (Session Description Protocol Security Descriptions) passes SRTP keys through the SDP in SIP signaling. While simple to configure, since keys are transmitted through the signaling channel, they will be exposed if signaling is not encrypted (SIP TLS not enabled).
- Keys are passed in the SDP crypto attribute
- Simple configuration, good compatibility
- Must be used with SIP TLS (otherwise keys are transmitted in plaintext)
- Does not support forward secrecy
Security Recommendation: Prefer DTLS-SRTP. If SDES must be used, ensure SIP TLS is also enabled. Otherwise, SRTP keys will be transmitted in plaintext through the signaling channel, defeating the purpose of encryption.
Asterisk Configuration
Below are the configuration steps for enabling SIP TLS and SRTP in Asterisk (using the chan_sip driver):
sip.conf Configuration
Generating Asterisk Certificates
SRTP Configuration
In Asterisk, SRTP is enabled by setting encryption=yes in the extension configuration. Asterisk automatically negotiates SRTP encryption parameters in the SDP. If the client supports DTLS-SRTP, Asterisk will also support it automatically (requires dtlsenable=yes).
FreeSWITCH Configuration
Below are the configuration steps for enabling SIP TLS and SRTP in FreeSWITCH:
SIP Profile Configuration (internal.xml)
SRTP Forced Mode
FreeSWITCH Certificate Setup
Security Best Practices
Beyond enabling SIP TLS and SRTP, the following security measures are essential components of a comprehensive VoIP security posture:
Network Security
- IP Whitelisting: At the firewall level, restrict access to ports 5060/5061 to known SIP peer IP addresses only
- Disable SIP ALG: Most routers' SIP ALG feature has bugs that can break SIP signaling; disable it on routers and firewalls
- Firewall Rules: Only open necessary ports (5061/TCP for SIP TLS, RTP port range/UDP); close all others
- RTP Port Range Limitation: Configure a fixed RTP port range (e.g., 10000-20000/UDP) for easier firewall management
Certificate Management
- Regular Certificate Renewal: Let's Encrypt certificates are valid for 90 days; set up automatic renewal (cron job)
- Certificate Monitoring: Set up expiration alerts to prevent SIP TLS connection failures due to expired certificates
- Private Key Protection: Set private key file permissions to 600, allowing only the asterisk/freeswitch user to read
Protocol Security
- Disable Weak Cipher Suites: Only allow TLS 1.2+; disable SSLv3, TLS 1.0/1.1
- Use Strong Cipher Suites: Prefer AES-GCM and ECDHE key exchange
- Enable SIP Digest Authentication: Prevent unauthorized registrations
- Disable Unencrypted Transport: Remove UDP/TCP transport options; keep only TLS
Monitoring and Auditing
- Log all SIP registration and call attempts
- Monitor TLS handshake failure rates (may indicate certificate or configuration issues)
- Regularly check SRTP encryption statistics (ensure media streams are actually encrypted)
- Implement call rate limiting to prevent brute force attacks and toll fraud
FAQ
Q: Are SIP TLS and SRTP mandatory?
A: Strongly recommended for SIP calls transmitted over public networks. Optional for enterprise internal networks, but mandatory for cross-border communications and compliance-required scenarios. Many countries' data protection regulations (such as GDPR, China's Data Security Law) require encryption of communication content.
Q: Does enabling TLS/SRTP affect call quality?
A: Encryption overhead is minimal (< 1ms), with virtually no impact on call latency or MOS. Modern processors support AES-NI hardware acceleration instructions, achieving AES encryption/decryption speeds of several GB/s, far exceeding the bitrate required for voice calls. SRTP adds less than 1% bandwidth overhead.
Q: How do I obtain a SIP TLS certificate?
A: You can use Let's Encrypt free certificates, commercial SSL certificates, or self-signed certificates. Production environments should use certificates issued by a trusted CA. Let's Encrypt can issue certificates for SIP domains through DNS validation and supports automatic renewal. Self-signed certificates are only suitable for testing environments since the peer must manually trust them.
Need Secure International Voice Routes?
Cainiao Voice provides fully TLS + SRTP encrypted SIP trunk services covering 200+ countries
Free Consultation