New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3098 link

Starred by 38 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Implement PeerConnection.onicecandidateerror

Reported by, Mar 24 2014

Issue description

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, Mar 25 2014

@justin, please help to evaluate this!
Project Member

Comment 2 by, Mar 25 2014

This should be discussed on the list.

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

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, 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:

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, 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, 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
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, 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, Dec 16 2014

Labels: Area-PeerConnection
Project Member

Comment 13 by, Jan 6 2015

Labels: EngTriaged mstone-42
Status: Assigned
Project Member

Comment 14 by, 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, Jan 30 2016

Labels: -Mstone-44
Summary: Implement PeerConnection.onicecandidateerror (was: TURN server event listener)
Project Member

Comment 16 by, Nov 8 2016

Labels: Pri-3

Sign in to add a comment