icecandidate_event update the meaning of null candidate about content HOT 7 CLOSED

@bardiharborow OK, thanks for the heads up. I'll reopen this and move it to our current content repo.

from content.

the recommendation to only signal non-null candidates is a pretty old one (2013?) which predates the icegatheringstatechange event. You should actually signal when you have gathered all candidates so the other side knows.

"Indicating the end of a generation of candidates" says that events where event.candidate == "" should be delivered,

This part actually works as intended since that candidate has event.candidate set to {candidate: "", sdpMid: ...}
Tagging @docfaraday who knows most about that end-of-candidates candidate but I might take this one

from content.

Yeah, the meaning of a null candidate changed a while back and the document clearly has not fully caught up. That needs to be cleared up. And yes, the references to RTCPeerIceCanddiateEvent are wrong and should be RTCPeerConnectionIceEvent.

from content.

@chrisdavidmills the main issue here doesn't appear to have been resolved, though the incorrect reference to RTCPeerIceCanddiateEvent seems to be gone.

from content.

To whoever fixes this issue, it looks like the following is needed:

• Check the meaning of null candidate and update examples accordingly
• Update any text to reflect changes

from content.

@dontcallmedom This seems like something that a contributor with WebRTC domain knowledge could make short work of. Do you think there’s any chance we could rope in somebody to take a look at it?

from content.

@danjenkins would you happen to be able to help with the above issue?

from content.