I get this error DOMException: Error processing ICE candidate when I try to add an ice candidate. Here's the candidate:
candidate:1278028030 1 udp 2122260223 10.0.18.123 62694 typ host generation 0 ufrag eGOGlVCnFLZYKTsc network-id 1
Moreover, it doesn't always happen - other time everything goes smoothly. I can't reproduce a consistent pattern where it would throw this error. Any ideas how to go about solving this / debugging it would be appreciated!
This problem is almost totally undocumented, and to make matters worse only Google seems to be implementing the w3 webRTC standard. They also deviate from this standard.
However, as it is most likely that this will be occurring on Chrome (I have not checked Firefox, and Safari does not implement getUserMedia()), this error message obtained by launching Chrome from the console will likely help:
[ERROR:rtc_peer_connection_handler.cc(1439)] Error processing ICE candidate. [ERROR:webrtcsession.cc(1134)] ProcessIceMessage: ICE candidates can't be added without any remote session description. So there, you can't add ICE candidates without setting remote description as according to the most recent build of Chrome, and as it is 2017 with no webRTC progress except for Facebook Messenger, this looks to be valid for the foreseeable future.
So remember to call
if(!peerConnection || !peerConnection.remoteDescription.type){ //push candidate onto queue... } and after setting the remote description, iterate the queue to add candidates with the peer connection in the right state!
If you're keeping more than one RTCPeerConnection object around, you must make sure you're adding the ICE candidates and descriptions to the correct one.
This may be outdated, but i had the same error,
On Chrome i got DOMException: Error processing ICE candidate,
On Firefox, there was an error that only stated DOMException.
The additional message was: "Invalid candidate (both sdpMid and sdpMLineIndex are null).", and that was exactly the case, i really did not use them from the response i got from the signaling server about the ice candidate.
Using those 2 values when i received the signal stopped this error from happening again.
Hope this helps someone else.
If I make a second round of offer-answer, it works. I'm not sure why this is necessary though.
Are you adding the candidate before calling setRemoteDescription? Firefox 36 had an issue where it sent candidates before the remote description but that has been solved long since.
This error can also occur if you attempt to connected to your own peer (local) id.