
A real world guide to WebRTC - wolframhempel
https://deepstreamhub.com/tutorials/protocols/webrtc-intro/
======
xrjn
We recently started using WebRTC to transmit video from Raspberry Pi's where I
work. There were a lot of gotchas that weren't obvious to someone who's never
worked with VOIP or related technology: STUN and TURN servers[0], 300 seconds
idle timeouts that shouldn't affect the connection but killed the video stream
regardless, and dropped calls which forced us to reboot the Pi.

In the end we managed to get something smooth working with UV4L[1] on a RPi
costing us a fraction of the previous solution.

[0] [http://numb.viagenie.ca/](http://numb.viagenie.ca/) has a free one

[1] [https://www.linux-projects.org/](https://www.linux-projects.org/)

~~~
fulafel
If your devices have real IP connectivity, you can skip TURN/STUN.

~~~
throwawaybbq1
Do you still need a server for signaling or is it actually P2P at that point?

~~~
fulafel
There needs to be some mechanism to tell you what the other P2P endpoints are
and what address/port pairs they are listening to. It doesn't have to be a
server necessarily, could be just a copy-paste string.

------
myfonj
> You will need [...] and drumroll - a server.

Actually, you can make poor human to do signalling servers work:
[http://blog.printf.net/articles/2013/05/17/webrtc-
without-a-...](http://blog.printf.net/articles/2013/05/17/webrtc-without-a-
signaling-server/)

~~~
_pmf_
That's amazing.

------
patrickaljord
Nice guide. A little warning, while WebRTC is known as a p2p tech, what few
people realize before starting using it is that while it is p2p technically,
you need like 3 to 4 centralized servers to make a connection between two
peers. Just google TURN, STUN and ICE servers and protocols, you will also
need a signaling server (usually your app) and a web server where the app is
hosted. That's why most people use webrtc as a service solutions or all in one
webrtc servers that are hard to customize/setup.

~~~
k__
I looked into Kurento, which made a promising first impression.

But I have the feeling, most WebRTC stuff is badly documented, proprietary
and/or outdated.

~~~
compuguy
Hasn't Kurento development ground to a halt since they were bought out by
twillo?

~~~
j1elo
Twillio acquihired most of the staff and some proprietary bits, but the
opensourve part is still alive and the Kurento project is starting to get out
of the halted state. A new version will get released in the coming days. Also
the new team is building upon Kurento to make a simpler layer with the more
specific use case of group video calling, named Openvidu.

------
Tepix
I'd love to see a minimal example of

a) client and _server_ that only use the WebRTC data connection for low
latency UDP based communications

b) a p2p example for a group of clients using WebRTC data connection

This website seems to cover b) but not a)

~~~
lxtx
You might want to check out the project I've been working on:
[https://github.com/seemk/WebUdp](https://github.com/seemk/WebUdp)

It's a minimal WebRTC server implementation (SDP, STUN, SCTP, DTLS and
everything else) contained in a single library. Note that it only implements a
subset of the specs to get it working and probably still is buggy
(experimental!) as I'm developing it while working on another project that
uses it.

~~~
49531
Hey this is awesome. I've been working on a webrtc project and will def look
into using this!

