摘要：使用能使得狀態(tài)被保存在服務(wù)器上會(huì)話描述協(xié)議將客戶端之間傳遞的信令分為兩種信令和信令。他們主要內(nèi)容的格式都遵循會(huì)話描述協(xié)議，簡(jiǎn)稱。

博客原文地址

建議看這篇之前先看一下使用WebRTC搭建前端視頻聊天室——入門篇

如果需要搭建實(shí)例的話可以參照SkyRTC-demo：github地址

其中使用了兩個(gè)庫：SkyRTC(github地址)和SkyRTC-client(github地址)

這兩個(gè)庫和demo都是我寫的，如果有bug或是錯(cuò)誤歡迎指出，我會(huì)盡力更正

這篇文章講述了WebRTC中所涉及的信令交換以及聊天室中的信令交換，主要內(nèi)容來自WebRTC in the real world: STUN, TURN and signaling，我在這里提取出的一些信息，并添加了自己在開發(fā)時(shí)的一些想法。

WebRTC提供了瀏覽器到瀏覽器（點(diǎn)對(duì)點(diǎn)）之間的通信，但并不意味著WebRTC不需要服務(wù)器。暫且不說基于服務(wù)器的一些擴(kuò)展業(yè)務(wù)，WebRTC至少有兩件事必須要用到服務(wù)器：
1. 瀏覽器之間交換建立通信的元數(shù)據(jù)（信令）必須通過服務(wù)器
2. 為了穿越NAT和防火墻

我們需要通過一系列的信令來建立瀏覽器之間的通信。而具體需要通過信令交換哪些內(nèi)容呢？這里大概列了一下：
1. 用來控制通信開啟或者關(guān)閉的連接控制消息
2. 發(fā)生錯(cuò)誤時(shí)用來彼此告知的消息
3. 媒體流元數(shù)據(jù)，比如像解碼器、解碼器的配置、帶寬、媒體類型等等
4. 用來建立安全連接的關(guān)鍵數(shù)據(jù)
5. 外界所看到的的網(wǎng)絡(luò)上的數(shù)據(jù)，比如IP地址、端口等

在建立連接之前，瀏覽器之間顯然沒有辦法傳遞數(shù)據(jù)。所以我們需要通過服務(wù)器的中轉(zhuǎn)，在瀏覽器之間傳遞這些數(shù)據(jù)，然后建立瀏覽器之間的點(diǎn)對(duì)點(diǎn)連接。但是WebRTC API中并沒有實(shí)現(xiàn)這些。

不去由WebRTC實(shí)現(xiàn)信令交換的原因很簡(jiǎn)單：WebRTC標(biāo)準(zhǔn)的制定者們希望能夠最大限度地兼容已有的成熟技術(shù)。具體的連接建立方式由一種叫JSEP（JavaScript Session Establishment Protocol）的協(xié)議來規(guī)定，使用JSEP有兩個(gè)好處：
1. 在JSEP中，需要交換的關(guān)鍵信息是多媒體會(huì)話描述（multimedia session description）。由于開發(fā)者在其所開發(fā)的應(yīng)用程序中信令所使用的協(xié)議不同（SIP或是XMPP或是開發(fā)者自己定義的協(xié)議），WebRTC建立呼叫的思想建立在媒體流控制層面上，從而與上層信令傳輸相分離，防止相互之間的信令污染。只要上層信令為其提供了多媒體會(huì)話描述符這樣的關(guān)鍵信息就可以建立連接，不管開發(fā)者用何種方式來傳遞。
2. JSEP的架構(gòu)同時(shí)也避免了在瀏覽器上保存連接的狀態(tài)，防止其像一個(gè)狀態(tài)機(jī)一樣工作。由于頁面經(jīng)常被頻繁的刷新，如果連接的狀態(tài)保存在瀏覽器中，每次刷新都會(huì)丟失。使用JSEP能使得狀態(tài)被保存在服務(wù)器上

JSEP將客戶端之間傳遞的信令分為兩種:offer信令和answer信令。他們主要內(nèi)容的格式都遵循會(huì)話描述協(xié)議（Session Description Protocal，簡(jiǎn)稱SDP）。一個(gè)SDP的信令的內(nèi)容大致上如下：

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

這些都什么玩意？說實(shí)話我不知道，我這里放這么一大段出來，只是為了讓文章內(nèi)容顯得很多...如果想深入了解的話，可以參考SDP for the WebRTC draft-nandakumar-rtcweb-sdp-04自行進(jìn)行解析

其實(shí)可以將其簡(jiǎn)化一下，它就是一個(gè)在點(diǎn)對(duì)點(diǎn)連接中描述自己的字符串，我們可以將其封裝在JSON中進(jìn)行傳輸，在PeerConnection建立后將其通過服務(wù)器中轉(zhuǎn)后，將自己的SDP描述符和對(duì)方的SDP描述符交給PeerConnection就行了

