- When I add an RTP and RTCP component on a single audio stream, I
notice that the StunCandidateHarvester is in the disabled state when
harvesting for the second component (RTCP), so gathering only finds the
Strange, does it happen with Jitsi or an application you write ?
If it the second ones, can you send us part that deals with ice4j. In
any cases the pcap logs (maybe the STUN servers doesn't reply to RTCP
STUN query, ...).
I am using TURN and trying both the open turnserver and reTurn from
I noticed that in StunCandidateHarvester.harvest(), after the call
waitForResolutionEnd(), there were no new candidates found
However, if I add the line
to make it wait a little more after waitForResolutionEnd(), then it
finds the candidates
In the case where candidates are not found, (without the sleep), then
ice4j disables the harvester
Have you seen problems with waitForResolutionEnd() elsewhere?
In case it's relevant, I'm running the code on android (not a regular JVM)
Jitsi uses intensively ice4j for XMPP Jingle and all the components
(RTP/RTCP) correctly gather STUN candidates.
Have you got a SIP implementation in the works? It would be good to
have inter-op with my own app.
We suggest you to see
class that Jitsi uses to setup ice4j's Agent.
Thanks for referring me to that, I'll go over that now