RTCIceCandidateComplete dictionary

[robin-raymond]

Testing for an empty object is not straight forward in JavaScript. It would be easier to add a name / value pairing like this when stringified:

{ "complete": true }

So we should have complete in the RTCIceCandidateComplete dictionary which is mandatory and set to true.

[robin-raymond]

Sample code please (in RTCIceGatherer)...

[juberti]

This seems kind of bizarre, an event with a variable that is only set to a single value.

Can't this be handled entirely through IceGathererStateChange?

[robin-raymond]

We don't really need to generate RTCCandidateComplete at all because we know from the state, but how do we tell the remote RTCIceTransport that "candidates complete" is reached. We currently do that by adding this dictionary to "RTCIceTransport.addRemoteCandidate(candidateComplete)".

[pthatcherg]

Could we add a method that is effectively RTCIceTransport.expectNoMoreCandidates()? That might be more simple.

Perhaps call it "RTCIceTransport.completeRemoteCandidates()"

[robin-raymond]

@pthatcher certainly can be done that way instead (think it's better).

[pthatcherg]

According to http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-addIceCandidate-Promise-void--RTCIceCandidate-candidate

PeerConnection.addIceCandidate(IceCandidate) takes a non-nullable candidate. So going down the "overload addRemoteCandidate" path provides no similarity with WebRTC 1.0. That makes me more convinced we should go with a separate method of "RTCIceTransport.completeRemoteCandidates".

But we should write some sample code to make sure what we're coming up with makes sense.

[robin-raymond]

This same issue existing in WebRTC 1.0 (which does not have a nullable candidate option to addIceCandidate in 1.0); Not sure how 1.0 even does this at all...

[ibc]

how do we tell the remote RTCIceTransport that "candidates complete" is reached. We currently do that by adding this dictionary to "RTCIceTransport.addRemoteCandidate(candidateComplete)".

IMHO that is valid as a network signaling fuideline and should not be defined by the spec. The very same can be achieved as follows:

// Sender:
mySignaling.send('no more candidates');

// Receiver:
mySignaling.on('msg', function(data) {
  if (data === 'no more candidates') {
    iceTransport.completeRemoteCandidates();
  }
}

[aboba]

Currently there is a PR in WebRTC 1.0 to allow the null candidate as an argument to addIceCandidate():
w3c/webrtc-pc#527

It is awkward to have RTCIceCandidateComplete defined differently in WebRTC 1.0 and ORTC.

[robin-raymond]

@aboba If my memory serves me correctly, I believe it was Google who did not want to use "null" as an end of candidate scenario which is why we did the specialized "completed" candidate object. I don't personally care what we do but I prefer consistency.

CC: @taylor-b @pthatcherg

[taylor-b]

Well, in ORTC, an RTCIceCandidateComplete is emitted by onlocalcandidate and passed into addRemoteCandidate.

And in WebRTC 1.0, null is emitted by onicecandidate and passed into addIceCandidate.

So at least for both specs, the things that are emitted look the same as the things that are passed down.

I prefer the RTCIceCandidateComplete approach, but with WebRTC there are applications depending on the "null" candidate for indicating the end of gathering, which is why we decided to leave it that way, since no one had strong opinions. Though if we end up deciding to trickle the ufrag/password (to resolve ICE restart ambiguities), we'll probably want to trickle that with "end-of-candidates" too, in which case it would need to become a dictionary.

[aboba]

@robin-raymond There seems to be a preference for leaving the current RTCIceCandidateComplete definition alone. Can we close this issue or is there more to do?