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

Đã đóng
  • Có gì không ổn?
#2,234 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@matteocanevari94-dot đang làm issue này rồi.

Từ ngày 4/11/2026.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
perl
Lĩnh vực
audio-video-rtc, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Perl
Star
992
Fork
459
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sipwise/rtpengine

Tất cả issue của sipwise/rtpengine

Issue tương tự

Thêm issue về Perl

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.