It's in development in WebKit, it has been for a long while (the author just noticed it now and went with the full-of-assumptions article for the ad money) and it means absolutely nothing. Yeah, it will probably (and hopefully) one day end up in Safari. On the other hand, it also wouldn't be the first time WebKit had a feature that Apple chose to disable, especially on iOS Safari.
Apple has traditionally locked down mobile Safari to a far greater extent than desktop Safari when it feels there is a compelling UX or security reason. For instance non-fullscreen video is not possible on mobile Safari, but easily doable in desktop Safari and native applications. I'd expect this to be similar at least initially - it could still come to mobile Safari some day, I just think the initial release will be for desktop.
While I understand there's an argument to make on standards for them supporting it in mobile Safari, a mobile web browser is really a lousy place to build software like this. Customers are going to be much happier using a native application. We could certainly get into a discussion on what Google is doing with the mobile web on Android that would make mobile Safari support more important, but Apple is not going to be moving away from installable Swift/Objective-C based applications for the foreseeable future, and that's going to remain the best implementation route for a while.
There are really only two viable options, both plugins. The first is Flash, but the problem here is that you need a Flash media server on the back end. Twilio Client release branch 1.2 implements this. The second is the Temasys plugin which allows you to run WebRTC as you normally would in Chrome. Neither are good options to be honest.
I wouldn't assume that. Since Safari Technology Preview is going to be updated every 2 weeks, as soon as WebRTC is stable enough, it'll be included in the Preview.
I'd be surprised if WebRTC isn't on the list to be a major feature of Safari in this fall's OS X 10.12 release, which will be previewed at June's WWDC.
That's why site-based VPNing is considered the gold standard. Instead of using a VPN client on a PC, you use a network appliance, that way the PC never has a concept of what your "true" IP is. Thus cannot leak it.
Some people have been toying with doing the same but using Virtual Machines. The VM wouldn't have a concept of what the true IP is and since everything goes through the virtual router it acts like a site-to-site VPN connection hiding your true address.
It looks like it, but with pfsense you get more control I think. I have several more segments (read: virtual adapters) that route through a VPN or just from my home ip.
So then I can go to mange>adapter settings>lan segments in my vmware settings and change my upstream gateway. This is all 100% transparent to the programs running inside the VM (only problem is that not all protocols support being routed in this sense).
But tcp works, as does DNS over tcp, so most programs you use will work.
Which is great on a desktop or a home office situation. That's what I have. But for mobile situation where it's just your phone and the telco, that is not an option (unless you're in the habit of carrying a suitcase with your appliance).
The problem with this is that the VAST majority of endpoint appliances don't support OpenVPN. You're limited to PPTP, L2TP, or IPSec with pretty much every single vendor.
The important issue is that some WebRTC capable browsers can leak your internal address to a random page you are visiting even if you are not using WebRTC. If you are actually using WebRTC then you probably don't care if they know what your internal IP address is. ... that is of course if you ever care...
Reminder: WebRTC data channels can silently leak your internal and (if behind a VPN) real IP address.
I have been writing an MMO server, and I would be glad to use WebRTC datachannels, but only for client-server communications. I am far more interested in UDP-like semantics than peer to peer.
>This demo secretly makes requests to STUN servers that can log your request. These requests do not show up in developer consoles and cannot be blocked by browser plugins (AdBlock, Ghostery, etc.).
That's a bit of an overstatement. Running NoScript. No scripts, no WebRTC.
Well, imagine you're in a controlled environment (eg, China) and having your non-vpn IP leaked could compromise your identity. Having an easy way for a site to reveal you is therefore a security issue.
Even if he is, it's still information that doesn't need to be revealed. It's not a security issue in and of itself, but if combined with another exploit, it could help an attacker. Good security is all about layers and protecting information.
LAN IPs are also useful for distinguishing computers from the same external IP which could help compromise your identity or privacy.
And I'm fairly sure my Sys Admin won't want random websites knowing my internal IP address.
Network shares etc. would likely be somewhere on the same range and they could launch subsequent attacks to try to sniff confidential documents and resources.
Again: that is a problem. If that is possible your internal network is insecure.
The castle and moat model is obsolete anyway. Most attacks today come through "pulled" vectors that bypass the firewall. If you rely on a physical network perimeter for security your security is an illusion.
No, any website can detect your local IP address, then use ajax to scan a targeted IP subnet range fairly quickly (and completely hidden from the user) to find any shitty CORS-enabled web interface your company has (think some "modern" internal accounting webapp that enables CORS for its "API").
Prior to WebRTC you'd have to scan much larger IP ranges to try and find internal network webapps that are CORS enabled.
Browser fingerprinting. If a site knows your Internet-facing IP address and your local IP address, then they can uniquely identify you, even if you delete your cookies or use private browsing mode.
This is huge for many of us working with WebRTC for video (or audio), because the only way for Safari users to have the same experience as other browsers was through a plugin.
By closing this gap, you can have the same experience for 99% of desktop users. iOS will stil require a native app (I really, really, really hope they will implement it there next).
The use case I'm working with is embedding video as part of live support for retail, and we're looking at doing more than that.
Why does it matter: my personal belief is that WebRTC might be an important enabling technology for VR or AR-based shopping experiences (We actually applied to Y Combinator with that, but got rejected).
Sweet. Any documentation to point at? I am trying to stream the microphone of my iPhone through Safari and could not find any compelling way to do so, with plugins or anything else.
WebRTC can be used with TCP or UDP, so that's really beside the point. I'm waiting for WebRTC on Safari, but I use TCP exclusively for a number of reasons. (I transmit the data myself, and don't use PeerConnections).
Legitimate question, outside of WebRTC, plugins which are icky, and Flash which I hope dies a fiery death in a chlorine triflouride fire, is there any other options for doing browser based audio and video chat? It'd be cool to know of alternatives.
Rhetorical follow up, if it's the only wagon in town that doesn't either require you to maintain several different plugins for several different browsers (plus having users install them), or doesn't run on my OS (Thanks Adoma/be), how is it a bandwagon instead of a future standard? That makes about as much sense to me as talking about the CSS bandwagon, or the http bandwagon, or the TCIP bandwagon.
> how is it a bandwagon instead of a future standard
Not saying I subscribe, but there's a view that a web browser should be for browsing web documents, not peer to peer video. There are limited development resources, and some feel those should be allocated to making web browsing faster and more power-efficient, rather than making a new networking platform and dealing with all the performance, compatibility, and security work that entails.
There's the cynic in me who thinks that the year of the linux desktop is when everything runs in the browser anyway. After switching away from windows, proper web clients have been a godsend for those programs that think: "linux port, lol nope". Considering I'm working in China right now and there's a sizeable population still running XP, that's happened quite a bit. Anything that makes that easier to do is a win in my book.
If I wanted to spartanly text browse the web, I'll point emacs at an URL. Not gonna waste cycles on all those silly stylesheets.
Safari and IE don't support the Stream API either, that's the more critical piece you need to get pluginless video into the browser. Without WebRTC, you could still do server-mediated audio/video chat but access to the webcam and microphone hardware is a prerequisite.
This is excellent news! Now we have all the major browser vendors committing to include WebRTC. I look forward to seeing this get implemented and deployed.
They can't. It uses a bunch of technologies they licensed, but which they have no rights to open up for others to implement. Apparently when he made the announcement Steve Jobs thought that it was all based on open technology, but the licensing turned out to be a can of worms.
That sounds really presumptuous, since chances are high @amelius knows about the alternatives, and since it's still a great point even with the alternatives; if I want to use Linux, great, good for me, but I'm not going to walk around trying to convince all my friends & family that are happily using FaceTime to switch to something that requires an installation, is harder to use, and is not integrated with the calling features of their devices.
No, they use a bunch of nonstandard extensions to WebRTC that basically amounts to the plugin. This is why the plugin is required on Firefox, even though it supports WebRTC.
I am curious about this, since I assumed that Google would have put in quite a bit of effort to make sure that Hangouts is competitive in terms of bandwidth usage across platforms.
Do you have any performance figures?
And a harder question: any ideas as to why this is the case?
Anyone with more experience in this area know if WebRTC would be useful for building a distributed hash table? It looks like it isn't just for audio and video data.
Apple could support H.265 with hardware acceleration, which would make this very interesting. Also will be instructive to see their specific choices on WebRTC/ORTC implementations.
STUN server is not a real solution. It is typically unable to penetrate NAT. Maybe WebRTC will work sometimes, but it is not a reliable solution. It is difficult to come up with alternative to Skype until IPv6 is widely adopted. But when we get IPv6, every computer will have its own address, then yes.
TL;DR: Does the same as STUN but also is able to relay video & audio for hosts where STUN fails.
I'm using it in a Android app of mine for video conference and works really good. You can download something like coturn and drop it in a 5$ digitalocean and run with it.
Though I agree with you that IPv6 will be a boon to P2P networking, your statement is mostly incorrect. STUN can penetrate the most common types of NAT including full-cone, restricted-cone and port-restricted-cone[1]. As the other comments note, TURN can almost always get the job done with other NAT configurations.
The WebRTC API is actually surprisingly robust. It was built with these limitations in mind, so client code can supply a list of STUN and TURN servers, which the ICE framework underpinning WebRTC uses in the order they were supplied. So if setup correctly, WebRTC clients can use TURN as a backup when STUN isn't enough.
Here in Brazil, all NATs are either defective or ``symmetric'' whatever this means I am not an expert sorry. I do not expect STUN to work. As for TURN, this means traffic will go through the server. Then how is it better than Skype? Microsoft can afford, if I understand it correctly, a huge network of TURN servers, essentially. Is this how Skype works?
Finally Apple has taken the plunge! This is good news for companies which are based on WebRTC such as the one I work for. This will give us more work but we couldn't stand the wait any longer for this release! Today is a good day!
I use appear.in every day. 1-click video chat with no account sign up. The ease of launching is what keeps me coming back, even though it seems a little buggy now and then (which might be the early WebRTC support, who knows).
I actually used this a couple days ago for an interview. Cool stuff. The UI needs work, but functionality wise, really impressive. The quality was great and there were 3 people on the call. I'm not sure how it'll handle much more than that, but it worked great without any hiccups.
Just looking at startups is not enough to evaluate the impact of WebRTC. Call center tech companies worth their chop have been working with this tech for a while now as it will save money and lower the barrier of entry for their customers.
The other companies paying attention to this are the chat companies/products (slack, hipchat, etc.) - having really simple reliable calling and videochat in their products is going to be a competitive feature going forward.
Startups 100% focused on WebRTC? not many as per startup/high growth definition... The question is tricky, but I'd say that some of the startups using WebRTC as a key part of their offer are: Twilio, Tokbox, Plivo, Tropo, Slack....
We just launched a hardware video conferencing device that uses WebRTC. https://pluot.co
We route all media streams peer-to-peer. Which gives you the lowest possible latency and highest possible quality on a decent network connection. But, as other comments here have said, using a mesh topology has the downside of degrading badly if you have more than four (or so) participants in a call.
We'll add bridging in a future release, to support larger meetings, but it's actually fairly difficult to make a "routing media through the cloud in real time" architecture rock solid -- high quality and reliable for everyone, all the time. We've got customers in eight countries, so far, for example. So we'll need servers in multiple data centers, but somebody on an international call will always be farther from the bridge than is ideal.
We've surveyed a lot of people about video conferencing, and there's a lot of dissatisfaction with Hangouts and other similar products, much of which comes down to call quality, much of which is attributable to the difficulty of bouncing media streams through centralized servers.
We were in the most recent YC batch (W16) and a bunch of YC companies use our stuff. The basic idea is that big screens are super useful for team meetings, engineering standups, customer demos, etc. But big-screen video conferencing hardware has always been really expensive, or something you have to cobble together yourself. We're turnkey, set up in five minutes, are super easy to use, designed for getting real work done, and the hardware is free. You just pay $50/month per room, and there's no commitment (you can send us back the hardware and cancel any time).
You can try the Chrome browser version of our call stack from any laptop/desktop: https://pluot.co/new -- that bounces your browser to a new, unique, permanent meeting URL.
We've been following the Apple WebRTC development for a while, because we'd love to support Safari with no plugins, just like we can Chrome. We're hoping for full mobile WebKit support, too.
> We're turnkey, set up in five minutes, are super easy to use, designed for getting real work done, and the hardware is free. You just pay $50/month per room, and there's no commitment (you can send us back the hardware and cancel any time).
So, am I understanding it correctly that your main distinction from Google’s Hangouts-based offering is the pricing model? See https://www.google.com/work/chrome/devices/for-meetings/ (800 USD one-time). I haven’t personally set it up (just used it a lot), so I’m not entirely sure if your statement “designed for getting real work done” implies that Google’s lacks in that regard…?
Pricing is a difference. But we also think our UX is easier, in general, and a better fit for project, design, and engineering meetings. We made lots of little UI choices that we think add up to a different level of ease and productivity. Here are the big things:
We support two TVs (if you have two), and two simultaneous screen shares.
Our hardware has WiFi, in addition to Ethernet.
You control a Pluot box using your phone or laptop. So our "software remote control" always shows you only options that make sense for whatever the state of the Pluot call is, at the moment. There's no remote control to learn or lose. And we can continually update the "software remote control" to improve and simplify things.
Hangouts can be futzy because of how Google thinks about identity. It's pretty common for people to have trouble getting calendar invites and joining meetings because they have multiple email addresses but the Google Apps/Hangouts don't treat all of those email addresses equally. We opted for a "no sign in" approach, after doing a lot of user testing. Calendar integration and "identity" is great, when it works, but a real pain when it doesn't. Google's tight integration of Hangouts, Apps, and sign-in is a double edged sword.
Leaning on the Google WebRTC stack for the software that runs on the Pluot hardware device has been fun and interesting. We wrap Chromium (via Electron nee Atom Shell) with a UI designed to take full advantage of the HD TV (or two TV's) pixels and a provide one-click meeting start via any browser that has been paired with the room as a remote control using code displayed on the TV.
The web client uses largely the same code as the hardware device to perform its call machinery and screen shares.
We'll try to write more about this in the days to come, this week we're turning screwdrivers in the garage to ship orders, and updating the web layouts to be consistent with the in-room experience.
We do notice however, that the quality and performance of current webrtc videochat depends a lot on different conditions and we believe that it is still somewhat early for a robust experience all around. This will hopefully change when new codecs become mainstream.
A lot of our current clients are attracted by the videochat option, but in practice just use our co-browsing solution combined with a phone call. It is just very annoying if you want to give a remote product demo to a prospect and you'll need to spend time debugging audio/video issue's.
I wanted to like Talky but I tried having a large group conversation there (10-12 people) and it was laggy, some people couldn't see other people, and other people would drop from the call randomly. A few of us had fiber connections but it didn't seem to make any difference on the connection quality or reliability. We had to move to Hangouts just to be able to hear and see each other clearly.
Peer to peer in WebRTC is limiting and we suggest no more than 4 participants. If you want more than 4 you can use a Selective Forwarding Unit (SFU) such as Jitsi or a Multipoint Conferencing Unit (MCU). WebRTC is more than peer-to-peer but it depends on the implementation.
If you need some help or have questions please contact us at hi@blaccspot.com or visit our website at https://www.blaccspot.com
This is an important distinction to say P2P webrtc is limiting. WebRTC is just a collection of protocols, codecs, etc. There isn't anything stopping you from using WebRTC as a user endpoint that talks to a centralized server. I used google's java wrappers included in their WebRTC implementation to get a toy server working.
I played with the idea of relaying a stream across multiple nodes and it works. What I was doing was kinda silly I guess since it is way to cpu intensive to open so many media streams, but the general idea works. I guess it would be better to have the user endpoint talk to the server through a mediastream and then transcode the data for consumption like other systems do it.
I'm sure it's amateur compared to a project like Jitsi, but was still interesting to get working. I haven't played with it in several months but the code was here: https://github.com/jgrowl/livehq
One of the fundamental limitations of WebRTC is that the protocol is by nature peer-to-peer, so group video chat is a many to many (every client sends their video stream to every other client) network bandwidth hog!
I am extremely impressed by appear.in, however, with any more than 4 people on video chat, even with everyone on broadband connections, it became laggy and choppy at 5 and 6 participants. The reason is simple: as soon as 1 person consumes their upstream bandwidth by sending their video stream to 5 or 6 other clients, their video/audio becomes unstable, and it becomes impossible to communicate when a few people are experiencing that.
Unless everyone is on a local fiber gigabit network, I wouldn't expect WebRTC to work well with group video chat of any more than a half dozen clients at a time.
Hangouts and other server-based video chat systems can certainly handle more because they centralize and multiplex the client streams.
Now i haven't worked with webRTC in a little over a year, and my time with it was only working with data-streams, but could you have each client send a "thumbnail" size to everyone, and only send the full-size when talking or when "active" by some other means?
The client would still need to send the full size stream to every other client "when talking" so you have the same problem if the client's upstream is < 5 mbps.
You aren't! This is just a hard design problem -- mesh topologies degrade rapidly beyond two-party communications, mixer topologies introduce lag and quality issues during the compositing phase, and router topologies are still being proved out (but are probably the best option for not-huge multiparty communications). There's no silver bullet, but several options that force reasonable tradeoffs in design.
Exactly, it's just a tough problem to solve. As you so eloquently stated, the server-based solutions all introduce a terrible amount of latency (500ms-1 sec+ round trip) so they're not a silver bullet either.
The impressive things about WebRTC like appear.in are:
- Video/audio quality is extremely good - better than almost any other server-based video chat.
- Latency is extremely low because of it's direct peer-to-peer communication method. It's awesome having video chat that is <20ms round trip latency (assuming you're all in the same geographic/metropolitan area).
- HTTPS/TLS/SSL gives you end-to-end encryption, which is very nice to have.
At the cost of very high bandwidth due to the mesh topology.
I just meant that I felt a little silly for overlooking something like that.
One of my biggest pet-peeves is when people swoop into a field they know very little about and proclaim they figured it all out, and i kind of feel like i did that here a little bit and it bothers me.
I don't know of any client that settles for "good enough" based on available bandwidth. Even just audio is good enough a lot of the time (apart from one person screen-sharing); anything beyond that should be a bonus!
In general though the solution requires a server somewhere to "un" peer-to-peer everything.
vector.im and the Matrix protocol in general uses webrtc for the audio / visual calling part of a messaging protocol. It has additional functionality baked into Matrix itself for the signaling part.
But seriously, great news. I've been spending a lot of time with WebRTC and this news truly made my day. I'm an Apple fan, they just need to do better adopting standards and making developers happy.
Probably not. Apple only joined after Chrome started supporting H.264. Without Chrome support for H.264, Apple would have had to support VP8 to be inter-operable with Chrome.
The RFC is still a draft [0]; I wouldn't call this late, I'd call it waiting for a standard to settle. As a developer, I hate chasing ever-updating requirements, and as a user, I prefer stability and speed over shiny new features.
Reminds me video games, p2p is cheaper since you don't have to host your gameservers, but p2p lags hard and enabled a lot of "cheats" and so on... Plus you have to manage network issues like unpn / NAT ect..
