Apple Jumps on the WebRTC Bandwagon
nojitter.com
nojitter.com
Tweet from February from Google's WebRTC Project Director citing the change. [1]
It's definitely coming to desktop Safari. Doubtful we'll see it on mobile Safari, but fortunately on iOS, WebRTC support is already possible in-app.
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.
It's possible on iPad, but not iPhone.
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.
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.
Here's a guide that is recent and I can confirm that it works:
http://www.malwaretech.com/2015/08/creating-ultimate-tor-vir...
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.
[880] http://www.cisco.com/c/en/us/support/routers/880-integrated-...
But for a more reliable setup you want a business-grade router which supports it natively.
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.
My ip address is 192.168.99.105
Script tries XSS attacks on:
http://192.168.99.1/ciscowebinterface/known_dodgy_admin?user=root&pass=NEVERCHANGED1
http://192.168.99.1/juniper/also_leaky_admin?user=root&pass=NEVERCHANGED2
http://192.168.99.2/... enumeratedPrior to WebRTC you'd have to scan much larger IP ranges to try and find internal network webapps that are CORS enabled.
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.
That's a bit of an overstatement. Running NoScript. No scripts, no WebRTC.
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.
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).
Pretty certain they're still a couple of years from mainstream adoption though, but I can certainly envision lots of business uses.
The plugin I mentioned is http://skylink.io/plugin/ , but it only works for Safari on Mac.
You'll need to build a native app
https://webrtc.org/native-code/ios/
or try Bowser
http://www.openwebrtc.org/bowser/
(I haven't yet).
edit it looks like I misread the OP's comment, but it would have been more useful to comment than to downvote.
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.
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.
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.
Until video chat works without plugins I'm using the standalone apps.
I know chrome bundles the hangouts plugin. I wish it didn't and worked without plugins.
In additino, Skype is not updated in Linux since ages
Do you have any performance figures? And a harder question: any ideas as to why this is the case?
http://arstechnica.com/tech-policy/2013/08/report-after-pate...
http://techcrunch.com/2016/02/04/apple-ordered-to-pay-625m-t...
https://github.com/feross/webtorrent
https://github.com/feross/bittorrent-dht
https://bitbucket.org/vardump/webrtc-kademlia
etc...
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.
It works for me.
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.
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.
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.
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.
In general though the solution requires a server somewhere to "un" peer-to-peer everything.
If you need some help or have questions please contact us at hi@blaccspot.com or visit our website at https://www.blaccspot.com
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
The actual server code is here: https://github.com/jgrowl/livehq/tree/master/media/src/main/...
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.
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.
Streaming video internally at large enterprises (facebook, ericsson, aol). Things like CEO monthly video calls, etc.
Startups whose core value proposition includes WebRTC might be most of those doing live video customer service, like http://liveninja.com/
Y Combinator had a few in the last batches, like http://www.breakoutroom.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.
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.
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…?
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.
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.