New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 31 users
Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
Implement PeerConnection.onicecandidateerror
Reported by cow...@bbs.darktech.org, Mar 24 2014 Back to list
We need an event listener that notifies of events related to connecting to a TURN server. I'm expecting the following events:

1. Establishing connection.
2. Connection established.
3. Connection failed due to authentication failure.
4. Connection failed due to timeout.

#3 indicates a programming error. #4 could indicate the client's firewall is blocking the connection (I've run into this case multiple times myself). Without being able to differentiate between the two, we very often have clients blaming us for what is essentially a problem on their end.
 
Project Member Comment 1 by braveyao@webrtc.org, Mar 25 2014
Cc: mallinath@webrtc.org braveyao@webrtc.org
Owner: juberti@webrtc.org
@justin, please help to evaluate this!
Project Member Comment 2 by juberti@webrtc.org, Mar 25 2014
This should be discussed on the webrtc@w3.org list.
Justin,

I remembered discussing this on the list but couldn't find the associated bug report. I just checked again and found:

http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0151.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23920

How do feature requests walk their way from the mailing list, to W3C bug system, to this system? In other words, do we have to wait for this to get added to the specification before filing bugs on this issue tracker?
Project Member Comment 4 by juberti@webrtc.org, Mar 25 2014
What we need now is a proposal for how this should work.

maybe something like pc.ongathererror(server, error)
That would address the second half of the request, but we'd still need a callback for successfully connecting to a TURN server.

How about: pc.addGatheringServer(server, gatheringListener), where gatheringListener contians:

onConnecting(server)
onConnected(server)
onFailure(server, reason)

This has the added benefit of being able to register servers outside of the SDP. Existing servers would simply register the listener. If the server does not exist, it would get added.
Project Member Comment 6 by juberti@webrtc.org, Mar 25 2014
I don't think connecting/connected makes much sense; the only thing we should care about is whether allocation failed (or possibly, succeeded). Is the candidate callback not sufficient for the success case?

Not sure why we would need a separate listener for each server, if the server is passed in the callback.

Is it possible to successfully connect to a TURN server but get back an empty result? If so, that case would not be covered by the candidate callback.

Also, I assume that you disconnect and reconnect to the TURN server at some point (when the connection is renegotiated)? If so, how do you differentiate between onicecandidate results from a previous and current connection session?
Project Member Comment 8 by juberti@webrtc.org, Mar 25 2014
Re: #7, no. It would be an error for this to occur.

Regarding renegotiation, that would be covered by an IceGatheringState transition back to gathering.
Okay, so your proposal sounds like a possible solution.
Justin: checking connectivity without doing a createOffer-setLocalDescription would be useful as well.
Otherwise people will invent their own ways to achieve that functionality... e.g. with something like https://www.npmjs.org/package/stunturncheck
The technique used is pretty simple, createOffer-setLocalDescription, then wait for end-of-candidates and inspect the SDP for candidate-lines.

That is going to be bad in the long run by creating unnecessary peerconnections as well as NAT bindings.
Project Member Comment 11 by juberti@webrtc.org, Apr 2 2014
I don't see anything wrong with what is described in #10. We can look into separating out ICE gathering from setting up a session in WebRTC 2.0.
Project Member Comment 12 by juberti@webrtc.org, Dec 16 2014
Labels: Area-PeerConnection
Project Member Comment 13 by pthatcher@webrtc.org, Jan 6 2015
Labels: EngTriaged mstone-42
Status: Assigned
Project Member Comment 14 by pthatcher@webrtc.org, Feb 19 2015
Labels: -mstone-42 Mstone-44
This looks like it's not going to make it in M42.  Please update it if I'm wrong.
Project Member Comment 15 by juberti@webrtc.org, Jan 30 2016
Cc: -mallinath@webrtc.org juberti@webrtc.org
Labels: -Mstone-44
Owner: pthatcher@webrtc.org
Summary: Implement PeerConnection.onicecandidateerror (was: TURN server event listener)
Project Member Comment 16 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Sign in to add a comment