使用WebRTC搭建前端視訊聊天室——信令篇
如果需要搭建例項的話可以參照SkyRTC-demo：github地址
其中使用了兩個庫：SkyRTC(github地址)和SkyRTC-client(github地址)
這兩個庫和demo都是我寫的，如果有bug或是錯誤歡迎指出，我會盡力更正
前面的話
這篇文章講述了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 111103 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
其實可以將其簡化一下，它就是一個在點對點連線中描述自己的字串，我們可以將其封裝在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);
當然這個地址也需要交換，還是以甲乙兩位為例，交換的流程如下（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);
//連線建立後的其他操作
});
由於有房間的劃分，所以我們需要在伺服器上建立一個容器，用來儲存房間內的使用者資訊。顯然物件較為合適，鍵為房間名稱，值為使用者資訊列表。
同時我們需要監聽上面所說的使用者加入房間的信令（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);
//連線建立後的其他操作
});
最後再加上點對點的信令轉發就行了，一份完整的程式碼可參照我寫的SkyRTC專案原始碼