WebRTC多人视频通话分析

1、 WebRTC是什么？
2、 WebRTC能做什么
3、 常用API
4、 基本原理

WebRTC全称是Web Real-Time communication，是一种实时音视频通讯技术，通过WebRTC可以使浏览器之间建立点对点的连接，并实时传输数据。

通过上述可以看到浏览器M和浏览器L可以在不依赖于Web服务器的情况下点对点实时传输数据。上图中的Web服务器不是用于数据传输，而是用于协助浏览器M和浏览器L进行连接，进行协助连接的服务器也叫信令服务器。

WebRTC主要分为四部分，分别是信令、建立连接、安全加密、数据传输，下面分别介绍四个步骤。

信令是指通信两端基于交换的数据进行协商。通俗的解释就是在互联网中两个浏览器之间如果要进行点对点的数据传输，连接双方需要交换对方的一些基本信息，基本信息包括对方的地址，带宽，数据的编解码格式，是否支持音视频等等信息。

通信双方的基本信息完成交换后，浏览器双方开始建立连接。在网络中，浏览器双方可能在同一个内网，可能不在同一个内网，中间可能还隔着交换机、路由器，还会存在防火墙。在网络的环境复杂的情况下，通信的双方需要找到一条最佳路径传输数据建立连接。建立连接主要使用的协议就是ICE协议。ICE协议又需要依赖STUN协议和TURN协议。

在WebRTC中，为了保证媒体传输的安全性，引入了DTLS作为传输加密协议，DTLS原理和作用类似于SSL/TLS，DTLS主要适用于UDP通信过程的加密，SSL/TLS主要适用于TCP通信过程的加密。
在WebRTC中，音视频数据传输是使用RTP协议，然后通过 DTLS 协商出加密密钥之后，RTP 也需要升级为 SRTP，通过密钥加密后进行通信。协议栈如下图所示：

上面说了对数据加密是使用DTLS，传输数据则分为两种情况，一种是传输音视频数据，另一种是传输自定义应用数据。

1、音视频数据传输，主要使用RTP/SRTP、RTCP/SRTCP协议

前面主要对WebRTC做了一个简单介绍，跳过了很多细节，有些地方可能不够严谨，如果有兴趣的读者，可以对技术做进一步研究，比如：
1、信令如何进行协商？
2、传输层用了UDP，UDP本身是不可靠的，那么，音视频数据、自定义用户数据的时序、质量是如何保证的？
3、RTP用来传递音视频数据，为什么还需要有RTCP？
4、SCTP如何从协议层面兼顾传输的效率和质量？如何实现自定义数据的高效传递？
5、ICE协议的完整流程。
6、其他。

