Unbounded per-SSRC RTCP statistics history causes linear memory growth
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c
- Domain
- performance
Research direction
Read ssrc_receiver_report() in daemon/ssrc.c: it allocates an ssrc_stats_block (L411-418) and appends it to other_e->stats_blocks after only rejecting samples under a second apart (L433-445), and the list is freed only when the SSRC entry is destroyed (L51-58); master repeats this near L2453-2472. Decide a bound (sample count or age) and enforce it at append time, keeping the newest entries. Done means RTCP/MOS memory stays flat across a long call; look for existing ssrc/statistics tests before changing the list.
Written by the indexing model from the issue text.
Description
rtpengine version the issue has been seen with
12.5.1.41-1~bpo13+1
Used distribution and its version
trixie/sid
Linux kernel version used
6.6.48-flatcar
CPU architecture issue was seen on (see uname -m)
x86_64
Expected behaviour you didn't see
Memory used for RTCP/MOS statistics should remain bounded independently of call duration
Unexpected behaviour you saw
For every accepted RTCP Receiver Report, ssrc_receiver_report() allocates an ssrc_stats_block and appends it to other_e->stats_blocks.
The implementation:
- allocates and populates the statistics record
- only rejects samples received less than one second apart, then appends without a count or age limit
- clears the queue only when the SSRC entry is destroyed
The same unbounded append is still present on master
--final-timeout=SECS provides an indirect bound by deleting the call after a fixed time regardless of continuing RTP/RTCP, which also releases the SSRC history.
Steps to reproduce the problem
No response
Additional program output to the terminal or logs illustrating the issue
Anything else?
No response
- Dominant language
- Perl
- Stars
- 992
- Forks
- 459
- PR merge metrics
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sipwise/rtpengine
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
HTTP/WS worker threads spin forever in `__websocket_write_done()` (`sched_yield` loop) — 100% CPU with `--listen-http`Possibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 15/100
sipwise/rtpengine#2197 · 1 comment ·
Maintainers usually reply within 2 days
-
Kernel NULL pointer dereference in target_put() during target deletionPossibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
sipwise/rtpengine#2190 · 1 comment ·
Maintainers usually reply within 2 days
-
Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sipwise/rtpengine#2181 · 4 comments ·
Maintainers usually reply within 2 days
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 45/100
sipwise/rtpengine#2162 · 1 comment ·
Maintainers usually reply within 2 days
All issues in sipwise/rtpengine
Similar issues
-
Add .gitattributes so share/skel keeps LF on a Windows git checkoutPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
PerlDancer/Dancer2#1854 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
major/MySQLTuner-perl#1007 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bioconda/bioconda-recipes#70187 ·
Maintainers usually reply within 2 days