在前一篇文章中介紹過，WebRTC使用RTCPeerConnection來在瀏覽器之間傳遞流數(shù)據(jù)，在建立RTCPeerConnection實(shí)例之后，想要使用其建立一個(gè)點(diǎn)對(duì)點(diǎn)的信道，我們需要做兩件事：
1. 確定本機(jī)上的媒體流的特性，比如分辨率、編解碼能力啥的（SDP描述符）
2. 連接兩端的主機(jī)的網(wǎng)絡(luò)地址（ICE Candidate）

需要注意的是，由于連接兩端的主機(jī)都可能在內(nèi)網(wǎng)或是在防火墻之后，我們需要一種對(duì)所有聯(lián)網(wǎng)的計(jì)算機(jī)都通用的定位方式。這其中就涉及NAT/防火墻穿越技術(shù)，以及WebRTC用來達(dá)到這個(gè)目的所ICE框架。這一部分在上一篇文章中有介紹，這里不再贅述。

大致上在兩個(gè)用戶（甲和乙）之間建立點(diǎn)對(duì)點(diǎn)連接流程應(yīng)該是這個(gè)樣子（這里不考慮錯(cuò)誤的情況，RTCPeerConnection簡(jiǎn)稱PC）：
1. 甲和乙各自建立一個(gè)PC實(shí)例
2. 甲通過PC所提供的createOffer()方法建立一個(gè)包含甲的SDP描述符的offer信令
3. 甲通過PC所提供的setLocalDescription()方法，將甲的SDP描述符交給甲的PC實(shí)例
4. 甲將offer信令通過服務(wù)器發(fā)送給乙
5. 乙將甲的offer信令中所包含的的SDP描述符提取出來，通過PC所提供的setRemoteDescription()方法交給乙的PC實(shí)例
6. 乙通過PC所提供的createAnswer()方法建立一個(gè)包含乙的SDP描述符answer信令
7. 乙通過PC所提供的setLocalDescription()方法，將乙的SDP描述符交給乙的PC實(shí)例
8. 乙將answer信令通過服務(wù)器發(fā)送給甲
9. 甲接收到乙的answer信令后，將其中乙的SDP描述符提取出來，調(diào)用setRemoteDescripttion()方法交給甲自己的PC實(shí)例

通過在這一系列的信令交換之后，甲和乙所創(chuàng)建的PC實(shí)例都包含甲和乙的SDP描述符了，完成了兩件事的第一件。我們還需要完成第二件事——獲取連接兩端主機(jī)的網(wǎng)絡(luò)地址

這個(gè)網(wǎng)絡(luò)地址應(yīng)該是能從外界直接訪問，WebRTC使用ICE框架來獲得這個(gè)地址。RTCPeerConnection在創(chuàng)立的時(shí)候可以將ICE服務(wù)器的地址傳遞進(jìn)去，如：

var iceServer = {
    "iceServers": [{
        "url": "stun:stun.l.google.com:19302"
    }]
};
var pc = new RTCPeerConnection(iceServer);

當(dāng)然這個(gè)地址也需要交換，還是以甲乙兩位為例，交換的流程如下（RTCPeerConnection簡(jiǎn)稱PC）：
1. 甲、乙各創(chuàng)建配置了ICE服務(wù)器的PC實(shí)例，并為其添加onicecandidate事件回調(diào)
2. 當(dāng)網(wǎng)絡(luò)候選可用時(shí)，將會(huì)調(diào)用onicecandidate函數(shù)
3. 在回調(diào)函數(shù)內(nèi)部，甲或乙將網(wǎng)絡(luò)候選的消息封裝在ICE Candidate信令中，通過服務(wù)器中轉(zhuǎn)，傳遞給對(duì)方
4. 甲或乙接收到對(duì)方通過服務(wù)器中轉(zhuǎn)所發(fā)送過來ICE Candidate信令時(shí)，將其解析并獲得網(wǎng)絡(luò)候選，將其通過PC實(shí)例的addIceCandidate()方法加入到PC實(shí)例中

這樣連接就創(chuàng)立完成了，可以向RTCPeerConnection中通過addStream()加入流來傳輸媒體流數(shù)據(jù)。將流加入到RTCPeerConnection實(shí)例中后，對(duì)方就可以通過onaddstream所綁定的回調(diào)函數(shù)監(jiān)聽到了。調(diào)用addStream()可以在連接完成之前，在連接建立之后，對(duì)方一樣能監(jiān)聽到媒體流

上面是兩個(gè)用戶之間的信令交換流程，但我們需要建立一個(gè)多用戶在線視頻聊天的聊天室。所以需要進(jìn)行一些擴(kuò)展，來達(dá)到這個(gè)要求

