0

We use a provider of global TURN servers (Xirsys). When establishing a connection between peers, each peer first identifies the closest TURN server to their location, then fetches credentials for that server. The peers then exchange ICE candidates, including their respective TURN server URLs.

If those peers are in different regions, they will propose different TURN servers. According to the accepted answer to this question: TURN-Server for RTCConfiguration the respective TURN servers will connect to each other to relay streams from Peer1 <> TURN1 <> TURN2 <> Peer2. However, I have been unable to get this to work. Forcing TURN in the clients (i.e. no direct p2p connections), and attempting to establish a peerConnection using a TURN server in e.g. the United States to one in Brazil, negotiation always fails.

Is this because the servers require credentials that are not passed in the ICE candidates? Or perhaps it's a Xirsys-specific problem? Or should it actually work fine and we're doing something else wrong?

Ash Eldritch
  • 1,504
  • 10
  • 13
  • Please send us an email to experts@xirsys.com so we can work out what you're trying to do and help you resolve your issue. – Lee Sylvester Sep 25 '20 at 07:07

2 Answers2

3

No it's not going to be because of the credentials. They are used between the client and its TURN server. The connection between the TURN server and remote end point doesn't use any authentication.

In fact each TURN server should be blissfully unaware that the remote party is even another TURN server. As far as they are concerned they forward packets to the remote end point just the same no matter whether it's a browser, another TURN server or some other application.

sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • Thank you for the answer, it's helpful and does answer the original question. (It might be helpful to update the answer to add a "Yes, it should work" to more directly answer the question.) I'm hoping Xirsys will chime in too so won't discourage that by accepting your answer just yet. – Ash Eldritch Sep 11 '20 at 00:12
1

So, while working through two TURN servers is possible, it's definitely not easy. The reason is that the first TURN server will generate an allocation with a given port. The second TURN server will need to send data to this port. However, how does the first TURN server know where to send that data? The second TURN server will not yet have an allocation!

Typically, WebRTC applications use a singular TURN server. If you want to use two, it means having control of the allocation generation and massaging of the SDP.

Lee Sylvester
  • 183
  • 1
  • 7
  • 1
    I disagree. Both clients gather their relay candidates, then ICE figures out how the TURN-TURN connection gets used. – Philipp Hancke Sep 11 '20 at 08:46
  • 1
    No you don't need to massage the SDP. Each WebRTC peer generates an ICE candidate for its TURN server. Once the relay candidates are exchanged the ICE negotiation will be able to set up a connection via the TURN servers without anything extra. – sipsorcery Sep 11 '20 at 08:49
  • @Lee Sylvester Thank you! I imagine you can speak with authority on how Xirsys functions :) So is it fair to say that specifically with Xirsys, if peers are in different regions, offering their closest TURN server to the other peer, connections will not be established? And if so, is there any "best" strategy we can use to work around that? Only thing I can think of would be to negotiate a single TURN server, e.g. the peer that initiates the negotiation sends their own RTC Config as part of the initial signaling when requesting a call – Ash Eldritch Sep 11 '20 at 23:56
  • @Lee Sylvester The answer here seems to indicate that each peer would simply use their own TURN server and data flow would be unidirectional. However, we still cannot establish connections between two peers offering different Xirsys TURN servers: https://stackoverflow.com/questions/54796460/will-ice-negotiations-between-peers-behind-two-symmetric-nats-result-in-requiri – Ash Eldritch Sep 22 '20 at 21:19
  • Ahh, I see. Why use two TURN servers? The flow of data in a connection is bi-directional, so one TURN server should be fine. However, if you simply want to use two, this should be no different to using one. Are you using two separate RTCPeerConnection instances for both connections? Are you sure you're handling both negotiation flows separately? It sounds like, somewhere, there's a little mud in the water. Using two unidirectional TURN servers for a two way connection is no different to using one TURN server for a one-way connection. – Lee Sylvester Sep 25 '20 at 07:06