WebRTC基础原理和项目经验泛讲(1)

antonio 10-12 3057

前言：

现在看官们对“pythonwebrtc”大体比较注意，你们都想要知道一些“pythonwebrtc”的相关资讯。那么小编在网上搜集了一些有关“pythonwebrtc””的相关内容，希望你们能喜欢，姐妹们快快来学习一下吧！

0.引言

本篇文章主要讲解前面关于webrtc和项目经验的总结。为了更好理解本篇文章，也给出了前面文章的参考列表，如下:

webrtc之一对一通话原理(1)

webrtc之一对一通话实战与原理(2)

webrtc之一对一通话实战与原理(3)

详细讲解webrtc原理(1)

WebRtC音视频通话之AppRTC实战(2)

WebRtC音视频通话之AppRTC实战(1)

手把手实现WebRtc一对一视频通话实战(7)

webrtc实战打开摄像头和麦克风

手把手实现WebRtc一对一视频通话实战(5)

手把手实现WebRtc一对一视频通话实战(1)

手把手实现WebRtc一对一视频通话实战(2)

手把手实现WebRtc一对一视频通话实战(3)

手把手实现WebRtc一对一视频通话实战(9)

手把手实现WebRtc一对一视频通话实战(6)

手把手实现WebRtc一对一视频通话实战(4)

手把手实现WebRtc一对一视频通话实战(8)

WebSocket基础讲解(2)

websocket聊天实战(1)

websocket聊天实战(3)

WebSocket基础讲解(1)

websocket聊天实战(4)之js补充

1.WebRtc基本介绍

WebRtc支持主流浏览器，Android、IOS、win、linux原生API。比如支持js/API/java/obkect-c/c++。Flutter跨IOS/Android。IE(微软)是不支持WebRtc。新的IE也是使用谷歌的内核。

刚开始学习，一定不要编译WebRtc的源码，为什么呢？

(1)因为，首先国内的网是没办法访问WebRtc的官网。

(2)然后，需要翻墙，翻墙后能够访问，但是也未必能够下载下来。可以在国外的服务器编译完，再把编译后的文件，拷贝回大陆的服务器。这个过程是非常麻烦。

(3)最后，推荐一个声网的镜像，但是这个也很慢，我试过，下载了好多天，都没有下载完全，中间还要搭建各种网络环境。所以这个过程是非常费时间。

如果不需要修改源码，网上，有直接编译好的库，就可以用。

WebRtc技术细节

分辨率的限制

码率限制

多个人通话

网上搜的文章，很多都是描述的不够细致。健壮性也不是很好。涉及的知识点也很多。

2.单人通话模型

P2P就是表示A端和B端在传输数据的时候就是点对点。A端和B端直通成功就表示p2p成功。如果不成功就需要通过turn去转发。P2P成功，可以节省服务器带宽。turn和信令服务器是需要自己搭建。

3.多人通话模型

3.1 Mesh 模型

对于N方通话来说，任意一个终端来说，如这里的A端要发送的数据的路数是N-1。对于Mesh模型来说，无论P2P是否成功，都需要发送N-1路数的数据。如果7人通话来说，对于任意客户端来说上行6路码流，这里的带宽压力就非常大。不支持转发N-1路数据，只是简单的中继转发数据。转发N-1路数据就是由SFU模型去做。Mesh模型的开发相对简单，前面WebRTC实战中，我们就使用的这种模型。

适合场景:

Mesh方案无法适应多人通话(为了节省客户端的上行带宽，期望P2P成功，P2P成功率也不是百分百成功的)，也无法实现服务端的各种视频处理需求，如录制(没办法在服务器上录制)，一般只只适合三方以下通话的需求。据说，有些公司可以支持到6人通话。

3.2 SFU模型

SFU的服务器，也是需要自己搭建。当N方通话时，对于任意终端来说，终端A的数据只需要发送一次。这种就类似于发布-订阅模式。对于C来说，如果需要听到A和B端的数据，需要订阅A和B的数据。这种方式对于客户端来说，上行带宽压力就没那么大。同样上面的例子，如果使用7路，那上行的带宽就只有1路，客户端压力就会小很多。市面上，大部分是选择SFU这种模型。SFU开发难度较大。

注意:微信的通话质量还是会显得一般，如果和声网的对比，就会发现，差距还是挺大。

适合场景:

SFU相比MCU，服务器的压力更小，适合纯转发，无转码合流，灵活性更好，可以选择开关任意一路数据的上下行等。SFU也是比较主流方案，常见的开源SFU服务器有Licode，janus，jitsi，mediasoup，Medooze等，各有特点，可以去官网了解。

3.3 MCU模型