首先需要確定一個(gè)用戶在聊天室中的操作大致流程：
1. 打開頁面連接到服務(wù)器上
2. 進(jìn)入聊天室
3. 與其他所有已在聊天室的用戶建立點(diǎn)對(duì)點(diǎn)的連接，并輸出在頁面上
4. 若有聊天室內(nèi)的其他用戶離開，應(yīng)得到通知，關(guān)閉與其的連接并移除其在頁面中的輸出
5. 若又有其他用戶加入，應(yīng)得到通知，建立于新加入用戶的連接，并輸出在頁面上
6. 離開頁面，關(guān)閉所有連接

從上面可以看出來，除了點(diǎn)對(duì)點(diǎn)連接的建立，還需要服務(wù)器至少做如下幾件事：
1. 新用戶加入房間時(shí)，發(fā)送新用戶的信息給房間內(nèi)的其他用戶
2. 新用戶加入房間時(shí)，發(fā)送房間內(nèi)的其他用戶信息給新加入房間的用戶
3. 用戶離開房間時(shí)，發(fā)送離開用戶的信息給房間內(nèi)的其他用戶

以使用WebSocket為例，上面用戶操作的流程可以進(jìn)行以下修改：
1. 瀏覽器與服務(wù)器建立WebSocket連接
2. 發(fā)送一個(gè)加入聊天室的信令（join），信令中需要包含用戶所進(jìn)入的聊天室名稱
3. 服務(wù)器根據(jù)用戶所加入的房間，發(fā)送一個(gè)其他用戶信令（peers），信令中包含聊天室中其他用戶的信息，瀏覽器根據(jù)信息來逐個(gè)構(gòu)建與其他用戶的點(diǎn)對(duì)點(diǎn)連接
4. 若有用戶離開，服務(wù)器發(fā)送一個(gè)用戶離開信令（remove_peer），信令中包含離開的用戶的信息，瀏覽器根據(jù)信息關(guān)閉與離開用戶的信息，并作相應(yīng)的清除操作
5. 若有新用戶加入，服務(wù)器發(fā)送一個(gè)用戶加入信令（new_peer），信令中包含新加入的用戶的信息，瀏覽器根據(jù)信息來建立與這個(gè)新用戶的點(diǎn)對(duì)點(diǎn)連接
6. 用戶離開頁面，關(guān)閉WebSocket連接

由于用戶可以只是建立連接，可能還沒有進(jìn)入具體房間，所以首先我們需要一個(gè)容器來保存所有用戶的連接，同時(shí)監(jiān)聽用戶是否與服務(wù)器建立了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);
        //關(guān)閉連接后的其他操作
    });
    sockets.push(socket);
    //連接建立后的其他操作
});

由于有房間的劃分，所以我們需要在服務(wù)器上建立一個(gè)容器，用來保存房間內(nèi)的用戶信息。顯然對(duì)象較為合適，鍵為房間名稱，值為用戶信息列表。

同時(shí)我們需要監(jiān)聽上面所說的用戶加入房間的信令（join），新用戶加入之后需要向新用戶發(fā)送房間內(nèi)其他用戶信息（peers）和向房間內(nèi)其他用戶發(fā)送新用戶信息（new_peer），以及用戶離開時(shí)向其他用戶發(fā)送離開用戶的信息（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; //當(dāng)前房間的socket列表
    var socketIds = []; //房間其他用戶的id

    curRoomSockets = rooms[room] = rooms[room] || [];

    //給所有房間內(nèi)的其他人發(fā)送新用戶的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;

    //給新用戶發(fā)送其他用戶的信息，及服務(wù)器給新用戶自己賦予的id
    socket.send(JSON.stringify({
        "eventName": "peers",
        "data": {
            "socketIds": socketIds,
            "you": socket.id
        }
    }));
};

server.on("connection", function(socket) {
    //為socket構(gòu)建一個(gè)特有的id，用來作為區(qū)分用戶的標(biāo)記
    socket.id = getRandomString();
    //用戶關(guān)閉連接后，應(yīng)做的處理
    socket.on("close", function() {
        var i = sockets.indexOf(socket);
        var room = socket.room;
        var curRoomSockets = rooms[room];
        sockets.splice(i, 1);
        //通知房間內(nèi)其他用戶
        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];
            }
        }
        //關(guān)閉連接后的其他操作
    });
    //根據(jù)前臺(tái)頁面?zhèn)鬟f過來的信令進(jìn)行解析，確定應(yīng)該如何處理
    socket.on("message", function(data) {
        var json = JSON.parse(data);
        if (json.eventName) {
            if (json.eventName === "join") {
                joinRoom(data, socket);
            }
        }
    });
    //將連接保存
    sockets.push(socket);
    //連接建立后的其他操作
});

最后再加上點(diǎn)對(duì)點(diǎn)的信令轉(zhuǎn)發(fā)就行了，一份完整的代碼可參照我寫的SkyRTC項(xiàng)目源碼

WebRTC in the real world: STUN, TURN and signaling

SDP for the WebRTC draft-nandakumar-rtcweb-sdp-04