突然の通話切断。誰も再現できない片方向の音声。ピーク時間帯にしか起きない音声の途切れ。VoIPの問題は厄介です。なぜなら、シグナリングを担うSIPと実際の音声を運ぶRTPという、2つの別々のプロトコルにまたがっているからです。診断のたびに数千行のログを掘り起こし、ちょうど問題が起きた瞬間のログを捕まえられるよう祈るしかない状況です。
定番の対処法は tcpdump -i eth0 -w voip.pcap port 5060 を実行してWiresharkで分析することです。一度限りのデバッグなら有効ですが、スケールしません。そして顧客が午前3時に「2時間前に通話が切れた」と電話してきたとき、まったく役に立ちません。
Homer SIPCaptureはこの問題を解決します。すべてのSIPトランザクションを一元管理・検索可能なデータベースとして保存し、コールフローのラダー図や相関付きのRTP品質統計など全体像を提供します。しかも通話パスに手を加えることなく、測定可能なレイテンシも追加しません。
アプローチ比較：VoIPをデバッグする3つの方法
Homerを導入する前に、代替手段が実際に何を提供できるかを把握しておく価値があります。
パッシブパケットキャプチャ（tcpdump / Wireshark）
インターフェースで生パケットをキャプチャし、オフラインで分析します。WiresharkにはSIPとRTPの優れたディセクタが搭載されており、簡単な一回限りの調査ならこれで十分なことも多いです。ただし純粋にリアクティブな手法です。問題が発生したまさにそのときにキャプチャしていなければならず、複数のホップにまたがるSIPシグナリングとRTPストリームを手動で関連付けるのは、すぐに煩雑になります。
PBX詳細ログ（Asterisk / FreeSWITCH）
AsteriskもFreeSWITCHも、SIPメッセージのフルログを記録できます。Asteriskなら sip set debug on、FreeSWITCHなら sofia global siptrace on を実行すると、すべてのSIPパケットがコンソールやログファイルに出力されます。問題は、これらのログが非構造化テキストであることです。RTP品質データも、視覚的なコールフローもなく、先週の木曜日の特定の通話を10万行のログから探す良い手段がありません。
Homerによる集中型SIPキャプチャ（HEPプロトコル）
HEP（Homer Encapsulation Protocol）は、SIPメッセージをラップしてリアルタイムで中央コレクターに転送する軽量なUDPカプセル化プロトコルです。Asterisk、FreeSWITCH、Kamailio、OpenSIPSはすべてHEPをネイティブでサポートしています。Homerはこれらのパケットをフルテキストインデックスとともにデータベースに保存します。WebUIでは、発信者・着信者・コールID・SIPレスポンスコード・時間範囲で検索でき、任意の通話の視覚的なラダー図を数秒で表示できます。
各アプローチのメリット・デメリット
| アプローチ | メリット | デメリット |
|---|---|---|
| tcpdump / Wireshark | セットアップ不要、あらゆるホストで動作 | 障害発生時に実行中である必要がある；RTP相関を手動で行う；履歴なし |
| PBX詳細ログ | 主要PBXに標準搭載；追加ツール不要 | テキストのみ；RTP統計なし；検索困難；コールフロー可視化なし |
| Homer SIPCapture | リアルタイム；全文検索可能；コールフロー図；RTP MOS/ジッター統計；履歴データ | 各PBXでHEPエージェントの設定が必要；専用サーバーが必要 |
1日に数十件以上の通話を処理するなら、Homerを導入する価値は十分あります。複数のFreeSWITCHクラスターを本番環境で運用してきた経験から言えば、以前は2時間かかっていたログ検索が5分で済むようになります。
推奨構成
Homerの現代的なスタックは4つのコンポーネントで構成されています：
- heplify-server — HEPコレクター（Goバイナリ）；SIPキャプチャを受信してデータベースに書き込む
- Homer App — 検索と可視化のためのReact WebUI
- PostgreSQL — ストレージバックエンド（1日最大約5万件の通話まで対応）；より大きなボリュームにはClickHouseに切り替える
- HEPエージェント — Asterisk/FreeSWITCH/Kamailioに組み込み済み、またはパッシブキャプチャ用にスタンドアロンの
heplifyエージェントを使用
中小規模のVoIP環境（同時通話200件未満）なら、4 vCPU、8 GBメモリ、高速SSDを搭載したUbuntu 22.04の単一VMで十分です。PostgreSQLはチューニングなしでその負荷を処理でき、Homerのパーティションローテーションがデフォルトで30日以上古いデータを削除するため、ディスク使用量は一定に保たれます。
実装ガイド
ステップ1：heplify-serverのインストール
# heplify-serverをダウンロード
wget https://github.com/sipcapture/heplify-server/releases/latest/download/heplify-server_linux_amd64.tar.gz
tar -xzf heplify-server_linux_amd64.tar.gz
sudo mv heplify-server /usr/local/bin/
sudo chmod +x /usr/local/bin/heplify-serverステップ2：PostgreSQLデータベースの作成
sudo -u postgres psql <<EOF
CREATE DATABASE homer_data;
CREATE DATABASE homer_config;
CREATE USER homer WITH PASSWORD 'your_secure_password';
GRANT ALL PRIVILEGES ON DATABASE homer_data TO homer;
GRANT ALL PRIVILEGES ON DATABASE homer_config TO homer;
EOFステップ3：heplify-serverの設定
/etc/heplify-server.toml を作成します：
HEPAddr = "0.0.0.0:9060"
DBDriver = "postgres"
DBAddr = "localhost:5432"
DBUser = "homer"
DBPass = "your_secure_password"
DBDataTable = "homer_data"
DBConfTable = "homer_config"
DBBulk = 200
DBWorker = 8
DBRotate = true
DBPartSip = "2h"
DBPartLog = "24h"
DBPartRaw = "2h"
DBDropDays = 30
LogLvl = "info"
LogStdout = true# systemdサービスを作成
sudo tee /etc/systemd/system/heplify-server.service <<EOF
[Unit]
Description=HEPlify Server
After=network.target postgresql.service
[Service]
ExecStart=/usr/local/bin/heplify-server -config /etc/heplify-server.toml
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now heplify-serverステップ4：DockerでHomer Appをデプロイ
docker run -d \
--name homer-app \
--restart unless-stopped \
-p 9080:80 \
-e "DB_HOST=your-postgres-host" \
-e "DB_USER=homer" \
-e "DB_PASS=your_secure_password" \
-e "DB_NAME=homer_config" \
sipcapture/homer-app:latesthttp://your-server:9080 でUIにアクセスします。デフォルト認証情報は admin / sipcapture です——必ずすぐに変更してください。
ステップ5：FreeSWITCHでHEPを有効化
SIPプロファイルを編集します（例：/etc/freeswitch/sip_profiles/internal.xml）：
<param name="capture-server" value="udp:YOUR_HOMER_IP:9060"/>
<param name="capture-enabled" value="true"/>通話を切断せずにプロファイルをリロードします：
fs_cli -x "sofia profile internal rescan"ステップ6：AsteriskでHEPを有効化
/etc/asterisk/hep.conf を作成します：
[general]
enabled = yes
capture_address = YOUR_HOMER_IP
capture_port = 9060
capture_type = HEP3
uuid_type = call-idsip.conf または pjsip.conf に記述：
[general]
hep_enabled = yes
hep_capture_id = 1次にリロードします：asterisk -rx "module reload res_hep.so"
ステップ7：heplifyによるパッシブRTPキャプチャの追加
組み込みHEPエージェントはSIPシグナリングを送信しますが、RTP品質統計は送信しません。MOS、ジッター、パケットロスのデータを取得するには、メディアサーバーにパッシブスニファーとして heplify をデプロイします：
wget https://github.com/sipcapture/heplify/releases/latest/download/heplify_linux_amd64.tar.gz
tar -xzf heplify_linux_amd64.tar.gz
sudo mv heplify /usr/local/bin/
# ポート5060でSIPをキャプチャし、RTCPからRTP統計を取得
sudo heplify \
-hs YOUR_HOMER_IP:9060 \
-i eth0 \
-m SIPRTCP \
-pr 5060-5061 \
--rtp_stats \
-sl 7結果の確認方法
通話データがHomerに流れ始めたら、検索画面を開き、時間範囲・発信者番号・SIPレスポンスコードでフィルタリングします。任意の通話をクリックして分析ビューを開きます：
- コールフローラダー — INVITE → 100 Trying → 180 Ringing → 200 OK → ACK → BYE と、タイムスタンプとホップごとのルーティングが表示
- RTP統計タブ — MOSスコア、ジッター（ms）、パケットロス（%）、RTPストリームごとの遅延パケット
- 生のSIPメッセージ — SDPオファー/アンサーを含む完全なヘッダー、コーデックとNATのデバッグに必須
RTP品質を確認する際は、以下の閾値を参考にしてください：
ジッター： < 20ms — 透明（問題なし）
20–50ms — 気になるレベル
> 50ms — 音声に明らかな乱れが発生
パケットロス： < 1% — 許容範囲内
1–5% — 品質低下
> 5% — 音声が途切れ、実用不可
MOSスコア： > 4.0 — 優秀（固定電話品質）
3.5–4.0 — 良好
< 3.5 — クレームが想定される水準よくある問題の診断
片方向音声
通話は完了（200 OKを受信、ACKを送信）しているにもかかわらず、音声が一方向にしか流れない状態です。生のSIPメッセージを開き、SDP内の c= 行を確認してください。両エンドポイントがパブリックインターネット上にあるのに、プライベートなRFC1918アドレスが表示されている場合、PBXがNAT配下にあり、外部IPが正しく設定されていません。FreeSWITCHの ext-rtp-ip 設定、またはAsteriskの externaddr を修正してください。
ちょうど30秒で通話が切断される
ほぼ必ず、30秒のリフレッシュタイマーでのSIP re-INVITEの失敗が原因です。Homerのコールフローには、re-INVITEとエラーレスポンスが表示されます——通常は 403 Forbidden または 488 Not Acceptable Here です。リモートエンドがre-INVITEをサポートしていないか、リフレッシュSDPでコーデックの不一致が発生しているかのいずれかです。
営業時間中の音声途切れ
ピークトラフィックと相関する高ジッターはネットワーク輻輳が原因です。HomerからRTP統計をエクスポートし、ジッターの時系列グラフを作成して相関を確認してください。その後、QoS設定を見直しましょう——VoIPのRTPトラフィックは、バルクデータトラフィックとは別に優先キュー（DSCP EF / CS5）に配置する必要があります。
登録の失敗
Homerで from_user または認証ユーザー名を検索し、REGISTERシーケンスを確認します。正常なフローは REGISTER → 401 Unauthorized（サーバーがチャレンジを送信）→ 認証情報付きREGISTER → 200 OK です。200 OK なしで 401 レスポンスが繰り返される場合、クライアント設定のSIPパスワードまたはレルムが誤っています。
本番環境でのHomerのオーバーヘッドは極めて低いです——同時通話50件を処理するFreeSWITCHインスタンスで追加CPU使用率は1%未満です。HEPパケットはSIPテキストのみを運び、RTP音声は含まないため、ネットワークコストも最小限です。高負荷なクラスターで実測すると、HEPトラフィックは約2〜3 MB/時間でした。過去30日間の任意の通話を1分以内に呼び出せるようになることへの対価として、それは十分な価格です。
