🔍 Network Analysis

Webex VC Share 故障分析报告

基于 pcap 对比分析的 Webex 视频会议屏幕共享失败根因排查

📅 2026-04-09 起始

🔄 2026-05-11 更新

📄 网络故障分析

📑 目录

概述
1. 关键发现
2. 抓包文件对比
3. Share 视频流核心对比
4. 失败 pcap 时间线
5. 根因判断（综合 pcap + 厂商回复）
6. 建议排查方向
7. 第二次复现分析（2026-04-20）
8. 后续发现与建议（2026-05-11 更新）

概述

日期： 2026-04-09 问题： Webex 视频会议中 VC Share（屏幕内容共享）失败，对端无法看到共享内容 分析对象： 失败 pcap vs 成功 pcap 对比分析 本机 IP： 10.66.42.25

1. 关键发现

本机视频编码器输出了"空壳帧"，视频 RTP 包的 payload 仅有 ~55 字节，而正常应为 800-1200 字节。网络层面无异常。

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

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 的音频流特征一致。

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 秒就开始了。

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 resolved

5.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 状态，画面不出现	❌ 用户可见的故障

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    ! WebSocket

6.3 设备/服务端

RoomOS 11.36.1.1 和 11.34.1.5 均复现，已排除版本问题（注：RoomOS 11.38 Preview 已尝试修复，见第 8 节）
多台 Codec Plus、直连 HDMI 和矩阵均可复现 — 指向网络环境
对端 IP 不固定（.38 / .113），确认不同 MCU 节点均受影响

报告生成：2026-04-17 | 基于 tshark 2.6.2 分析 + Cisco 厂商回复综合

更新：2026-04-17 | 修正根因判断，由"编码器问题"修正为"网络层信令阻断"

更新：2026-04-20 | 新增第二次复现分析（H3C + Fortinet 双设备抓包），发现 Codec DNS 绕过问题

更新：2026-05-11 | 新增 DNS 配置重启生效 & RoomOS 11.38 修复信息（Cisco TAC 确认）

7. 第二次复现分析（2026-04-20）

日期： 2026-04-20
Codec IP： 10.66.42.26（与 4/9 不同，换了一台设备）
Webex 对端： 144.196.81.129（两次抓包连接同一 TURN 服务器）
抓包位置： H3C 核心防火墙 CNBRCLCOREFW01（node8）+ FortiGate CNBRCLFW01 出口（packet-capture）

7.1 抓包文件概览

项目	❌ 失败 (16:39)	✅ 成功 (16:45)
Fortinet 抓包时长	37.7 秒 / 399 包	25.3 秒 / 436 包
H3C 抓包文件数	6 个 cap 文件	11 个 cap 文件（node8 + node16）
Webex 对端 IP	144.196.81.129	144.196.81.129
DNS 全部正常？	✅ 是	✅ 是
locus-t.wbx2.com 解析	170.72.236.220, 248, 57	248, 170.72.236.220, 57
Codec 实际连接的 Locus IP	170.72.236.89（不在解析结果中）	170.72.236.248（解析结果中的地址）

7.2 核心发现：Codec 绕过 DNS 解析结果

🚨 关键发现

Codec 在 DNS 解析 locus-t.wbx2.com 得到 170.72.236.220/248/57 后，没有使用任何一个解析结果，而是连接了 170.72.236.89（一个不在 DNS A 记录中的 IP）。成功 Share 时 Codec 正确使用了 DNS 返回的 170.72.236.248。

失败时 Locus 信令连接时间线

时间	事件
19.21s	DNS 解析 locus-t.wbx2.com → 170.72.236.220, 248, 57
19.46s	Codec 连接 170.72.236.89（不在解析结果中！）
19.53s	TCP SYN-ACK 到达
19.60s	Codec 发 TLS Client Hello (679B)
19.68s	服务器回 TLS Server Hello (1354B) + 其他数据
19.68s+	Codec 未完成 TLS 握手 — 之后 0 bytes outbound payload on TCP 443

成功时 Locus 信令连接时间线

