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

DTLS rekeying causes calls to lose audio

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
c
Domain
audio-video-rtc, networking

Research direction

Reproduce with a WebRTC-to-Asterisk call and a 2-minute DTLS rekey interval, watching for the res_srtp unprotect failures and the 'DTLS data received after handshake, code: 2' log lines. Read the diff of commit 2f4f6d52738984ab625525ccd18695b46365494c, the change bisected as the cause, and follow how post-handshake DTLS data is handled in the crypto layer. Done means SRTP/SRTCP keep authenticating across a rekey with no audio loss.

Written by the indexing model from the issue text.

Description

We've been using rtpengine 11.2.1.12 with the corresponding kernel module to connect WebRTC calls to Asterisk (16.x and 20.x) via Kamailio (5.7). This setup has been working for quite a while. After an update to basically any newer rtpengine release (we've tried 11.3.1.11 and 11.4.1.3 initially), calls lose audio after exactly 2 minutes, which corresponds to the DTLS rekeying interval specified in our Asterisk PJSIP configuration for those endpoints.

Asterisk logs unprotect errors for both SRTP and SRTCP packets:

VERBOSE[66457][C-00000012] res_srtp.c: SRTP unprotect failed on SSRC 458523204 because of authentication failure 160
VERBOSE[66457][C-00000012] res_srtp.c: SRTCP unprotect failed on SSRC 458523204 because of authentication failure

rtpengine also logs INFO and WARNING level messages:

INFO: [i6qrqdih95obm7i4auob/6eddbd88-a2d6-42bd-83cf-a41c51d78507/1 port 11248]: [crypto] DTLS data received after handshake, code: 2
INFO: [27f810d3-8b40-4464-81b5-f6f43dc62610/3bbc999a-c4ba-493b-bb81-4f719d8b3ead/1 port 10264]: [crypto] DTLS data received after handshake, code: 2
INFO: [i6qrqdih95obm7i4auob/6eddbd88-a2d6-42bd-83cf-a41c51d78507/1 port 11248]: [crypto] DTLS data received after handshake, code: 2
INFO: [27f810d3-8b40-4464-81b5-f6f43dc62610/3bbc999a-c4ba-493b-bb81-4f719d8b3ead/1 port 10264]: [crypto] DTLS data received after handshake, code: 2
INFO: [27f810d3-8b40-4464-81b5-f6f43dc62610/3bbc999a-c4ba-493b-bb81-4f719d8b3ead/1 port 10264]: [crypto] DTLS data received after handshake, code: 2
WARNING: [27f810d3-8b40-4464-81b5-f6f43dc62610/3bbc999a-c4ba-493b-bb81-4f719d8b3ead/1 port 10264]: [rtcp] Discarded invalid SRTCP packet: authentication failed
WARNING: [i6qrqdih95obm7i4auob/6eddbd88-a2d6-42bd-83cf-a41c51d78507/1 port 11248]: [rtcp] Discarded invalid SRTCP packet: authentication failed

With git bisect, we narrowed down the cause to commit 2f4f6d52738984ab625525ccd18695b46365494c. As soon as this commit is reverted, calls no longer lose audio after 2 minutes. Also, disabling DTLS rekeying for the endpoints in Asterisk fixes the issue.

We thus suspect the code added in the mentioned commit does not handle DTLS rekeying correctly.

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.