当 A 与 B 建立连接时，A 要带着它的用户名和密码过来，此时 B 端就可以通过验证 A 带来的用户名和密码与 SDP 中的用户名和密码是否一致的，来判断 A 是否是一个合法用户了。
fingerprint也是验证合法性的关键一步，它是存放公钥证书的指纹（或叫信息摘要），在通过 ice-ufrag 和 ice-pwd 验证用户的合法性之余，还要对它发送的证书做验证，看看证书在传输的过程中是否被窜改了。
从这张图中你可以看到， A 与 B 在传输数据之前，需要经历如下几个步骤。
首先通过信令服务器交换 SDP 信息，也就是进行媒体协商。
在 SDP 中记录了用户的用户名、密码和指纹，有了这些信息就可以对用户的身份进行确认了。
紧接着，A 通过 STUN 协议（底层使用 UDP 协议）进行身份认证。
如果 STUN 消息中的用户名和密码与交换的 SDP 中的用户名和密码一致，则说明是合法用户。
确认用户为合法用户后，则需要进行 DTLS 协商，交换公钥证书并协商密码相关的信息。
同时还要通过 fingerprint 对证书进行验证，确认其没有在传输中被窜改。
最后，再使用协商后的密码信息和公钥对数据进行加密，开始传输音视频数据。
前面我们说了 WebRTC 是通过使用 DTLS、SRTP 等几个协议的结合来达到 数据安全的，那接下来我们就来分别看一下这几个协议是如何实现的。
TLS 协议由TLS 记录协议和TLS 握手协议组成：
TLS 记录协议，用于数据的加密、数据完整性检测等；
TLS 握手协议，主要用于密钥的交换与身份的确认。
由于 TLS 底层是基于 TCP 协议的，而 WebRTC 音视频数据的传输主要基于 UDP 协议，因此 WebRTC 对数据的保护无法直接使用 TLS 协议。但 TLS 协议在数据安全方面做得确实非常完善，所以人们就想到是否可以将 TLS 协议移植到 UDP 协议上呢？ 因此 DTLS 就应运而生了。
所以你可以认为DTLS 就是运行在 UDP 协议之上的简化版本的 TLS，它使用的安全机制与 TLS 几乎一模一样。
在 WebRTC 中为了更有效地保护音视频数据，所以需要使用 DTLS 协议交换公钥证书，并确认使用的密码算法，这个过程在 DTLS 协议中称为握手协议。
DTLS 的握手过程如下：
首先 DTLS 协议采用 C/S 模式进行通信，其中发起请求的一端为客户端，接收请求的为服务端。
客户端向服务端发送 ClientHello 消息，服务端收到请求后，回 ServerHello 消息，并将自己的证书发送给客户端，同时请求客户端证书。
客户端收到证书后，将自己的证书发给服务端，并让服务端确认加密算法。
服务端确认加密算法后，发送 Finished 消息，至此握手结束。
DTLS 握手结束之后，通信双方就可以开始相互发送音视频数据了。
在 WebRTC 中，为了防止这类事情发生，没有直接使用 RTP/RTCP 协议，而是使用了 SRTP/SRTCP 协议 ，即安全的 RTP/RTCP 协议。
WebRTC 使用了非常有名的 libsrtp 库将原来的 RTP/RTCP 协议数据转换成 SRTP/SRTCP 协议数据。libsrtp 的使用非常简单，具体步骤可总结为如下。
第一步，初始化 libsrtp。
第二步，创建 Session。创建 Session 要略微复杂一些，这过程中需要指定创建的策略，比如使用哪种算法进行内容的完整性检测，解码时的公钥是什么，等等。
第三步，对 RTP 包加密。
第四步，对 SRTP 包解密。
第五步，也就是最后一步，是释放资源。