WebRTC搭建前端视频聊天室——信令篇

这篇文章讲述了WebRTC中所涉及的信令交换以及聊天室中的信令交换，主要内容来自WebRTC in the real world: STUN, TURN and signaling，我在这里提取出的一些信息，并添加了自己在开发时的一些想法。

WebRTC的服务器

---

WebRTC提供了浏览器到浏览器（点对点）之间的通信，但并不意味着WebRTC不需要服务器。暂且不说基于服务器的一些扩展业务，WebRTC至少有两件事必须要用到服务器：
1. 浏览器之间交换建立通信的元数据（信令）必须通过服务器
2. 为了穿越NAT和防火墙

为什么需要信令？

---

我们需要通过一系列的信令来建立浏览器之间的通信。而具体需要通过信令交换哪些内容呢？这里大概列了一下：
1. 用来控制通信开启或者关闭的连接控制消息
2. 发生错误时用来彼此告知的消息
3. 媒体流元数据，比如像解码器、解码器的配置、带宽、媒体类型等等
4. 用来建立安全连接的关键数据
5. 外界所看到的的网络上的数据，比如IP地址、端口等

在建立连接之前，浏览器之间显然没有办法传递数据。所以我们需要通过服务器的中转，在浏览器之间传递这些数据，然后建立浏览器之间的点对点连接。但是WebRTC API中并没有实现这些。

为什么WebRTC不去实现信令交换？

---

不去由WebRTC实现信令交换的原因很简单：WebRTC标准的制定者们希望能够最大限度地兼容已有的成熟技术。具体的连接建立方式由一种叫JSEP（JavaScript Session Establishment Protocol）的协议来规定，使用JSEP有两个好处：
1. 在JSEP中，需要交换的关键信息是多媒体会话描述（multimedia session description）。由于开发者在其所开发的应用程序中信令所使用的协议不同（SIP或是XMPP或是开发者自己定义的协议），WebRTC建立呼叫的思想建立在媒体流控制层面上，从而与上层信令传输相分离，防止相互之间的信令污染。只要上层信令为其提供了多媒体会话描述符这样的关键信息就可以建立连接，不管开发者用何种方式来传递。
2. JSEP的架构同时也避免了在浏览器上保存连接的状态，防止其像一个状态机一样工作。由于页面经常被频繁的刷新，如果连接的状态保存在浏览器中，每次刷新都会丢失。使用JSEP能使得状态被保存在服务器上

会话描述协议（Session Description Protocol）

---

JSEP将客户端之间传递的信令分为两种:offer信令和answer信令。他们主要内容的格式都遵循会话描述协议（Session Description Protocal，简称SDP）。一个SDP的信令的内容大致上如下：

v=0 o=- 7806956 075423448571 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video data a=msid-semantic: WMS 5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=recvonly a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:video a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:3162115896 cname:/nERF7Ern+udqf++ a=ssrc:3162115896 msid:5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g 221b204e-c9a0-4b01-b361-e17e9bf8f639 a=ssrc:3162115896 mslabel:5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g a=ssrc:3162115896 label:221b204e-c9a0-4b01-b361-e17e9bf8f639 m=application 1 DTLS/SCTP 5000 c=IN IP40.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:data a=sctpmap:5000 webrtc-datachannel 1024 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

这些都什么玩意？说实话我不知道，我这里放这么一大段出来，只是为了让文章内容显得很多…如果想深入了解的话，可以参考SDP for the WebRTC draft-nandakumar-rtcweb-sdp-04自行进行解析

其实可以将其简化一下，它就是一个在点对点连接中描述自己的字符串，我们可以将其封装在JSON中进行传输，在PeerConnection建立后将其通过服务器中转后，将自己的SDP描述符和对方的SDP描述符交给PeerConnection就行了

信令与RTCPeerConnection建立

---

在前一篇文章中介绍过，WebRTC使用RTCPeerConnection来在浏览器之间传递流数据，在建立RTCPeerConnection实例之后，想要使用其建立一个点对点的信道，我们需要做两件事：
1. 确定本机上的媒体流的特性，比如分辨率、编解码能力啥的（SDP描述符）
2. 连接两端的主机的网络地址（ICE Candidate）

