
Apple Jumps on the WebRTC Bandwagon - blaccspotmedia
http://www.nojitter.com/post/240171589/apple-jumps-on-the-webrtc-bandwagon
======
numerlo
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.

~~~
joshdickson
This is correct. This is not new, it's been "in development" for months and
it's been reflected in Webkit's public commit history for even longer.

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.

[1]
[https://twitter.com/juberti/status/701482981647474688](https://twitter.com/juberti/status/701482981647474688)

~~~
mikeash
What makes it doubtful that it'll make it to mobile Safari? (Not questioning
it, just wondering.)

~~~
joshdickson
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.

~~~
noblethrasher
> For instance non-fullscreen video is not possible on mobile Safari, but
> easily doable in desktop Safari and native applications.

It's possible on iPad, but not iPhone.

~~~
joshdickson
Yes, my bad, you're right. Do so little iPad dev that I forgot about that :)

------
diafygi
Reminder: WebRTC data channels can silently leak your internal and (if behind
a VPN) real IP address.

[https://diafygi.github.io/webrtc-ips/](https://diafygi.github.io/webrtc-ips/)

[https://bugzilla.mozilla.org/show_bug.cgi?id=959893](https://bugzilla.mozilla.org/show_bug.cgi?id=959893)

~~~
Someone1234
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.

~~~
SCHiM
Yes. This is very easy to install using PFsense inside a virtual machine.

Here's a guide that is recent and I can confirm that it works:

[http://www.malwaretech.com/2015/08/creating-ultimate-tor-
vir...](http://www.malwaretech.com/2015/08/creating-ultimate-tor-virtual-
network.html)

~~~
aaren
Is this basically the same as what Whonix does (routing through a dedicated
gateway VM)?

[http://whonix.org](http://whonix.org)

~~~
SCHiM
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.

------
GFischer
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).

~~~
Kunlun
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.

~~~
GFischer
I don't think you can stream iPhone's microphone from Safari with WebRTC.

The plugin I mentioned is
[http://skylink.io/plugin/](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/](https://webrtc.org/native-code/ios/)

or try Bowser

[http://www.openwebrtc.org/bowser/](http://www.openwebrtc.org/bowser/)

(I haven't yet).

~~~
Kunlun
Thanks, this is exactly what I found out.

------
CountHackulus
It's not a bandwagon, it's an important web standard for HTML5 game developers
who don't want to be stuck with TCP.

~~~
cpncrunch
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).

~~~
cpncrunch
Why are people downvoting a fact?

 _edit_ it looks like I misread the OP's comment, but it would have been more
useful to comment than to downvote.

~~~
quicklyfrozen
Because his point was that you need WebRTC to have access to UDP

~~~
cpncrunch
Thanks for clarifying. A comment is a lot more useful than a downvote.

------
50CNT
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.

~~~
peyton
> 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.

~~~
50CNT
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.

------
danyork
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.

------
amelius
Still dreaming of Apple opening up its FaceTime protocol, so that I can call
my friends from within Linux.

~~~
skrowl
You know there are dozens of video chat apps that interoperate between OS X
and Linux, right? Try Google Hangouts, ooVoo, or Skype.

~~~
AndrewUnmuted
None of your examples deliver sound quality that comes anywhere near that of
FaceTime Audio.

~~~
microcolonel
What a load of crap.

------
meddlepal
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.

~~~
joeyspn
Yes, there are already several implementations...

[https://github.com/feross/webtorrent](https://github.com/feross/webtorrent)

[https://github.com/feross/bittorrent-
dht](https://github.com/feross/bittorrent-dht)

[https://bitbucket.org/vardump/webrtc-
kademlia](https://bitbucket.org/vardump/webrtc-kademlia)

etc...

~~~
agumonkey
webtorrent homepage demo is so pleasing.

------
erikpukinskis
The gods have smiled on us! They allow us to continue to work on their land!

------
gz5
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.

------
oandrei
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.

~~~
abvdasker
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.

[1]
[https://en.wikipedia.org/wiki/STUN#Limitations](https://en.wikipedia.org/wiki/STUN#Limitations)

~~~
oandrei
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?

------
jlouazel
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!

------
jaxondu
What are some of the notable startups in WebRTC space?

~~~
kwindla
We just launched a hardware video conferencing device that uses WebRTC.
[https://pluot.co](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](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.

~~~
secure
> 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/](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…?

~~~
kwindla
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.

------
coetry
finally.

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.

------
shmerl
So Opus support is coming? Apple for long opposed free codecs.

~~~
cptskippy
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.

------
tkubacki
I hope this wave will kill Skype (or Skype will adpot WebRTC)

------
andrewvijay
They are late as usual!

~~~
falcolas
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.

[0] [https://w3c.github.io/webrtc-pc/](https://w3c.github.io/webrtc-pc/)

------
Thaxll
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..

