SRTP in WebRTC

WebRTC mandates encryption of media by means of the Secure Realtime Protocol, or SRTP, which is described in RFC 3711.

The key negotiation in WebRTC happens using DTLS-SRTP which is described in RFC 5764. The older SDES protocol is implemented but not enabled by default.

Unencrypted RTP can be enabled for debugging purposes by setting the PeerConnections disable_encryption option to true.

Supported cipher suites

The implementation supports the following cipher suites:

  • SRTP_AES128_CM_HMAC_SHA1_80
  • SRTP_AEAD_AES_128_GCM
  • SRTP_AEAD_AES_256_GCM

The SRTP_AES128_CM_HMAC_SHA1_32 cipher suite is accepted for audio-only connections if offered by the other side. It is not actively supported, see SelectCrypto for details.

The cipher suite ordering allows a non-WebRTC peer to prefer GCM cipher suites, however they are not selected as default by two instances of the WebRTC library.

cricket::SrtpSession

The cricket::SrtpSession is providing encryption and decryption of SRTP packets using libsrtp. Keys will be provided by SrtpTransport or DtlsSrtpTransport in the SetSend and SetRecv methods.

Encryption and decryption happens in-place in the ProtectRtp, ProtectRtcp, UnprotectRtp and UnprotectRtcp methods. The SrtpSession class also takes care of initializing and deinitializing libsrtp by keeping track of how many instances are being used.

webrtc::SrtpTransport and webrtc::DtlsSrtpTransport

The webrtc::SrtpTransport class is controlling the SrtpSession instances for RTP and RTCP. When rtcp-mux is used, the SrtpSession for RTCP is not needed.

webrtc:DtlsSrtpTransport is a subclass of the SrtpTransport that extracts the keying material when the DTLS handshake is done and configures it in its base class. It will also become writable only once the DTLS handshake is done.

cricket::SrtpFilter

The cricket::SrtpFilter class is used to negotiate SDES.