让更多人随时发言：从千方会议到 Webinar

一场千人会议，听众被点名后，希望打开麦克风就能回答。这个动作在小会议里很普通，放到千人规模，却曾经需要主持人先把他调整到有限的互动席位里。

早期 RTC，也就是实时音视频系统，主要服务于小规模互动。即使一个房间可以容纳很多听众，能够发布声音、参与互动的人数也可能很有限。对客户来说，“能进来一千人”和“一千人都有机会直接开麦”，是两种不同的会议体验。

我们当时要解决的，就是后者。千方会议让千人规模的参会者拥有自由开关麦的能力，减少主持人围绕互动名额反复调度的负担。这项能力在当时具有明显的行业创新性，2022 年已对外发布单房间超千人上麦实时互动能力。当时的公开发布记录

之后，这项能力继续沿着两个方向演进：一方面，把大会模式收敛为更通用的音频选路，并补充发言优先级；另一方面，支撑少数嘉宾互动、更多观众收听的 Webinar。贯穿其中的判断，是把参与者的发言机会，与系统需要持续承担的媒体分发负担分开设计。

千人可以开麦，不等于每个人都要接收千路声音

如果沿用小会议的处理方式，每增加一个发言者，系统就要把他的声音转给其他参会者。人数扩大后，服务器之间需要维护更多转发关系，接收端也要承担更多网络传输和声音处理。即使参会者的大部分时间都没有说话，围绕这些声音建立和维护的关系仍会带来压力。

但真实会议里的信息需求并不是这样分布的。千人参加，不意味着千人会持续同时说话；听众通常需要听清当前正在发言的少数人。把每个人的声音始终转给所有人，并没有与之相称的体验价值。

音频选路就是据此作出的改变：服务器从房间内的音频中，动态选择少量活跃的声音向下分发。发言者变化，选中的声音也随之变化。这样，一千个人可以保有开麦参与的机会，而每个接收者不必持续接收和处理一千路声音。

这个选择必须发生在服务端。假如所有声音已经传到接收者设备上，再由设备只播放其中几路，服务器转发和下行带宽的压力仍然存在。产品上希望降低的是整条链路的负担，而不只是让扬声器少播放一些声音。

音频和视频也需要分开考虑。声音承担连续交流，适合根据发言活跃程度动态选择；画面则受会议布局、用户关注对象和设备能力影响，由业务按需要订阅。千人会议并不要求每个人同时看到一千个视频窗口。让不同媒体采用适合自己的分发方式，才能在扩大规模时保住关键体验。

这项能力的前提同样需要讲清：它适合多数人收听、少数人轮流或交叠发言的会议。它并不承诺把所有人同时说话的声音完整地送到每位听众耳中，也不适合直接代替按距离决定能听见谁的空间音频规则。

声音活跃程度之外，还需要表达会议秩序

只按声音的活跃程度选择，能解决规模问题，却不能完整表达一场会议里的重要关系。

例如在线课堂里，老师正在讲课，台下学生的环境声可能比老师更响；互动讨论时，老师和被邀请回答的学生，都应当获得更高的发言保障。主持人、主讲人也有类似需要。系统知道谁的声音更活跃，业务才知道谁在此刻承担重要角色。

因此，选路能力进一步支持由业务设置用户的高优先级，并随着会议进程动态调整。老师、主持人或正在台上互动的人，可以优先参与声音选择。平台提供通用规则，业务将自己的会议角色映射到这些规则上，无需为每一种课堂或会议形态定制一套底层机制。

这里最容易产生的误解，是把“高优先级”理解为“不受限制、一定能被听见”。优先级是在有限资源内安排先后；如果高优先级用户本身也很多，仍然需要在其中继续选择。若把所有人都设为高优先级，这项规则就失去了区分作用。

另一个边界是录制等处理链路。现场听众只接收当前活跃声音，不代表后续处理也只需要这些声音。此类链路可能需要独立订阅指定音频，因此要与普通听众的选路规则分开考虑，同时保留自身的订阅资源上限。

音频选路由此从一种统一的系统优化，逐步变成能够接纳业务意图的能力：既保留规模上的收益，也允许业务表达哪些声音更重要、哪些处理链路有不同需求。

