Justin Uberti
Justin Uberti
Chrome has a decent CoC that we could adopt.
Hi folks, just stumbled across this issue. It's great to see the proposed steps here as these were all things I ran into when implementing support for our multimodal audio...
definitely a good idea, I've wished for this a few times
Do we do this for 401 in fetch/XHR? Seems like it reduces debugging ability and may not be all that effective. Generally, we should understand the threat model here before...
For a too long TURN username, pretty sure setConfig should fail, same as if some other invalid IceServer attribute was supplied.
We already differ from fetch in some ways (e.g., failing immediately in setConfig for an unknown scheme), so I'd prefer a more explicit rationale rather than just 'consistency'.
I could get behind a delineation where missing, unknown, or unparsable data results in an exception (i.e., the current behaviors defined in https://w3c.github.io/webrtc-pc/#set-the-configuration) and values that just exceed some protocol...
I'm guessing we'd want to use onicecandidateerror with error code 701 for this (which seems to be our current generic-error code). https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnectionIceErrorEvent
Right. But that basically means all non-parse-errors necessarily need to be async.
If we put the request on the wire and the server returns an error code, we should just use whatever the server sends back (although @annevk 's comment is worth...