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

[Youness Alaoui]

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130627/4eaf7002/attachment.pgp>