引言
音视频通话主要需要解决以下几个问题，怎么找到对方；如何与对方连接以及如何看到（听到）对方。那么音视频会议就是要解决如何管理控制音视频通话。
如何发现对方
信令
视频会议系统经过几十年的发展，信令层面两分天下。传统视频会议设备一般走 H323 协议，互联网一般走 SIP 协议。但是随着互联网的高速发展，目前的会议设备与会议系统都同时支持 H323 与 SIP 协议，其中 H323 一般作为网关用于支持一些专业的视频会议终端，SIP 作为集群部署时服务间的信令通信。其中代表有华为、思科等老牌视频会议方案供应商。至于提供公共视频会议的方案的厂商（如腾讯、阿里），一般采用自有的私有协议，需要第三方厂商或自己去开发以支持 SIP 协议。
库
如何与对面连接
SDP 与 COTURN
音视频在复杂网络环境下的音视频流传输一直是一个问题，此问题一般只有大厂（如：思科、华为等）才能有成熟的解决方案。目前，开源的 WebRTC 通过 SDP 与 COTURN 解决了在复杂网络环境的连接问题。
库
如何看到与听到对方
音视频采集
音视频的采集目前需要根据不同的平台与设备进行单独的音视频流采集，采集后的音视频就可以进行编码，然后通过 WebRTC 重新封装或者 RTP 直接发送给对方
视频编码
视频编解码方面又是风气时！目前的视频会议系统中一般都提供对 H264 的支持，好点的更能支持 H264HP。随着互联网的发展，人们对视频提出更苛刻的要求，因而 H265 应运而生。但是 H265 的授权造成一定的困扰，传统视频会议厂商应该没有太多的选择余地。互联网企业这边提出了满足他们需求的开源的 AV1 视频编码，目前此协议还在发展阶段，有待观察。
至于 Google 的 开源的VP8、VP9等，主要一般用户 Web 端这块儿，在其它地方未曾看到有具体的使用场景。目前 chrome 自己本身也支持 H264 ，在开发中一般直接选择 H264。下图是视频会议厂商维海德的 C9 设备终端的视频编解码能力支持列表：
库
音频编码
音频编解码方面，音视频会议的主流解决方案是 opus 、g711、g722 等编码方案。其中 opus 主要用于带宽较低或网络较差的网络环境，g711 或 g722 用于带宽高且网络环境稳定的网络环境。下图是视频会议厂商维海德的 C9 设备终端的音频编解能力支持列表：
如何控制音视频通话
MCU
MCU（全称：Multipoint Conferencing Unit，多点会议控制单元），采用全变全解的方式。
主要有以下优缺点。
- 优点：
- 技术非常成熟，在硬件视频会议中应用非常广泛。
- 作为音视频网关，通过解码、再编码可以屏蔽不同编解码设备的差异化，满足更多客户的集成需求。
- 将多路视频混合成一路，所有参与人看到的是相同的画面，客户体验非常好。
- 缺点：
- 重新解码、编码、混流，需要大量的运算，对 CPU 资源的消耗很大。
- 重新解码、编码、混流还会带来延迟。
服务器
- FS（全称：FreeSWITCH）: 音视频交换服务，目前比较主流的服务器
SFU
SFU（全称：Selective Forwarding Unit）该方案只管将音视频进行转发，不对音视频进行任何处理。主要有以下优缺点。
- 优点：
- 由于直接转发数据包，不需要编解码，对 CPU 资源消耗小
- 能够适应不同的网络环境
- 缺点：
- 参与人多路视频时可能出现不同步的问题
- 参与人同时观看多路视频，在多路视频窗口显示、渲染等会带来很多麻烦，尤其对多人实时通信进行录制，多路流也会带来很多回放的困难
总结
目前的传统音视频厂商如（华为、思科）一般走 MCU 的控制方式，互联网企业（如：腾讯、阿里）从各种 QQ 与行业认识交流中得知也是走 MCU 的控制方式。本人目前了解到的走 SFU 的国内有两家公司，具体有多少或为什么选择这条技术路线都不可知。目前能够已知的就是走 SFU 无法直接与现有的设备进行互联互通，