从“大会模式”收敛为清楚的能力

技术突破能够运行，还需要经过产品化，才能让更多客户稳定使用。

早期围绕大规模会议，存在多种模式名称和分散配置。开启能力需要配合多个模块，客户也很难判断切换后哪些行为会变化。一个“大会模式”的名称，容易让人以为房间进入了某种整体状态，所有相关能力都随之提升。

后来我们将概念收敛为“音频选路”，直接说明它改变的对象。这个名称不要求客户先理解内部架构，也能用于会议之外、同样需要多人发言选择的场景。

名称收敛之后，还要把行为和边界一起说清。例如，业务明确取消订阅某个人的声音，应当能够确保不再听到他；重新订阅，则是恢复其被接收的资格，实际能否听到还受选路结果影响。用户的明确操作，需要与系统的自动选择形成一致的规则。

同样，房间可以容纳多少人、多少人能够发布音视频、每个接收者能订阅多少画面，是不同的上限。到达发布上限时，也要区分“还能否进入并收听”和“还能否继续发布”，不能用一个笼统的人数限制覆盖所有行为。

媒体能力与会议管理也有分工。选中的几路声音只代表当前分发结果，不能被当作完整参会名单。成员展示、人数统计、权限和上下麦等会议管理，需要有各自可靠的状态来源。

平台能力的完整性，就体现在这些约定里：客户既知道可以做什么，也知道系统自动决策到哪里，业务还需要负责什么。

Webinar：让观众能够进入实时互动

千方会议解决了大规模参会者的发言机会。Webinar 则进一步区分了人群：一部分嘉宾参与实时互动，更多观众主要收听观看，但在需要时可以转为互动角色。

企业全员会、培训和线上宣讲，都存在这种需求。大部分时间由少数人讲，到了提问或点名环节，观众需要及时回应。如果只是将会议转成延时较高的直播，观看可以扩大，来回对话却容易被等待打断。

我们在千方会议能力基础上，将 Webinar 的第一阶段规模扩展为最多一千名嘉宾和一万名观众，后续又把观众规模提升到两万人。这里的嘉宾数量表示可参与互动的规模，并不意味着每位听众同时接收一千路声音；观众也需要经过相应的业务权限和角色切换，才能进入发言状态。

从观众转为发言者，不能只改变界面上的身份标识。业务决定谁可以上麦，RTC 则需要配合改变其媒体发布能力。角色、权限和实际媒体行为一致，用户才会觉得自己是在同一场会议里自然参与，而不是被搬进另一套流程。

这也解释了 Webinar 的产品价值：保留会议的低延迟互动，同时针对大量观众主要接收内容的特点组织资源。它延续了千方会议的思路，又增加了更明确的人群分工。

万人规模，需要重新定义容量和稳定性

音频选路提供了重要基础，但扩大到万人观众，不能只提高一个房间人数参数。

一场活动开始前，很多人可能在短时间内集中进入。系统需要判断如何将他们分配到不同服务节点：过于分散会增加跨节点转发，过于集中又可能让单个节点承压。进入速度、媒体使用方式和持续在线人数，共同决定实际负载。

对产品而言，不需要把每一种调度算法都变成对外功能，但需要把这些约束带进能力定义与验证：能否承受集中入会，角色切换后能否及时互动，局部故障会影响哪些人，恢复过程是否打断活动。

成本也必须一起评估。万人长时间收听，会持续消耗分发资源；即使技术上能够容纳，如果每场活动的资源成本过高，能力也难以持续提供。容量、实时性、稳定性和成本，需要放在同一个产品判断中。

从千方会议到音频选路，再到 Webinar，产品创新来自对真实参与方式的重新拆解：哪些人需要随时发言，哪些内容需要持续分发，谁的声音应当优先，以及角色何时发生变化。

当参与人数远大于同时活跃人数时，可以通过动态选择和角色分工控制资源负担；当业务对发言秩序有明确要求时，就需要在自动策略中保留表达优先级的入口。每次扩大规模，都应重新检查这些规则的适用条件，并把容量、行为和限制清楚地交付给客户。