[0.x] When full_trickle = true is enabled in janus.jcfg, ICE failures occur frequently.

[Manivannanj127]

What version of Janus is this happening on?
[1.2.3]

Have you tested a more recent version of Janus too?
Yes.

Was this working before?
No

Is there a gdb or libasan trace of the issue?
When I enable full_trickle=true, Users frequently encounter ICE failures. Could you please explain the possible reasons for these ICE failures when full_trickle=true is enabled? I need a permanent solution for this issue, which is deployed in a Docker environment in cloud.

nat: {
stun_server = "stunserver.com"
stun_port = 3478
nice_debug = false
full_trickle = true
#ice_lite = true
ice_tcp = true

should i add other condition in janus.jcfg file.

ERROR : [2454795505169243] ICE failed for component 1 in stream 1, but we're still waiting for some info so we don't care... (trickle pending, answer received, alert not set)

[ERR] [janus.c:janus_process_incoming_request:1159] Invalid handle
[LDFgDOwHzvUO] Returning Janus API error 459 (Handle not found)
(31a0e943-20ba-4064-9355-ff6e5831d566)

[ERR] [dtls.c:janus_dtls_retry:1115] [6747472049327195] DTLS taking too much time for component 1 in stream 1...
[6747472049327195] Hanging up PeerConnection because of a DTLS timeout
[6747472049327195] Telling the plugin about the hangup (JANUS VideoRoom plugin)

[youcci]

I've got the same problem

[atoppi]

Why is full trickling enabled on the server in the first place? ICE trickling is usually needed on the user side where it is often enabled by default, whereas on the server side you have network interfaces under control and the developer is able to pick the specific addresses that Janus will offer (e.g. by setting ice white/black lists in janus.jcfg).
Anyway, as usual, ICE failures must be analyzed through the candidates being exchanged and the pairs being generated. Use the Admin API or a dump on the client for that.

There's also a chance that ICE worked and DTLS failed because of large certificates and unsuccessful retransmissions.