[TOC] 转载文章 ## webrtc的概念可以有三个角度去解释： （1）.一个W3C和IETF制定的标准，约定了Web间实时音视频通信机制，通过该标准可开发基于浏览器的、无插件的web多媒体应用（一般是js），该标准仅设定了点对点无中心的实时会话场景，没有强制约束信令协议与内容，没有要求有媒体处理的中心服务器，主要目标是形成开发者与浏览器厂商良好的生态环境，并积极向HTML5靠拢争取被纳入进去； （2）.一群音视频算法和网络适应性算法，这些算法囊括了视频会议几乎所有的核心技术，包括音视频的采集、编解码、网络传输、播放显示、安全等功能，还提供了操作系统系统调用跨平台封装的实现，包含Windows，Linux，Mac，Android，iOS； （3）.一个开源工程，核心由c++实现，可通过修改、封装、提取代码等方式实现一套视频会议系统，客户端可实现为Web js、App或Windows应用程序等多种形式，服务端可实现包括业务外的所有服务，包括媒体服务、信令服务、穿墙服务、中继服务等等，这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。 ## 对webrtc的理解与使用，我认为有三个境界： （1）.能搭建一个简易的视频会议系统，其中客户端部分可以这样做： Windows端Mac端Linux（x86）端在自带的peerconnection client或libjingle改一下（取决于信令是http还是sip家族信令）；Android/iOS端在apprtc或licodeAndroidClient及Licode-ErizoClientIOS改一下；web端用webrtc 自带js api实现一下。服务端部分可以这样做：信令服务器在apprtc的collider改一下；穿墙服务器用自带的stun server，turn server部署一下；中继服务器在自带的relay server改一下；媒体服务器在kurentos、licode、jitsi、Intel Collaboration Suite for WebRTC或janus改一下；如果需要和传统的SIP体系互通则在webrtc2sip改一下；如果需要关注实时通信过程中的延时、丢包、接通率、掉线率等质量问题，可以部署callstats来进行专业监测；把所有服务都再部署于云平台的多个虚拟主机上或阿里云的容器云服务，完成以上操作就搭建起初级规模的云上视频会议系统原型了。 （2）.能提取、理解并使用webrtc的算法模块，即或将算法模块融入到自己的代码中，或将自己的算法添加至webrtc里作为开源贡献或自己产品的差异性优势。值得提取的算法模块包括音视频编解码与处理框架（vp8、vp9、voice engine、video engine），音视频采集呈现封装、音视频预处理（NetEq、NS、AEC、Video Jitter Buffer）、网络适应性（GCC算法、ARQ、FEC）、安全性（Dtls、Srtp/Srtcp）等，自己可添加的有视频编码模块（x265、nvenc、intel qsv、xavs2、以及其他定制化的网络传输策略）。 （3）.能够结合基于rtmp-cdn/p2p等直播技术，构建既支持交互互动，又支持海量围观，可商用、能运营、易扩展、全兼容的音视频PaaS服务平台，完成一个多媒体通信的终极产品。 ## webrtc开源服务器 licode: Licode是达到第一境界技术层面所需要了解的开源工程，它从webrtc代码中提取出了SFU/MCU媒体服务所用到的音视频、媒体传输、信令的功能代码，结合libnice与libav实现了ICE与媒体转发功能，并封装成了可被调用的js API，此外还用js实现了包含全局管理服务、数据库服务、业务逻辑服务与信令媒体的调用服务的业务代码。Licode实现了webrtc开源工程没直接实现的中心侧的媒体服务功能，并提供了简单的业务模型与分布式部署方式，从而得到了多媒体通信工程师的广泛关注。但是Licode的相关文档与资料非常少，故本文是在我个人观察运行调试代码后总结所写的，不正确之处希望在留言中能够得以指正。