共计 4075 个字符，预计需要花费 11 分钟才能阅读完成。
（点击报名）
在古代生存中，音视频通话是咱们最常应用的沟通形式之一。比方，社交中的一对一音视频，医疗中的近程问诊征询，房产交易中的线上看房，以及近程工作场景下随时随地可能产生的一对一和群组音视频沟通。* 本文转自公众号【融云寰球互联网通信云】，回复 抽奖 获福利。
而咱们在应用中也多少感触过产品逻辑的“卡壳”，比方音视频无奈自在切换、1V1 不能降级群聊、退出群视频无奈随时退出等等。
6 月 16 日，融云 RTC · 进阶实战高手 课聚焦音视频通话，从音视频通话实现、多场景体验痛点和融云 New CallLib 的最佳实际等方面，拆解音视频通话在多种应用场景下面临的体验挑战，分享优化计划。后盾回复【通话】获取残缺课件
音视频通话实现
咱们通常说的音视频通话，指相似微信等必须含有呼叫流程的利用场景。有一个主叫和一个或多个被叫，主叫发动通话，被叫能够抉择接听或者挂断。
音视频通话的应用场景十分多，特地是当咱们正在经验一场大型数字化转型时。
比方，近程问诊，医生能够通过音视频通话对患者进行沟通从而不便诊断；VR 看房，房产中介通过音视频通话和租客进行沟通，联合 VR 实现近程看房；线上相亲，红娘能够通过群聊让相亲对象交换，这是一个群组的音视频通话应用场景。
（音视频通话应用场景）
音视频通话呈现在咱们线上生存的方方面面，也是各类利用的必要能力。那么，如何实现一个音视频通话呢？
从须要把握的基本知识方面来看，大体分三个局部，音视频、网络传输和服务器。这是一个非常复杂的零碎，这里只做大略形容。
（RTC 基本知识）
音视频
音视频的基础知识：音视频的采集，不同的平台采集办法有所不同。开发者须要把握元数据的基本知识，也就是咱们通过采集间接失去的数据格式。
音视频数据的解决：要把握音频降噪、音频的回音打消、图像的裁剪等。
音视频的编解码：至多要把握一种音频编码和一种视频编码。
编码格局有对应的解码器，比拟通用的编码格局还能够应用硬件解码，可依据解决方案的不同抉择软解还是硬解。软解的兼容性高，但会损耗 CPU 性能，硬解性能好，但可能面对一些兼容性问题。
音视频的播放和渲染 也是必须把握的，通常播放和渲染指的是对元数据的播放和渲染，音频其实就是 PCM 的播放，视频如果是客户端会用到 OpenGL，浏览器须要用到 WebGL 等。
网络传输
客户端能够抉择 TCP 或 UDP，通常音视频应用 UDP 传输，这是因为音视频数据要求的是实时性，而不是完整性，音视频的数据即便不残缺也能够失常播放。
TCP 和 QUIC 都是 可靠性传输协定，相似业务信令数据等要求完整性的更多应用 TCP 或者 QUIC。
QUIC 协定是建设在 UDP 协定上的一种保障完整性的协定。UDP 自身是不牢靠协定，如果要保障完整性就须要本人做丢包重传策略，而 QUIC 是具备丢包重传策略的一套数据协定，能够达到与 TCP 同样的成果。
服务器
通常分为 信令服务器和音视频服务器。顾名思义，信令服务器负责传输业务相干数据，音视频服务器负责传输音视频数据。不同的技术计划对应实现服务器的技术也会有所不同。利用以上基本知识，咱们能够实现音视频通话场景的外围逻辑了。在思考和呼叫场景强相干的业务解决之前，要先解决以下两个问题。
首先是 业务数据的即时传输。要发动一个通话，要有主叫端、被叫端两个客户端。被叫端如何收到主叫端发送的发动信令？能够应用 Push+ 长链接的模式，或者第三方提供的 IM SDK 来实现。
接下来是更要害的 音视频根底能力 ，以及 音视频数据的实时传输能力。
开发者如若自研，能够抉择 WebRTC，这是 Google 提供的一套具备音视频根底能力及传输能力的残缺开源计划；或者能够从头自研一套残缺的 RTC 零碎。当然，不论是抉择哪种自研计划，都有非常复杂的底层常识须要学习，须要有相当的研发能力和人员配备。
融云为开发者提供了另一个更加便捷的实现计划，融云 CallLib。
针对音视频呼叫场景，融云将 IM 和 RTC 能力交融封装，提供了蕴含残缺呼叫流程的 SDK。开发者只须要关怀 CallLib 提供的大量接口，即可实现呼叫需要，同时具备以下劣势。
完整性，呼叫流程残缺，反对单人、多人呼叫，开发者不须要关怀底层实现原理。
易用性，开箱即用，疾速实现，灵便定制。
稳定性，IM 音讯 100% 牢靠达到，RTC 音频抗丢包 80%，视频抗丢包 60%。
场景的多样性，扩展性强，能够满足多畛域对音视频呼叫的需要。
基于融云 CallLib，开发者能够疾速实现具备呼叫性能的 App，而针对开篇咱们说到的应用场景卡壳状况，咱们还对产品进行了针对性降级优化。
多场景通话体验优化需要
呼叫的降级
音视频的升降级：用户在打音频通话时能够间接切换为视频通话。
1V1 降级为群聊：从 1V1 单聊间接变为多人探讨群聊。
随时退出未完结的通话：当群组通话时，若用户当下未立刻接入，只有通话还没有完结，就能够抉择退出。
流控制的降级
自在的音视频流公布 API；多个通话实现预览；抉择接听以及呼叫期待。
次要优化流控制的 API，让开发者便捷应用的同时能够依据本人的需要开发出一些高阶性能。
数据一致性的降级
包含通话计时的一致性、参与者状态同步一致性以及极其场景下，操作业务逻辑的一致性。
数据一致性的降级次要是为了给所有参加音视频通话的用户，特地是通过不同端接入通话的用户带来更加统一的体验，也不便前期的业务扩大。
那么，如何实现这些优化和降级呢？
融云 CallLib 基于 IMLib 和 RTCLib 实现，是一个重客户端的设计。
所有的状态和业务逻辑须要存储在客户端，减少了客户端的实现复杂度，业务逻辑要在每个端进行反复实现，也会导致极其状况下状态不统一。
比方主叫和被叫同时点击挂断。主叫挂断叫 勾销 ，被叫挂断叫 回绝，体现在通话记录上是不同的。而如果主叫和被叫同时挂断，因为这个操作都是从客户端收回和解决的，无奈分辨到底是谁先做的操作，导致通话记录不精确。
这个问题其实是能够解决的，但会很简单，因为重客户端的设计很难实现性能的扩大。
融云 New CallLib 实际
融云 New CallLib 能够优雅地解决上述问题。
降级业务解决能力：重服务端，轻客户端的设计。
原有的 CallLib 负责保护的状态，改为在服务端保护和保留；CallLib 转变为了由 Server 驱动的状态机模型；
大大简化了客户端的实现复杂度，并能够防止多端逻辑实现不统一的问题。
因为状态变更都是由服务端收回，也就保障了状态的一致性，在解决极其场景和在线离线状态方面也熟能生巧。比方下面说到的两端同时做出挂断操作，肯定有一个操作先达到服务器，而后服务器进行状态的下发，更加有序。通话记录的生成也是由服务器实现，就不会造成两端状态不统一的状况。
上面联合具体场景看一下，新的设计如何做到体验再降级。
1V1 音视频通话呼叫流程
这是咱们最根本的通话性能，右侧是这个根底能力的残缺时序图，由 4 个角色共同完成，Client A、Client B 别离代表主叫端和被叫端，Call Server 解决呼叫相干的业务逻辑，RTC Server 解决音视频的通话。
从图中能够看出，这个根底能力的流程实现起来其实非常复杂。
音视频的升降级
置信很多人有过这样的体验，当你在一个语音通话过程中因为一些起因须要开启摄像头，要先挂断音频通话从新发动视频。
融云对这样的场景做了优化实现，让这个场景下用户应用更加便捷，当我须要长期将音频通话降级为视频通话时能够在通话内发动一次降级申请。被发动端能够抉择承受或回绝，如果接管了就降级为视频通话，回绝就持续音频通话。当然发动端也能够抉择勾销降级。
这个场景下，也可能呈现一些极其操作，比方发动端的勾销操作和被发动端的承受同时点击，这时 CallServer 会起到一个决策的作用，比方咱们以勾销为准，只有操作了勾销，即便被发动端点击承受仍然会让两端都降级为音频通话。而在此前的重客户端设计中，这个判断会变得非常复杂。
通话中复电
在咱们常见的音视频通话场景中，如果被呼叫用户正在进行语音或视频通话，通常会显示对方忙碌，需期待他挂断。
类比电话场景，通话中的咱们可能会收到第三个人的复电，此时运营商电话有抉择接听和呼叫期待的性能，也就是说咱们同时能够解决两个电话。针对这个场景，融云的 CallServer 存储了每个电话的状态，所以即便曾经在通话中了仍然具备解决其余通话的能力。
群聊呼叫流程
群聊和单聊的区别在于两点，一是参与者可能为两人或以上，二是只有通话中还有一个人，通话就未完结。
所以群聊通话只有发动，发起人就第一工夫进入了 RTC 房间，期待其他人退出。另一个比拟非凡点在于，过程中能够随时邀请别人退出房间，流程和发动十分相似。
在咱们罕用的通信软件中，群聊只能产生在某个群组里，而融云服务能够反对随时随地从不同的群组或者私人通讯录中做发动和邀请的操作。
1V1 降级群聊
这个场景产生在两人正在通话的过程中，有可能长期发现这个沟通须要其他人参加，融云反对将一个 1V1 通话间接降级为一个群通话。
降级的过程和群通话过程中邀请别人的过程相似，不同的是在降级为群聊的时候，Call Server 会明确通知 1V1 的参加单方以后通话曾经变为一个群通话了。降级胜利后的后续流程和群聊是一样的。
未完结通话的随时退出
这也是一个常见状况——收到群通话时不不便接听，或接听一段时间后长期有事须要来到一下。群通话只有有一人在就不会完结，所以临时未参加群聊的用户，能够抉择在完结前的任意工夫再次退出通话。
这是一个特地实用的优化，尤其是在咱们当初越来越多的 线上办公和沟通 的场景中，长期有事要来到，前面又须要退出沟通持续之前的探讨。这也得益于 Call Server 对通话状态的保留，让客户端能够随时获取未退出通话的状态。
通话记录实现
此前，咱们的通话记录存储在本地，想要做到多端同步其实很艰难。
当初能够做到通话记录的更新删除，甚至通话记录的未读计数都能够多端同步，给使用者带来更加正当和对立的体验。体验优化是一个长期话题，而音视频通话属于既非常罕用又极其简单的性能。融云基于多年通信行业深厚技术积攒，将继续优化体验到细枝末节，毁灭应用中的“卡壳”，为开发者提供更便捷和符合用户应用习惯的解决方案。