Using Janus 1.1.3 for the Videoroom plugin, about 5-10% of the answers to publisher offers have no ICE candidates in the SDP.
I have tried using full trickle for Janus, but I have never received the trickle event. I get the “local-candidate” events, but those appear to really just be for logging and not for use. In particular I see that the local-candidate events can be published but an extra conditional check in Janus can then exclude that candidate. This tells me not to rely on the local-candidate events.
We are still in the testing phase, and most of the calls are identical in terms of the client media constraints & networking. The calls that do not include candidates in the answer are functionally identical to those that do include candidates.
I have multiple questions:
When configured for full-trickle, what would keep Janus from sending trickle events? I am logging every event I receive from Janus, even if I am not acting on them, and I have never received a trickle event.
Using half-trickle, what is keeping Janus from including candidates? The STUN and TURN servers are local to the same network with extremely low latency. I don’t see anything in Janus server logs to indicate what went wrong when Janus omits candidates from the answer.
I can detect when the SDP does not have a candidate, and rather than providing that to the client, it looks like I can send a configure with the offer SDP again. Are there any special considerations for using that approach to recover when there are no candidates in the answer?
Missing candidates on the client side sound like client issues: so something you need to fix there, not Janus. Maybe no interfaces work for the purpose, or you need STUN/TURN?
My apologies if I wasn’t clear with my question. I am talking about the Janus side. My client (via a signaling server) sends the offer, and the Janus answer is the one that sometimes does not have a candidate. The Janus answer does have the expected candidate(s) most of the time, but not always. That’s the scenario I need to be able to recover from automatically, and I’m hoping to send a configure message when I don’t see a candidate in the answer with the intention that it will create a new answer from Janus.
For clarity, I am using TURN in both directions – mainly for limiting the number of ports to map through firewalls and other network appliances. I have Coturn installed on the same server with Janus in each server instance. I am using TURN REST API for credentials for the TURN server for Janus and the clients. I can see Janus request the credentials, I can see the TURN allocation succeed, and in 90% of the calls the relay candidate is provided by Janus in the answer to the publisher offer. In these calls, I can see in the Janus admin page that the remote candidates from the client are listed for that publisher handle, but no local candidates. Yet nothing I see in the Janus logs indicates why Janus doesn’t think it has its own local candidate.
I would love to have insight into the cause, but most important to me is how I can automatically retry to recover, thus question 3 about whether I am assuming correctly that sending a configure message is valid.
I would normally try so I can see if it works, but I cannot reproduce the situation at-will.
You should check Janus logs then. I’d say the lack of TURN candidates may be due to a timeout of some sort, but at least the host candidates should be there. If those aren’t either, my guess is you have a network interface that’s not responding properly at times. Or maybe you configured a too small RTP range in janus.jcfg and all ports are taken sometimes?