对于一个实时互动的音视频系统而言，存在很多技术难点，有几个比较重要的点：
首先是低延迟，如果要满足比较流畅地进行实时互动，那么单向的端到端的迟延大概要在400毫秒以下才能保证流畅沟通;
第二点就是流畅性，你也很难想象在视频过程中频繁卡顿会有良好的互动;
第三点是回声消除，回声的产生是扬声器播放的声音经过环境反射被麦克风重新采集并传输给对方，这样对方就会一直听到自己的回声，整个互动过程会非常难受;
第四点是国内外互通，随着现在国内同质化产品越来越多，国内的竞争也异常激烈，很多厂商纷纷选择出海，这时就需要做好海内外的互通;
第五点是海量并发，当然这不仅仅指实时音视频了，基本对于任何一款互联网产品而言都是必须要考虑的难点。
技术难点解决方案
关于这几个技术难点，在这里跟大家分享一下ZEGO即构科技的解决思路和实践经验。
1、低延迟
首先，如果实时音视频要保证低延迟，那么前端和后端的整个链条一定要做到极致的，比如前端的一些编码算法、流控，甚至丢帧、追帧策略等等都要做到足够好。另外，不同的业务场景下，编码器的选择也会有所区别，从而会带来不同的编码延迟，因此不同的业务场景能达到的延迟程度也是不一样的。
其次，就是对推拉流网络的选择，通常的方案是让需要实时互动的用户通过核心语音视频网络——像BGP这样的优质节点来做语音视频传输，而对于一些特定场景来说，比如互动游戏会直播给一些围观用户看，那么这里就需要做转码、转协议、甚至混流，再通过内容分发网络去分发。像 内容分发网络本身天然就有做就近接入，但对于接入核心语音视频网络就需要有智能的调度策略来完成就近接入，以及跨运营商、跨区域的接入，比如可以采用上次登录IP、常用IP和区域调度，甚至可以测速再去连接，当然网络调度的策略也需要根据业务群的分布仔细规划，甚至采用多个策略配置权重的方式。
2、流畅性
要实现流畅性也会有很多的技术难点和策略，我主要会介绍其中几种。第一个是可以做动态伸缩的JitterBuffer，在网络较差或者网络抖动比较剧烈的情况下，可以适当增大JitterBuffer，从而降低一点点延迟来对抗抖动。
第二个是快播和慢播技术，在网络较差的环境，可以在用户无感知的条件下稍微降低播放速度，来应对短暂网络抖动引起的立即卡顿，当网络恢复可以加快速度追回来，但这种方式并非适合所有场景，比如对于节奏要求非常准确的唱歌场景，当播放速度稍微放慢就可以被感知。
第三个是码率自适应，也就是以比较合适的码率做动态传输，为了保证流畅度甚至可以调整帧率和分辨率。语音视频引擎会根据当前网络测速的结果和应用所期望的码率，动态地调整码率、帧率和分辨率，最终达到流畅观看的用户体验。
第四个是分层编码、传输控制，在推流端做一些分层的编码，这样在拉流端可以动态根据侦测到的网络带宽情况来拉取不同的数据去做渲染。分层编码允许拉流端取选择不同层次的视频编码数据，网络情况好的时候，就拉取较多层次的数据;网络情况差的情况下，就拉取基础层次的数据。
第五个是动态调度，当在推拉流端监测当前推拉流质量比较差，而且即使通过降低码率、帧率和分辨率等策略已经无法保证质量，这时就可以选择放弃这条链路，直接重新做选入、建立连接，当然在这个过程中可能会出现短暂的停顿。
3、回声消除
首先介绍下回声消除的原理：对端发送的信号会先给到回声消除的模块，作为将来消除的参考信号，再把信号给到扬声器播放，扬声器播放后由于周围环境反射形成回声，与真实的音频输入一同被麦克风采集，这时采集到的输入信号是带有回声的，回声消除模块会根据前面的参考信号生成滤波抵消掉回声消后再发送出去。
原理听起来会比较简单，但在实际过程中却蕴藏着很多的难点，比如回声消除模块接收的参考信号与最终被环境反射后的回声本身就是存在差异的，此外设备也会极大的影响回声消除，尤其是国内的安卓机型特别多，比如国内某手机厂商，从麦克风采集音频数据到提交中间有将近一百毫秒的延迟，这时回声消除算法如何适应这么长回声延迟的手机就很关键;再比如很多用户在直播中都会用外置声卡，甚至是模拟器，这无形中也会带来回声的延迟。除了设备，场地同样存在很大的相关性，对于普通会议室，设置 40米的回声延迟可能已经足够了，但一些大会场这种回声延迟能达到将近上百米，这也是一种挑战。
关于回声消除，其实谷歌开源的WebRTC提供了回声消除模块，但WebRTC的设计本身是为了在PC端实时音视频互动的场景，在移动端的适应性上就会差一些，尤其体现在安卓的一些低端机上。而相对来说，苹果因为整体硬件、软件全是自己实现的，麦克风、扬声器也都有声学模型设计，因此回声消除的效果会比安卓好很多。即构科技的音视频引擎都是采用自研，在真机和模拟器等1000多的机型上测试过，都可以做到很好的回声消除。
4、 国内外互通
前面提到很多产品都会选择出海，包括主打国内市场的产品也会有一些海外用户，因此流媒体数据和控制信令就要做好跨国的互通，这就需要考虑在全球合理布置一些中继节点。
这张图就是一个典型的中继续传，北京用户和迪拜用户之间要做视频沟通，根据就近接入原则他们会分别连接当地的节点，而这两个节点间如果互拉，效果会非常差，这时就需要布置适合的中继节点，比如香港、新加坡、日本等等，数据路径的选择是需要根据业务侧决定的，也就是说在物理链路路由之上还要再有一条业务的路由表，需要根据用户场景制定，包括用户分布、用户访问频率、高频段峰值等等，可能每次的路由都会有所不同。
5、海量并发
海量并发是所有互联网产品都会遇到的问题，这里就不再展开，主要要考虑负载均衡，如何平滑扩容，对于无法覆盖的地方要做代理调度，甚至需要考虑容灾、接入层的设计等等。
实时语音视频的技术门槛相对比较高，如果依靠自己研发，可能即使会投入很多开发成本也无法与匹配市场快速发展的节奏。现在实时音视频云服务已经十分成熟，其实不妨“让专业的人去做专业的事”。