I was read the turnserver rfc-5766. In this the figure 1 the following are the things are gets take placed.
Turn server
Turn client
Peer A
Peer B
My understanding is the peer A and peer B are used for the webrtc clients who wants to communicate each other behind a symmetric NAT. They uses the turn server to communicate.
But I don't know what is the use of turn client in here. Then I did not understand what is the use of send indication and data indication. They said the data is transfered using the allocated relayed address. But that address is not yet used. But the the data transferring is gets successful. I don't know how it gets succeed. Please explain me the flow of the coturn 4.5.0.3 turn server.
Related
Let's say I have access to a server via ssh and my own laptop. However, I wish to use webrtc to transmit data via a peer connection for it's ultra low latency over UDP. It's also crucial that I have NO communication between a third server.
What I would like to do, is use ssh to get the signalling information for the two machines (offers and answers) to then create a webRTC channel. This way I can say that no information ever went to a third server (including the signalling part).
I understand the requirement is a bit silly, but it's due to how we network things currently, and the important part is the super low latency webRTC provides.
Or is this the wrong tool for the job perhaps? Open to other suggestions :)
I have been reading a bit about WebRTC, and I'm not getting why we need a Turn Server if only 1 peer is using Symmetric NAT, and the other is using neither Symmetric nor Port Restricted NAT, so let’s say A is using Full Cone NAT, B is using Symmetric NAT:
STUN SERVER will send the correct IP address of B to A, and the correct IP + Port address of A to B.
A tries to connect to B (now A will be able to accept messages from B since it’s in the Dest Address Column).
B tries to connect to A, which will allow requests from A going to B (ofc A needs to update the port to the one received from B instead of the Sdp).
am I missing something, or is this correct (and implemented), or is this too complicated to be implemented?
And if this is correct, then theoretically, if I’m peer A and I'm using Full Cone NAT, any peer B can connect to me (as long as I send the connection request first), without needing a TURN server.
Thanks
If the symmetric NAT environment only changes the port, you would be correct with regarding connectivity to Full Cone NAT. The hole punching step would work.
But many enterprise and mobile environments have complex routing schemes and crazy network environments that are different from a legacy home network router. These environments aren't just a little router box that hooks up to a cable modem. It's a complex array of routers and load balancers using a bank of IP addresses. And each outbound connection might get an IP address different from a previous connection. So it's technically "symmetric NAT".
And so after a node within this environment obtains an external IP/port pair from a STUN server, subsequent sends to a peer address might change both both the port and the IP address as well.
As such, the NATs see completely different IP addresses than expected when the UDP packets arrive during the hole punching step. Hence, a relay address (TURN) is needed here.
This question is a little easier if you think in terms of Mapping/Filtering. The other NAT terms don't do a good job of describing how things actually work. My answer comes from RFC 4787 and WebRTC for the Curious: Connecting
Mapping is when your NAT allocates a IP/Port for an outbound packet. A remote peer can the send traffic to this mapping. Filtering are the rules around who can use these mappings.
Filtering and Mappings can then be address dependent and independent. If a mapping is address dependent it means a new mapping is created for each time you contact a new IP/Port. If a mapping is address independent it means it is re-used no matter where you send traffic. These same rules apply to filtering.
If one peer is address + filtering independent I don't believe a TURN server would provide a benefit.
If you want TCP connectivity deploying a TURN server is a good idea. Some WebRTC servers support TCP, but I don't believe any browsers generate passive TCP candidates.
Working in WebRTC, it would seem like only the offering client would need to provide STUN and TURN locations and credentials that would be encased in the offer and then used by the receiving client(s). Is that the case? If not, why not?
No, clients on both ends need to provide some sort of STUN/TURN configuration, note that these configurations need not to be the same.
Recall that STUN and TURN just provides you the tools to get around NAT. In other words, it provides the tools for a peer to figure out a way to be reachable publicly. They do that by generating ICE candidates that we send through signalling. As long as we can generate at least one valid ICE candidate and tell our peer about it, we can establish a connection.
The reason why both ends need to provide configuration is because otherwise, one of the peers would have no way to tell which IP address belongs to the other. Therefore, even though the answering peer has your ICE candidates (so it knows how to reach you), if the ICE candidates are generated only by the offering side, then this side has no way to securely tell that an incoming connection attempt is actually coming from the peer who you sent your offer to (although it most likely would be).
And for the bounty question "I would like to know if it's possible to connect peers over TURN when only one peer has the required TURN credentials.", the answer is also no.
To understand why, you need to understand that a TURN server is there so in case you can't establish a direct connection due to firewalls, incompatibilities, etc. it generates you "fake" ICE candidates to send to your peer because, in reality, these candidates are actually representing your TURN server. Your TURN server would then relay data sent by your peer to you, at this point, it is not considered peer-to-peer anymore.
That said, your peer doesn't even know about your TURN server, it sees your TURN generated candidates like any other candidate. Your peer still has to gather ICE candidates somehow to send you. And it can't use your TURN server to do that because you never provided its credentials throughout the workflow.
I recommend you read the book WebRTC For the Curious if you are interested in this stuff. It's very comprehensive.
I am building this video teaching site and did some research and got a good understanding but except for this thing. So when a user want's to connect to another user, P2P, I need signaling server to get their public IP to get them connected. Now STUN is doing that job and TURN will relay the media if the peers cannot connect. Now if I write signaling server with WebSocket to communicate the SDP messages and have ICE working, do I need coTURN installed? What will be the job of the job of them particularly?
Where exactly I am confused is the work of my simply written WebSocket Signaling server (from what I saw in different tutorials) and the work of the coTURN server I'll install. And how to connect them with the media server I'll install.
A second question, is there a way to use P2P when there is only two/three participants and get the media servers involved is there is more than that so that I don't use up the participant's bandwidth too much?
The signaling server is required to exchange messages between peers (SDP packets) until they have established a P2P connection.
A STUN server is there to help a peer discover information about its public IP and to open up firewall ports. The main problem this is solving is that a lot of devices are behind NAT routers within small private networks; NAT basically allows outgoing requests and their response, but blocks any other "unsolicited" incoming requests. You therefore have a Catch-22 scenario when both peers are behind a NAT router and could make an outgoing request, but have nowhere to send it to since the opposite peer doesn't expose anything to make a request to. STUN servers act as a temporary middleman to make requests to, which opens a port on the NAT device to allow the response to come back, which means there's now a known open port the other peer can use. It's a form of hole-punching.
A TURN server is a relay in a publicly accessible location, in case a P2P connection is impossible. There are still cases where hole-punching is unsuccessful, e.g. due to more restrictive firewalls. In those cases the two peers simply cannot talk 1-on-1 directly, and all their traffic is relayed through a TURN server. That's a 3rd party server that both peers can connect to unrestrictedly and that simply forwards data from one peer to the other. One popular implementation of a TURN server is coturn.
Yes, basically all those functions could be fulfilled by a single server, but they’re deliberately separated. The WebRTC specification has absolutely nothing to say about signaling servers, since the signaling mechanism is very unique to each application and could take many different forms. TURN is very bandwidth intensive and must usually be delegated to a larger server farm if you’re hoping to scale at all, so is impractical to mix in with any of the other two functions. So you end up with three separate components.
Regarding multi-peer connections: yes, you can set up a P2P group chat just fine. However, each peer will need to be connected to every other peer, so the number of connections and bandwidth per peer increases with each new peer. That’s probably going to work okay for 3 or 4 peers, but beyond that you may start to run into bandwidth and CPU limits of individual peers, especially if you’re doing decent quality video streaming.
I am using the google's TURN servers which is given in the demo, Sometimes the connection is established and remote video is streamed sometimes I just get a black screen instead of remote stream. Are these servers not reliable or is there any other issue because I can see the IP of the other machine on the peer which means the peer connection has been established. So what could be the possible problem is?
google doesn't provide any TURN server, only a STUN one.
There's a lot of situation where you need a TURN server, but as far as I know, there's no open TURN server. Even when the ip is detected, you can have problems with a proxy destroying the UDP stream or some of the ports needed.