[FEATURE REQUEST] Adaptive Jitter Buffer
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 10/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- audio-video-rtc
Research direction
The request is for an adaptive jitter buffer that shrinks when no jitter is detected and grows up to roughly 300 ms under jitter, replacing the current static configuration. The payload names no files, tests or entry points, so the first step is to locate the existing static jitter buffer option in the rtpengine configuration and its documentation, then read the two comments on the issue to see whether maintainers already answered the scope question. Done would mean an agreed design for adaptive sizing plus configuration to enable it; the thread has been silent for months, so confirm interest before starting.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe
No response
Describe the solution you'd like
Hi team -
Is there scope for having an adaptive jitter buffer as a future release?
We currently use your static jitter buffer configuration, but finding it hard to reach a middle ground on the value to set for static, either adding an unnecessary delay for connections with no jitter or not catering for extreme edge cases of jitter.
We have used solutions in the past enabling adaptative configurations , and have used with great success with the adaptive logic shrinking the buffer size when no jitter variables detected and growing in size to accommodate large jitter variables up to 300 ms, thus increasing perceived call quality on the platform even when the connecting networks upstream is sub-par.
Is such a solution in scope for a future release?
Thank you
Describe alternatives you've considered
No response
The rtpengine version you checked that didn't have the feature you are asking for
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
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 3 days
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 3 days
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 15/100
sipwise/rtpengine#2197 · 1 comment ·
Maintainers usually reply within 3 days
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
sipwise/rtpengine#2190 · 1 comment ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sipwise/rtpengine#2181 · 4 comments ·
Maintainers usually reply within 3 days
All issues in sipwise/rtpengine
Similar issues
-
documentation Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 93/100
Maintainers usually reply within 1 day
-
Proposed Text EditsOpen
Difficulty 1/5 Under an hour Newbie friendliness 82/100
curl/everything-curl#658 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
PDLPorters/pdl#561 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
objectionary/eolang.sty#197 ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
radiator-software/p5-net-ssleay#577 ·
Maintainers usually reply within 1 day