Could anyone share a tutorial on how to set up a basic WebRTC text and/or voice chat from scratch? I've tried but failed to get a proof of concept built, and personally have not found any great documentation
As someone who has done some work with WebRTC (attempting to build a video conferencing app for work) it's hard to boil things down to a "Hello World" due to the whole ICE and signalling thing. It's unfortunate, but in order to get this client-side peer-to-peer thing working, you need to have a server in the cloud (i.e. not behind NAT) that can pass signals between the two peers.
The tutorials other people have linked to look good, just note that unless you're talking between 2 computers within your local network (and even then you'll have to copy-paste their IP addresses to each other), you'll need to either deploy a server or use a 3rd party library like PeerJS that uses one.
I hope that eventually IPv6 will obviate the need for NAT and make this whole thing much simpler, but until then, this is what we've got.
Hi there, I authored this small chat-text/file-transfer demo without any third party libraries for WebRTC communication [0].
It is very easy to get running in your computer since it's made with the purpose of explaining data flow withing WebRTC, logs have been implemented describing this flow in both client and server, you can find a blog post about it here [1].
Maybe it's better, but another one is simpler (no need to bother with the server part at all). From reliability viewpoint, hard to say. A priory, I would trust firebase more, but I might be wrong.
Neat idea to use WebRTC. Do I understand it correctly therefore no central server is involved?
I was once in need to stream my shell to some colleges and so I hacked together a tiny shellscript http://liveshell.43z.one/ which should work on most Linux systems without installing any dependencies.
Correct, no central server. It does use google's stun server to establish the connection, but you can swap that out with another stun server with the -s flag (it's easy to host your own and there are many free stun servers)
The -o flag makes things easier but uses https://10kb.site to do the sdp exchange
Neat! I wrote something similar [1] more than a year ago which allows you to create one or more remote shells but sharing can only be done via tmux (shameless advertising).
There have been a few libraries popup that tie libnice + OpenSSL + libsrtp + usrsctp together, it is nice that the stack is all there. Just have to jump through lots of hoops :) The creation of them also seems to be accelerating! I think the P2P excitement has helped a lot.
Congrats on the release maxmcd, you really built something cool quick!
The best thing about Go is those easy deploys, it would be great to drop this on a remote server and go at it. Could be helpful for getting quick shell help for a friend. Or maybe a way for people to avoid having jump boxes (and SSH only available via VPN) solutions are endless :)
WebRTC is mostly about peer-to-peer communication (with a focus on audio and video support alongside data), whereas WebSockets is more about client-server communication. That is, a WebSocket connection needs to be made explicitly to some kind of server; WebRTC handles a peer-to-peer connection setup somewhat transparently.
WebRTC still needs to communicate between peers in order to set up that connection. In fact, many applications using it will use a WebSocket server to handle that initial communication – basically messages between the peers that say "this is where I am and how you can connect". In the case of this WebTTY project, this initial communication is encoded in the "connection data" that needs to be shared to set up the connection, so there's no need for that channel.
The tutorials other people have linked to look good, just note that unless you're talking between 2 computers within your local network (and even then you'll have to copy-paste their IP addresses to each other), you'll need to either deploy a server or use a 3rd party library like PeerJS that uses one.
I hope that eventually IPv6 will obviate the need for NAT and make this whole thing much simpler, but until then, this is what we've got.
I guess that's where your central server comes in - even in a perfect scenario where there's no NAT between peers.
It is very easy to get running in your computer since it's made with the purpose of explaining data flow withing WebRTC, logs have been implemented describing this flow in both client and server, you can find a blog post about it here [1].
[0] https://github.com/agilityfeat/file-transfer-demo
[1] https://webrtc.ventures/2018/04/file-transfers-small-demonst...
https://suldashi.com/dead-simple-webrtc-explanation/
I was once in need to stream my shell to some colleges and so I hacked together a tiny shellscript http://liveshell.43z.one/ which should work on most Linux systems without installing any dependencies.
The -o flag makes things easier but uses https://10kb.site to do the sdp exchange
That shell script is cool
[1]: https://github.com/rawrtc/rawrtc-terminal-demo
* https://github.com/xhs/librtcdc (This was the first non-chrome one afaik)
* https://github.com/chadnickbok/librtcdcpp
* https://github.com/jlaine/aiortc
* https://github.com/rawrtc/rawrtc
* https://github.com/pions/webrtc
* https://github.com/nodertc
* https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gs...
There are also a few that aren't public, I haven't used them directly though. Only by talking to other devs.
The best thing about Go is those easy deploys, it would be great to drop this on a remote server and go at it. Could be helpful for getting quick shell help for a friend. Or maybe a way for people to avoid having jump boxes (and SSH only available via VPN) solutions are endless :)
WebRTC still needs to communicate between peers in order to set up that connection. In fact, many applications using it will use a WebSocket server to handle that initial communication – basically messages between the peers that say "this is where I am and how you can connect". In the case of this WebTTY project, this initial communication is encoded in the "connection data" that needs to be shared to set up the connection, so there's no need for that channel.
[1]: https://en.m.wikipedia.org/wiki/Radioteletype
https://savannah.nongnu.org/projects/rtty/
They do call out the potential confusion with radio.