[Nice] Why are TURN allocates necessary on both sides of a call?

[John Selbie]

Thanks Youness.


On Thu, Jun 27, 2013 at 3:16 PM, Youness Alaoui <
youness.alaoui at collabora.co.uk> wrote:

> Hi John,
>
> It is not important for both sides of the call to allocate TURN relay
> ports, but
> I think it will increase your chances of establishing a connection...
> Assuming
> that only one of them is needed, I can still see many reasons why both
> peers
> would send their TURN candidates :
> 1 - it doesn't cost anything to do it
> 2 - It would be more complicated to negotiate which one of the two should
> be
> doing it (especially if one of them doesn't have TURN configured)
> 3 - It would be even more complicated if once you decide which one should
> do it,
> the TURN allocation fails, and you have to renegotiate so the other peer
> tries
> it instead..
> 4 - There is no specification for negotiating such a thing
> 5 - lazy developers ?
> 6 - in SIP, you send your invite in one shot with the SDP and all your
> candidates, so you already have your TURN set up at that point
> 7 - Some clients will only have a TURN server setup (no STUN) and find the
> server reflexive candidates through the TURN server anyways..
>
> So overall, Even if there was no need for it, it would still be a huge
> hassle
> (not that huge) to have only one peer use TURN.
>
> As for the second question, it can happen that both TURN servers are
> used.. I
> know that I've seen it before, I can't remember the exact use case, but I'm
> guessing it's something like this :
> - Peer A and peer B both behind a symmetric NAT
> - Peer A has candidates 1.2.3.4 port 1234 + TURN
> - Peer B has candidates 4.3.2.1 port 4321 + TURN
> - Peer A sends normally to peer B, symmetric router drops all packets
> - Peer B sends normally to peer A, symmetric router drops all packets
> - Peer A sends to peer B through the TURN server, symmetric router drops
> all packets
> - Peer A sends to peer B's TURN candidate, since it's a symetric NAT, a new
> outgoing port is used on the router, so the TURN server drops the packet
> since
> there is no permission to allow those packets coming in.
> - Peer A sends to peer B's TURN candidate through its own TURN server, it
> works...
> - Connection is established between both TURN servers.
>
> I hope this answers your questions.
>
> p.s: As for your previous email about TURN server recommendations. I've
> only
> known/used turn-server.org and Viagenie's server (http://numb.viagenie.ca/
> )
> which work well with libnice. I haven't tried the other ones. I know the
> TURN
> servers of google (libjingle) works as well in google compatibility mode,
> but I
> don't think the actual open source version in libjingle as the same as
> what they
> use on their servers...
>
>
> Thanks,
> Youness.
>
>
> On 05/14/2013 03:33 AM, John Selbie wrote:
> > From experience, I know that in SIP calls using ICE, both endpoints of a
> call
> > will allocate a TURN relay port and use that as an address candidate to
> send to
> > the other side. Additionally, the endpoints can use STUN or the
> mapped-address
> > in the TURN allocation response to infer the server reflexive address as
> a
> > higher priority candidate.
> >
> > Two questions:
> >
> > Why is it important that both sides of a call allocate a TURN relay port
> as
> > opposed to just letting the inviter side do TURN+STUN and have the
> callee do
> > STUN only for gathering address candidates? If there a network topology
> in which
> > ICE could not converge unless both sides had a TURN relay as an address
> candidate.
> >
> > If both sides of the call allocate a TURN server address, is there a
> network
> > topology that will causes ICE to converge on sending packets through
> both TURN
> > servers? Does is obviously the lowest priority candidate pair, but can
> it happen?
> >
> > jrs
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > nice mailing list
> > nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
> >
>
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130628/c2df7096/attachment.html>