Is there a way to use webrtc without any server or cost and without downloading anything? I'm trying to make a peer to peer network without a server of any kind (I can't set up my own). Every tutorial that I've found needs some kind of server, or downloading node.js, or using some service that you pay for with a subscription. Is there a way to do this?
WebRTC is actually a Peer to Peer RTC Protocol which happens between browser.
But you got it in wrong way. For establishing the direct link between two systems WebRTC requires,
The topology between itself, and the peer it wants to communicate with
Establish connectivity on the best path through a given topology
Have a fallback mechanism if all else fails.
WebRTC standards require the use of three IEFT NAT traversal standards to address these issues:
Interactive Connectivity Establishment (ICE) – RFC 5245
Session Traversal Utilities for NAT (STUN) – RFC 5389
Traversal Using Relay NAT (TURN) – RFC 5766
So, the final answer is it's not possible with WebRTC.
Related
For a mostly offline browser game I'm researching the possibility to run a WebRTC signalling server from a browser.
I can imagine that security-wise it's a big no-no to open a port and serve connections from a browser (or service worker), but I cannot* find any information on this.
Q. Can Chrome, Firefox (or perhaps any other major browser) open a network port and serve connections using javascript? Or is this fundamentally disallowed by browser design?
*) For sake of completeness, I did find one option (maybe), but it's overly complex, and therefore isn't very appealing. There is a javascript package called filerjs, which allows for a posix-like filesytem in the browser, I think using indexedb, that would allow for a nodejs installation in the browser. I did not further investigate it, so no idea if it actually works, and if a connection could be served this way.
I don't think that you can run a signaling server in the browser. But you say "mostly offline", does that mean that the peers are connected to the internet, but playing from the same LAN? Or are they completely offline? Here are a few ideas:
Signaling server on the web
Even if the signaling server is running on the web, chances are that WebRTC will connect directly through the LAN (to be tested, and it may depend on how the browser selects the ICE candidates).
Manual signaling
Now, the signaling server is only there to exchange SDP messages. So you could theoretically copy-paste the offer and answer (or copy it manually, or scan it with a QR code). It may not be practical, but for instance you could try hardcoding the SDP offer/answer. The two players would need to exchange information somehow, though:
The ICE candidates (those are IPs) that you would need to create the SDP message
The SDP type (one has to be the offer, the other has to be the answer)
I never tried it, but maybe your UI could tell the player "Please share the following IPs to the other player, and enter their IPs below. Also select if you are the offerer or the answerer". But you see that it seems a bit convoluted...
Signaling server in the LAN
If the peers are completely offline and the manual signaling is too convoluted, my next idea would be to run the signaling server in the LAN, and have the peers connect to it. You could even make it such that your game first tries to contact your signaling server on the Internet, and if it fails (because it is offline), it could fallback and try to contact the one in the LAN (maybe it would need to ask the user for the IP of the signaling server, then).
I am using the simple-peer js library to create peer to peer connections in the browser. I have setup proper signaling through socket.io and most of the time everything works fine; hand-shake is successful and p2p connection is established.
But sometimes despite proper hand-shake, p2p connection does not initiate, no error is thrown. This happens consistently on a VPN but sometimes it can happen without VPN. I am using the default google STUN server for now and there is no TURN server provided.
Any enlightenment as to what could be the cause will be appreciated.
Problem is that sometimes one of the peers "sits" behind the doubled NAT or symmetric NAT, VPN is a good example. You use only STUN server, STUN could not solve internal<->external IP of the client behind the doubled NAT. You need to set up TURN server for that. You can test with free TURN, however, this is only to test the problem, not as a permanent solution. For permanent solution better to use your own TURN server.
I'm trying to setup an a cordova plugin for iOS which implements the webrtc functions without using any server and it will only be used on a local network. I know there is this plugin, which looks promising but i have some problems with it.
My plan is not to use a TRUN, STUN or any kind of signaling server.
Maybe you think right now: "Ok this is not possible. No signaling equals no connection." But let me explain first. As pointed out here and
here it's possible to avoid using a TRUN, STUN or ICE server. I think this is a good way to start my project but there is still an open question. How shall the devices find each other if there isn't any kind signaling (in the example they use a Node.js server)? Right now i'm playing with the idea of an QR-Code which contains all the necessary information.
At the end it should look like this (black arrwos are more important):
The idea is that everyone who comes into a room has to scan a QR-Code on the RP and then the device knows the IP, port, etc. of the RP and a WebRTC connection with a DataChannel will be established.
I've been looking for an answer for days now, but due to the fact (or at least one of the reasons) that WebRTC is not even supported on iOS nativly there aren't many WebRTC examples out there which work on iOS and no one for a local network.
So my question is: Am I on the right way or is this not even possible? (I found no example for this anywhere, but if I put all the posts I read together, I think it should be possible.)
First of all, TURN and STUN are not signaling server. Signaling server is the term normally associated with the backend server that let's you relay the messages between two peers before the connection is established. The signaling server is thus used to establish the connection. Once the connection is established, there is no role of the signaling server in the communication, unless you intend to make any changes to the connection parameters.
TURN and STUN servers, on the other hand, are used during the connection establishment process. It helps the two peers find a direct path to each other. So when the connection is established, the peers can talk directly with each other and they don't require the signaling server to relay the messages anymore.
Now coming to your question, short answer is, no, your plan is incomplete.
Here are some changes that you'd need in order to make it work:
QR Code is not adequate to convey all required information. According to this answer, they can store roughly 4kb of maximum data. Thus it is not sufficient to pass all candidates.
Not to mention that WebRTC requires both devices to share the candidates. So, you'd need a display and QR code scanner on the Raspberry PI.
You might want to explore alternatives such as Wifi to allow for two-way data sharing between the device and Raspberry Pi. Once setup, the Wifi connection will act as the Signaling server.
Though I am not well versed in iOS or Raspberry Pi. So I would recommend that you ask a separate question about the choice of communication channel if you are unsure about what to choose. Keep in mind that you need Raspberry Pi to be able to communicate with the device for a short period of time in order to allow WebRTC connection to be established.
Coming to STUN and TURN servers, you may be able to get away without using them. I have seen a few cases when my app is able to establish connection to peers within the local network without STUN and TURN servers.
However, I would strongly recommend that you use at least a STUN server. They are often available for free of charge. Google and Firefox also provide their own STUN servers that you can use in any of your WebRTC apps. You can search on internet to get their details.
TURN servers are required only when the two peers are behind NAT's. In such cases STUN servers are sometimes incapable of finding a direct route between them, and you need the TURN server to relay the audio/video/message stream.
Your plan to establish the WebRTC channel between Raspberry Pi and the phones (the black arrows) seem fine to me. It would help you establish further connections between two phones whenever required.
However, if you eventually decide to implement something like Wifi on your Raspberry Pi, the WebRTC connection may be redundant. After all, you could use Wifi to pass the data back and forth, and don't really need an additional layer of WebRTC channel to do that.
Since you run your app on a local network you don't need STUN and TURN servers. But still you need a signaling server. Signaling can't be done with QR-codes, read more about WebRTC and you will understand why.
But a signaling server can be very simple. Since you have that raspberry pi in your local network, you can use this as your signaling server. Just install node, express and socket.io on it. You need only one simple javascript file, mine is only 23 lines of code. Stop wasting your time with QR-codes and you will have your signaling server up and running in no time. You can look at Google Codelab for an example. Hopes this helps you !!
I'm a noob, and I'm starting to learn about webRTC, recently I found a web page called simplewebrtc, I read about the demo, but I don't understand how they manage the firewalls and NAT traversal in a network, I know that webRTC uses STUN Servers but I can't find them in the source code of the demo from simplewebRTC, can anybody explain me that please?
Thank you
Currently SimpleWebRTC uses the public google STUN server as default, check this line.
About the NAT/firewall traversal: as you already pointed out this is done using a STUN (or TURN) server. The STUN protocol simply allows clients that are trying to establish a connection to discover each others public IPs, with which they can establish direct connections. If some client is behind a symmetric NAT then a TURN server that acts as a relay will be necessary.
You can find a more detailed explanation about STUN/TURN here.
This question already has answers here:
Why is a signaling server needed for WebRTC?
(5 answers)
Closed 7 years ago.
I'm working on a project which should allow users to connect with one another (1 on 1) and chat via the website. If I go with the http://peerjs.com/ implementation or another custom solution for WebRTC peer connection, will I need a server to broker the connections? If so, what's the purpose of it? I thought the whole point of WebRTC peer connection was to allow for direct user-to-user connections.
I thought the whole point of WebRTC peer connection was to allow for
direct user-to-user connections.
Direct user to user connection means P2P connection is when two users exchange data directly without any relay server in the middle. But for them to be that way they need to first connect to each other. And for that they need each other IP addresses and other related information.
Two devices on internet can't know each other addresses unless someway they exchange these infos between them. That's why a Signaling server like SIP,XMPP are used. Peers log into these servers for exchanging these IP information. When Peer A and Peer B are logged into say in a SIP server then when peer A wants to communicate with peer b,
1) A will send its IP info to the sip server. Sip server will forward this info to B.
2) Upon receiving the information peer B will send its IP addresses to the SIP server and SIP server will forward it to Peer A.
3) After they both know each others IP information they can then connect with each other directly without the using the SIP server again.
This is what P2P connection is. It uses signaling server only for creating connection between peers after that its P2P connection.
But P2P connection is not always possible even after knowing all the Ip information of each peers. There are some NATs which makes it impossible to create P2P connection. But that is another topic.
Hope this clears up your confusion.
Peers need some way to find one another and setup a media connection. A server is a convenient way to do this. You can setup a direct connection for signaling to exchange SDP messages, but whether this will work depends on whether you know the addresses of endpoints and firewalls are configured correctly. Mobile phones and laptops, for example, will have IP addresses that change frequently, which makes locating them directly difficult. The process of exchanging information to start the peer connection is called signaling.
The media in a peer connection is sent normally between peers, though you can also do things like send media through a TURN server.
The signaling portion of the WebRTC process is very lightweight compared to the media sent over the peer connection. Due to the simplicity of using a server for signaling, servers are frequently used for signaling.