I am using this example https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser and try to connect to a nodejs peer through the given hosted rendezserver ‘/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star’ . The peer get found but the connection is not established. If i run the nodejs peer in the same machine as the browser peer they get connected but if the nodejs peer is on a different machine/network the peers find each other but they don’t get connected. Is this normal ?
Yes that's totally normal. WebRTC will only work if you can get through the NAT. IPv6 really helps with NAT traversal too, but it can be trickier with IPv4. So it will work over more than locally, but each peer must be able to directly reach each-other.
https://docs.ipfs.io/how-to/create-simple-chat-app/
We can use WebRTC-Star nodes to help discover other peers we can connect with directly browser-to-browser. If you're familiar with the concept of STUN, it might be helpful to think of them as conceptually similar. Effectively, each connecting node will be given a WebRTC-Star multiaddress that other nodes can use to discover and connect to your browser directly. This means that if you peer with someone using the star node, and the star node goes offline, you remain connected!
[...]
Tip
This is a very clean and effective method of P2P communications; however, sometimes NATs get in the way. We use p2p-circuit to get around that.
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 :)
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 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.
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.