SDES: new crypto key in re-INVITE answer (hold) but ROC/SSRC kept -> one-way audio after resume

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

Maintainers usually reply within 2 days

@matteocanevari94-dot is already working on this.

Since Nov 4, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
perl
Domain
audio-video-rtc, security

Research direction

Start by tracing how rtpengine handles SDES keys and SRTP index/ROC state during a re-INVITE that puts a call on hold, then compare that path with the endpoint-change reset described in #1277. Use the supplied SIP, ng, and RTP captures to confirm whether the answer's new key is paired with the existing ROC. Done means the resumed phone can authenticate incoming audio after the sequence number has wrapped.

Written by the indexing model from the issue text.

Description

bug
rtpengine version the issue has been seen with

11.2.2.0 git-mr11.2-db152948

Used distribution and its version

Ubuntu 24.04.5 LTS (container image of NethVoice proxy on NethServer 8), host Rocky Linux 9.8

Linux kernel version used

5.14.0-687.31.1.el9_8.x86_64

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

x86_64

Expected behaviour you didn't see

On a re-INVITE (hold) where nothing changed on the phone side, either:

  • rtpengine keeps the same SDES key in the answer to the phone, or
  • if it sends a new key, it starts a fresh SRTP context towards the phone (index/ROC reset or new SSRC), since the phone will create a new crypto context for the new key.

Audio towards the phone should keep working after resume.

Unexpected behaviour you saw

Setup: rtpengine driven by Kamailio with rtpengine_manage() (NethVoice proxy on NethServer 8, we can't upgrade rtpengine independently). Phones use SDES-SRTP (RTP/SAVP) towards rtpengine. No SDES-* flags in the options. Seen on 3 different phones (Fanvil X5 two hw/fw versions, Yealink DECT).

  1. When the phone puts the call on hold (re-INVITE sendonly), the answer to the phone contains a NEW a=crypto key. The phone keeps its own key. Happens on every hold, on every call.
  2. rtpengine keeps sending to the phone with the same SSRC and the same sequence/index as before.
  3. If the seq towards the phone already wrapped past 65535 before the hold (ROC = 1), after resume packets are encrypted with the new key but still with ROC 1. The phone starts the new context at ROC 0 and fails auth on everything -> phone hears nothing, the other side still hears the phone.
  4. If the wrap didn't happen yet (ROC 0) everything works, so it looks random. At 50 pps the wrap always happens within about 22 minutes.

In the other direction the phone starts a new SSRC with ROC 0 on every resume and rtpengine accepts it fine.

Steps to reproduce the problem
  1. Incoming call to a phone using SDES-SRTP via rtpengine.
  2. Keep the call up until the RTP seq towards the phone wraps past 65535 (max ~22 min at 50 pps; can be computed from the initial seq).
  3. Put the call on hold from the phone, then resume.
  4. The phone hears nothing from now on.

Reproduced twice: once on a production call (hold ~17 s after the wrap) and once in a lab test (wrap at ~16 min, hold and resume a few minutes later -> phone muted).

Additional program output to the terminal or logs illustrating the issue
SRTP auth tag recomputed on captured packets rtpengine -> phone, keys taken from the ng control channel (keys not shown here):

before wrap            : original key + ROC 0  -> valid
after wrap             : original key + ROC 1  -> valid
hold re-INVITE answer  : rtpengine sends a new a=crypto key to the phone
after resume           : new key + ROC 1       -> valid (same SSRC)
                         new key + ROC 0       -> no packet valid  (what the phone uses)
Anything else?

Related: #1277 (ROC desync on hold/unhold, fixed by resetting the index on endpoint change - here the endpoint doesn't change, rtpengine changes its own key) and #71.

Questions:

  1. Is it intended that rtpengine generates a new SDES key in the answer to a re-INVITE when nothing changed on the phone side?
  2. If the outgoing key changes, shouldn't the index/ROC be reset (or a new SSRC used)?
  3. Is SDES-static the recommended workaround, and are there downsides?
  4. Was anything in this area changed after mr11.2?

We have SIP + ng + RTP captures and can share sanitized extracts if useful.

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.