- From: Cullen Jennings <fluffy@cisco.com>
- Date: Mon, 13 Feb 2012 08:43:35 -0700
- To: public-webrtc@w3.org
On Feb 10, 2012, at 1:45 PM, Timothy B. Terriberry wrote: > Dominique Hazael-Massieux wrote: >> Hi, >> >> That question may become irrelevant if we adapt a JSEP-based proposal, >> but I'm curious as to why the current PeerConnection interface exposes >> iceState and sdpState — it's not obvious to me what use cases makes it >> useful for the application to know state of the SDP and ICE agents to >> that level (in the current approach). > > The primary use I see is helping the webapp developer debug their application (i.e., "It got this far before it broke" or "It took X ms to complete ICE negotiation"). I agree with Adam that it's not the greatest API for that. We could rely on console error messages instead (which I don't think need to be standardized, but would be harder to access programmatically, e.g., to collect statistics in a live, deployed system), or add a real error reporting mechanism (which is probably a bit of work, though worthwhile). > and not just developers debugging. Imagine you have a deployed applications on an operational service. Someone calls your support desk and says "Voice and video does not work for me". We need the application to be able to find out what happened with the progression. Was it that the TURN server could not be contacted? Did ICE manage to find a connection? Did the DTLS security fail? Did RTP arrive? Once we get some basic idea about what "sunny day" flow is, I think we will need to do a pass on the API to make sure the JS application can get the information it needs about what worked and what failed. You also might need some of this information along these lines to render a user interface that allows the user to know when they are "connected" and can expect to be able to have the far end hear whatever they are saying.
Received on Monday, 13 February 2012 15:44:04 UTC