SRTP

rtpbridge supports SRTP encryption for plain RTP endpoints using SDES key exchange.

SDES Key Exchange

For plain RTP endpoints with srtp: true, rtpbridge generates an a=crypto line in the SDP:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<base64-key>

When accepting an offer with a=crypto, rtpbridge generates an independent TX key for the SDP answer. The offerer's key is used only for the RX (decrypt) direction to prevent keystream reuse between directions.

rtpbridge accepts an optional RFC 4568 SDES lifetime (inline:<key>|<lifetime>), including the compact power-of-two form such as |2^32. It enforces that policy independently for each SRTP and SRTCP SSRC stream: no stream can protect or accept another packet once its master-key lifetime is exhausted. A same-key renegotiation may tighten the lifetime without resetting packet counts or replay state; expanding it requires a new master key. An offered lifetime cannot exceed the AES_CM_128_HMAC_SHA1_80 maximum of 2^48 SRTP packets; SRTCP also remains capped at its RFC 3711 maximum of 2^31 packets. MKIs and SDES session parameters remain unsupported and cause the crypto attribute to be rejected rather than silently ignored.

For carrier trunks where encryption is preferred but not universally supported, srtp_optional: true generates an RFC 8643 opportunistic-SRTP offer: RTP/AVP with an a=crypto attribute. An answer that returns crypto uses SRTP; an answer that omits crypto selects plain RTP and rtpbridge removes the provisional transmit crypto context. A strict srtp: true offer rejects a plaintext answer instead of establishing one-way media. srtp and srtp_optional are mutually exclusive.

Cipher Suite

Only AES_CM_128_HMAC_SHA1_80 is supported:

• Encryption: AES-128 in Counter Mode (AES-CM, RFC 3711 §4.1.1)
• Authentication: HMAC-SHA1 truncated to 80 bits
• Key material: 30 bytes (16-byte master key + 14-byte master salt)
• Key derivation: SRTP KDF (RFC 3711 §4.3.1)

Key Material

The base64-encoded key in a=crypto decodes to 30 bytes:

Bytes 0-15:  Master key (128 bits)
Bytes 16-29: Master salt (112 bits)

Session keys are derived using the SRTP KDF:

• Label 0x00 → cipher key (16 bytes)
• Label 0x01 → auth key (20 bytes)
• Label 0x02 → salt key (14 bytes)

Packet Processing

Outbound (protect)

1. Encrypt RTP payload using AES-CM with IV derived from SSRC + packet index
2. Compute HMAC-SHA1 over (RTP header + encrypted payload + ROC)
3. Append truncated 10-byte auth tag

Inbound (unprotect)

1. Verify HMAC-SHA1 auth tag
2. Decrypt RTP payload using AES-CM
3. Return decrypted RTP packet (auth tag stripped)

WebRTC

WebRTC endpoints handle SRTP internally via str0m's DTLS-SRTP. The SRTP module is only used for plain RTP endpoints with SDES.

Rekey

Plain RTP/SRTP endpoints support mid-session key rotation via endpoint.rtp.srtp_rekey:

1. endpoint.rtp.srtp_rekey generates a new TX master key and returns an SDP offer with the new a=crypto line. The TX context is replaced immediately — outbound packets use the new key.

2. endpoint.rtp.accept_answer with the remote's new SDP installs the remote's new RX key as a pending context. A 5-second dual-context transition window begins.

3. Dual-context decryption: During the transition, inbound packets are tried against the new key first. If the new key succeeds, the old key is discarded (early promotion). If the new key fails, the old key is used as fallback.

4. Switchover deadline: After 5 seconds, any remaining old context is force-replaced by the new context, regardless of whether early promotion occurred.

5. Tuple latching: The established symmetric RTP tuple remains pinned while the rekey offer is outstanding. An accepted rekey answer reopens latching, so the next authenticated packet can establish a new tuple if the NAT binding changed.

SRTCP contexts follow the same dual-context pattern independently of SRTP.

Implementation

The SRTP implementation uses pure Rust crates (aes, ctr, hmac, sha1) with no C dependencies beyond what str0m already requires.