Document
01
概述
日期： 2026-04-09 问题： Webex 视频会议中 VC Share（屏幕内容共享）失败，对端无法看到共享内容 分析对象： 失败 pcap vs 成功 pcap 对比分析 本机 IP： 10.66.42.25
02
1. 关键发现
本机视频编码器输出了"空壳帧"，视频 RTP 包的 payload 仅有 ~55 字节，而正常应为 800-1200 字节。网络层面无异常。
03
2. 抓包文件对比
| 项目 | 失败抓包 | 成功抓包 |
|---|---|---|
| 文件名 | extendedlogging-eth0-2026-04-09-14-19-15.pcap | extendedlogging-eth0-succeed.pcap |
| 时长 | 563.8 秒 | 46.8 秒 |
| 总包数 | 81,196 | 6,727 |
| 总流量 | 18.5 MB | 3.5 MB |
| Webex 对端 | 144.196.98.38 | 144.196.98.113 |
04
3. Share 视频流核心对比
3.1 发送方向包大小
| 指标 | ❌ 失败 (52072) | ✅ 成功 (52262) |
|---|---|---|
| 视频包数 | 27,102 | 1,549 |
| 平均包大小 | 95 B | 998 B |
| 最大包大小 | 190 B | 1,226 B |
| RTP Payload | ~55 B | ~960 B |
| RTP PT | 96 (H.264) | 101 (H.264) |
| 发送间隔 | 19 ms | 18 ms |
💬 引用
证据 1： 失败 pcap 中本机发送到 144.196.98.38:5004 的 全部 31,072 个 UDP 包中，没有任何一个超过 500 字节。
tshark -Y "ip.src==10.66.42.25 && ip.dst==144.196.98.38 && udp && frame.len>500"
→ 零结果
证据 2： 成功 pcap 中 Share 视频流 (52262) 的包大小分布：
| 大小范围 | 包数 |
|---|---|
| 100-199 B | 81 |
| 200-499 B | 192 |
| 500-999 B | 120 |
| 1000-1299 B | 1,191 |
正常 H.264 视频帧以 1000-1200 字节的大包为主。
证据 3： 失败 pcap 中主视频流 (52072) 的包大小分布：
| 大小范围 | 包数 |
|---|---|
| 50-99 B | 26,565 |
| 100-149 B | 537 |
| 150-199 B | 216 |
99% 的视频包只有 50-99 字节，远低于正常视频帧大小。
3.2 网络层对比
| 指标 | 失败 | 成功 |
|---|---|---|
| 发送间隔 | 19 ms | 18 ms |
| 是否有丢包（ICMP） | 357s 时有少量 ICMP Type 3 | 无 |
| 音频流是否正常 | ✅ 正常（52080/52216/52234） | ✅ 正常 |
| 对端视频接收 | ✅ 正常（平均 211 B/包） | ✅ 正常 |
⚠️ 注意
证据 4： 网络发送间隔一致（18-19 ms），说明 网络链路正常，包能正常发出。问题不在网络传输层。
证据 5： 音频流正常工作。失败 pcap 中 52080 发送 328 个 Opus 音频包（PT=73），平均 120 B，与成功 pcap 的音频流特征一致。
05
4. 失败 pcap 时间线
| 时间 | 事件 |
|---|---|
| 0s | 会议开始，4 条媒体流建立（52072 视频 + 52080/52216/52234 音频） |
| 0-357s | 视频流持续发送小包（95 B），对端持续回传正常视频帧 |
| 357s | 本机向 144.196.98.38 发出 4 个 ICMP Type 3 (Destination Unreachable) |
| 379s | 新建 4 条 TCP 连接到 144.196.98.38:443 和 :5004（可能是重新协商 Share） |
| 379s | 新增 3 条 UDP 流（52056/52272/52212），尝试重新建立 Share |
| 385s | 所有 TCP 连接 FIN 关闭（仅存活 ~6 秒） |
| 379-557s | 170.72.88.38 持续回复 ICMP Type 3（每 30 秒一次） |
💬 引用
证据 6： 357s 的 ICMP Destination Unreachable 可能是中间设备（防火墙/路由器）在某个时刻的路由异常，但这不是 Share 失败的根因——因为视频小包从第 0 秒就开始了。06
5. 根因判断（综合 pcap + 厂商回复）
5.1 初步判断（纯 pcap 分析）
💬 原始结论
基于 pcap 包大小分析，最初判断为编码器输出空壳帧（payload ~55B）。但结合厂商日志后，这一结论需要修正。5.2 厂商分析结论（2026-04-17 收到）
厂商结合设备底层日志与 Webex 后台服务器数据，确认根本原因是网络层的信令与媒体通道阻断，而非编码器问题。
| 层次 | 厂商发现 | 与 pcap 证据的对应 |
|---|---|---|
| 应用层 | 设备正常接收共享指令，进入 STARTING 状态，但未收到云端确认的 Presentation Token | pcap 中 0s 起 52072 流就在发小包 — 可能是 ICE/STUN 探测而非视频帧 |
| 信令层 | Webex 后台显示 missing.floor.request，云端未收到共享申请；设备未收到 SCR（媒体流控制请求） | 357s 出现 ICMP Type 3（网络阻断），379s TCP 重连到 :443 后 6 秒即 FIN 关闭 |
| 网络层（根因） | DNS 解析失败（locus-t.wbx2.com 超时 10s）、WebSocket 信令通道超时断开、UDP ICE/STUN 失败 | ✅ 357s ICMP Destination Unreachable、379s TCP 短连接后立即断开 |
📋 厂商日志证据
2026-04-09T14:19:46.743 main[2298]: APPL_Presentation[3]:
LocalPresentation::prepareResourcesForOutgoingPresentation
[LOCAL/1] current-mode=STARTING
2026-04-09T14:19:46.743 main[2298]: APPL_Presentation[3]:
TokenBasedPresentationCtrl::conditionalActivateLocalPresentation
confId=2 cause=UserSpec/1 state=TOKEN_RELEASED/PRES_IDLE/[LOCAL/1]
HttpClient W: Failed to connect to 'locus-t.wbx2.com':
Operation timed out after 10003 milliseconds, DNS not resolved5.3 修正后的根因链路
⚠️ 修正说明
pcap 中观察到的小包（~55B）并非编码器输出的空壳帧，而是信令通道未建立成功前的 ICE/STUN 探测包。编码器从未进入 SENDING 状态（因未获得 Presentation Token），因此根本没有开始编码。完整的故障链路：
| 步骤 | 描述 | 状态 |
|---|---|---|
| 1 | HDMI 输入正常 → 用户点击共享按钮 | ✅ 正常 |
| 2 | 设备发送共享请求 → 尝试获取 Presentation Token | ✅ 正常发出 |
| 3 | 信令到 Webex 云端 — DNS / WebSocket / UDP ICE | ❌ 网络阻断/超时 |
| 4 | 云端未收到 floor.request → 不下发 SCR | ❌ 信令中断 |
| 5 | 设备卡在 STARTING 状态，画面不出现 | ❌ 用户可见的故障 |
07
6. 建议排查方向
6.1 DNS 解析排查
厂商日志显示 locus-t.wbx2.com DNS 解析失败，HTTPS 超时 10 秒。需确认是防火墙 DNS ALG 拦截还是上游 DNS 问题。
! === 在防火墙上直接测试域名解析 ===
ping locus-t.wbx2.com
! === 查看 DNS 服务器配置 ===
display dns server
! === 查看 DNS ALG 是否拦截/修改 DNS 响应 ===
display alg dns
! === 查看 DNS 流量会话（复现时抓） ===
display session table ipv4 verbose destination-port eq 53💡 注意
如果防火墙自身解析正常，还需确认 Codec Plus (10.66.42.25) 使用的 DNS 服务器。如果 DNS 请求经过防火墙转发，检查 display session table ipv4 verbose destination-port eq 53 中是否存在超时或 RST。6.2 WebSocket 长连接排查
Webex 信令走 WebSocket（TCP 443），防火墙对长连接的超时时间或深度包检测可能中断 WebSocket 通道。
! === 查看长连接超时配置（最关键） ===
display firewall aging-time
! 重点：TCP FIN/RST 超时、TCP ESTABLISHED 超时
! WebSocket 是长连接，超时太短会被防火墙主动 RST
! === 查看 DPI 引擎是否检测 WebSocket 流量 ===
display dpi policy
display dpi application
! === 查看安全策略对 TCP 443 的处理 ===
display security-policy ip
! === 查看 ASPF 状态检测（可能干扰 HTTP Upgrade） ===
display aspf all
! === 查看 SSL 解密配置（开启会破坏 WebSocket 握手） ===
display sslv2 policy⚠️ 重点
如果 display sslv2 policy 中有 SSL 解密策略匹配了 Webex 流量，WebSocket 的 Upgrade 握手会被破坏，导致信令通道中断。同时 display firewall aging-time 中的 TCP ESTABLISHED 超时如果过短（如 10 分钟以下），长时间会议中的 WebSocket 会被防火墙主动清除。6.3 ICE/STUN 及其他网络层排查
- ICE/STUN（UDP） — Webex 媒体协商走 ICE，需 UDP 3478/5004 等端口，检查防火墙 ALG 或 SIP 模块是否有干扰
- ICMP Destination Unreachable — 排查 357s 出现的阻断原因
6.4 防火墙通用检查命令汇总（H3C Comware V7）
! === ALG 模块 ===
display alg sip ! SIP ALG 是否修改 SDP 媒体地址/端口
display alg dns ! DNS ALG 是否拦截域名
display alg rtsp ! RTSP ALG 状态
! === 状态检测 ===
display aspf all ! ASPF 状态检测配置
! === 深度包检测 ===
display dpi engine ! SIO 智能识别引擎状态
display dpi policy ! 深度包检测策略
display dpi application ! 应用识别配置
! === 长连接超时 ===
display firewall aging-time ! TCP 超时（WebSocket 关键）
! === SSL 解密 ===
display sslv2 policy ! SSL 解密策略（WebSocket 关键）
! === 会话表（复现时抓） ===
display session table ipv4 verbose destination-port eq 5004 ! RTP
display session table ipv4 verbose destination-port eq 3478 ! STUN
display session table ipv4 verbose destination-port eq 53 ! DNS
display session table ipv4 verbose destination-port eq 443 ! WebSocket6.3 设备/服务端
- RoomOS 11.36.1.1 和 11.34.1.5 均复现，已排除版本问题
- 多台 Codec Plus、直连 HDMI 和矩阵均可复现 — 指向网络环境
- 对端 IP 不固定（.38 / .113），确认不同 MCU 节点均受影响
报告生成：2026-04-17 | 基于 tshark 2.6.2 分析 + Cisco 厂商回复综合
更新：2026-04-17 | 修正根因判断，由"编码器问题"修正为"网络层信令阻断"