Use receiver report stats for loss/rtt/jitter. #1781
Merged
Conversation
This file contains 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
Reversing a bit of #1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later.
davidzhao
approved these changes
Jun 9, 2023
hautvfami
pushed a commit
to Stark-Industries-Ltd/livekit
that referenced
this pull request
Jul 21, 2023
* Use receiver report stats for loss/rtt/jitter. Reversing a bit of livekit#1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later. * return available streams * fix test
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.
Reversing a bit of #1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter.
So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not received, packets sent/bytes sent will not be reported to analytics.
An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data.
(NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening)
One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later.