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.
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.
This approach has been really helpful to me, as I often work on networks without Internet access (also for a long time setting up your own local signaling server was somewhat of a pain).
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.
You don't need STUN or TURN so long as you can be certain that your devices can talk to each other directly (without NAT punching or tunnelling). They exist because it's generally impossible to create peer-to-peer connections over the internet, unfortunately. Luckily, it's not difficult to set them up - [coturn](https://github.com/coturn/coturn) is a decent implementation. The major downside is that you're going to be paying for the bandwidth of anyone who can't make a direct connection.
The signalling server, though, just copies information about each peer to the other. Technically, you could transfer it any way you like - by carrier pigeon or through js-libp2p.
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.
That was my experience with it. However, I was trying to use the native android build, and I believe the browser version is much better about that stuff.
I looked into WebRTC for a few days and had the same issues with the docs you folks mentioned. What is up with that? My sense was that WebRTC is just a repackaging of many existing standards so it isn't a new tech by itself. The challenge some of us are having is that we are not familiar with each of the underlying technologies. I felt I should revise SIP, and NAT traversals before I have a hope of cracking WebRTC.
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.
The example in my blog post isn't really minimal because it assumes that you're writing your server in C++ for performance reasons. You can cut away a lot of the setup and boilerplate if you're fine with your server running on node and delegating all WebRTC tasks to a background electron process (see electron-webrtc).
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.
> 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):
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.
Not sure about in the phone, but in the desktop versions, you can click the (i)/Secure icon to the left of the website to review/change your permissions for the site.
For mobile, it looks like you can hit the vertical menu button in the top right, then the (i) icon, then Site Settings...
iOS and Android have both had WebRTC support for years now, so I don't see this as a differentiating factor. If anything, apps have the advantage of having access to some very low-level APIs that would allow you to develop your own P2P protocol.
You are wrong. ios does not have support for it. Not in safari nor chrome. I have tested it extensively. It is scheduled for inclusion in next ios release. Chrome and firefox on Android both support it and have for ages.
Perhaps so. So to be proactive we should all disable WebRTC and hopefully (fat chance) we can stifle it enough that web developers can't rely on it being available.
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.
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.
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
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.
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.
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)
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.
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).
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.
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/ has a free one
[1] https://www.linux-projects.org/