宝利通视频会议终端无法被邀请故障排查

现象描述：

在点对点专线网络架构中，宝利通（Polycom）视频会议终端表现为：主动呼叫总部的MCU（多点控制单元）或多点会议正常，音视频流畅；但接受总部MCU的邀请入会时，终端振铃显示正常，接听后却无法建立连接，通常表现为黑屏、断连或长时间缓冲后超时。

故障原因分层解析：

这种现象通常被归类为“单向呼叫失败”或“信令与媒体流分离故障”。在专线环境下，虽然网络延迟和丢包率较低，但网络安全策略的配置不当是主要原因。

信令交互正常（看到邀请）： H.323或SIP协议的信令通道是通畅的。通常信令使用TCP端口（如H.323的1720端口，SIP的5060端口）。这说明总部MCU到终端的TCP/IP层路由是连通的，专线物理层没有问题。

媒体流交互失败（接听后失败）： 接听后，终端与MCU开始动态协商RTP/RTCP（实时传输协议）端口用于传输音视频。这些端口通常是动态的UDP端口（例如宝利通常用3230-3300端口范围）。失败的核心原因通常是：

防火墙策略限制： 分公司的防火墙允许了入向的TCP信令，但阻止了入向的UDP媒体流端口，导致视频数据无法进入内网。

ALG（应用层网关）兼容性问题： 防火墙的H.323 ALG功能可能未能正确解析信令中的端口信息，或错误地修改了数据包，导致媒体流无法建立。

路由返回问题： 尽管是专线，但若存在双向ACL（访问控制列表）不一致，导致媒体流返回时被拦截。

终端注册模式差异： 如果终端采用H.323注册模式（Gatekeeper模式），本地邀请成功可能是基于IP直呼，绕过了注册；而总部邀请可能需要通过Gatekeeper别名寻址，若GK（网守）配置不当或注册过期，也会导致媒体协商失败。

排查步骤建议：

第一步：基础连通性验证

在分公司终端上Ping总部MCU的IP，在总部核心侧Ping分公司终端的IP。确保专线两端双向ICMP（互联网控制报文协议）通，且丢包率小于1%。

第二步：端口放行策略

检查两端防火墙（尤其是分公司出口防火墙）的访问策略。

必须放行的协议： 确保TCP 1720（H.323信令）和UDP 1719（RAS）双向开放。

动态端口范围： 建议开放UDP 3230~3300（宝利通终端默认动态端口范围，具体可查阅设备手册），用于音视频流。如有条件，可针对总部MCU的IP地址设置完全不限制的IP规则进行测试，以验证是否为端口问题。

第三步：ALG功能调整

尝试暂时禁用防火墙上针对H.323的ALG功能。某些防火墙的ALG实现存在bug，会导致媒体端口协商错误。禁用ALG，让视频流作为纯粹的UDP数据包通过，有时能解决问题。

第四步：检查NAT策略（重要）

虽然用的是专线，但如果分公司终端配置了私有IP，且经过NAT（网络地址转换）转换后访问总部，这属于“一对一NAT”或“路由模式”。需要确保NAT映射是双向的，或者在防火墙上配置“源进源出”规则，防止媒体流从专线出去，却从其他链路返回（造成异步路由被丢弃）。

第五步：MCU侧配置核查

确认总部的MCU在邀请终端时，使用的呼叫带宽没有超出终端的最大承受能力，且音视频编解码格式（如H.264 HP/SVC）双方都支持。

总结：

专线解决了“路宽不宽、堵不堵”的问题，但“让不让走、走哪个门”是由策略决定的。面对“只能主叫，不能被叫”的故障，请将80%的精力放在媒体端口的安全策略和会话的双向性检查上。