一) sipdroid
1）架构
sip协议栈使用JAVA实现，音频Codec使用skype的silk（Silk编解码是Skype向第三方开发人员和硬件制造商提供免版税认证(RF)的Silk宽带音频编码器）实现。NAT传输支持stun server
2）优缺点：
NAT方面只支持STUN，无ICE框架，如需要完全实现P2P视频通话需要实现符合ICE标准的客户端,音频方面没看到AEC等技术，视频方面还不是太完善，目前只看到调用的是系统自带的MediaRecorder，并没有自己的第三方音视频编解码库。
3）实际测试：
基于sipdroid架构的话，我们要做的工作会比较多，（ICE支持，添加回音消除，NetEQ等gips音频技术，添加视频硬件编解码codec）,所以就不做测试了。
二) imsdroid
1)架构：
基于doubango(Doubango 是一个基于3GPP IMS/RCS 并能用于嵌入式和桌面系统的开源框架。该框架使用ANSCI-C编写，具有很好的可移植性。并且已经被设计成非常轻便且能有效的工作在低内存和低处理能力的嵌入式系统上。苹果系统上的idoubs功能就是基于此框架编写) 音视频编码格式大部分都支持（H264(video)，VP8(video)，iLBC(audio),PCMA,PCMU,G722,G729）。NAT支持ICE（stun+turn）
2）效果实测
测试环境：公司局域网内两台机器互通，服务器走外网sip2sip
音频质量可以，但是AEC打开了还是有点回音（应该可以修复）。视频马赛克比较严重，延迟1秒左右。
3）优缺点
imsdroid目前来说还是算比较全面的，包括音视频编解码，传输（RTSP，ICE），音频处理技术等都有涉猎。doubango使用了webrtc的AEC技术，但是其调用webrtc部分没有开源，是用的编译出来的webrtc的库。如果要改善音频的话不太方便，Demo的音频效果可以，视频效果还是不太理想。
三）csipsimple
1）sip协议栈用的是pjsip,音视频编解码用到的第三方库有ffmpeg（video）,silk(audio),webrtc默认使用了webrtc的回声算法。支持ICE协议。
2）优缺点：
csipsimple架构比较清晰，sip协议由C实现，java通过JNI调用，SIP协议这一块会比较高效。其VOIP各个功能也都具备，包括NAT传输，音视频编解码。并且该项目跟进新技术比较快，官方活跃程度也比较高。如果做二次开发可以推荐这个。
3）实测效果
测试环境：公司局域网内两台机器互通，服务器走外网sip2sip
音频质量可以，无明显回音，视频需要下插件，马赛克比imsdroid更严重。
四）Linphone
这个是老牌的sip，支持平台广泛 windows, mac,ios,android,linux，技术会比较成熟。但是据玩过的同事说linphone在Android上的bug有点多，由于其代码实在庞大，所以我暂时放弃考虑Linphone不过如果谁有跨平台的需要，可以考虑Linphone或者imsdroid和下面的webrtc。。。好像现在开源软件都跨平台了。。。
五) webrtc
imsdroid,csipsimple,linphone都想法设法调用webrtc的音频技术，本人也测试过Android端的webrtc内网视频通话，效果比较满意。但是要把webrtc做成一个移动端的IM软件的话还有一些路要走，不过webrtc基本技术都已经有了，包括p2p传输，音视频codec,音频处理技术。不过其因为目前仅支持VP8的视频编码格式（QQ也是）想做高清视频通话的要注意了。VP8在移动端的硬件编解码支持的平台没几个（RK可以支持VP8硬件编解码）。不过webrtc代码里看到可以使用外部codec,这个还是有希望调到H264的。
总结：sipdroid比较轻量级，着重基于java开发（音频codec除外），由于其音视频编码以及P2P传输这一块略显不足，不太好做定制化开发和优化。imsdroid,遗憾就是直接调用webrtc的库，而最近webrtc更新的比较频繁，开发比较活跃。如果要自己在imsdroid上更新webrtc担心兼容性问题，希望imsdroid可以直接把需要的webrtc相关源码包进去。csipsimple的话，都是围绕pjsip的，webrtc等都是以pjsip插件形式扩充的,类似gstreamer webrtc如果有技术实力的开发公司个人还是觉得可以选择这个来做，一个是google的原因，一个是其视频通话相关关键技术都比较成熟的原因。个人觉得如果能做出来，效果会不错的。

WebRTC给我们带来了浏览器中的视频、音频聊天体验。但个人认为，它最实用的特性莫过于DataChannel——在浏览器之间建立一个点对点的数据通道。在DataChannel之前，浏览器到浏览器的数据传递通常是这样一个流程：浏览器1发送数据给服务器，服务器处理，服务器再转发给浏览器2。这三个过程都会带来相应的消耗，占用服务器带宽不说，还减缓了消息从发送到接收的时间。其实最理想的方式就是浏览器1直接与浏览2进行通信，服务器不需要参与其中。WebRTC DataChannel就提供了这样一种方式。

如果对WebRTC和DataChannel不太了解的同学，可以先阅读如下文章：

- WebRTC的RTCDataChannel

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

- 使用WebRTC搭建前端视频聊天室——入门篇

当然服务器完全不参与其中，显然是不可能的，用户需要通过服务器上存储的信息，才能确定需要和谁建立连接。这里通过一个故事来讲述建立连接的过程：

不如钓鱼去

