"I want to know daily about minimum, average and maximum in-call latency" => Is it what the NSA calls "metadata"? ;-) As a user, if I don't want you to have this info, do I have an opt-out?

This data won't be related to a specific user ID but should be collected to get an overall view of how the service performs. We have not agreed yet on the mechanism by which the data will be collected but it is possible we'll be using Telemetry, which already exposes a way for users to opt out.

(In reply to Romain Testard [:RT] from comment #2) > This data won't be related to a specific user ID but should be collected to > get an overall view of how the service performs. Ok, good to know, thanks :-) > We have not agreed yet on the mechanism by which the data will be collected > but it is possible we'll be using Telemetry, which already exposes a way for > users to opt out. Why wouldn't it be Telemetry? Telemetry has fairly clear rules about user privacy, etc. Wondering whether choosing Telemetry or not is what triggered my question. Why would you choose something else if you're collecting anonymized performance data? Where is this discussion taking place?

TokBox will provide this for MVP - this bug is kept opened until TokBox provides details on how to access their reporting solution.

we discussed this with the Loop team - and latency and call set up need to be determined on the client side.

I'd love these sooner, but I think we can push this to Fx35.

Hi RT - can you validate what we aren't getting from other folks and then we'll look at this.

TokBox confirmed they only can get us bitrate values so it's not a really good indicator of A/V quality. Technically they can't give us latency data. There is a lot there and I suggest we break it down as in-call latency, call set-up latency and in-call A/V quality are probably all very different areas. I'd like to understand from the team what area is likely to give us the best value for time as it's hard for me to understand what are the technical challenges of delivering these and the type of metrics most likely to be reflective of user issues. A quick look at https://useradvocacy.mozilla.org/dashboards/hello-v1/ tells me 3% of users suffer video issues and 5% suffer audio issues.

revisit after looking for ways to gather simply.

Shell, can you add this to the info we need to gather in Portland for Fx37?

The platform needs to provide the appropriate stats which can then be sent upstream as part of our metrics. Doing a needinfo to myself to gather those stats. This bug likely won't become actionable until Fx38, so moving blocking-loop to Fx38?

To start, we should take the stats that are available and being displayed in about:webrtc such as avg framerate, avg bitrate, loss, jitter, a/v sync, etc. Those are available today to the Loop/Hello code if we want to pass them upstream.

Maire, I understand this will happen soon by leveraging the Telemetry work already in place for platform and bringing the ability to split Hello and non Hello calls on the reports, could you please mark this bug as duplicate of the bug where this work is happening?