rtpengine-recording: recording occasionally not produced (no output file, no notify) — intermittent, ~1 in 10–15 calls
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 15/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- c, debian, linux
調査の方向性
The payload names no source files; start by grepping both daemons' logs by Call-ID for a failed call and check whether core rtpengine wrote the spool-dir pcap/metadata file (Stage 1) or whether rtpengine-recording failed during decode/finalize (Stage 2). Compare a successful and a failed call's spool-dir contents and rtpengine-recording.conf settings (output-dir, notify-uri, log-level). Done means the failing stage and root cause are identified and the pipeline either produces output plus notify or logs a clear actionable error.
索引モデルが issue の本文から書いたものです。
説明
Description
We're running a two-daemon call recording setup (core rtpengine + rtpengine-recording) in production, using kernelized packet export (recording-method = proc) triggered per-call via the record call: yes ng protocol flag from our SBC application on a mid-call re-INVITE.
Intermittently — roughly 1 in every 10–15 recorded calls — the recording pipeline fails to produce a usable result:
- No final output file appears in
output-dir. - No
notify-uriHTTP notification is ever received by our webhook endpoint. - The affected calls are otherwise entirely normal: they connect, run for a normal duration, and terminate cleanly with a standard BYE. There is nothing unusual in the SIP signaling for the affected calls that we've been able to identify.
- This is not reproducible on demand. It happens sporadically under normal production load.
Steps we've taken to isolate the cause so far
- Ruled out our own webhook handler as the sole cause — added logging immediately on request receipt (before any other processing) to confirm whether a notify request lands at all. For the affected calls, no request arrives at our endpoint — so this is not a case of our handler failing to respond in time or erroring silently.
- Ruled out
notify-purgedeleting the file after a successful notify —notify-purgeis disabled in our config, so it cannot be responsible for the missing file. - Ruled out filesystem permissions — both
rtpengine-recordingand our consuming application run asroot, so standard ownership/permission mismatches are not a factor. - Still to confirm (would appreciate guidance on where to look): whether the core
rtpenginedaemon is writing the initial spool-dir pcap/metadata file for the affected calls at all (Stage 1), versus the spool file existing butrtpengine-recordingfailing during decode/finalize (Stage 2). We plan to grep both daemons' logs by Call-ID the next time this reproduces and will attach the pcap + metadata for an affected call once captured.
Expected behavior
Every call for which record call: yes is successfully acknowledged by rtpengine (response.result === 'ok') should reliably result in either:
- a completed output file plus a corresponding
notify-uriHTTP notification, or - a clearly logged failure (decode error, resample error, storage error, etc.) that we can act on.
Actual behavior
For an intermittent subset of calls, neither occurs — no file, no notification, and (so far) no clearly attributable error logged at our default log level.
Environment
| Field | Value |
|---|---|
| rtpengine version | 13.1.0.0+0~mr13.1.0.0 git-HEAD-f3aa776b (confirmed identical for both rtpengine and rtpengine-recording) |
| Distribution | Debian GNU/Linux 10 (buster) |
| Linux kernel version | 5.10.0-0.deb10.16-cloud-amd64 |
| CPU architecture | x86_64 |
| Recording method | proc (kernelized, xt_RTPENGINE kernel module) |
| Deployment | core rtpengine and rtpengine-recording on separate hosts (SBC host vs. recording-engine host) |
Configuration files
Attached: rtpengine.conf and rtpengine-recording.conf (full files as currently deployed in production).
Key options for reference:
rtpengine.conf ([rtpengine] section):
recording-dir = /var/spool/rtpengine
recording-method = proc
recording-file-per-stream = false
recording-all = false
rtpengine-recording.conf:
output-storage = file
output-format = wav
spool-dir = /var/spool/rtpengine
output-dir = /root/apps/sbc-recorder-server/recordings
resample-to = 8000
log-level = 6
output-mixed = true
flush-packets = true
notify-uri = https://<redacted>/recordings/recording-completed
notify-post = true
- 主要言語
- Perl
- スター
- 992
- フォーク
- 459
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sipwise/rtpengine のほかの issue
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
メンテナーはふだん 2 日以内に返信
-
HTTP/WS worker threads spin forever in `__websocket_write_done()` (`sched_yield` loop) — 100% CPU with `--listen-http`対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug
難易度 4/5 3〜5日 初心者へのやさしさ 15/100
sipwise/rtpengine#2197 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
Kernel NULL pointer dereference in target_put() during target deletion対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
sipwise/rtpengine#2190 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
sipwise/rtpengine#2181 · コメント 4 件 ·
メンテナーはふだん 2 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
sipwise/rtpengine#2162 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
sipwise/rtpengine の issue をすべて見る
似ている issue
-
Add .gitattributes so share/skel keeps LF on a Windows git checkout対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
PerlDancer/Dancer2#1854 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
major/MySQLTuner-perl#1007 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 69/100
bioconda/bioconda-recipes#70187 ·
メンテナーはふだん 2 日以内に返信