时间	事件
5.80s	DNS 解析 locus-t.wbx2.com → 248, 170.72.236.220, 57
6.42s	Codec 连接 170.72.236.248（✅ DNS 返回的地址）
6.47s	TCP SYN-ACK 到达
6.52s	Codec 发 TLS Client Hello (589B)
6.58s	服务器回 TLS Server Hello (1354B) + 1090B
6.58s	✅ TLS 握手完成，信令正常建立

⚠️ 分析

170.72.236.89 也是 Webex 的服务器（能完成 TCP 握手并返回 TLS Server Hello），但它可能不是 Locus 信令服务器，或者该节点的 TLS 配置与 Codec 不兼容，导致 TLS 握手无法完成。Codec 发了 Client Hello 但没有继续发送 Client Key Exchange（353B）。

7.3 TCP 443 信令对比（H3C 防火墙视角）

指标	❌ 失败	✅ 成功
远端 → Codec (TCP 443 payload)	46 包, 34,732 bytes	46 包, 34,732 bytes
Codec → 远端 (TCP 443 payload)	2 包, 714 bytes	2 包, 714 bytes
TLS 握手完成？	❌ Server Hello 到了，Codec 未回复 Client Key Exchange（对 144.196.81.129 的连接）	✅ 双向完成

📋 补充

H3C 防火墙侧看到 Codec 对 144.196.81.129 的 TCP 443 信令连接确实存在少量 payload（714B），但对比 Fortinet 出口侧的数据（失败时 0 bytes outbound），说明 Codec 发出的数据可能只到了 H3C 就被丢弃或未成功转发，或者两台设备抓包的时间窗口不完全重叠。

7.4 UDP 5004 媒体流对比（H3C 防火墙视角）

指标	❌ 失败	✅ 成功
TX (Codec → 远端) 包数	3,218	1,336
TX 平均包大小	176 B	319 B
TX 最大包大小	207 B	1,224 B
RX (远端 → Codec) 包数	744	926
RX 平均包大小	118 B	119 B

成功时 TX 平均 319B（正常 H.264 视频），失败时 176B（编码器虽在工作，但可能发送的是本地摄像头画面而非 Share 内容，因为 Share 信令从未成功建立）。

7.5 DNS 完整性对比

域名	❌ 失败解析结果	✅ 成功解析结果
locus-t.wbx2.com	170.72.236.220, 248, 57	170.72.236.248, 220, 57
data-channel-r.wbx2.com	空响应（无 A 记录）	170.72.250.85, 225, 99
meeting-container-a.wbx2.com	170.72.245.60, 203, 83	170.72.245.203, 60, 83
client-logs-a.wbx2.com	170.72.245.206, 46, 81	—
llm1-connection-t.wbx2.com	170.72.236.21, 72, 254	—
xlm83.*.webex.com	空响应	144.196.81.129

⚠️ 注意

失败时 data-channel-r.wbx2.com 和 xlm83.*.webex.com 均返回空响应，但 locus-t.wbx2.com DNS 解析成功。因此 DNS 本身不是本次失败的直接原因，问题出在 Codec 解析后没有使用返回的 IP 地址。

7.6 更新后的根因判断

🎯 最终结论（2026-04-20 更新）

Codec (RoomOS) 存在 DNS 缓存/连接选择 bug：在 DNS 解析 locus-t.wbx2.com 成功获取 A 记录后，Codec 没有使用任何 DNS 返回的 IP 地址，而是连接了一个不在解析结果中的"幽灵 IP" 170.72.236.89。该 IP 可能是 Codec 缓存的旧 DNS 记录，或 RoomOS 内部硬编码的备选地址。

故障链路：

DNS 解析 locus-t.wbx2.com → 正常返回 3 个 A 记录
Codec 忽略 DNS 结果，连接缓存/硬编码的 170.72.236.89
170.72.236.89 能完成 TCP 握手，但 TLS 握手失败（Codec 未发送 Client Key Exchange）
信令通道无法建立 → 无法获取 Presentation Token → Share 失败

