SDES: new crypto key in re-INVITE answer (hold) but ROC/SSRC kept -> one-way audio after resume

Abierto
  • ¿Algo no está bien?
#2,234 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@matteocanevari94-dot ya está trabajando en esto.

Desde el 4/11/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
perl
Área
audio-video-rtc, security

Línea de trabajo

Start by tracing how rtpengine handles SDES keys and SRTP index/ROC state during a re-INVITE that puts a call on hold, then compare that path with the endpoint-change reset described in #1277. Use the supplied SIP, ng, and RTP captures to confirm whether the answer's new key is paired with the existing ROC. Done means the resumed phone can authenticate incoming audio after the sequence number has wrapped.

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

Descripción

bug
rtpengine version the issue has been seen with

11.2.2.0 git-mr11.2-db152948

Used distribution and its version

Ubuntu 24.04.5 LTS (container image of NethVoice proxy on NethServer 8), host Rocky Linux 9.8

Linux kernel version used

5.14.0-687.31.1.el9_8.x86_64

CPU architecture issue was seen on (see uname -m)

x86_64

Expected behaviour you didn't see

On a re-INVITE (hold) where nothing changed on the phone side, either:

  • rtpengine keeps the same SDES key in the answer to the phone, or
  • if it sends a new key, it starts a fresh SRTP context towards the phone (index/ROC reset or new SSRC), since the phone will create a new crypto context for the new key.

Audio towards the phone should keep working after resume.

Unexpected behaviour you saw

Setup: rtpengine driven by Kamailio with rtpengine_manage() (NethVoice proxy on NethServer 8, we can't upgrade rtpengine independently). Phones use SDES-SRTP (RTP/SAVP) towards rtpengine. No SDES-* flags in the options. Seen on 3 different phones (Fanvil X5 two hw/fw versions, Yealink DECT).

  1. When the phone puts the call on hold (re-INVITE sendonly), the answer to the phone contains a NEW a=crypto key. The phone keeps its own key. Happens on every hold, on every call.
  2. rtpengine keeps sending to the phone with the same SSRC and the same sequence/index as before.
  3. If the seq towards the phone already wrapped past 65535 before the hold (ROC = 1), after resume packets are encrypted with the new key but still with ROC 1. The phone starts the new context at ROC 0 and fails auth on everything -> phone hears nothing, the other side still hears the phone.
  4. If the wrap didn't happen yet (ROC 0) everything works, so it looks random. At 50 pps the wrap always happens within about 22 minutes.

In the other direction the phone starts a new SSRC with ROC 0 on every resume and rtpengine accepts it fine.

Steps to reproduce the problem
  1. Incoming call to a phone using SDES-SRTP via rtpengine.
  2. Keep the call up until the RTP seq towards the phone wraps past 65535 (max ~22 min at 50 pps; can be computed from the initial seq).
  3. Put the call on hold from the phone, then resume.
  4. The phone hears nothing from now on.

Reproduced twice: once on a production call (hold ~17 s after the wrap) and once in a lab test (wrap at ~16 min, hold and resume a few minutes later -> phone muted).

Additional program output to the terminal or logs illustrating the issue
SRTP auth tag recomputed on captured packets rtpengine -> phone, keys taken from the ng control channel (keys not shown here):

before wrap            : original key + ROC 0  -> valid
after wrap             : original key + ROC 1  -> valid
hold re-INVITE answer  : rtpengine sends a new a=crypto key to the phone
after resume           : new key + ROC 1       -> valid (same SSRC)
                         new key + ROC 0       -> no packet valid  (what the phone uses)
Anything else?

Related: #1277 (ROC desync on hold/unhold, fixed by resetting the index on endpoint change - here the endpoint doesn't change, rtpengine changes its own key) and #71.

Questions:

  1. Is it intended that rtpengine generates a new SDES key in the answer to a re-INVITE when nothing changed on the phone side?
  2. If the outgoing key changes, shouldn't the index/ROC be reset (or a new SSRC used)?
  3. Is SDES-static the recommended workaround, and are there downsides?
  4. Was anything in this area changed after mr11.2?

We have SIP + ng + RTP captures and can share sanitized extracts if useful.

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.