W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Recap from WebRTC World

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Wed, 24 Jul 2013 06:08:22 +0000
To: cowwoc <cowwoc@bbs.darktech.org>
CC: "<public-webrtc@w3.org>" <public-webrtc@w3.org>
Message-ID: <DBFF43DE-35D2-4A9C-BB48-0D31B3849E22@ericsson.com>

24 jul 2013 kl. 07:56 skrev "cowwoc" <cowwoc@bbs.darktech.org<mailto:cowwoc@bbs.darktech.org>>:

On 24/07/2013 1:50 AM, Göran Eriksson AP wrote:

  *   Troubleshooting WebRTC: There is a gaping hope when it comes to user-facing diagnostic tools.

Just to make sure I understand Your point- could You elaborate in what You mean and add some concrete proposals? Do You for instance mean the stats API?

Hi Göran,

    Imagine you wrote a production web conferencing app and customers are calling tech support saying "It doesn't work" where do you begin?

    A good starting point is looking at Skype. Skype provides a user-friendly UI that gives a quick overview of potential network, hardware, configuration problems and allows you to drill-down for more information. I am asking for:

  *   A user-facing UI that allows you to drill down from a high to low level.
  *   Make this functionality available through an API so applications can collect this information programmatically and, say, refund a user if a meeting was aborted due to no fault of his own.

    One problem I found very hard to diagnose (in development, not to mention production) is why I was getting smooth video at home but choppy video at a customer's location. Is the bandwidth too low? Is the latency too high? Is the router dropping UDP packets? Is the CPU usage too high (leading WebRTC to drop frames)? Etc... It goes on and on. The stats API dumps a lot of information (too much for me to parse quickly, obviously) but even with all this information it's hard to come up with a conclusive answer to these actions.


Thanks for Your answer. I have the same or similar idea on what trouble shooting needed in a solution. Part of such a solution is the browser UA and the support it gives via the API, including the stats API.

There are other components in solution for a service like Skype, such as stats from network boxes, but those are outside the scope of this WG i think.

Do You agree with me that it sounds as if we should add some bugs/actions with proposals concerning the stats API?

BTW- I assume You have looked at the stats output from Canary?

Received on Wednesday, 24 July 2013 06:08:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:50 UTC