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

RFC 2833 issue - tripling of digits due to final 2 payloads getting new timestamp

Abierto
  • ¿Algo no está bien?
#1,812 3 comentarios 0 reacciones 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
28/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Área
audio-video-rtc

Línea de trabajo

The report names no code paths, only pcaps and frame numbers (frame 581 in both). First locate rtpengine's RFC 2833 DTMF relay and timestamp translation logic, then replay rtpengine-input.pcap through the daemon and compare outgoing packet timestamps. The last two end-bit packets getting distinct timestamps while the first ten share one points at the end-of-event timestamp handling; done means all twelve packets for one '1' press carry the same timestamp on output.

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

Descripción

bug
rtpengine version the issue has been seen with

mr11.2.1.2

Used distribution and its version

Debian 11

Linux kernel version used

No response

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

x86_64

Expected behaviour you didn't see

The incoming RTP stream had 12 RFC 2833 packets corresponding to a single digit press (of '1') by the user. The first packet had the marker bit set and the last 3 had the end bit set. They all had the same timestamp (different duration) indicating this was a single dtmf event.

The outgoing stream relayed by rtpengine also had 12 RFC 2833 packets. Again, the final 3 packets had the end bit set, but the last 2 had different timestamps. In other words, the first 10 packets all had the same timestamp but packet 11 had a different timestamp and packet 12 yet a different timestamp.

As a result, the far end system detected that the user had pressed '1' three times instead of once.

Unexpected behaviour you saw

Final 2 RFC payloads have a different timestamp from the others that were part of the same dtmf event

Steps to reproduce the problem

For some reason, this is recreatable against a Genesys sip trunk, but I can see no issues with the rtp that they are sending. I will attach links to the two pcaps (coming into rtpengine, and leaving it below).

Note: we are not using the kernel module.

Additional program output to the terminal or logs illustrating the issue

No response

Anything else?

I am attaching links to two pcaps - one showing the rtp stream coming into rtpengine, and one showing the rtp stream leaving rtp engine.

Notes:

  • rfc 2833 dtmf events start at frame 581 in rtpengine-input.pcap. All 12 packets have the same timestamp of 626536140
  • rfc 2833 dtmf events start at frame 581 in rtpengine-output.pcap. The first 10 packets have the same timestamp of 626536418, the 11th has 626536578, and the 12th has 626536738.
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.