一些背景：

现在，老刘听说老姚钓鱼技术高超，想和老姚讨论钓鱼技巧。只要老刘和老姚相互之间知道对方的门牌号以及凭证，就可以串门了:

老刘和老姚相互之间知道了对方的门牌号和小区出入凭证，他们相互之间有什么需要交流的直接串门就行了，消息不再需要门卫老大爷来代为传达了

换个角度

我们把角色做一个映射：

于是乎故事就变成了这样：

这样，就建立了一个点对点的信道，流程如下所示：

故事

老刘和老姚已经可以相互串门了，经过一段时间的交流感情越来越深。老姚的亲友送了20斤葡萄给老姚，老姚决定送10斤给老刘。老姚毕竟年事已高，不可能一次带10斤。于是乎，老姚将葡萄分成了10份，每次去老刘家串门就送一份过去。

这里可以做如下类比：

这其实就是通过datachannel传输文件的方式，首先将文件分片，然后逐个发送，最后再统一的进行组合成一个新的文件

分片

通过HTML5的File API可以将type为file的input选中的文件读取出来，并转换成data url字符串。这也就为我们提供了很方便的分片方式：

组合

通过datachannel发送的分片数据，我们需要将其进行组合，由于是data url字符串，在接收到所有包之后进行拼接就可以了。拼接完成后就得到了一个文件完整的data url字符串，那么我们如何将这个字符串转换成文件呢？

方案一：直接跳转下载

既然是个dataurl，我们直接将其赋值给windowlocationhref自然可以下载，但是这样下载是没法设定下载后的文件名的，这想一想都蛋疼

方案二：通过a标签下载

这个原理和跳转下载类似，都是使用dataurl本身的特性，通过创建一个a标签，将dataurl字符串赋值给href属性，然后使用download确定下载后的文件名，就可以完成下载了。但是很快又有新问题了，稍微大一点的文件下载的时候页面崩溃了。这是因为dataurl有大小限制

方案三：blob

其实可以通过给a标签创建blob url的方式来进行下载，这个没有大小限制。但是我们手上是dataurl，所以需要先进行转换：

获得blob后，我们就可以通过URL API来下载了：

这里有几个点：

1 datachannel其实是可以直接传送blob的，但是只有ff支持，所以传data url

2 chrome下载是直接触发的，不会进行询问，firefox会先询问后下载，在询问过程中如果执行了revokeObjectURL，下载就会取消，囧

升级

如我们所知，WebRTC最有特点的地方其实是可以传输getUserMedia获得的视频、音频流，来实现视频聊天。但事实上我们的使用习惯来看，一般人不会一开始就打开视频聊天，而且视频聊天时很消耗内存的（32位机上一个连接至少20M左右好像，也有可能有出入）。所以常见的需求是，先建立一个包含datachannel的连接用于传输数据，然后在需要时升级成可以传输视频、音频。

看看我们之前传输的session description，它其实来自Session Description Protocol。可以看到wiki上的介绍：

这意味着什么呢？我们之前建立datachannel是没有加视频、音频流的，而这个流的描述是写在SDP里面的。现在我们需要传输视频、音频，就需要添加这些描述。所以就得重新获得SDP，然后构建offer和answer再传输一次。传输的流程和之前一样，没什么区别。但这一次，我们不需要传输任何的ice candidate，这里我曾经遇到了坑，经过国外大大的点拨才明白过来。

Peertc

我将datachannel和websocket组合，实现了一个构建点对点连接的库Peertc，它提供非常简洁的方式来建立连接和发送数据、文件和视频/音频流，详情见github。走过路过的记得star一下哦，有什么bug也非常希望能够提出来。

最后

WebRTC的点对点方式能够运用在很多场景：

- 如web qq这种Web IM工具，这就不说了

- 如象棋这种双人对战 游戏 ，每一步的数据服务器时不关心的，所以完全可以点对点发送

- 一对一在线面试、在线教育，这其实是即时通信的一个业务方向

简介
WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。

