Crate rtc_srtp 

SRTP and SRTCP for the Sans-I/O WebRTC stack.

The Secure Real-time Transport Protocol (RFC 3711) as WebRTC keys it: protection profiles negotiated through DTLS-SRTP (RFC 5764), with keying material exported from the DTLS handshake rather than signalled.

Structure

• context — Context, the encrypt/decrypt state for one direction: encrypt_rtp/decrypt_rtp and the RTCP equivalents, plus the replay protection and rollover-counter tracking the RFC requires.
• protection_profile — the negotiable profiles (AES-128-CM-SHA1-80, AEAD-AES-128-GCM, and friends) and their key/salt lengths.
• config, option — how a context is built, including replay-window sizing.

Example

A profile is negotiated through DTLS-SRTP, and it fixes the key, salt and tag sizes the context will use:

use rtc_srtp::protection_profile::ProtectionProfile;

let profile = ProtectionProfile::Aes128CmHmacSha1_80;
assert_eq!(profile.key_len(), 16); // AES-128
assert_eq!(profile.salt_len(), 14);
assert_eq!(profile.rtp_auth_tag_len(), 10); // 80-bit tag

// The AEAD profiles authenticate inside the cipher, so they carry no HMAC key.
assert_eq!(ProtectionProfile::AeadAes128Gcm.auth_key_len(), 0);

Most applications do not depend on this crate directly — the rtc crate creates the contexts from the DTLS handshake and applies them to media as one layer of the peer-connection pipeline.

Modules

config

Session configuration: keys, protection profile, and replay-protection options.

context

The encrypt/decrypt state for one SRTP/SRTCP session.

option

Per-context options, currently the replay-detector factory.

protection_profile

The DTLS-SRTP protection profiles and their key, salt and tag lengths.