摘要：使用能使得狀態被保存在服務器上會話描述協議將客戶端之間傳遞的信令分為兩種信令和信令。他們主要內容的格式都遵循會話描述協議，簡稱。

博客原文地址

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

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

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

這兩個庫和demo都是我寫的，如果有bug或是錯誤歡迎指出，我會盡力更正

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

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

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

在建立連接之前，瀏覽器之間顯然沒有辦法傳遞數據。所以我們需要通過服務器的中轉，在瀏覽器之間傳遞這些數據，然后建立瀏覽器之間的點對點連接。但是WebRTC API中并沒有實現這些。

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

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

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

其實可以將其簡化一下，它就是一個在點對點連接中描述自己的字符串，我們可以將其封裝在JSON中進行傳輸，在PeerConnection建立后將其通過服務器中轉后，將自己的SDP描述符和對方的SDP描述符交給PeerConnection就行了

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

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

大致上在兩個用戶（甲和乙）之間建立點對點連接流程應該是這個樣子（這里不考慮錯誤的情況，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描述符了，完成了兩件事的第一件。我們還需要完成第二件事——獲取連接兩端主機的網絡地址

這個網絡地址應該是能從外界直接訪問，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項目源碼

WebRTC in the real world: STUN, TURN and signaling

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