Codec / Transcoding information returned by ng query
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- perl
- Domain
- audio-video-rtc
Research direction
Start from the handler that builds the ng query reply in the rtpengine control protocol and see what per-call state is already available there. Codec selection is decided during SDP handling for the A-leg and B-leg media streams, so trace where negotiated codecs and any transcoding decision are recorded on the call. Nothing in the issue names files or tests, so locating those entry points is the first task. Done means the ng query output reports A-leg and B-leg codecs plus a flag for whether transcoding was engaged.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe
When a call is established and the ng query command is ran, we get a lot of useful information about what is happening, however this information about what codecs are being used.
This is particularly important if we want to limit the amount of transcoded calls which are allowed to pass through a system. By being able to know if transcoding was engaged for a specific call we can better help to control the capacity allowed from OpenSIPs/Kamalio, etc.
Describe the solution you'd like
If RTPEngine is aware of what codec's are used the information should be available in the response to the ng query command.
This can include:
- A-leg / B-leg codecs which are used
- Has the call been transcoded
Describe alternatives you've considered
There is no simple feasible solution.
The rtpengine version you checked that didn't have the feature you are asking for
12.1.1
- 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