`--timeout` closes a held (sendonly/recvonly) call after 60 s; docs say a call is removed only when all streams go dead

Cerrado
  • ¿Algo no está bien?
#2,230 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
57/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c
Área
backend

Línea de trabajo

The report points to docs/rtpengine.md lines 273–285 and call_timer_iterator() in daemon/call.c lines 219–239; read the timeout logic and commit 750f0a88 to establish the intended behavior. Clarify the --timeout and --silent-timeout documentation to match that behavior. Done when the docs explain how muted streams and sendonly streams affect call lifetime.

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

Descripción

rtpengine version the issue has been seen with

mr26.3.1.2 (3a3ef61), built from the tag, userspace only. The same logic is on master at f950a9f.

Used distribution and its version

Debian 13 (container)

Linux kernel version used

6.8.0-90-generic (kernel module not used)

CPU architecture issue was seen on

aarch64

Expected behaviour you didn't see

docs/rtpengine.md (L273-L285) says two things:

  • a call is removed when all of its media streams go dead;
  • --silent-timeout applies to muted or inactive streams.

Hold is usually an offer with a=sendonly and an answer with a=recvonly. The answerer's
streams are muted, so by the docs they should be dead only after --silent-timeout. A held
call should therefore stay until then, just like a call held with a=inactive.

Unexpected behaviour you saw

If the holding side sends no RTP or RTCP (no hold music), the call is closed after
--timeout, the same as a fully silent sendrecv call. A held call with a=inactive on both
sides is kept.

In call_timer_iterator():

  • the sendonly side's streams count as receive streams, so recv_checked is set;
  • the recvonly side's silent_good result is then never used
    (daemon/call.c#L219-L239).

The media RECV flag comes from the party's own SDP direction
(daemon/call.c#L3959-L3963).

The message of commit 750f0a88 ("improve timeout handling") describes this as intended:
"only consider the silent-timeout for calls that have no receive streams at all". If so, only
the documentation is out of date.

Steps to reproduce the problem

  1. Start rtpengine:

    rtpengine --foreground --log-stderr --table=-1 --interface=127.0.0.1 --listen-ng=127.0.0.1:2223 --timeout=60 --silent-timeout=3600 --port-min=30000 --port-max=30100

  2. Over NG, create four calls with one PCMU m=audio line each. Nobody sends RTP or RTCP.

    Call-ID Offer Answer
    sendonly-recvonly a=sendonly a=recvonly
    inactive-inactive a=inactive a=inactive
    sendrecv-sendrecv a=sendrecv a=sendrecv
    hold-reoffer a=sendrecv, then a re-offer with the same tags and a=sendonly a=sendrecv, then a re-answer with a=recvonly

  3. Send query for each call at +30, +55, +70 and +100 s.

Additional program output to the terminal or logs illustrating the issue

t=+55s  all four calls: ok
t=+70s  sendonly-recvonly: error Unknown call-id
t=+70s  inactive-inactive: ok
t=+70s  sendrecv-sendrecv: error Unknown call-id
t=+70s  hold-reoffer: error Unknown call-id
t=+100s inactive-inactive: ok (the other three still unknown)

INFO: [hold-reoffer]: [core] Closing call due to timeout
INFO: [sendrecv-sendrecv]: [core] Closing call due to timeout
INFO: [sendonly-recvonly]: [core] Closing call due to timeout

Anything else?

If the behaviour is intended, the --timeout/--silent-timeout text could say so:

  • muted streams only keep a call alive when it has no stream that is expected to send;
  • a sendonly party therefore has to send RTP or RTCP within --timeout.

If it is not intended, the recvonly side's silent_good result could also be considered while
the sendonly side is silent.

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.