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

クローズ
  • 何か問題がありますか？
#2,234 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@matteocanevari94-dot がすでに取り組んでいます。

2026年11月4日 から。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
perl
領域
audio-video-rtc, security

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Perl
スター
992
フォーク
459
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sipwise/rtpengine のほかの issue

sipwise/rtpengine の issue をすべて見る

似ている issue

Perl の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。