SRTP is the Secure Real-time Transport Protocol. It encrypts the actual audio packets traveling between endpoints during a call. While TLS protects the signaling that sets up the call, SRTP protects the media itself. SRTP requires keying material, which is usually negotiated through the encrypted SIP signaling and then used to encrypt the audio stream.

A TLS certificate is a digital credential issued by a Certificate Authority that authenticates the identity of a server. The certificate contains the server's public key, the CA's digital signature, and metadata like the server name and expiration date. When a device connects to the server over TLS, it verifies the certificate to ensure it's really connecting to whom it thinks it is.

SIP trunk encryption means using TLS to encrypt the SIP signaling between your SBC and the terminating carrier's equipment. This protects the call setup messages, caller identity information, and the keys used for SRTP media encryption. SIP trunk encryption requires both sides to support TLS and to have valid certificates that they trust.

Both rely on TLS and certificate trust, but they do different jobs.

TLS works over TCP and maintains a persistent connection. DTLS works over UDP and doesn't require persistent connections.

For SIP signaling, TLS is currently the standard and most widely supported. DTLS is technically better for SIP because UDP avoids TCP connection-state failover headaches and head-of-line blocking, but DTLS support for SIP signaling is still limited. 

A TLS error occurs when the TLS handshake fails. Common examples include:

• Certificate Verification Failure: The certificate has expired or isn't trusted.

• Hostname Mismatch: The certificate is for a different server.

• Cipher Suite Mismatch: The client and server can't agree on encryption.

• Wrong Clock: The device's time is too far off, and it thinks the certificate has expired.

Each TLS error tells you something specific about what went wrong.

Perfect Forward Secrecy (PFS) uses ephemeral keys so that even if you have the server's private key, you can't decrypt old captures. While this is good for security, it's bad for troubleshooting. You can't hand somebody the server key and ask them to decrypt yesterday's packet capture.

At ECG, we help you build out monitoring feeds from the SBC, rather than trying to break the TLS encryption. With this approach, your engineers get what they need to troubleshoot without weakening the encryption your customers are paying for.

Device manufacturer certificates are credentials baked into phones from the factory. A Polycom phone has a Polycom certificate signed by Polycom's CA. A Yealink phone has a Yealink certificate signed by Yealink's CA.

Configuring mutual TLS ensures the device management server trusts these manufacturer CAs. When a phone connects, it presents its certificate, the server verifies it came from a real manufacturer, and only then does it serve the config. This prevents attackers from spoofing device connections.

Each endpoint sends a certificate signed by the manufacturer's private key, and containing the  MAC Address of the endpoint. This allows the SBC and other servers to confirm the device connecting is authentic.

Certificate lifecycle management means planning and automating the entire lifecycle of your certificates. Doing this effectively means:

• Procuring certificates from a Certificate Authority

• Deploying them to your devices

• Monitoring them for expiration

• Requesting a renewal

• Deploying the new certificates without downtime

• Verifying that everything works

• Retiring the old certificate 

Automation can help you do this consistently across hundreds or thousands of devices without manual oversight.

Most BroadWorks, MetaSwitch, and NetSapiens deployments don't have TLS or SRTP on the core side. You encrypt the access leg (phone to SBC) with TLS and SRTP, and the core traffic behind the SBC is plaintext. The access network is untrusted, and the core network is your trusted security enclave. This isn't true end-to-end encryption, but it protects traffic across the public internet and is how nearly every carrier deploys today. 

If your customers need end-to-end encryption, you can't get there with the current generation of carrier voice software. ECG can help you through voice architectures that achieve those goals. But for classic PSTN Voice, this design works for protecting traffic across the public internet against eavesdroppers and against attackers spoofing or modifying SIP, and it's defensible.

 rtpengine is an open-source media relay and SRTP transcoder. It's typically used for deployments that have SRTP-speaking endpoints on one side and plaintext RTP endpoints on the other. rtpengine sits in the middle, handles the SRTP keying on the encrypted side, and passes plain RTP to the core. It's useful for media steering, NAT traversal, and compliance recording.