一、背景

近些年，直播连麦这把火在流媒体领域整整燃烧了 6 年。从刚开始的简单探索，到现在的成熟全链路方案，不得不说日益增长的激烈竞争，已将让原本的蓝海领域变成了深海互搏。在这样的大环境下，是否意味着小厂将再也没有机会追逐流媒体行业风口，以小搏大呢？答案当然不是，感谢多年来的市场驱动带来的技术思想碰撞，由此诞生了一批专精通讯的技术供应商。使得任何组织都可通过合理的对端方案设计，实现流媒体赋能。而声网作为这样的合作伙伴，则是其中的佼佼者。

这就是这篇文章将要谈到的内容：基于声网的对端连麦方案。

二、宏观流程

在我们正式开始前，首先需要做的就是根据连麦的参与者，和连麦的阶段，进行阶段角色划分。从整体流程上看，对于任意连麦的两端来说，自己都是主播端，而另一方都是连麦端。因此，唯一的区别不在于身份上，而在于谁先发起了连麦的请求。这会决定整个连麦从发起到接通的完整链路流，是一个怎样的过程。

所以，我们就有了基本的框架需求：

1.从被连麦端开始，构建建立房间、开始连麦、连麦中、结束连麦的完整链路

2.业务层处理流程，刨除底层复杂技术实现的快速集成方案

3.高接通率健壮性，从实现角度保证请求的及时准确

根据这三则核心诉求，我们提供如下的连麦解决方案。

图2-1 宏观流程说明

接下来，我们就来分别拆分来看一下。

三、阶段拆解

主播启播阶段

对于主播启播阶段的处理，主要是通过当前主播服务侧的特征数据，来决定该主播是否能够开启连麦直播间。为什么会就直播间是否是连麦直播间而进行区分呢？主要还是涉及到连麦直播间全链路对于各环节要求会更多一些。在这里做区分一方面对于主播来说操作代价并不大，另一方面也可以减少服务端对于此类直播间的记录，并利于维持更合适的预准备策略资源池大小。

主播在请求启播时，向服务器发出的启播地址请求，会被服务器根据启播策略筛选开启直播间类型。服务器会根据判断结果，选择是否开启具有连麦扩展能力的直播间并返回其推流地址到主播端。主播就可以以此地址进行开播推流了。

图3-1 启播阶段关键环节示意图

连麦发起阶段

在主播开启直播间后，所有满足连麦要求的对端，都可以向主播发起连麦请求。连麦请求的一方有可能存在竞争。因此对于先发起请求的连麦方，在其或者主播并未因为客观原因明确否定本次连麦活动前。我们应该通过绑定主播和连麦端的方式，来避免旁路干扰。

当然呢，在确立连麦关系前，我们需要对连麦方的资格进行校验。目的是为了保证，当次连麦活动的实际有效性。否则我们对于不满足资质的连麦方分配了连麦关系，就会等于变相的抢占了对单一直播间来说本就稀少的连麦权限。这将会带来不少的安全和管理风险。同时为了避免发起连麦端，在发起之后相当短的时间内反悔连麦操作。我们需要预留出来部分时间用来提供一个“返回窗口期”，这部分的时间策略具体阈值界定，就需要产品根据用户特征来进行数据分析决定了。

一旦连麦关系确定，那么对于连麦端来说，就需要进入“连麦等待”状态了。此时主播则会接收到连麦请求。根据主播决定同意/拒绝，来决定是否需要建立连麦直播间。

如果主播选择拒绝，则当前连麦绑定关系被释放，发起连麦方会收到单推并获之失败原因，其他用户也可以从新竞争连麦。

如果主播同意，则在预准备策略中进行预处理的资源会被直接分配给当前确立的连麦活动。并就此将原有直播间提升为连麦直播间。服务端会开启推流地址的动态切换策略，并将关联信息返回给推流双端，以完成声网链接初始化。

【学习地址】：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击1079654574加群领取哦~

图3-2 发起阶段关键环节示意图

整个连麦发起阶段对于用户来说，基本是无缝衔接的。这主要通过混合推流来实现这样的操作。在主播连麦前，主播端相当于直接将本地流推送到推流服务器，由推流服务器进行后续的包括转码分发等操作。而当连麦建立后，双端推流首先通过声网服务器进行了流混合。之后通过我们传递的主播端推流地址，将混合后的流转发给我们自身的推流服务器。这也就相当于，用声网完成处理后的流替换了我们原始主播的直推流，服务端只需要就此完成部分时间戳校验同步服务，减小了切流带来的卡顿影响。

连麦过程阶段

当主播和连麦方完整建立连接后，就进入了连麦过程阶段。这一阶段就心跳维持和推拉流来说，为了保证稳定链接和一定的交互扩展性，应该在声网自身 IM 消息判断外，额外维持一套独立的心跳请求。通过心跳请求，将双端时间戳发由服务端进行连麦实际时长同步。同时，也利于服务端根据具体情况，就一些关键数据与双端进行协同。另一方面，如果不采用强绑定机制，即推流 CDN 等相关流推送部分为非声网的第三方供应商时，我们也需要通过心跳请求来得到并判断当前网络状态。当然，除了心跳请求这种方式外，还存在诸如控制流消息定制等其他方式可以实现相同的效果。这种方式保活相对快捷方便消耗较小，不需要维持长链接，不过需要小心请求的安全处理。

图3-3 连麦过程关键环节示意图

连麦中，双端经常有一些交互活动。对于类似于打赏的操作，建议通过直播间消息管线来实现。这样的话可以不需要再独立维护一套自建 IM 用于双路双端的消息传递，而可以直接利用直播间现有消息管线实现双端通讯。如此不论直播间如何切换，消息管线都是持续存在且不用重启，保证了主播和观众的体验。其实，如果没有一些特殊的定制化操作，连麦端的消息处理和其余观众是一样的，即消息逻辑一致。

连麦断开阶段

那么什么时候连麦结束呢？这个实际上是有多种情况的。最常见的就是主播或者连麦端的主动断开，除此之外还有网络波动断开、服务端策略断开等情况。从大体上讲可以分成两类，即主动断连和被动断连。

主动断连，指的是由参与连麦的双端中的一端或者多端，单方面或者达成一致的短线操作。

被动断连，指的是由于外部干扰或者服务端策略影响，导致的连线终止。

对于被动断连（如：断连、费用不足、持续掉线等），我们最好在问题发生前，有足够的策略能够进行容错处理。其目的是为了保证，在断开后直播间还能够恢复正常，而不至于因此产生健壮性问题。

图3-4 连麦断开关键环节示意图

连麦中我们使用声网来作为了真正的推流端，声网混流服务器将混合好的数据推送到我们自建/第三方推流服务器上，并以此分发到 CDN。当一端退出时，退出的消息会随着视频流（声网将对应的状态消息封装到了数据流中的关键字段上，以保证链接方画面与接收操作的端上一致性）推送到对端。对端接收到消息后，也需要向当前占用的声网直播间发送退出房间消息，才能使连麦房间真正变成双端无关的房间（有时存在审核需求，连麦房间内可能存在除连麦双方外的多个用户，这些用户都属于在服务端的审核机器人或着人工账号），进而才能由服务端释放房间资源归还到资源池，或者重新分配给新场景。

当连麦结束后，主播端情况选择是否请求服务端直播间地址更新（个人建议执行，让服务端选择是否更新），在取得后切换当前端推流地址为取得的地址。连麦方则关闭推流模块，重启拉流模块并重新进入被连麦的主播直播间。

就此，连麦流程完毕。