SRTP decryption failed after client seq wrap on transcoded WebRTC call (mr26.2.1.2)

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

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

  • #2221 de @armanbahlakeh-ct — cerrado sin fusionar

Evaluación

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

Línea de trabajo

Start by examining the attached SRTP debug log around the sequence number wrap at 10:34:37.6 and compare the ROC values with the packet summary for the same interval. Then trace the SRTP decryption and rollover counter handling in rtpengine's userspace forwarding path; the issue names no source files or tests. Done means reproducing the decryption failure under uplink packet loss and identifying why the stream stops forwarding after the wrap.

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

Descripción

rtpengine version the issue has been seen with

26.2.1.2+0~mr26.2.1.2 (also seen on mr26.2.1.1)

Used distribution and its version

Debian GNU/Linux 12 (bookworm)

Linux kernel version used

6.12.95+deb12-cloud-amd64

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

x86_64

Expected behaviour you didn't see

Audio from a WebRTC client keeps being decrypted and forwarded for the whole call.

Unexpected behaviour you saw

On transcoded calls between a WebRTC client (DTLS-SRTP AEAD_AES_256_GCM, opus) and a plain RTP peer (PCMU), rtpengine at some point starts logging Discarded SRTP packet: decryption failed for the client's stream and stops forwarding that direction until the call ends. The client keeps sending on the same 5-tuple; the other direction keeps working.

In our tests it happens in the same second the client's RTP sequence number wraps from 65535 to 0, and only when the client's uplink has some packet loss. With srtp debug enabled, the ROC logged for the client's SSRC rises during the call before the client has wrapped. We did not see this on mr14.1.1.20.

We'd appreciate any help understanding what is happening here, or whether something in our setup could cause it.

Steps to reproduce the problem
  1. WebRTC client (Chrome) <-> rtpengine <-> plain RTP peer. Flags on the WebRTC side:
    replace-origin rtcp-mux-accept rtcp-mux-offer ICE=force RTP/SAVPF SDES-off codec-strip-all codec-transcode-opus codec-transcode-PCMA codec-transcode-PCMU asymmetric-codecs always-transcode loop-protect
    Plain RTP side: ICE=remove RTP/AVP always-transcode asymmetric-codecs
  2. Add about 2% random packet loss on the client's uplink.
  3. Keep the call up until the client's sequence number wraps (11 to 22 minutes in, depending on the start sequence).

It happened on every attempt with packet loss.

Additional program output to the terminal or logs illustrating the issue

Attached (IPs masked, SRTP keys and payloads removed):

  • rtpengine.conf.txt: the config.
  • rtpengine-run3-srtp-debug.log: the call with srtp loglevel 7. Client SSRC 28930993. Its sequence number wraps at 10:34:37.6, and the first decryption failed is logged at 10:34:37.670.
  • rtpengine-run3-pcap-summary.txt: a packet count per second and per direction from a pcap on the rtpengine host, plus backward sequence steps in the stream rtpengine sends to the plain RTP peer.
Anything else?

Userspace forwarding only (no kernel module). The full pcap is available 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.