Webex Calling 無音事象の総合解析

対象: 20260415_UC8300D.txt (debug ccsip messages / debug ccsip media / show voip rtp connections) + CAP2.pcap

結論: 原因は Webex から LGW への戻り RTP (UDP) 不達 です。
LGW から Webex へは RTP を送出できていますが、逆方向が到達せず、受信タイムアウトで切断しています。

1. 解析対象と観測条件

通話経路: PSTN/ISDN 側端末 ↔ LGW (UC8300D) ↔ Webex Calling
LGW ログ: SIP シグナリング + メディア処理 + RTP接続テーブル
キャプチャ: CAP2.pcap (LGW 側採取)

2. 20260415_UC8300D.txt の主要事実

2.1 通話は張れており RTP セッション情報も生成される

show voip rtp connections ではアクティブ接続が 1 本表示され、以下の対向が見えています。

No. CallId     dstCallId  LocalRTP RmtRTP   LocalIP          RemoteIP
1   176965     176964     16634    24944    192.168.120.31   144.196.102.126

2.2 しかし通話終端時の RTP 受信統計が 0

Reason: Q.850;cause=102
P-RTP-Stat: PS=1511,OS=317310,PR=0,OR=0,PL=0,JI=1,LA=-1,DU=30

PS: 送信パケット数は増加
PR=0: 受信パケットは 0
cause=102: RTP受信タイマ満了での切断と整合

3. CAP2.pcap のフロー解析結果

3.1 方向別 RTP パケット数

方向	5タプル	パケット数	判定
LGW → Webex	192.168.120.31:16634 → 144.196.102.126:24944	1529	送信できている
Webex → LGW	144.196.102.126:24944 → 192.168.120.31:16634	0	戻りRTPが不達

3.2 CAP2 のプロトコル分布

UDP: 1563 パケット
TCP: 382 パケット
OSPF (proto 89): 12 パケット

UDP の大半が 192.168.120.31:16634 → 144.196.102.126:24944 の片方向フローで、逆方向が存在しません。

4. CAP2.pcap における STUN 処理の実体

4.1 検出された STUN メッセージ

STUN 総数: 36 パケット
メッセージ種別: すべて 0x0011 (Binding Indication)
Method bits: 0x0001 (Binding)
Message Length: すべて 108 byte

4.2 STUN の方向と本数

方向	5タプル	本数
LGW → Webex	192.168.120.31:16634 → 144.196.102.126:24944	18
LGW → Webex	192.168.120.31:16635 → 144.196.102.126:24945	18

4.3 この STUN が意味すること

本キャプチャの STUN は、RTPポート対に対する Binding Indication ベースの keepalive 動作です。
主目的は NAT/FW のピンホール維持と、ICE 系の到達性維持です。
Indication は応答必須ではないため、返信が見えないこと自体は STUN 異常とは断定できません。

重要: STUN keepalive は正常に送出されていますが、Webex → LGW の戻りRTPは 0 のままです。
したがって今回の無音事象は「STUN 不動作」ではなく、戻りRTP経路の遮断/不達が本体です。

5. 相関分析 (ログ × pcap)

観測	txtログ	pcap	解釈
通話確立	RTP接続エントリあり	RTP送信あり	シグナリング/送出開始は成立
無音	PR=0	戻りRTP 0	受信方向のみ欠落
切断	cause=102	片方向のまま	受信タイマ満了で自然切断

技術結論: 問題の本体は SRTP 交渉そのものではなく、Webex → LGW の戻り UDP/RTP 経路です。
境界 FW/NAT の許可方向・タイムアウト・対称NAT挙動を最優先で見直してください。

6. 追試結果 (2026-04-20: CAP4 + debug)

FW に RTP 許可ルール追加後の再試験でも片通話は継続し、LGW 側で 30 秒切断 (cause=102) が再現しました。

6.1 debug 側の結果

show voip rtp connections ではセッション自体は成立 (16700 -> 31582 @ 144.196.102.32)
通話終端統計は P-RTP-Stat: PR=0 のまま
切断理由は再び Reason: Q.850;cause=102

6.2 CAP4 側の結果

LGW 送信 RTP は大量に存在
- 192.168.120.31:16698 -> 144.196.102.103:30972 (1524 packets)
- 192.168.120.31:16700 -> 144.196.102.32:31582 (1521 packets)
LGW 宛ての戻り RTP/UDP は観測されず (DNS 応答のみ)
ICMP は Type 3 Code 3 (Port Unreachable) が 24 件
ICMP 送信元は Webex 側メディア IP (144.196.102.103, 144.196.102.32)

解釈: ICMP Destination Unreachable は「主原因」ではなく、LGW が送信した RTP 宛先ポートが相手側で閉じていることを示す結果です。
根因は引き続き Webex -> LGW の戻りRTP不達 であり、受信側経路が成立しないため 30 秒でタイムアウトします。

6.3 CAP3 と CAP4 の差分比較

観点	CAP3	CAP4	評価
片通話の有無	継続	継続	未改善
切断要因	`Q.850 cause=102` (30秒前後)	`Q.850 cause=102` (30秒前後)	未改善
RTP受信統計	`PR=0`	`PR=0`	未改善
LGW → Webex RTP	送信あり	送信あり	正常継続
Webex → LGW RTP	観測なし	観測なし	未改善
ICMP Destination Unreachable	Type 3 Code 3 を観測	Type 3 Code 3 を多数観測	副次症状が明確化
総合判定	戻りRTP不達	戻りRTP不達	根因は同一

この比較から、FWルール追加後もメディア受信方向の実効性が得られていないことが分かります。ICMP は「戻りRTPが来ない」事象の代替シグナルであり、根因の置き換えではありません。

7. 推奨対策

7.1 ファイアウォール許可

宛先: LGW メディアIP (192.168.120.31)
プロトコル: UDP
宛先ポート: 16384-32766
送信元: Webex Calling メディアレンジ (運用中リージョン全体)

7.2 NAT/セッション維持の確認

UDP セッションタイムアウトが過小でないこと (少なくとも 60 秒以上を推奨)
SIP ALG の不適切な書き換え無効化
ポリシーが片方向のみ許可になっていないこと
ICMP Unreachable を生成した装置/ポリシーの確認 (上流FW/キャリア境界を含む)

7.3 再試験時の確認コマンド

show voip rtp connections
show call active voice compact
(debug ccsip messages / media を同時採取)

成功判定は次の 3 点です。

P-RTP-Stat の PR > 0
Reason: Q.850;cause=102 が出ない
pcap で Webex → LGW の RTP が継続到達する

8. 補足

本解析では、LGW から送信された RTP が Webex 側へ到達している一方、逆方向のみ欠落しているため、音声品質やコーデック不一致よりも、ネットワーク境界での受信方向制御を優先して対処するのが最短です。