使用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=
o=-    IN IP4 .
s=-
t= 
a=group:BUNDLE audio video data
a=msid-semantic: WMS UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g
m=audio  RTP/SAVPF         
c=IN IP4 .
a=rtcp: IN IP4 .
a=ice-ufrag:grnpQ0BSTSnBLroq
a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5
a=ice-options:google-ice
a=fingerprint:sha- :A3::E::E:EF:::C:B:C:E:B0::F6::E9::E3:F:::ED:EC::C:C::E3::B
a=setup:actpass
a=mid:audio
a=extmap: urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=rtcp-mux
a=crypto: AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV
a=rtpmap: opus//
a=fmtp: minptime=
a=rtpmap: ISAC/
a=rtpmap: ISAC/
a=rtpmap: PCMU/
a=rtpmap: PCMA/
a=rtpmap: CN/
a=rtpmap: CN/
a=rtpmap: CN/
a=rtpmap: telephone-event/
a=maxptime:
m=video  RTP/SAVPF   
c=IN IP4 .
a=rtcp: IN IP4 .
a=ice-ufrag:grnpQ0BSTSnBLroq
a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5
a=ice-options:google-ice
a=fingerprint:sha- :A3::E::E:EF:::C:B:C:E:B0::F6::E9::E3:F:::ED:EC::C:C::E3::B
a=setup:actpass
a=mid:video
a=extmap: urn:ietf:params:rtp-hdrext:toffset
a=extmap: http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto: AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV
a=rtpmap: VP8/
a=rtcp-fb: ccm fir
a=rtcp-fb: nack
a=rtcp-fb: goog-remb
a=rtpmap: red/
a=rtpmap: ulpfec/
a=ssrc: cname:/nERF7Ern+udqf++
a=ssrc: msid:UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g b204e-c9a0-b01-b361-e17e9bf8f639
a=ssrc: mslabel:UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g
a=ssrc: label:b204e-c9a0-b01-b361-e17e9bf8f639
m=application  DTLS/SCTP 
c=IN IP40..
a=ice-ufrag:grnpQ0BSTSnBLroq
a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5
a=ice-options:google-ice
a=fingerprint:sha- :A3::E::E:EF:::C:B:C:E:B0::F6::E9::E3:F:::ED:EC::C:C::E3::B
a=setup:actpass
a=mid:data
a=sctpmap: webrtc-datachannel

這些都什麼玩意？說實話我不知道，我這裡放這麼一大段出來，隻是為了讓文章内容顯得很多…如果想深入了解的話，可以參考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）：

甲和乙各自建立一個PC執行個體

甲通過PC所提供的createOffer()方法建立一個包含甲的SDP描述符的offer信令

甲通過PC所提供的setLocalDescription()方法，将甲的SDP描述符交給甲的PC執行個體

甲将offer信令通過伺服器發送給乙

乙将甲的offer信令中所包含的的SDP描述符提取出來，通過PC所提供的setRemoteDescription()方法交給乙的PC執行個體

乙通過PC所提供的createAnswer()方法建立一個包含乙的SDP描述符answer信令

乙通過PC所提供的setLocalDescription()方法，将乙的SDP描述符交給乙的PC執行個體

乙将answer信令通過伺服器發送給甲

甲接收到乙的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）：

甲、乙各建立配置了ICE伺服器的PC執行個體，并為其添加onicecandidate事件回調

當網絡候選可用時，将會調用onicecandidate函數

在回調函數内部，甲或乙将網絡候選的消息封裝在ICE Candidate信令中，通過伺服器中轉，傳遞給對方

甲或乙接收到對方通過伺服器中轉所發送過來ICE Candidate信令時，将其解析并獲得網絡候選，将其通過PC執行個體的addIceCandidate()方法加入到PC執行個體中

這樣連接配接就創立完成了，可以向RTCPeerConnection中通過addStream()加入流來傳輸媒體流資料。将流加入到RTCPeerConnection執行個體中後，對方就可以通過onaddstream所綁定的回調函數監聽到了。調用addStream()可以在連接配接完成之前，在連接配接建立之後，對方一樣能監聽到媒體流

聊天室中的信令

上面是兩個使用者之間的信令交換流程，但我們需要建立一個多使用者線上視訊聊天的聊天室。是以需要進行一些擴充，來達到這個要求

使用者操作

首先需要确定一個使用者在聊天室中的操作大緻流程：

打開頁面連接配接到伺服器上

進入聊天室

與其他所有已在聊天室的使用者建立點對點的連接配接，并輸出在頁面上

若有聊天室内的其他使用者離開，應得到通知，關閉與其的連接配接并移除其在頁面中的輸出

若又有其他使用者加入，應得到通知，建立于新加入使用者的連接配接，并輸出在頁面上

離開頁面，關閉所有連接配接

從上面可以看出來，除了點對點連接配接的建立，還需要伺服器至少做如下幾件事：

新使用者加入房間時，發送新使用者的資訊給房間内的其他使用者

新使用者加入房間時，發送房間内的其他使用者資訊給新加入房間的使用者

使用者離開房間時，發送離開使用者的資訊給房間内的其他使用者

實作思路

以使用WebSocket為例，上面使用者操作的流程可以進行以下修改：

浏覽器與伺服器建立WebSocket連接配接

發送一個加入聊天室的信令（join），信令中需要包含使用者所進入的聊天室名稱

伺服器根據使用者所加入的房間，發送一個其他使用者信令（peers），信令中包含聊天室中其他使用者的資訊，浏覽器根據資訊來逐個建構與其他使用者的點對點連接配接

若有使用者離開，伺服器發送一個使用者離開信令（remove_peer），信令中包含離開的使用者的資訊，浏覽器根據資訊關閉與離開使用者的資訊，并作相應的清除操作

若有新使用者加入，伺服器發送一個使用者加入信令（new_peer），信令中包含新加入的使用者的資訊，浏覽器根據資訊來建立與這個新使用者的點對點連接配接

使用者離開頁面，關閉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, );
        //關閉連接配接後的其他操作
    });
    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, );
        //通知房間内其他使用者
        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, );
            if (this.rooms[room].length === ) {
                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);
    //連接配接建立後的其他操作
});

最後再加上點對點的信令轉發就行了，一份完整的代碼可參照我寫的

使用WebRTC搭建前端視訊聊天室——信令篇（轉）

繼續閱讀

SSL 伺服器與用戶端樣本代碼SSL API函數說明：

新知實驗室TRTC初體驗小記正文運作效果展示代碼分析測試回報及問題解決總結

現在直播大部分都是RTMP RTMP VS RTC

RTSP、RTP、RTCP協定簡介什麼是RTSPRTSP是如何工作的RTP/RTCPRTCP如何保證RTP的傳輸品質？SRTP

Chrome 57版本的WebRTC預設使用rtp,rtcp端口複用

Webrtc NS子產品算法

VS中引入并使用WebRTC庫

licode服務架構及流程

WebRtc音視訊

WebRTC 音頻抗弱網技術（上）前向糾錯技術後向糾錯技術編碼器 OPUS 抗弱網特性[7]

webrtc 中RTP和RTCP類型判斷

[webrtc] rtcp子產品中rtt時間計算

前端:3分鐘實作一個共享桌面，還能聽見麥克風聲音哦

唱吧錄制的歌曲轉換成mp3_錄制開放文化歌曲

建構基于浏覽器的Web P2P網絡直播摘要