------
dbrgn
Nice guide. In contrast to what the article says about data channel size
limitations (1200 bytes), 16 KiB seems to be safe:
[https://lgrahl.de/articles/demystifying-webrtc-dc-size-
limit...](https://lgrahl.de/articles/demystifying-webrtc-dc-size-
limit.html#demystifying-webrtc-dc-size-limit)

In case you want to do chunked data channel transfers but don't want to
implement the chunking yourself, I wrote a library to do just that:
[https://www.npmjs.com/package/@saltyrtc/chunked-
dc](https://www.npmjs.com/package/@saltyrtc/chunked-dc) It's based on this
specification: [https://github.com/saltyrtc/saltyrtc-
meta/blob/master/Chunki...](https://github.com/saltyrtc/saltyrtc-
meta/blob/master/Chunking.md)

------
ShirsenduK
IMO, WebRTC is the technology which will make browsers trump apps. Especially,
now as iOS 11 starts shipping with support for it.

~~~
greggman
I'm a little worried about webcam access in browsers at least as currently
implemented (and native apps I suppose but less so)

As it is, in Chrome, if you let a webpage access your camera (or mic) that
page gets permanent permission to access the camera whenever it wants forever,
no questions asked again. I recently visited one of the early HTML5 Webcam
demos that I hadn't visited in over two years. I expected to get asked for
permission to access the camera. Instead the camera just came on. That is
_NOT_ a good model for web sites that are covered in ads and scripts from all
over the net.

I'm sure Google was thinking of supporting hangouts when designing webcam
support and for the most part I agree that if hangouts always had access to
the camera that might be no worse than a native app. But, it's the browser
it's not a native app, it's untrusted code.

Even for communications sites though if I run them in an iframe they get
camera permission. In other words, say _yes_ just once and now that domain can
follow you all over the net and use your camera, at least as of Chrome 59.

I don't know what the best permission UX is. Always asking seems lame for
actual communication websites (messenger, hangouts, slack?, ...) but not
asking sucks for the open web. It even sucks on a communications website if
the camera feature is not something I use often. I don't want any app to have
permission to spy on me. I personally want to opt-in to always ask. I'd prefer
this even in native apps but especially for the web.

[https://greggman.github.io/doodles/html5-webcam-
iframe.html](https://greggman.github.io/doodles/html5-webcam-iframe.html)

PS: I filed a bug on this about 5 months ago but no word

[https://bugs.chromium.org/p/chromium/issues/detail?id=687834](https://bugs.chromium.org/p/chromium/issues/detail?id=687834)

~~~
notnarb
> As it is, in Chrome, if you let a webpage access your camera (or mic) that
> page gets permanent permission to access the camera whenever it wants
> forever, no questions asked again.

Firefox asks if you would like to remember allowing camera access (this
appears to be respected when refreshing the page):

[http://imgur.com/a/3lbt2](http://imgur.com/a/3lbt2)

Chrome does not:

[http://imgur.com/a/2aSY5](http://imgur.com/a/2aSY5)

~~~
greggman
Yes, I mentioned that in the bug report.

I get the feeling camera access should always ask from an iframe period. There
should be no "always allow" from iframes.

On top of that, given that many pages use 3rd party scripts from CDNs etc I
feel like it's pretty dangerous to give any site permanent permission to
access the camera/mic.

------
samsonradu
Wowza Streaming Engine now provides WebRTC support (beta), which is great news
since it can ingest WebRTC streams and transcode into any other formats for
usage with non-compatible devices.

As mentioned in the article already, P2P is quite heavy to scale (one-to-many
streaming) so you will likely need centralisation. WebRTC is also fragile in
the wild due to NAT. Wowza would split the NAT problem into smaller pieces at
least.

Not involved with the product, just really excited about it.

[https://www.wowza.com/products/capabilities/webrtc-
streaming...](https://www.wowza.com/products/capabilities/webrtc-streaming-
software)

------
aphextron
WebRTC badly needs interop with the official Bittorrent protocol. It's a neat
API for now, but doing this would allow web clients to take advantage of the
massive seedbox infrastructure already out there, making it actually useful.

------
allpratik
Shamelessly plugging a job requirement here! But it is hard to find people who
love taking on challenges like this. WebRTC based development is hard and
scaling it, is even harder. We're developing a WebRTC based product to be used
on massive scale.

And we have an opening for experienced NodeJs backend guys. We'll give you
opportunity to transition in WebRTC role as well.

If interested and experience in NodeJs ecosystem please forward your CV to
mail ( at ) khandagale.com while mentioning HN in title.

Position Location: Remote/India Min exp needed: 2+ yrs

------
Pigo
So none of this functionality would work for mobile browsers? Or can you at
least receive messages somehow?

After some googling I found OpenWebRTC which says "WebRTC standard would
transcend the pure browser environment and that native apps, implementing the
same protocols and API's, would become an important part of the WebRTC
ecosystem". But I thought the beauty of this would be transcending the need
for native apps.

~~~
dmm
WebRTC works on android and will be supported by iOS 11, due to be released
later in 2017.

> But I thought the beauty of this would be transcending the need for native
> apps.

Right now the only implementations of webrtc are web browsers so if you want
to use webrtc on a server you have to run a browser environment like electron.

~~~
matthewmacleod
_Right now the only implementations of webrtc are web browsers so if you want
to use webrtc on a server you have to run a browser environment like
electron._

Wait, that's not right, is it? There is a native implementation for iOS for
example (demoed in this app: [https://github.com/ISBX/apprtc-
ios](https://github.com/ISBX/apprtc-ios))

~~~
dmm
You're right. What I said didn't make sense. I was just trying to communicate
that although webrtc is sold as a peer-to-peer technology that can avoid the
use of intermediate servers, there are compelling use cases for client/server
communication using webrtc and that requires a server-side webrtc
implementation.

There are two webrtc implementations that I know of google's native
implementation from chromium and openwebrtc. That project uses google's.

------
tenryuu
Screensharing dabbles into Firefox, but doesn't offer any instructions for it,
even though it's properly supported by the browser

~~~
cpncrunch
You can use these constraints in firefox:

var mediaConstraints = { video: { mozMediaSource: "screen", mediaSource:
"screen" } };

Alternatively, replace "screen" with "window" to share an individual window.
(Unfortunately there is no single constraint that will allow the user to
choose either window or screen, as there is on Chrome).

~~~
nomercy400
And you have to set a value in about:config to whitelist your domain. Or has
that changed?

~~~
cpncrunch
That changed a few months ago...no need to change any values or whitelist
anything now. However, the UI does default to "no screen", so the user has to
specifically choose "entire screen" from the drop-down list.

------
n-gauge
What I would like to see is something like:

var conversation = new dataChannel("Chat") // if 'Chat' is valid then join
'Chat' else create a new connection

if (conversation.init) {

    
    
       onConversation.receive(fn); // some event model
       conversation.send("Hi"); 
    
       // some receive fn...
    }

------
bflesch
This is a great guide, really appreciate it.

------
nottorp
They missed the most important piece of information about this:

How the hell do I turn it off in all my browsers?

------
davidcarrington
Helpful site to test for WebRTC IP leaks.

[https://privacytoolsio.github.io/privacytools.io/#webrtc](https://privacytoolsio.github.io/privacytools.io/#webrtc)

------
z3t4
"Chrome extension not found"

