Split RTCP compound packet before forwarding #359
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (50.00%) is below the target coverage (70.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## master #359 +/- ##
==========================================
- Coverage 82.64% 82.54% -0.11%
==========================================
Files 19 19
Lines 1458 1461 +3
==========================================
+ Hits 1205 1206 +1
- Misses 140 141 +1
- Partials 113 114 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
boks1971
force-pushed
the
raja_srtp_compound
branch
6 times, most recently
from
ff4a028 to
6faec8e
Compare
When a compound RTCP packet is received, it is forwarded as is to the read streams. Downstream components have to check for the SSRC in the packets matching the track(s) it is handling. This leads to situations where downstream components could see duplicate RTCP reports. Happens when there is a downstream handler for all SSRCs. It receives the compound packet, unmarshals it and invokes the handlers. As it is fielding all SSRCs, it will get the same compound packet `n` times and invoke the handlers `n` times. This PR splits up the compound packet and forwards individual packets to avoid the end handlers from seeing duplicates. API wise, it is compatible as it still emits an encoded/marshaled packet. But, this does add a marshaling step. Add an unit test. Before this change, the test fails at the point where the test tries to read the CNAME packet and sees an incorrect type.
boks1971
force-pushed
the
raja_srtp_compound
branch
from
6faec8e to
40818b0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When a compound RTCP packet is received, it is forwarded as is to the read streams. Downstream components have to check for the SSRC in the packets matching the track(s) it is handling.
This leads to situations where downstream components could see duplicate RTCP reports. Happens when there is a downstream handler for all SSRCs. It receives the compound packet, unmarshals it and invokes the handlers. As it is fielding all SSRCs, it will get the same compound packet
ntimes and invoke the handlersntimes.This PR splits up the compound packet and forwards individual packets to avoid the end handlers from seeing duplicates. API wise, it is compatible as it still emits an encoded/marshaled packet. But, this does add a marshaling step.
Add an unit test. Before this change, the test fails at the point where the test tries to read the CNAME packet and sees an incorrect type.