远程会议是双向对称负载：上行推流与下行拉流同时存在。很多分流方案只关注下行，结果就是本端听得清对方、对方却听不清本端。这个类别必须为上行单独保留路径份额。
视频会议同时存在两股流量：本地摄像头与麦克风采集的数据被编码后上行推到会议服务端，其他参会者的音视频被下行拉取到本地。上行与下行的数据量通常接近，但两者的失败表现完全不同。
下行劣化表现为自己看到的画面模糊或声音断续，用户能立即察觉并主动处理。上行劣化表现为对方听不清或看不到自己，而本端界面完全正常，用户往往意识不到问题所在，直到被对方提醒。这种不可自察的特性让上行成为更需要主动保障的一侧。
办公协作类应用通常同时承载三类流量：音视频实时通道（UDP 为主）、文件同步通道（TCP 长连接）、消息与状态通道（小包频繁）。三者对网络的要求差异很大：音视频要低时延低丢包，文件同步要高吞吐，消息通道要稳定不要断连。
如果按进程整体归入同一类别，会出现文件同步的大流量挤占音视频通道的情况。合理的做法是在应用分类之下再做通道级区分，至少把大文件传输与实时音视频分开。
| 指标 | 权重取向 | 原因 |
|---|---|---|
| 上行时延 | 最高 | 直接影响对方收听质量 |
| 丢包 | 高 | 音视频丢包直接造成断续 |
| 抖动 | 中 | 抖动缓冲可吸收部分波动 |
| 吞吐 | 中 | 文件同步需要，但不应挤占实时通道 |
对方反馈听不清但自己一切正常：典型的单向上行劣化，检查上行是否被下行大流量挤占。会议中共享屏幕卡顿：共享内容是上行负载，与摄像头叠加会显著提高上行需求，建议关闭摄像头或降低共享画质。文件同步时会议质量下降：把文件同步通道限速，或将其归入非实时类别。会议开始时正常、后段变差：多与后台同步任务启动有关，检查任务调度时段。