Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

rtpengine-recording: recording occasionally not produced (no output file, no notify) — intermittent, ~1 in 10–15 calls

Abierto
  • ¿Algo no está bien?
#2,136 7 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
c, debian, linux
Área
audio-video-rtc, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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-uri HTTP 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

  1. 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.
  2. Ruled out notify-purge deleting the file after a successful notify — notify-purge is disabled in our config, so it cannot be responsible for the missing file.
  3. Ruled out filesystem permissions — both rtpengine-recording and our consuming application run as root, so standard ownership/permission mismatches are not a factor.
  4. Still to confirm (would appreciate guidance on where to look): whether the core rtpengine daemon is writing the initial spool-dir pcap/metadata file for the affected calls at all (Stage 1), versus the spool file existing but rtpengine-recording failing 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-uri HTTP 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
Lenguaje dominante
Perl
Estrellas
992
Forks
459
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sipwise/rtpengine

Todos los issues de sipwise/rtpengine

Issues similares

Más issues de Perl

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.