让用户意图进入 RTC 策略：一次 Pin 画面丢失的需求复盘

在视频会议中，Pin 可以把某个画面固定为观看对象，让用户持续关注它。其他画面可能随着发言者、摄像头状态等变化而更新，被 Pin 的对象则保持固定，视频内容仍然正常播放。

我们曾遇到一个与这项操作相冲突的问题：用户 Pin 了一个 SIP 终端的画面，却在弱网下看不到视频。界面保留了用户的选择，媒体层却可能停止下发他最想看的内容。

我分析梳理问题成因，并在 PRD 中比较了几种可能的解决路径。这个案例让我更关注 RTC 产品中的一层关系：用户已经明确表达的观看意图，需要进入底层的资源分配策略。

默认策略遗漏了什么信息

问题发生在一个会议终端的缩略图视图中。用户将 SIP 画面 Pin 为大图，但当下行带宽预估下降时，服务端开始按照默认规则分配有限带宽，停止部分视频的下发。这路 SIP 视频恰好被选中，因此用户暂时看不到画面。

当时默认规则会结合内容类型、订阅分辨率，以及视频是否支持大小流等信息判断优先级。在这个案例中，SIP 接入提供的是转码合成后的单路视频，没有大小流，被归入了较低的优先级类别。

这些媒体属性能够帮助系统做自动决策，但它们没有完整表达用户当前的观看需求。用户把画面放大并固定，已经明确表示“我想持续看它”；这项信息没有充分进入带宽分配，导致界面操作与媒体处理出现了偏差。

因此，分析这个问题时，需要同时看两条链路：界面是否固定了正确对象，以及网络受限后，该对象的视频怎样被保留或降级。前一条链路正常，并不意味着整个观看过程已经满足用户预期。

最初的问题以 SIP 为入口，但在需求分析中，我进一步指出：其他没有配置大小流的视频，也可能出现类似现象。

这让需求的范围变得更清楚。真正需要表达的是“当前指定内容更重要”，这项能力应该适用于业务想优先保留的观看对象。

这个区别影响了后续方案的方向。如果只围绕 SIP 的媒体格式处理，其他具有相似约束的流仍可能遇到同样的问题。把观看优先级表达出来，才能让资源分配更直接地响应业务需要。

这也是我在这次需求分析中最想沉淀的做法：从异常对象出发，继续追问它暴露了什么信息缺口。一个具体案例，可以帮助我们发现系统还缺少哪一种业务表达能力。

在 PRD 中，我梳理了几种可能的解决路径及其利弊。

第一种是修改服务端的默认排序，主要按分辨率判断优先级，去掉是否支持大小流的条件。但调整已有带宽分配逻辑，也需要评估对其他场景的影响。

第二种是增加专门的信令，把当前 Pin 状态从订阅端传递给媒体服务器。这条路径能够补充业务信息，它传递的对象是一个具体的界面操作。

第三种是在 SIP 转码环节提供大小流，让这类视频也具备更多媒体规格。它涉及额外的转码工作，同时需要区分两个问题：视频是否有可调整的规格，以及用户当前更想看哪个对象。

比较这些路径时，我更关注它们各自改变了什么：默认排序、业务信息传递，还是媒体本身的可调整能力。把作用层次分清，才能判断哪个能力直接回应当前需求，哪些问题还需要分别解决。

方案最终收敛到向业务开放设置订阅优先级的能力，再由媒体服务器在带宽分配时考虑这项信息。

业务侧理解 Pin 的含义，可以据此提高指定观看对象的优先级；RTC 侧结合业务指定的优先级和原有媒体规则，决定资源受限时的取舍。技术设计中，业务指定的优先级具有更高权重，默认规则仍然参与同一业务等级内的排序。

这样，业务可以告诉 RTC 哪个对象更重要，RTC 继续负责怎样分配和调整媒体资源。Pin 成为这项能力的一个使用入口，其他指定观看需求也有了表达优先级的方式。

从产品边界看，这种分工有明确的价值：业务不必向用户暴露底层带宽参数，RTC 也获得了仅靠分辨率和媒体属性难以推断的信息。用户的一次操作，可以通过业务规则转化为资源分配的依据。

评审中还有一个很具体的边界：接口当时按远端用户设置优先级，而业务界面按视频流显示画面。

一个用户可能同时发送摄像头视频和共享屏幕。对用户设置一个优先级，会让这两路内容获得相同的业务优先级；但用户关注的可能只是其中一个画面。

这个粒度差异在评审中被提出。当前方案先沿用已有的用户级接口，更细的视频流级区分被列入后续优化讨论。

这让我更重视接口参数背后的业务对象。设计“设置优先级”时，还需要说清楚优先的是一个人、一条流，还是某个内容类型；它与用户实际操作的对象是否一致。作用对象的差异，会直接影响业务能否准确表达需求。

提高优先级，可以改变资源分配的顺序，但可用带宽仍然有限。当带宽能够支持重点画面时，策略可以更晚牺牲它；当带宽连该画面本身的传输需要都难以满足时，仍然要面对卡顿或无法持续下发的问题。

当时的测试方案也区分了正常网络、可以优先支撑 SIP 视频的受限网络，以及更严重的带宽不足。优先级需要在这些条件下验证，才能理解它能够改善什么，以及资源不足时还会发生什么。

回看这次需求，产品设计需要同时说明优先顺序和能力边界。让用户指定重要内容之后，还要让业务理解这种指定怎样影响策略，以及无法满足时的行为。

系统可以用媒体属性建立默认策略，真实业务还需要一个表达用户明确意图的通道。

分析异常时，要先核对用户已经做出了什么选择，再沿着界面、SDK 与服务端的链路，检查这项选择有没有被传递，以及是否真正影响了后续决策。

提出能力时，进一步看它能否回应一类需求，作用对象是否与业务语义一致，以及资源不足时的边界是否清楚。这样，一个 Pin 画面丢失的问题，就能推动我们补齐更通用的优先级控制能力。

RTC 的自动策略与业务控制需要共同构成完整体验。默认规则提供基础行为，业务输入补充当前场景中更重要的信息，两者一起决定用户最终看到什么。