[libnice] why is TURN prefered before STUN ?

[Philip Withnall]

You’ve verified that all the local candidates on each peer are being
successfully set as remote candidates on the other peer?

Note that libnice will emit NiceAgent::candidate-gathering-done twice:
once for the STUN candidates, and a second time for the TURN candidates.

If it’s still chosen the TURN server at STATE_READY, there’s either a
problem with all of the non-TURN candidates, or a bug somewhere in your
code or libnice. Try running with NICE_DEBUG=all G_MESSAGES_DEBUG=all
set in your environment and see why libnice is rejecting the non-TURN
candidates.

Philip

On Mon, 2014-11-10 at 17:27 +0100, Klaus Kranz wrote:
> Hi Philip,
> I wait until I get gathering_done callback. Then send the list of candidates
> to the other peer.
> At NICE_COMPONENT_STATE_READY event it has selected the "relay" instead of
> the "srflx" candidate, even though priorities are lower than the srflx ones.
> Rgds
> Klaus
> 
> 
> -----Original Message-----
> From: nice [mailto:nice-bounces at lists.freedesktop.org] On Behalf Of Philip
> Withnall
> Sent: Montag, 10. November 2014 16:11
> To: Klaus Kranz
> Cc: nice at lists.freedesktop.org
> Subject: Re: [libnice] why is TURN prefered before STUN ?
> 
> Hi,
> 
> On Mon, 2014-11-10 at 13:47 +0100, Klaus Kranz wrote:
> 
> > in the hope not chasing a phantom, I am wondering that even though a
> > STUN srflx based connection is possible, libnice uses the TURN relay
> > path.
> >
> > Is there a way to let the library select relay as the last resort only
> > in the case that STUN srflx fails ?
> 
> ICE assigns priorities to candidate pairs, and STUN is always prioritised
> above TURN — precisely because TURN is so slow and expensive.
> 
> Are you using trickle ICE[1] or normal ICE? How are you checking which
> candidate pair libnice chooses to use? Are you waiting for the NiceAgent to
> reach NICE_COMPONENT_STATE_CONNECTED or NICE_COMPONENT_STATE_READY?
> The candidate pair selection isn’t final until STATE_READY.
> 
> This kind of general question can go on the libnice mailing so that others
> can respond (and benefit from the answer!). :-)
> 
> Philip
> 
> [1]: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20141110/b9b70d98/attachment.sig>