需要注意的是，由于连接两端的主机都可能在内网或是在防火墙之后，我们需要一种对所有联网的计算机都通用的定位方式。这其中就涉及NAT/防火墙穿越技术，以及WebRTC用来达到这个目的所ICE框架。这一部分在上一篇文章中有介绍，这里不再赘述。

通过offer和answer交换SDP描述符

大致上在两个用户（甲和乙）之间建立点对点连接流程应该是这个样子（这里不考虑错误的情况，RTCPeerConnection简称PC）：

1. 甲和乙各自建立一个PC实例
2. 甲通过PC所提供的createOffer()方法建立一个包含甲的SDP描述符的offer信令
3. 甲通过PC所提供的setLocalDescription()方法，将甲的SDP描述符交给甲的PC实例
4. 甲将offer信令通过服务器发送给乙
5. 乙将甲的offer信令中所包含的的SDP描述符提取出来，通过PC所提供的setRemoteDescription()方法交给乙的PC实例
6. 乙通过PC所提供的createAnswer()方法建立一个包含乙的SDP描述符answer信令
7. 乙通过PC所提供的setLocalDescription()方法，将乙的SDP描述符交给乙的PC实例
8. 乙将answer信令通过服务器发送给甲
9. 甲接收到乙的answer信令后，将其中乙的SDP描述符提取出来，调用setRemoteDescripttion()方法交给甲自己的PC实例

通过在这一系列的信令交换之后，甲和乙所创建的PC实例都包含甲和乙的SDP描述符了，完成了两件事的第一件。我们还需要完成第二件事——获取连接两端主机的网络地址

通过ICE框架建立NAT/防火墙穿越的连接

这个网络地址应该是能从外界直接访问，WebRTC使用ICE框架来获得这个地址。RTCPeerConnection在创立的时候可以将ICE服务器的地址传递进去，如：

var iceServer = {     "iceServers": [{         "url": "stun:stun.l.google.com:19302"     }] }; var pc = new RTCPeerConnection(iceServer);
1
2
3
4
5
6

当然这个地址也需要交换，还是以甲乙两位为例，交换的流程如下（RTCPeerConnection简称PC）：

1. 甲、乙各创建配置了ICE服务器的PC实例，并为其添加onicecandidate事件回调
2. 当网络候选可用时，将会调用onicecandidate函数
3. 在回调函数内部，甲或乙将网络候选的消息封装在ICE Candidate信令中，通过服务器中转，传递给对方
4. 甲或乙接收到对方通过服务器中转所发送过来ICE Candidate信令时，将其解析并获得网络候选，将其通过PC实例的addIceCandidate()方法加入到PC实例中

这样连接就创立完成了，可以向RTCPeerConnection中通过addStream()加入流来传输媒体流数据。将流加入到RTCPeerConnection实例中后，对方就可以通过onaddstream所绑定的回调函数监听到了。调用addStream()可以在连接完成之前，在连接建立之后，对方一样能监听到媒体流

聊天室中的信令

上面是两个用户之间的信令交换流程，但我们需要建立一个多用户在线视频聊天的聊天室。所以需要进行一些扩展，来达到这个要求

用户操作

首先需要确定一个用户在聊天室中的操作大致流程：

1. 打开页面连接到服务器上
2. 进入聊天室
3. 与其他所有已在聊天室的用户建立点对点的连接，并输出在页面上
4. 若有聊天室内的其他用户离开，应得到通知，关闭与其的连接并移除其在页面中的输出
5. 若又有其他用户加入，应得到通知，建立于新加入用户的连接，并输出在页面上
6. 离开页面，关闭所有连接

从上面可以看出来，除了点对点连接的建立，还需要服务器至少做如下几件事：

1. 新用户加入房间时，发送新用户的信息给房间内的其他用户
2. 新用户加入房间时，发送房间内的其他用户信息给新加入房间的用户
3. 用户离开房间时，发送离开用户的信息给房间内的其他用户

实现思路

以使用WebSocket为例，上面用户操作的流程可以进行以下修改：