这是百度百科上的介绍，维基百科也差不多。对完全小白来讲，可能不是很理解这句话。

首先，什么是实时通信？
举个直白的例子，我们平时打电话就是实时通信。现在有很多实时通信的软件，比如 丁丁、有信……这是手机app。PC客户端像Xlite、Linphone等等。这些客户端接入网络，注册到相应的服务器上就可以进行音频通信了，支持视频的还能进行视频通信。拿Xlite来说，它的信令机制采用的是sip协议。SIP协议是IMS网络广泛使用的信令协议，已经很成熟。两个uesr 通过Xlite客户端注册到sip server（如 Asterisk）上，就可以互相拨打对方的号码音视频通信了，不过就Xlite来说，语音通话是免费的，但是视频的话，是要支付money软件才提供视频功能的……

其次，为什么要提出WebRTC？
一直以来，用户如果想通过互联网进行实时通信，就需要安装软件，要么就得在浏览器中安装插件。WebRTC的宗旨是不需用户安装任何插件，直接使用浏览器就可以进行实时音视频通信。就是如果WebRTC实现了，我们打开浏览器，输入网址，登陆进去，拨打号码，就可以互相音视频了。不再需要安软件，也不需要安装额外的浏览器插件。Web版QQ大家都用过吧，现在还只能发发消息发发表情，如果引入WebRTC，那音视频传文件都不在话下，现在QQ客户端有的功能，通过网页访问都能体验，估计到时候都不愿意再装体积越来越大的QQ客户端了吧。

最后，需要知道的内容

WebRTC已经纳入HTML5标准
目前支持webrtc的浏览器有 Chrome Firefox Opera，IE不支持~
WebRTC没有指定具体的信令协议，具体的信令协议留给应用程序实现。
webRTC使用JSEP协议建立会话，什么是JSEP后面说
WebRTC采用ICE实现NAT穿越
WebRTC客户端之间可以进行点对点的媒体传输。
JSEP
JSEP（JavaScript Session Establishment Protocol，JavaScript会话建立协议）是一个信令API，允许开发者构建更强大的应用程序以及增加在信令协议选择上的灵活性。

建立会话最关键的就是媒体的协商，WebRTC虽然没有指定具体的信令协议，但是媒体协商采用了SDP协议。JSEP是干什么的呢，一方面提供接口如createOffer()供web应用程序调用生成SDP，另一方面提供ICE功能接口。这些功能都由浏览器实现，浏览器
WebRTC传输信令（offer/answer）采用Websocket。
需要说明的是，如果web应用程序不使用额外的信令协议，仅使用JSEP，两个WebRTC client （同一个WebRTC client程序，两处登陆） 之间也是可以建立链接的，即只要应用程序能解析用WS传递过来的Offer/Answer消息，提取出其中的SDP和ICE信息就可以了。

github上codelabdemo 就是不用其他信令协议，直接使用JSEP生成offer/answer信令，然后采用ws协议传输实现的。

JSEP并不是信令协议，可以在JSEP的基础上引入SIP等信令协议，使WebRTC应用功能更加完备。

WebRTC与SIP互通
要想让WebRTC与sip互通，要解决两个层面的问题：信令层和媒体层。
两个网络使用的信令机制不同，所以要进行信令的转换，才能完成媒体的协商，建立会话。媒体层要完成编码的转换，以及rtp/srtp转换等功能。这里主要说项信令层面的互通。

信令互通方案
目前sip和webrtc信令上互通有两种解决方案：

用JavaScript实现sip协议栈，webrtc应用程序基于这个协议栈开发。这样webrtc client发出的信令就是sip信令，但一般采用websocket为信令传输协议。这样的webrtc client就可以直接注册到支持ws的sip server上了。
jssip 、sipml5 都是这种解决方案。
通过转换网关实现协议的转换，从而互通。一个开源的网关项目就是 webrtc2sip。
webrtc2sip是一个功能很完善的网关，既实现了信令层，也实现了媒体层，编码转换功能很强大，也可以直接当做媒体网关，用于编解码，沟通两端的媒体。

---