[libnice] why is TURN prefered before STUN ?

[Klaus Kranz]

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

-- 
.