<div dir="ltr"><div>Thanks Youness.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jun 27, 2013 at 3:16 PM, Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk" target="_blank">youness.alaoui@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="http://turn-server.org" target="_blank">turn-server.org</a> and Viagenie's server (<a href="http://numb.viagenie.ca/" target="_blank">http://numb.viagenie.ca/</a>) 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 > <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> > _______________________________________________ nice mailing list <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> </blockquote></div> </div>