The SRTP_AES128_CM_HMAC_SHA1_32 cipher suite is not enabled by default and
off in Chromium. When enabled, it is accepted for audio-only connections if
offered by the other side. It is not actively supported, see [SelectCrypto][2]
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.
## webrtc::SrtpSession
The [`webrtc::SrtpSession`][3] is providing encryption and decryption of SRTP
packets using [`libsrtp`](https://github.com/cisco/libsrtp). Keys will be
provided by `SrtpTransport` or `DtlsSrtpTransport` in the [`SetSend`][4] and
[`SetRecv`][5] methods.
Encryption and decryption happens in-place in the [`ProtectRtp`][6],
[`ProtectRtcp`][7], [`UnprotectRtp`][8] and [`UnprotectRtcp`][9] 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`][10] class is controlling the `SrtpSession`
instances for RTP and RTCP. When
[rtcp-mux](https://datatracker.ietf.org/doc/html/rfc5761) is used, the
`SrtpSession` for RTCP is not needed.
[`webrtc:DtlsSrtpTransport`][11] 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.