7.7 建议给 Cisco 厂商

💬 反馈要点

H3C 核心防火墙 + FortiGate 出口双设备同时抓包（2026-04-20 16:39-16:46）对比分析：

Codec DNS 解析 locus-t.wbx2.com 得到 170.72.236.220/248/57，但连接了 170.72.236.89（不在 DNS A 记录中）
成功 Share 时 Codec 正确使用了 DNS 返回的 170.72.236.248
170.72.236.89 能完成 TCP 握手并返回 TLS Server Hello，但 TLS 握手未完成（Codec 未回复 Client Key Exchange）
请排查 RoomOS 为什么会绕过 DNS 解析结果使用缓存/硬编码 IP 地址
请确认 170.72.236.89 是否是有效的 Locus 信令节点，如果不是，为何 Codec 会尝试连接该地址

更新：2026-04-20 | 基于 H3C + Fortinet 双设备抓包对比分析 | tshark 2.6.2

8. 后续发现与建议（2026-05-11 更新）

日期： 2026-05-11
来源： Cisco TAC（Jessica Zhang）邮件回复 + 内部测试验证

8.1 DNS 配置需重启 VC 才能生效

⚠️ 关键发现

在 Webex Codec 上修改 DNS 服务器配置后，必须重启 VC 设备才能生效。仅保存配置而不重启，Codec 仍会使用旧 DNS 服务器。这解释了为什么之前更改 DNS 后问题仍然持续——配置变更未实际生效。

DNS 选择建议

DNS 服务商	地址	体验评价	建议
Google DNS	8.8.8.8 / 8.8.4.4	体验不佳	❌ 不推荐 — 解析 Webex 域名延迟/不稳定
Cloudflare	1.1.1.1 / 1.0.0.1	待测试	⚠️ 可测试
运营商 DNS	当地 ISP 提供	推荐优先使用	✅ 推荐 — 本地解析延迟最低
Cisco Umbrella	208.67.222.222 / 208.67.220.220	Webex 官方推荐	✅ 推荐 — Webex 生态原生支持

💡 操作建议

在 Codec 上修改 DNS 为运营商 DNS 或 Cisco Umbrella
重启 Codec 设备
重启后运行 nslookup locus-t.wbx2.com 验证解析正常
测试 Share 功能确认稳定性

8.2 RoomOS 11.38 修复（Cisco 厂商反馈）

2026-04-16，Cisco TAC（Jessica Zhang, jinzhan5@cisco.com）确认：

🎯 厂商结论

问题定位在设备端：当 VC Share 失败时，设备端没有成功发起与 Webex Server 的共享权限请求连接（missing.floor.request）。Cisco 设备开发团队已在 RoomOS 11.38 版本尝试修复了这个问题。

RoomOS 11.38 版本信息

属性	值
版本号	RoomOS 11.38.0.29 ed6ed689fb4
发布日期	2026-04-16
可用渠道	Preview Channel（预览通道）
升级方式	Control Hub → 设备管理 → 软件版本 → 选择 Preview Channel

测试验证步骤

登录 Control Hub，选择 1-2 台问题设备
将设备软件通道切换至 Preview Channel
等待设备自动下载并安装 RoomOS 11.38
在多台设备上复现 Share 场景，验证问题是否解决

⚠️ 如果问题在 11.38 上仍然发生

Cisco 要求抓取设备的 debug log 提供给开发团队进一步调查。步骤参考 Cisco 官方文档：Webex Board, Desk, and Room Series Device Logs Collection Guide。

8.3 综合建议

✅ 推荐行动

短期： Codec DNS 改为 Cisco Umbrella 或运营商 DNS → 重启设备 → 验证
中期： 升级 1-2 台 Codec 至 RoomOS 11.38 Preview Channel → 测试 Share 稳定性
长期： 如果 11.38 修复有效，等待正式 Release 后全量升级；如果无效，抓取 debug log 向 Cisco 提交 Case

更新：2026-05-11 | Cisco TAC 邮件 + 内部测试验证 | Jessica Zhang (Cisco)

← 返回主页