Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unclear result of stats filtering by sender/receiver. #571

Open
murillo128 opened this issue Feb 3, 2020 · 4 comments
Open

Unclear result of stats filtering by sender/receiver. #571

murillo128 opened this issue Feb 3, 2020 · 4 comments
Assignees

Comments

@murillo128
Copy link

When filtering by sender or receiver, the stats selection algorithm is as follows:

- If selector is an RTCRtpSender, gather stats for and add the following objects to result:
  * All RTCOutboundRTPStreamStats objects representing RTP streams being sent by selector.
  * All stats objects referenced directly or indirectly by the RTCOutboundRTPStreamStats objects added.
- If selector is an RTCRtpReceiver, gather stats for and add the following objects to result: 
  * All RTCInboundRTPStreamStats objects representing RTP streams being received by selector.
  * All stats objects referenced directly or indirectly by the RTCInboundRTPStreamStats added.

but in no place it is defined which are the stats objects referenced directly or indirectly.

I understand that the intention was to leave it open so the webrtc stats define those stats, but currently it is defined nowhere which would lead to not deterministic implementation on browsers.

@jan-ivar
Copy link
Member

jan-ivar commented Feb 3, 2020

The language is a catch-all to ensure all referenced stats objects are included, so we don't have to update this in two specs.

We could probably update "referenced" to "referenced", except that section is non-normative for some reason.

@murillo128
Copy link
Author

I think we should move the filtering algorithm to the stats doc, that way we can explicitly specify which stats are returned and avoid updating two specs.

@jan-ivar
Copy link
Member

jan-ivar commented Feb 4, 2020

A problem with an explicit list in webrtc-stats is that not all of webrtc-stats is Mandatory to Implement in WebRTC 1.0. So the total list will vary based on which stats above that baseline are implemented. A rule seems more flexible than a list here (for every stat above that baseline, be sure to include everything it references).

The invariant sought is for every xxxId key encountered, stats.get(stat.xxxId) must succeed.

That seems like a referential integrity test we could do from webrtc-pc even without domain knowledge of individual stats.

@murillo128
Copy link
Author

Form a developer point of view it is unfortunate to have a different set of stats in each browser, but it is what it is.

Having a rule at least would allow know what to look for, i think that the referenced stat id would work

@alvestrand alvestrand transferred this issue from w3c/webrtc-pc Apr 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants