Asterisk PJSIP media encryption: SDES, DTLS-SRTP and call-leg proof

Keep signaling transport and media protection separate

Start with one direction and one Asterisk channel leg. SIP over TLS can protect a signaling connection between two adjacent systems; SRTP protects RTP and SRTCP under a negotiated cryptographic context. One does not prove the other. A TLS registration, a secure WebSocket, an SRTP-capable endpoint and an encrypted call are four different claims.

Asterisk can terminate one SIP dialog and create another, so the phone-facing and trunk-facing legs can use different transports, certificates, media addresses and encryption modes. State the protection on each leg and where signaling and media terminate. Do not describe a call as end-to-end encrypted merely because one endpoint shows a padlock.

Choose the endpoint media-encryption contract explicitly

Asterisk 22 documents the PJSIP endpoint media_encryption choices as no media encryption, SDES or DTLS-SRTP. Treat that as endpoint policy for the named object, not a server-wide fact. Inspect the loaded endpoint and the exact call's SDP; a value present in a source file or management interface is not proof that the running channel used it.

media_encryption_optimistic relaxes enforcement so encrypted media can be used when negotiated without requiring it for every session. That is a policy choice, not a troubleshooting switch. Record whether encryption is required or merely allowed, identify the downgrade behavior, and test rejection as well as success with an approved peer before production use.

Protect SDES keying material as well as the media

SDES uses SDP a=crypto attributes to carry the SRTP suite and key parameters. RFC 4568 warns that the SDP security description is not itself a key-management protocol and requires confidentiality and integrity protection for the keying material. An SRTP label without a protected signaling path can leave the inline key exposed to systems that can read SDP.

Preserve the signaling route, every proxy or back-to-back user agent that can terminate or inspect it, the offered and selected crypto suites, and the resulting SRTP profile. TLS on one hop does not establish protection across another hop or through every intermediary. Do not paste SDP crypto values, private keys or full captures into shared tickets.

Follow DTLS-SRTP fingerprint, role and handshake evidence

DTLS-SRTP uses a DTLS handshake on the media path to establish SRTP keying material. RFCs 5763 and 5764 keep the signaled certificate fingerprint and setup role distinct from ICE or ordinary SIP transport TLS. In Asterisk, media_encryption=dtls works with endpoint DTLS options for certificate material or automatic generation, verification, fingerprints, setup and rekey behavior. Confirm the options supported by the installed branch rather than copying a WebRTC template into a non-WebRTC peer.

For one call, preserve the SDP fingerprint and setup attributes, selected media addresses and ports, DTLS handshake result, negotiated SRTP protection profile and subsequent SRTP or SRTCP traffic. A selected ICE pair, a completed SIP answer or visible DTLS packets alone does not prove that the peers accepted the same fingerprint, derived working keys or decoded audio.

Treat TLS and DTLS certificates as different consumers

A PJSIP TLS transport certificate authenticates a SIP transport role. A DTLS certificate participates in media-path key establishment. They may use related certificate files, but their listeners, peer-verification rules, names, fingerprints, reload behavior and renewal evidence are separate. Inventory which certificate each transport and endpoint actually loaded before rotating either.

A file on disk, a renewed certificate in a management interface and a successful service reload are not presentation evidence. Verify the certificate or fingerprint observed by the intended peer on every required path, then repeat registration or dialog setup and protected media. Use the certificate-rotation guide for activation and rollback boundaries.

Account for direct media, bridges, recording and transcoding

When Asterisk stays in the media path, it can terminate one protected media relationship and create another. Bridging, transcoding, mixing and recording can require access to decrypted media inside the trusted system. When direct media is negotiated, RTP or SRTP may move between endpoints and bypass Asterisk after a re-INVITE. Neither design should be inferred from initial signaling alone.

Record the initial and final media addresses, direct-media policy, re-INVITEs, bridge membership, negotiated protection on both legs, recorder owner and any transcode. A recording file proves that a recorder received decodable media; it does not prove protection before or after that termination point. Conversely, an undecodable capture does not by itself prove SRTP was correctly authenticated.

Accept the protected call with bounded evidence

Use the installed Asterisk CLI to inspect the exact loaded endpoint, transport and channel, then correlate the offer, answer, keying method, selected profile, packet direction and audible result. Repeat inbound and outbound calls plus hold, resume, blind and attended transfer where supported, because media updates can renegotiate addresses, roles or protection. Include certificate renewal, endpoint restart and one approved failure case in the maintenance plan.

Keep authorization and dialplan permission independent from encryption. A correctly protected call from a compromised account can still be unauthorized. Preserve redacted evidence, configuration owner, versions, observed termination points and rollback. No Asterisk host, endpoint, certificate, key exchange, call leg, packet stream, recorder, direct-media path, interoperability combination or call was inspected or tested for this guide.

Verify media encryption per stream

The RTP channel-context guide treats CHANNEL(rtp,secure,audio|video) as a stream observation, not proof of signaling trust, another leg or end-to-end protection.