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

davehorton commented 6 months ago

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.

rfuchs commented 6 months ago

There were a few DTMF related fixes done by @tombriden recently, notably in the 11.5 branch. Try the latest version from that branch.

davehorton commented 6 months ago

ok, just to be clear I should test the 11.5 branch rather than the 12.2 branch? I was about to upgrade a bunch of my deployments to 12.2.1.5, bypassing the 11.5 branch now I am wondering if that is not a good idea..

rfuchs commented 6 months ago

ok, just to be clear I should test the 11.5 branch rather than the 12.2 branch? I was about to upgrade a bunch of my deployments to 12.2.1.5, bypassing the 11.5 branch now I am wondering if that is not a good idea..

You can go to 12.2 or 12.3 too, but 11.5 is the latest LTS and will get all the bugfixes, while 12.x has more new features (and possibly bugs). The mentioned DTMF fixes are in 12.2 as well though.

sipwise / rtpengine