WebRTC 服务器要干些什么

WebRTC 的服务器大体分为信令服务器和媒体服务器

WebRTC 信令服务器是主要功能是为 WebRTC 通讯搭建一个了解彼此能力的通道, 交换信息, 同步改动.

而媒体服务器就是用来交换媒体，包括对媒体数据的加解密，编解码，带宽和速率控制等功能

不同的 RTP Toplogies 对服务器有不同的要求

WebRTC 或者说多媒体通信一般有如下的几种拓扑结构：

如果是两个人之间的端到端 (P2P) 的通信, 信令服务器的功能很简单

而由于是点对点的通信，媒体服务器也就不需要了。

如果是 SFU(Selective Forward Unit), 那么它的信令服务器除了上述的 SDP 媒体参数协商， ICE 连接地址交换，还有参加 RTP 会话的参加者信息的同步。

多个人之间的会议系统, 信令控制会麻烦很多,除了上述两个基本功能之外, 还要有

在 RFC4575 中有这样的定义

Multiple Control Unit 多点控制单元相比 SFU, 它有着对于媒体流的 Mix 和 translate 功能，可以很好地适配传统的通信设备，在实际应用中，一般我们会以 SFU 为主， MCU 为辅，共同形成一个服务器集群。

在 WebRTC 服务器上，我们一般会维护如下的领域对象

领域对象的具体内容从略，一般有如下的 Command 或 Event

应用层的事件大约可以分为 5 类

具体的有

在一个视频会议中，大家都在向会议室中发布自己的音视频流，也订阅他人的音视频媒体流，所以服务器，特别是 SFU 需要维护这样一个 pub-sub 发布者和订阅者之间的关系

在WebRTC简介中提到信令服务器用于向中端传输数据，信令服务器是实现两个webRTC中端通信的重要角色。今天就来实现一下信令服务器。

作为前端开发对于后端的东西不是很熟悉，只能使用现成的一些服务器软件和nodejs来搭建信令服务器。

业务逻辑

当两个用户要进行通信时，他们首先要创建一个房间，成功加入房间之后，双方才能交换必要的信息。

当通信的双方结束通话后，用户需要发送离开房间的消息给信令服务器，此时信令服务器需要将房间内的所有人清除；如果房间里已经没有人了，还需要将空房间销毁掉。

这样的逻辑socket.io已经帮我们实现了，我们只需要使用就行，不需要自己重新开发。

因此，我们使用nodejs+express+socket.io实现信令服务器。

创建服务器

const http = require('http')//引入http库

const express = require('express')//引入express库

//创建HTTP服务，并侦听8980端口

const app = express()

const http_server = http.createServer(app)

http_server.listen(8080, '0.0.0.0')

1

2

3

4

5

6

7

1

2

3

4

5

6

7

首先，通过express创建一个Web应用；之后调用HTTP库的createServer（）方法创建HTTP对象，即http_server；最后调用http_server对象的listen（）方法侦听8080端口。通过上面的步骤就实现了一个HTTP服务。

注册socket.io的回调函数

io.sockets.on('connection', (socket) =>{

//收到message时，进行转发

socket.on('message', (message) =>{

//给另一端转发消息

socket.to(room).emit('message', message)

})

//收到 join 消息

socket.on('join', (room) =>{

var o = io.sockets.adapter.rooms[room]

//得到房

在不同的网络环境(带有摄像头/麦克风多媒体设备)中，为两个浏览器实现点对点实时视频/语音通信有什么困难?

1、了解对方的媒体格式、支持的最大分辨率和其他媒体信息？

2、要了解彼此的网络，就有可能找到一条通信链路？

3、两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢?

为了保证两端都有正确的编码和解码，最简单的方法就是取它们的交集H264

注:有一种特殊的协议叫做Session Description protocol (SDP)，可以用来描述上述信息 。

在webrtc中，参与视频通信的双方必须首先交换SDP信息，这样双方才能了解基本的SDP交换过程。

同样，在复杂的网络环境中，要在两端之间建立连接，必须有一个双方都可以访问的链路。

从图中可以看出，他们可以使用公用网段192沟通。

在web brtc通信过程中，这些与网络相关的信息也必须进行交换，以找到共同的交集。这个过程也被称为“网络协商”。

两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢?

此时，所谓信号服务器信号服务器应该出现:

如上图所示,两个浏览器可以抽象的上层一层信令服务器(可以是一个或多个,根据实际的应用程序中,如果两个浏览器可以访问公共网络环境,如公共如果没有公共网络环境中,您可以设置一组服务器两端,即信号服务器A和信号服务器B，但这两套信令服务器必须能够相互通信)，在信令服务器的帮助下，可以实现上述SDP信息和网络信息的交换。

交换SDP的过程大致如图所示:

1. Amy(假设一个人的名字)通过setLocalDescription方法保存自己的SDP信息，然后通过offer方法发送给信令服务器。

2. 信息服务器将Amy的SDP转发给另一端的Bob(另一个虚构的名字)，Bob将首先调用setremotedescription来保存Amy的SDP。

3.然后Bob调用setLocalDescription方法来保存他的SDP，然后使用answer方法通过信令服务器将他的SDP发送给Amy

4. Amy收到Bob的SDP后，调用setRemoteDescription进行保存，双方完成SDP交换，找到交集。如果他们能达成协议，他们就可以建立一个p2p连接并开始通信。

但现实往往是残酷的。在中国的网络环境下，据统计，至少有一半的网络不能直接连接。我个人认为根本原因是:在互联网发展的早期，绝大多数IP4地址资源都被国外所占据。当轮到中国等发展中国家使用IP地址时，大多数计算机没有公网IP地址，只能通过路由器和交换机进行NAT转换，相当一部分NAT是对称的。基本上，没有办法播放它。在这种情况下，您只能使用前一节提到的转向服务器进行转移。此外，在视频对话框中，通常会有房间(或组)的概念，用来隔离一些服务。这部分逻辑也在信号服务器中实现。对端、信令服务器、stun/转接服务器后，整个1对1实时视频通信顺序图如下:

主要流程如下:

1. 双方首先调用getUserMedia打开本地摄像头

2. 向信令服务器发送apply_join请求以加入房间

3.信令服务器通知我成功加入(joined)，同时向其他人广播加入消息(other_joined)

4. 第二个端开始创建peerConnection连接

5. PeerB创建报价，同时将SDP保存到本地机器(setLocalDescription)，并通过信令服务器将SDP传递给peerA

6. 在setLocalDescription之后，PeerB将异步触发“候选网络链接”的集合，这大致决定了它自己所有的NAT映射通过Stun退出。如果Stun返回的NAT是“对称的”，它将基本上无法穿透。再次通过Turn得到中继应答地址，并通过信令服务器将网络候选链接信息发送给peerA(即:启动网络协商)

7. peerA收到peerB的SDP后，开始响应(createAnswer)，仍然通过信令服务器将SDP发送给peerB

8. 同时，peerA也会开始收集网络候选链路，并通过信令服务器(即网络协商)将自己的网络信息发送给peerB。

通过这种方式，peerA和peerB相互交换了媒体信息和网络信息。如果他们能达成一致(即找到交叉点)，他们就能开始沟通。

---