Callback for rtcSetGatheringStateChangeCallback sometimes not firing for RTC_GATHERING_COMPLETE

[gasperov]

I'm encountering an issue in my test based on capi connectivity (with libjuice), where callback (set with rtcSetGatheringStateChangeCallback) function isn't consistently being invoked for the RTC_GATHERING_COMPLETE status.

This behavior is observed when both sides of the connection are using TURN servers.

What could be the root cause for this issue? How can I debug it?
Could there be a problem with calling rtcSetRemoteDescription before callback from rtcSetLocalDescriptionCallback is finished?

I also noticed that juice_set_remote_gathering_done is not somehow exposed in libdatachannel. Should there be a call to juice_set_remote_gathering_done on remote side after local gets RTC_GATHERING_COMPLETE ?

[gasperov]

Related to this issue I experimented with #1131.

[paullouisageneau]

What could be the root cause for this issue? How can I debug it?

Is the callback never called or called only after a long time (like 1min)? If the callback is never called, you should ensure you set it early enough and you don't block any other callback from the library. If it is called after a long time, the probable cause is an offline ICE server.

The gathering complete state is only reached when every candidate has been gathered. If an ICE server does not answer, for instance because it is unreachable or overloaded, then the state transition can only happen after the client times out, which can take a relatively long time (more than 30s). This is why it is recommended to use candidates trickling instead of sending full descriptions on gathering done when using ICE servers, in particular TURN servers.

For more information, you should look at the verbose log to investigate what is blocking.

Could there be a problem with calling rtcSetRemoteDescription before callback from rtcSetLocalDescriptionCallback is finished?

It should be fine, but it sounds like you block a callback, which is something you must not do. Could you please elaborate on the scenario where you end up with such a call order?

I also noticed that juice_set_remote_gathering_done is not somehow exposed in libdatachannel. Should there be a call to juice_set_remote_gathering_done on remote side after local gets RTC_GATHERING_COMPLETE ?

It's not exposed because it's mostly useless. It's part of the API only for the sake of completeness, libjuice do not use the information for anything apart from adding the end-of-candidates marker to the remote description and preventing more remote candidates from being added.

[gasperov]

@paullouisageneau thank you for your answer!

I was using timeout of 20s in my code stack - I didn't let timeout provided by libdatachannel to kick in ...

I also switched to different TURN provider (now metered) and now I do receive RTC_GATHERING_COMPLETE signal as expected (within few seconds). So, it seems it is not software issue in libdatachannel, but there is/was an issue with TURN server I was using.

Related to rtcSetRemoteDescription and rtcSetLocalDescriptionCallback I was just speculating on possible issue...

I understand about end-of-candidates ...