- From: Dennis Boldt via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Aug 2018 14:09:33 +0000
- To: public-webrtc-logs@w3.org
> Users should typically not interfere with this, and merely forward candidates opaquely.
I totally agree.
> Once browsers fix their bugs, onicecandidate will automatically emit the end-of-candidate candidate as a signal to the other side
So, how should/will the events on `onicecandidates` finally look like? Will an empty candidate be fired? The note in the spec says:
> The null candidate event is fired to ensure legacy compatibility. New code should monitor the gathering state of RTCIceTransport and/or RTCPeerConnection.
>From a users perspective, I don't want to monitor the states and detect the end of the geathering and send a "proprietary" end-of-candidates. I just want to signal the candidates fired by `onicecandidate`, where the last one signals the end. Thus, I expect as `onicecandidate` events:
- `{candidate: '...'}` (non empty string)
- ...
- `{candidate: '...'}` (non empty string)
- `''` (empty string as end-of-candidate / gathering is finshed)
Thus I can feed them 1:1 into `addIceCandidate()`:
- Fire `addIceCandidate({candidate: '...'})` (non empty string)
- ...
- Fire `addIceCandidate({candidate: '...'})` (non empty string)
- Fire `addIceCandidate('')` (corresponds to my example 1)
--
GitHub Notification of comment by boldt
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1952#issuecomment-414329319 using your GitHub account
Received on Monday, 20 August 2018 14:09:34 UTC