Create easy to understand reports

[nitedani]

I have a few suggestions:
I think it would be nice if the observer service processed the incoming stats, did some calculations and output results that are understandable for developers who are not webrtc experts. Right now all I see that the results of pc.getStats() are dumped to S3, but I can't make sense of them. I'm not a webrtc expert. I don't know which stats are the most important to watch out for when the customer reports a connection issue. I don't know how to write the calculations / what to calculate / how to process those dumped files. I think it would be a nice feature of the project to provide information about the calls in simple terms like:

average participant video publication bitrate during the call
participant video publication dropped frames during the call
average frame/sec during the call
minimum frame/sec during the call
how many times was the connection dropped during the call, what the cause is
maximum latency during the call
minimum latency during the call
average latency during the call

These might be completely wrong metrics to watch out for, but you get the idea.

[balazskreith]

Thank you very much for your feedback.

We need to distinguish some component in the pipeline.
the client-side collect measurements send to the observer. The client responsibility is to getStats and make a Sample, send it preferably with a low bandwidth usage (recommended to use protobuf for that).

The observer responsibility is to accept measurements from all clients, embed different stats to reports extend it with additional information, like which call they are in, who is connected to whom, when things happened, so on.

This is the base responsibility of the observer now we need to add some additional but taken into a consideration of what should be processed on-the-fly by streaming and what should be processed by, for example a react app or whatever querying the and analyzing the reports. Keep in mind Observer generate Reports.

Custom Reports what you suggested should be embedded to ObserverErventReport, and should be turned on/off through configuration.

Currently I am working on to finalize the version 1.0.0, and testing the horizontal scalability of the service fixing any error I see. It should be ready in the coming 1-2 weeks, after that this report can be added as a feature, or if you wish you can add it by yourself I can guide you where.

Alternatively the stats can be saved to S3 in a manner to be queried like all stats for a certain call and a simple script calculate what you want.