Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#1,812 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Domain
audio-video-rtc

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Perl
Stars
992
Forks
459
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipwise/rtpengine

All issues in sipwise/rtpengine

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.