1、先分清三类流量:信令、音频、视频不能混在一起
思科到 Teams 的跨域音频通常涉及三类流量:
信令流量:包括 Teams 会议加入、SIP/H.323 呼叫、CVI/WebRTC 互操作控制流。
实时音频流量:语音媒体流,对延迟、抖动和丢包最敏感。
实时视频/共享流量:视频、屏幕共享、内容协作,带宽占用更高,但容忍度略高于音频。
Teams 客户端侧的实时媒体流量需要通过 UDP 3478-3481 访问传输中继,客户端源端口通常使用 50000-50059。如果启用 QoS 标记,Teams 会按媒体类型进一步细分端口范围,音频对应 50000-50019,视频对应 50020-50039,应用/屏幕共享对应 50040-50059。
思科侧则需要关注 Webex 或 CUCM/ExpressWay 设备的媒体端口和 DSCP 行为。Webex 客户端和会议室设备通常使用 UDP 媒体端口,常见范围包括 16384-32767 或设备注册端口;CUCM/VCS 环境中语音媒体通常标记为 DSCP EF(46),视频媒体标记为 DSCP AF41(34),信令标记为 DSCP CS3(24)。
跨域优化的第一条原则是:两端端口和标记必须能被思科网络设备稳定识别,否则 QoS 策略无法生效。
2、Teams 侧 QoS 参数:端口范围要“先固定,再标记”
Teams 默认会使用动态端口,这不利于网络设备做精细分类。如果要实施 QoS,建议在 Teams 管理中心开启“实时媒体流量的服务质量标记”,并指定固定端口范围。
音频必须使用 EF(46),因为它对应加速转发队列,适合对延迟和抖动极度敏感的语音流。视频建议使用 AF41(34),屏幕共享可使用 AF21(18),避免把大量视频和共享流量都塞进严格优先级队列,进而挤压音频。
需要注意,Teams 浏览器客户端通常仍会使用动态端口,QoS 标记效果有限;Windows、Mac 和移动客户端对端口范围和 DSCP 的支持更稳定。
3、思科侧 QoS 参数:音频进 LLQ,视频进保障队列
思科网络设备处理实时音频时,推荐采用 MQC 框架,按“分类—标记—队列—限速—应用”的顺序配置。
关键参数建议:
Teams 音频:匹配源端口 50000-50019 或 DSCP EF(46),进入严格优先级队列 LLQ。
Teams 视频/共享:匹配 50020-50059 或 DSCP AF41/AF21,进入 CBWFQ 保障带宽队列。
Webex/CVSI 音频:匹配设备媒体端口或 DSCP EF(46),同样进入 LLQ。
Webex/CVSI 视频:匹配 DSCP AF41(34) 或 CS4(32),进入保障队列。
信令流量:匹配 TCP 443、UDP 5060/5061 或 DSCP CS3/CS5,放入信令队列,避免抢占媒体队列。
在思科路由器或三层交换机上,典型做法是创建 class-map 匹配音频端口或 DSCP 值,再在 policy-map 中为音频配置 priority,为视频配置 bandwidth。LLQ 总带宽不宜过高,一般建议不超过链路可用带宽的 33%,否则可能影响其他业务。
例如,在专线出口或 WAN 接口上,可以为音频保留稳定低延迟通道,为视频保留足够带宽但不让其抢占音频,为默认流量保留剩余带宽。这样即使会议并发增加,音频也不会被视频或大文件下载挤占。
4、防火墙与出口策略:UDP 3478-3481 必须放行
跨域音频问题中,很大一部分来自防火墙策略过严。Teams 实时媒体依赖 UDP,如果防火墙只放行 TCP 80/443,音频可能回退到 TCP 或长轮询,延迟和抖动都会明显上升。
出口防火墙上至少需要确认:
放行 TCP 80、443,用于 Teams 信令、身份认证、聊天和会议控制。
放行 UDP 3478-3481,用于 Teams 实时媒体传输中继。
放行客户端源端口 50000-50059,尤其是启用 QoS 后。
对 Teams 媒体流量绕过代理服务器;若必须经过代理,需要确认支持 UDP 直通。
对 Webex 流量放行相应域名和 UDP 媒体端口,避免只放行 TCP 443 导致媒体路径异常。
如果企业使用 SBC、CVI 网关或 ExpressWay,还需要确认 SBC 到 Microsoft 媒体中继的端口范围。部分场景下媒体会经过 50000-59999 或 3478-3481,具体取决于传输中继版本。
5、VPN、代理和跨境链路:音频尽量“少封装、少绕行”
跨国或跨域场景中,Teams 和 Webex 音频质量下降常见于三类路径问题:
全流量 VPN:所有流量先回传总部再出公网,增加延迟和抖动。
代理拦截:代理服务器无法正确处理 UDP 媒体流,导致音频回退。
跨境拥塞:晚高峰期间跨境链路丢包升高,音频出现断续和机器人音。
较优做法是采用拆分隧道或本地互联网出口,让 Teams 和 Webex 媒体流量就近访问 Microsoft 365 和 Webex 媒体节点,而不是全部回传总部。如果必须走 VPN,应确保 UDP 3478-3481 和客户端媒体端口不被 NAT 或策略阻断,同时避免对实时媒体做深度包检测。
跨境链路还需要关注 Teams 的网络指标:客户端到 Microsoft 网络边缘建议单向延迟低于 50ms,RTT 低于 100ms,抖动低于 30ms,长期丢包低于 1%。音频对突发丢包尤其敏感,即使平均丢包不高,短时间抖动和重排序也会造成明显听感劣化。
6、调校顺序:从“能通”到“好听”的四步法
实际落地时,建议按以下顺序调整:
确认端口放行:先验证 UDP 3478-3481、50000-50059、Webex 媒体端口和 TCP 443 是否正常。
固定 Teams 端口范围:在 Teams 管理中心启用 QoS 标记,并配置音频、视频、共享端口。
对齐思科 DSCP 和队列:音频统一走 EF(46) 并进入 LLQ,视频走 AF41(34) 进入保障队列。
抓包验证端到端标记:在客户端交换机端口、WAN 出口和防火墙外侧抓包,确认音频包的 DSCP 值没有被清除或重标记。
如果音频仍然断续,可进一步检查 Wi-Fi 接入层。无线环境中应优先使用 5GHz,开启 WMM,并确保语音流量映射到 AC_VO 队列;有线接入则建议在接入交换机端口信任终端 DSCP,或在交换机侧基于端口重新标记。
小结
思科到 Teams 的跨域音频优化,本质上是把“实时音频”从普通数据流量中剥离出来,给予端到端的优先转发。Teams 侧要固定端口并启用 EF 标记,思科侧要把音频放入 LLQ、视频放入保障队列,防火墙要放行 UDP 3478-3481 和客户端媒体端口,跨境链路则应尽量减少 VPN 和代理对实时媒体的干扰。参数调校完成后,最好通过 Teams 通话质量仪表板、Webex 健康检查以及端到端抓包持续验证,确保音频在真实拥塞场景下仍然稳定可用。