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

博客原文地址javascript

建议看这篇以前先看一下使用WebRTC搭建前端视频聊天室——入门篇html

若是须要搭建实例的话能够参照SkyRTC-demo:github地址前端

其中使用了两个库:SkyRTC(github地址)和SkyRTC-client(github地址)html5

这两个库和demo都是我写的,若是有bug或是错误欢迎指出,我会尽力更正java

前面的话

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

WebRTC的服务器

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

为何须要信令?

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

在创建链接以前,浏览器之间显然没有办法传递数据。因此咱们须要经过服务器的中转,在浏览器之间传递这些数据,而后创建浏览器之间的点对点链接。可是WebRTC API中并无实现这些。json

为何WebRTC不去实现信令交换?

不去由WebRTC实现信令交换的缘由很简单:WebRTC标准的制定者们但愿可以最大限度地兼容已有的成熟技术。具体的链接创建方式由一种叫JSEP(JavaScript Session Establishment Protocol)的协议来规定,使用JSEP有两个好处:
1. 在JSEP中,须要交换的关键信息是多媒体会话描述(multimedia session description)。因为开发者在其所开发的应用程序中信令所使用的协议不一样(SIP或是XMPP或是开发者本身定义的协议),WebRTC创建呼叫的思想创建在媒体流控制层面上,从而与上层信令传输相分离,防止相互之间的信令污染。只要上层信令为其提供了多媒体会话描述符这样的关键信息就能够创建链接,无论开发者用何种方式来传递。
2. JSEP的架构同时也避免了在浏览器上保存链接的状态,防止其像一个状态机同样工做。因为页面常常被频繁的刷新,若是链接的状态保存在浏览器中,每次刷新都会丢失。使用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

这些都什么玩意?说实话我不知道,我这里放这么一大段出来,只是为了让文章内容显得不少...若是想深刻了解的话,能够参考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);

固然这个地址也须要交换,仍是以甲乙两位为例,交换的流程以下(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

相关文章
相关标签/搜索