WebRTC中 setup:actpass、active、passive

1、先看一下整个DTLS的流程

 setup:actpass、active、passive就发生在Offer sdp和Anser SDP中

Offer的SDP是setup:actpass,这个是服务方：

v=0\r
o=- 1478416022679383738 2 IN IP4 127.0.0.1\r
s=-\r
t=0 0\r
a=group:BUNDLE 0 1\r
a=extmap-allow-mixed\r
a=msid-semantic: WMS 38360753-89ae-42b5-b793-203add491a5c\r
m=audio 62616 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126\r
c=IN IP4 125.88.8.165\r
a=rtcp:9 IN IP4 0.0.0.0\r
a=candidate:990939686 1 udp 2122260223 10.2.107.35 62616 typ host generation 0 network-id 1\r
a=candidate:3759385191 1 udp 1686052607 125.88.8.165 62616 typ srflx raddr 10.2.107.35 rport 62616 generation 0 network-id 1\r
a=candidate:3317325490 1 tcp 1518280447 10.2.107.35 9 typ host tcptype active generation 0 network-id 1\r
a=ice-ufrag:6bmy\r
a=ice-pwd:vWzBuDSxDLpkoqKw3eUns+Rm\r
a=ice-options:trickle\r
a=fingerprint:sha-256 10:12:BA:60:E9:46:72:75:75:2D:E1:45:30:2D:4A:C3:64:8F:4C:12:2D:82:5A:99:93:37:8B:4B:2F:8D:1A:AB\r
a=setup:actpass\r
a=mid:0\r

Answer的SDP是setup:active，这个是客户方

v=0\r
o=FreeSWITCH 1692858855 1692858856 IN IP4 10.2.107.35\r
s=FreeSWITCH\r
c=IN IP4 10.2.107.35\r
t=0 0\r
a=msid-semantic: WMS xkvzqsQ0Gh1p7wIyz5KXUqYTjrJDBaZB\r
m=audio 19540 UDP/TLS/RTP/SAVPF 111 110\r
a=rtpmap:111 opus/48000/2\r
a=fmtp:111 useinbandfec=1; minptime=10; stereo=1; sprop-stereo=1\r
a=rtpmap:110 telephone-event/48000\r
a=silenceSupp:off - - - -\r
a=ptime:20\r
a=sendrecv\r
a=fingerprint:sha-256 39:BF:A6:99:4D:64:DF:75:DB:98:52:25:A2:F6:31:F5:69:17:EE:1B:FF:04:EA:7D:91:39:5D:DF:47:22:B9:B7\r
a=setup:active\r
a=rtcp-mux\r

客户方需要找服务方认证

2、用一个真实的例子解释为什么这很烦

可以很清楚的看到这其中有什么问题。如果看不出来的话，我会用一个关于SDP a=setup真实的用例来解释：

# 让我们假设Alice想要与Bob进行音频和数据通道通信，所以Alice创建了她的本地RTCPeerConnection，并且得到了相应的SDP请求。

# 根据RFC 5763，SDP请求的a=setup属性必须是“actpass”，也就是应答方（Bob）需要决定谁是DTLS用户谁是DTLS服务器。

# Bob生成相应的SDP应答，其中包括a=setup:active，意思是Bob成为了DTLS用户，而Alice成为DTLS服务器。

# 在ICE和DTLS处理之后，Alice和Bob两个人互相交换了他们的音频和数据。

# 之后，Bob想要在通信中加上网络摄像头捕捉的视频，所以他得到了一个包括网络摄像头流信息的SDP重请求。

# 还是，依据RFC 5673，这个SDP重请求中要有a=setup:actpass。

# Alice接到SDP重请求并且产生一个重响应。

# 为了保持现有的DTLS关联开放，这个SDP重响应必须有a=setup:passive项。

你注意到了吗？为了不改变传输，SDP重请求和重响应必须表示与在最初SDP交换中a=setup属性相不同的值。

3、媒体协商

SDP内容十分重要，交换了ICE需要的Username，Password，以及后面的DTLS需要的证书的验证指纹，用来验证证书是否被中间人替换。部分SDP内容如下：

a=ice-ufrag:6bmy\r
a=ice-pwd:vWzBuDSxDLpkoqKw3eUns+Rm\r
a=ice-options:trickle\r
a=fingerprint:sha-256 10:12:BA:60:E9:46:72:75:75:2D:E1:45:30:2D:4A:C3:64:8F:4C:12:2D:82:5A:99:93:37:8B:4B:2F:8D:1A:AB\r
a=setup:actpass\r
a=mid:0\r

a=fingerprint也就是指纹，那指纹是用来干什么的呢？

指纹就是用来我们进行数据加密的时候，来验证这个证书的。那它首先通过信令层将SDP中的证书的指纹下发给对方，那么下次对数据加密前的它进行一下数据证书的交换，交换证书是通过DPLS进行，那么通过DPLS进行证书交换的时候，通过这个指纹去验证你这个证书的有效性，那如果这个证书验证是有效性的，然后后面你才能进行数据加密然后进行传输。如果通过指纹这个证书不匹配，那说明你这个连接也是有问题的。那这个时候就不能进行传输。通过以上这个种种方式呢，在打通的时候进行一次验证，在传数据的时候在交换证书的时候也要进行验证，那么通过这个层层的安全的验证，才能保证整个webRTC传输的安全性。以上就是安全性相关的一些描述。当然最后进行算法加密的时候你可以使用这个a=crypto指定的加密算法，也可以通过DPLS交换的证书里的指定的加密算法进行加密。

完成握手后就正常传输数据了