pc.AddIceCandidate complains when candidate.Candidate is the empty string

[jech]

Section 4.8.2 of the spec has the following to say:

An RTCIceTransport has finished gathering a generation of candidates, and is providing an end-of-candidates indication as defined by Section 8.2 of [TRICKLE-ICE]. This is indicated by candidate.candidate being set to an empty string. The candidate object should be signaled to the remote peer and passed into addIceCandidate like a typical ICE candidate, in order to provide the end-of-candidates indication to the remote peer.

However, if I pass such a candidate to pc.AddIceCandidate, it complains with the error attribute not long enough to be ICE candidate (0).

[marverix]

Is there any workaround for now?

[Sean-Der]

Not right now, but this would only take ~hour to fix if you are interested!

At this line https://github.com/pion/webrtc/blob/master/peerconnection.go#L1364

if candidateValue == "" {
  return nil
}

Then you just need to add a test that asserts it doesn't return an error! Happy to answer any questions/explain things :)

[marverix]

Thanks for your quick answer. So just from curiosity: So how the library "knows" that there is end-of-candidates?

[Sean-Der]

Pion doesn't care about end-of-candidates It takes the first connected candidate pair it can get. It waits before taking more expensive candidate pairs though (like TURN and STUN).

You can configure the amount of time you are willing to wait with the SettingEngine!

[Sean-Der]

https://github.com/pion/ice/blob/master/agent_config.go#L23-L33 these are the defaults

[marverix]

Thanks @Sean-Der !

[jech]

That's still not clear to me, Sean. If Pion doesn't care about end of candidates, how does it know when to switch to failed? Intuitively, I'd expect it to remain in disconnected state until it's exhausted all the candidates.

[Sean-Der]

@jech This happens here

Right now it just does disconnected+failed time. After 30 seconds of sending connectivity checks it goes to failed. This is a really easy change we could make!

In general pion/ice has been really naieve. I wish I could put more time into it, but I feel like we are always missing big parts :(

[jech]

I see, thanks. I've summarised this in pion/ice#271.