Webex Calling 無音事象の総合解析
対象: 20260415_UC8300D.txt (debug ccsip messages / debug ccsip media / show voip rtp connections) + CAP2.pcap
結論: 原因は Webex から LGW への戻り RTP (UDP) 不達 です。
LGW から Webex へは RTP を送出できていますが、逆方向が到達せず、受信タイムアウトで切断しています。
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: 受信パケットは 0cause=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経路の遮断/不達が本体です。
したがって今回の無音事象は「STUN 不動作」ではなく、戻りRTP経路の遮断/不達が本体です。
5. 相関分析 (ログ × pcap)
| 観測 | txtログ | pcap | 解釈 |
|---|---|---|---|
| 通話確立 | RTP接続エントリあり | RTP送信あり | シグナリング/送出開始は成立 |
| 無音 | PR=0 | 戻りRTP 0 | 受信方向のみ欠落 |
| 切断 | cause=102 | 片方向のまま | 受信タイマ満了で自然切断 |
技術結論: 問題の本体は SRTP 交渉そのものではなく、Webex → LGW の戻り UDP/RTP 経路です。
境界 FW/NAT の許可方向・タイムアウト・対称NAT挙動を最優先で見直してください。
境界 FW/NAT の許可方向・タイムアウト・対称NAT挙動を最優先で見直してください。
6. 推奨対策
6.1 ファイアウォール許可
- 宛先: LGW メディアIP (192.168.120.31)
- プロトコル: UDP
- 宛先ポート: 16384-32766
- 送信元: Webex Calling メディアレンジ (運用中リージョン全体)
6.2 NAT/セッション維持の確認
- UDP セッションタイムアウトが過小でないこと (少なくとも 60 秒以上を推奨)
- SIP ALG の不適切な書き換え無効化
- ポリシーが片方向のみ許可になっていないこと
6.3 再試験時の確認コマンド
show voip rtp connections show call active voice compact (debug ccsip messages / media を同時採取)
成功判定は次の 3 点です。
P-RTP-StatのPR > 0Reason: Q.850;cause=102が出ない- pcap で Webex → LGW の RTP が継続到達する
7. 補足
本解析では、LGW から送信された RTP が Webex 側へ到達している一方、逆方向のみ欠落しているため、
音声品質やコーデック不一致よりも、ネットワーク境界での受信方向制御を優先して対処するのが最短です。