* to negotiate keys for SRTP encryption using
[DTLS-SRTP](https://www.rfc-editor.org/info/rfc5763)
* as a transport for SCTP which is used by the Datachannel API
The DTLS handshake happens after the ICE transport becomes writable and has
found a valid pair. It results in a set of keys being derived for DTLS-SRTP as
well as a fingerprint of the remote certificate which is compared to the one
given in the SDP `a=fingerprint:` line.
This documentation provides an overview of how DTLS is implemented, i.e how the
following classes interact.
## webrtc::DtlsTransport
The [`webrtc::DtlsTransport`][1] class is a wrapper around the
`cricket::DtlsTransportInternal` and allows registering observers implementing
the `webrtc::DtlsTransportObserverInterface`. The
[`webrtc::DtlsTransportObserverInterface`][2] will provide updates to the
observers, passing around a snapshot of the transports state such as the
connection state, the remote certificate(s) and the SRTP ciphers as
[`DtlsTransportInformation`][3].
## cricket::DtlsTransportInternal
The [`cricket::DtlsTransportInternal`][4] class is an interface. Its
implementation is [`cricket::DtlsTransport`][5]. The `cricket::DtlsTransport`
sends and receives network packets via an ICE transport. It also demultiplexes
DTLS packets and SRTP packets according to the scheme described in
[RFC 5764](https://tools.ietf.org/html/rfc5764#section-5.1.2).
## webrtc::DtlsSrtpTranport
The [`webrtc::DtlsSrtpTransport`][6] class is responsіble for extracting the
SRTP keys after the DTLS handshake as well as protection and unprotection of
SRTP packets via its [`cricket::SrtpSession`][7].