1. 浏览器与服务器建立WebSocket连接
2. 发送一个加入聊天室的信令（join），信令中需要包含用户所进入的聊天室名称
3. 服务器根据用户所加入的房间，发送一个其他用户信令（peers），信令中包含聊天室中其他用户的信息，浏览器根据信息来逐个构建与其他用户的点对点连接
4. 若有用户离开，服务器发送一个用户离开信令（remove_peer），信令中包含离开的用户的信息，浏览器根据信息关闭与离开用户的信息，并作相应的清除操作
5. 若有新用户加入，服务器发送一个用户加入信令（new_peer），信令中包含新加入的用户的信息，浏览器根据信息来建立与这个新用户的点对点连接
6. 用户离开页面，关闭WebSocket连接

服务器实现

由于用户可以只是建立连接，可能还没有进入具体房间，所以首先我们需要一个容器来保存所有用户的连接，同时监听用户是否与服务器建立了WebSocket的连接：

var server = new WebSocketServer(); var sockets = [];  server.on('connection', function(socket){     socket.on('close', function(){         var i = sockets.indexOf(socket);         sockets.splice(i, 1);         //关闭连接后的其他操作     });     sockets.push(socket);     //连接建立后的其他操作 });
1
2
3
4
5
6
7
8
9
10
11
12

由于有房间的划分，所以我们需要在服务器上建立一个容器，用来保存房间内的用户信息。显然对象较为合适，键为房间名称，值为用户信息列表。

同时我们需要监听上面所说的用户加入房间的信令（join），新用户加入之后需要向新用户发送房间内其他用户信息（peers）和向房间内其他用户发送新用户信息（new_peer），以及用户离开时向其他用户发送离开用户的信息（remove_peer）:

于是乎代码大致就变成这样：

var server = new WebSocketServer(); var sockets = []; var rooms = {};  /* join信令所接收的格式 {     "eventName": "join",     "data": {         "room": "roomName"     } } */ var joinRoom = function(data, socket) {     var room = data.room || "__default";     var curRoomSockets; //当前房间的socket列表     var socketIds = []; //房间其他用户的id      curRoomSockets = rooms[room] = rooms[room] || [];      //给所有房间内的其他人发送新用户的id     for (var i = curRoomSockets.length; i--;) {         socketIds.push(curRoomSockets[i].id);         curRoomSockets[i].send(JSON.stringify({             "eventName": "new_peer",             "data": {                 "socketId": socket.id             }         }));     }      //将新用户的连接加入到房间的连接列表中     curRoomSockets.push(socket);     socket.room = room;      //给新用户发送其他用户的信息，及服务器给新用户自己赋予的id     socket.send(JSON.stringify({         "eventName": "peers",         "data": {             "socketIds": socketIds,             "you": socket.id         }     })); };  server.on('connection', function(socket) {     //为socket构建一个特有的id，用来作为区分用户的标记     socket.id = getRandomString();     //用户关闭连接后，应做的处理     socket.on('close', function() {         var i = sockets.indexOf(socket);         var room = socket.room;         var curRoomSockets = rooms[room];         sockets.splice(i, 1);         //通知房间内其他用户         if (curRoomSockets) {             for (i = curRoomSockets.length; i--;) {                 curRoomSockets[i].send(JSON.stringify({                     "eventName": "remove_peer",                     "data": {                         "socketId": socket.id                     }                 }));             }         }         //从room中删除socket         if (room) {             i = this.rooms[room].indexOf(socket);             this.rooms[room].splice(i, 1);             if (this.rooms[room].length === 0) {                 delete this.rooms[room];             }         }         //关闭连接后的其他操作     });     //根据前台页面传递过来的信令进行解析，确定应该如何处理     socket.on('message', function(data) {         var json = JSON.parse(data);         if (json.eventName) {             if (json.eventName === "join") {                 joinRoom(data, socket);             }         }     });     //将连接保存     sockets.push(socket);     //连接建立后的其他操作 }); 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

最后再加上点对点的信令转发就行了，一份完整的代码可参照我写的SkyRTC项目源码

参考资料

WebRTC in the real world: STUN, TURN and signaling
SDP for the WebRTC draft-nandakumar-rtcweb-sdp-04