Explicit method to start connectivity checks?
Partially related to #68, as it was originated from the same discussion in the same post.
Basically, the issue seems to be that if libnice never received a remote candidate from signalling, or those that were received were discarded (e.g., unsupported or unresolvable mDNS candidate), then libnice never starts its side of connectivity checks: even if incoming connectivity checks succeed and are answered to, thus implicitly adding new prflx candidates, libnice never sends its own, and so ICE never connects.
I remember encountering a similar issue some time ago, with iOS devices that were not sending host candidates (apparently for privacy reasons) and no srflx candidates either, meaning connectivity could only be achieved via prflx.
From what I could gather, apparently the problem is that libnice only starts to work after a successful call to
nice_agent_set_remote_candidates(), which means that the "connecting" part only becomes active implicitly, after remote candidates are made available. If no remote candidates are passed explicitly, but are only implicitly derived via prflx, then the process doesn't seem to start.
I'm not exactly sure if this is an issue or not, or even if I've identified the right cause of the issue, but if so my guess is that an explicit method to start connectivity checks might help in that regard: i.e., keep the existing behaviour (implicit start when remote candidates are provided), but an explicit request available if that doesn't happen. The method might be idempotent, so that even if you call it after the process already started, it's fine. Would this make sense?
The only alternatives with the existing API that I can see are the following:
- Since incoming connectivity checks still succeed, they might act as implicit triggers for starting connectivity checks, as they're basically doing a
nice_agent_set_remote_candidates()via network. Not sure if that breaks the internal behaviour in the library, though, and if it makes sense at all.
- These incoming connectivity checks results in the related prflx candidates being notified to the application via the
new-candidate-fullcallback, so the application can try to then manually add this discovered candidate via
nice_agent_set_remote_candidates()to kickstart the connectivity process. Anyway, IIRC I tried this approach and it didn't work (probably adding the candidate failed because it existed already?)
- The discovered candidate introduced before might be selected via
nice_agent_set_selected_remote_candidate(), since it managed to contact us; anyway, there's no guarantee our response managed to get the peer too, so it would probably be a bad idea to close on a candidate that may not really work.
Looking forward to your feedback!