この記事は筆者オンリーのAdvent Calendar 20258日目の記事です。
本記事ではSIP/RTP デバッグのための tcpdump & Wiresharkのネタを書いてみようと思います。
VoIP（特に SIP/RTP）を扱っていると、通話が鳴らない／片通話になる／音が途切れる といったトラブルは頻繁に発生します。
この記事では、SIP/RTP のデバッグを行う際によく使う tcpdump と Wireshark の基本〜すぐ使える実践方法 をまとめます。
はじめに
以下の構成で書いていきます。
1.なぜ SIP/RTP デバッグに tcpdump と Wireshark が必要なのか
2.tcpdump で必要なパケットだけを効率よく取る
3.Wireshark で SIP/RTP を読み解く
4.RTP ストリームの再生と音声解析
5.VoIP デバッグでよくある落とし穴
6.まとめ
1. なぜ SIP/RTP デバッグに tcpdump と Wireshark？
SIP はシグナリング、RTP はメディア（音声）を運ぶプロトコルです。
問題の原因を切り分けるには、どの時点で何が起きているのか をパケットレベルで見る必要があります。
例えば：
SIP INVITE が届いていない → 着信しない
200 OK の SDP が誤っている → 音声が片側しか聞こえない
RTP が送られていない／ポートが違う → 無音
NAT/FireWall 配置が原因 → コール確立失敗
tcpdump は 現場での即時キャプチャ、Wireshark は 詳細解析 に最適です。
2. tcpdump で必要なパケットだけを効率よく取る
最低限覚えておきたい tcpdump コマンド
▼ SIP（5060/UDP）を取る
sudo tcpdump -i any -nn port 5060 -w sip.pcap
▼ RTP（10000–20000 など任意ポート）を取る
sudo tcpdump -i any -nn udp portrange 10000-20000 -w rtp.pcap
▼ SIP と RTP をまとめて取る（推奨）
sudo tcpdump -i any -nn udp and ( port 5060 or portrange 10000-20000 ) -w voip.pcap
▼ 端末の IP（例: 192.168.1.50）に絞る
sudo tcpdump -i any -nn host 192.168.1.50 -w filter.pcap
🔍 キャプチャのポイント
-nn はホスト名・プロトコル名を解決しないので高速
-w は生データを保存する（Wireshark 解析用）
any インターフェイスは便利だが CPU コスト高 → NIC がわかれば代わりに eth0 等を指定
VoIP 機器では パケットドロップが発生しないように注意
3. Wireshark で SIP/RTP を読み解く
pcap を Wireshark に読み込んだら、まずは プロトコルツリー で SIP の流れを追います。
よく使う Wireshark ディスプレイフィルタ
SIP
sip
SDP のみ
sdp
RTP
rtp
特定の Call-ID のみ
sip.Call-ID contains "xxxxxx"
IP アドレスで絞る
ip.addr == 192.168.1.50
SIP コールの追跡（Follow SIP Flow）
Wireshark のメニューより
Telephony → SIP → Flow Sequence を開くと、
以下のような シーケンス図 が自動生成されます：
INVITE
100 Trying
180 Ringing
200 OK
ACK
BYE
SIP デバッグでは最も強力な機能のひとつです。
4. RTP ストリームの再生と音声解析
Wireshark は RTP 音声の再生が可能です。
▼ メニュー
Telephony → RTP → RTP Streams
すると、各 RTP ストリームの情報が閲覧できます：
パケットロス
ジッタ
コーデック（G.711 / Opus / G.729 …）
Payload Type
SSRC
"Analyze" → "Play Streams" を押すと、実際に音声を聞くこともできます。
通話品質の劣化原因（ノイズ・欠落）が目で見てわかるのが利点。
5. VoIP デバッグでよくある落とし穴
SIP の NAT 越え（特に家庭用ルータ）
SDP の c= や m= の IP がプライベートアドレスになる
外向き RTP が正しく届かず「片通話」になる
❗ PBX / SBC のポート制限
RTP のポート範囲が異なる機器間で問題が起きがち
❗ コーデック不一致
片側が G.711 μ-law のみ
もう片側が Opus のみ
→ どちらも Offer/Answer が成立せず無音
❗ firewall が UDP を破棄
SIP のみ許可し RTP を落とすケース
6. まとめ
現場では tcpdump で最小限のパケットを確実に取る のが重要
Wireshark は SIP シーケンス確認 と RTP 音声解析 に非常に強い
NAT まわりの問題は特に頻出。SDP を必ず確認する
RTP パケットのロスや遅延は Wireshark の RTP 解析で可視化可能