MCU模型又被称为混合模型，是另外的种策略。该模型的特点就是将各路客户端上行的视频流合称为一路，再转发给其它客户端。这种模型相比SFU转发N-1路数据来说，降低了下行带宽的压力。但是由于合流要转码操作(服务器需要做解码再编码)，对服务器的压力较大，而且下发给客户端的流是固定的合流画面，灵活性不是特别好。这种模型对于客户端来说，是非常友好的。SFU是独立的去拉取A\B\C的流，而MCU是拉取的ABC混合数据。特别是对于路数越多，MCU方案对于服务器的压力就越大。MCU开发难度较大。

适合场景:

适合服务器性能好，混流，音视频通话路数较小的方案。一般可以根据情况去选择SFU+MCU的混合方案，灵活应对不同的场景的应用需要。

声网目前是最高支持到17路。如下图所示:

这里会配合业务系统去做，业务系统主要还是去控制作用。

一般情况下学生客户端的视频是关掉，只开音频。学生要举手，老师确认了，才允许学生客户端开启视频，最后去推流。业务系统再通知其它客户端和老师端去拉流。

注意:这里说的17路，一般也不是每个客户端都要拉16路流，这种可能性也很小。

qq基本是p2p通话，需要提高打洞成功率，非常有难度。开源方案coturn小于qq的打洞方案，难度很大。

4.WebRtc多人会议系统框架

不管是用什么方案，信令服务器都是要做二次开发。

5.WebRtc应用领域

6.基于WebRtc开源方案比较

关于janus、licode、jitsi、AppRtc、kurento方案比较，根据不同的使用场景去使用，如下:

janus支持的比较好，可以直接应用在自己的商用方案中，使用C语言开发。licode使用c++开发，开发难度较大。jitsi使用的比较少，不是音视频流媒体主流方案。AppRTC是谷歌开源，提供了一整套方案，可以使用js端的思想，可以借鉴js的代码，使用的是Mesh模型，不太建议3人以上的群聊。即构科技，融云，就有使用kurento方案。如下图所示:

上图中表面，服务器的录制功能是很关键。即构科技，融云的音视频通话都是双向收费，当多路时，就是只要参与通话就收钱。视频录制，也是收费。当大规模的使用，难度就很大。如果给政府部门做项目，需要搭建私有的服务，肯定不会采用声网等公司的方案，因为这个私密性不太可靠。特别是小团队或团队经验不够，专业性不够，要想全国用户都使用，用户量大的时候，就会暴露出很多的问题。

7.国内音视频通话方案公司

声网目前是做的比较好了。特别是如果有海外业务的需求，如印度到中国的，声网效果是最好，腾讯的方案，都没办法比及。阿里云的直播业务，如RTMP的业务还是很多。

声网的js代码做了打包，没办法看到实际的源码。

8.WebRtc开发之SFU级联

如果不做SFU级联，所有的人都需要加到这个级联当中去，特别是跨国的通话，对于服务器的选址，难度也是非常大。在下图中，A要发送数据到SFU1，SFU1再发送数据到SFU2，而且服务器直接的传输更加通畅。这里的SFU2充当了一个订阅的模式，那C和D是直接去拉取一个SFU2的备份的A的码流。所以SFU的选址也是很关键。

9.AppRtc基本原理

AppRtc官方demo测试地址:

(1)浏览器以HTTPS方式访问Web服务器加载页面，并申请要加入的房间。

(2)Offer向信令服务器申请加入xxx房间，如果房间号已经存在则直接加入，如果不存在则创建。

(3)Answer向信令服务器申请加入xxx房间，如果房间号已经存在则直接加入并通知其它同个房间的加入者。

(4)offer和Answer以SDP格式通过信令服务器交换媒体信息。SDP包括包括音视频的格式等。

(5)offer和Answer都向STUN/TURN/ICE服务器申请打洞穿透，如果成功则offer和Answer进行直连通性，否则需要通过TURN中继服务器进行，否则需要通过TURN中继服务进行。

(6)以上步骤正常的情况下则offer和Answer进行音视频通话。

其中信令服务器的代码路径在apprtc/src/collider，web服务器是在apprtc/src/web_app/js，turn服务器使用的是开源的coturn方案。最具参考价值的就是web服务器js的代码，信令服务器也可以参考。

注意:这个APPRtc一般是针对一对一通话。AppRtc这个框架会涉及到google_appengine、python、nodejs。其中信令服务器还涉及到go语言。

web端是一定要使用https才有权限才能打开摄像头和麦克风，所以就有后面的使用Nginx做代理。如下图所示:

(1)大部分浏览器只有在HTTPS协议才能打开摄像头，因此web服务器需要提供HTTPS访问，但APPRtc的Web服务端是基于HTTP协议，这就直接冲突了，所以需要使用Nginx做Https的代理，再去当问AppRtc的Web服务端。