
Hello Firefox, this is Chrome calling - robin_reala
http://blog.chromium.org/2013/02/hello-firefox-this-is-chrome-calling.html
======
kyro
Yes, please, please, please kill Skype. Kill it mercilessly. Using it has been
the _worst_ experience I've ever had with an application.

I've been in a long distance relationship for a few years now and Skype has
sadly been our main mode of video communication. The app crashes when I search
chat history, can take upwards of 90+% of my CPU, literally forcing me to shut
down every other application I have running. The forums are _full_ of
complaints, all unanswered. We've tried gChat and the plugin either goes
undetected or slows down my machine as well (although not as bad as Skype).
I'm running a 2010 MBA, so I've got the resources.

So death to Skype, and open arms to WebRTC.

~~~
lightyrs
Have you tried Google Hangouts? I've had some success with that lately over
Skype.

~~~
gcb0
i tried and it's a pain to install the plugin. never works on my debian-sid.

~~~
donniezazen
It works flawlessly on Ubuntu, Fedora, Arch, etc. I have tried in all these
distros myself.

------
dbaupp
I feel like DataChannels are the best part of the WebRTC standard (or would
be, if they were usable): a true p2p connection allowing transfer of arbitrary
data without plugins or anything. This gives multiplayer games, file
transfers, realtime chat and collaborative editors (let your imagination run
wild...) and the only thing a server is required for is establishing the
connection (and saving state). This functionality is much more exciting than
simple video or audio chat.

~~~
comex
Unfortunately, if this page is accurate, DataChannels don't really work yet:

<http://www.webrtc.org/chrome#TOC-Data-Channels->

A shame, because I have a use in mind for them. :)

~~~
phowat
It works on some alpha release of both Firefox and Chrome. There are already
some file transfer apps if you're curious, although I haven't tested myself:
<https://github.com/lindstroem/FileTransfer> and
<https://github.com/peer5/sharefest> . Also, the folks from easyrtc (
<https://github.com/priologic/easyrtc> ) have already started working on
adding DataChannels to their library.

~~~
tracker1
A bit-torrent like client in the native browser would be interesting... wonder
where Opera is on this one.

------
Jabbles
Note that Chrome (or the application) chooses to reverse the self-view so that
it acts like a mirror, whereas Firefox (or its application) chooses to display
_what the other person sees_.

It's a hard choice to make.

~~~
timdorr
Actually, not really. It's all HTML 5 video elements on the page, so this is
all you need:

    
    
        .mirrored { transform: scaleX(-1); }
    

And you can make a button to add/remove that class as needed.

However, I do hope the implementations are consistent as to which way it flips
the video.

~~~
bajsejohannes
Changing it is easy. Adding options is an easy way to avoid choices.

But Jabbles' point still remains: It's a hard choice to make.

~~~
untog
I don't think it's a hard choice for the browser to make- send the data as it
is captured by the camera. How that is displayed is something else, but as
timdorr demonstrates, it's not difficult to toggle.

~~~
criley
It's a hard choice for the human who has to pick one or the other and justify
that decision.

~~~
untog
In what way? The developer should have no problem justifying the decision.
"It's what the camera sensor sees".

I absolutely understand the application in webchat and why you would want it
to be mirrored _at a page level_ , but I'm at a loss to understand why the
browser implementation would try to reflect that.

~~~
wubbfindel
"reflect" tsk boom!

------
jstalin
Well, it's encrypted, so that seems like a reasonable alternative to the
potential of being spied upon when using Skype.

~~~
superuser2
So is Skype. Unless there's evidence that Google couldn't be compelled to
comply with US law and honor a legally binding order to intercept a Chrome
video call?

~~~
josh2600
The intercept service you're talking about is CALEA if I'm not mistaken, and
it's not yet clear that CALEA applies to IP communications.

VoIP is covered by CALEA, but it isn't yet clear if Video is covered. There's
a bit of a raging debate about this in Telco circles. There are basically two
arguments:

1) Companies that do not operate exchanges are not liable for CALEA compliance

2) CALEA compliance is not clear.

For the first argument, many folks interpret the law as only covering
companies that have equipment inside of phone exchanges (CLECs and ILECs).
There is a 3rd class of operator that is only IP with no equipment in the
exchange. It is not yet clear if this 3rd class has CALEA as a requirement
(Goolge is all IP).

On the second point, there's no clear documentation about acceptable formats
for release. Can I send raw log files? Does it have to be a csv? None of this
is clearly defined anywhere.

In short, it's a lot more tangled when it comes to video. I'm not certain the
Feds could've gotten access to Skype monitoring without $MSFT buying Skype.

------
IgorPartola
Imagine how much more awesome this will be when we also have IPv6. We will
have no more need for things like ICE [1], just direct point to point
communication. Oh, and multicast for giant video chat sessions.

[1]
[http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...](http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment)

~~~
loeg
Multicast on the internet is a nice dream. Will it actually happen with IPv6?
My understanding is there is a barrier to adoption ­— basically all routers
involved need to be aware of the multicast initiation/join/leave protocol, and
basically, there's a bunch of old hardware/software out there that isn't
aware. Is all IPv6-capable hardware capable of this (given that IPv6 came out
in ... 1998)?

~~~
0x0
I had the impression that the biggest hurdle for multicast to happen on the
internet is the insane memory requirements for routers to track all the
multicast memberships (as well as being extremely open for abuse -- imagine
one client subscribing to every multicast stream out there and never leaving,
that would flood the incoming pipes for that ISP)

~~~
Ironlink
While I don't know anything about how multicast is specified, I would
certainly hope that it is possible to implement in such a way that each router
only needs to track the memberships of it's direct neighbors. They would then
themselves advertise that membership in order to serve their neighbor's
request.

As for the abusive client, I say if the ISP has any sense of self
preservation, they should be interested to police this themselves. For
example, knowing how much bandwidth the client is paying for, they could
refuse additional or even cut existing memberships of that client once that
limit is reached.

~~~
wmf
The problem is that a router's direct neighbors may be subscribed to millions
of multicast groups and nobody has enough TCAM to track those memberships.

------
shmerl
It's good to see this moving forward. A few questions need to be addressed in
order for this to become really useful.

How is XMPP/Jingle supposed to work over WebRTC? I.e. in order for the browser
to connect to a standalone VoIP client for example (think of implementing
Google Talk plugin in pure JavaScript). From what it looks like, this can
require some support for this scenario in XMPP servers (not unlike they need
something to support XMPP over WebSockets). So this is really an important
piece of the puzzle which needs to be ready.

~~~
jallmann
Interoperability with V/VoIP protocols will still require a translation layer
somewhere. That can be on the browser, or on the server, but you will still
need some server-side component to relay the signaling information through
(eg, websocket proxy), or a browser-interoperability mechanism (for xmpp,
BOSH). If the remote endpoint doesn't support WebRTC's flavor of SRTP, then
you're going to have to relay media through your server.

If SDP offer/answer is still being considered for WebRTC, then that should
simplify interop a bit since media negotiation shares a common denominator
with most other V/VoIP protocols (which is really the only relevant part when
we're talking about WebRTC). Of course, all that is moot if both endpoints
can't agree on a codec to support. Opus is brand new, and no one cares about
VP8. Hardware devices are not likely to be compatible anytime soon (without a
transcoding layer in between), which leaves softphones.

~~~
shmerl
That's what I meant - most probably some server support will be required. I
hope ejabberd and others will address this. Until that WebRTC won't be useful
for building web based XMPP/Jingle clients.

Regarding codecs - most XMPP/Jingle clients support VP8 and Opus is catching
up too. It's not like there are many of them around anyway. Farstream supports
both if corresponding gstreamer components are present.

~~~
jallmann
IIRC, ejabberd is agnostic about the XMPP messages going through, you should
be able to use strophe.js to craft the proper Jingle packets from the
browser's offer/answer session description.

Given codec and SRTP compatibility with clients, eg GTalk (which I don't know
about), you should be good to go.

~~~
shmerl
But ejabberd still had to enable support for BOSH or WebSockets first. Without
it Strophe was of no use. So I assumed that similar thing has to happen with
in this case in order to be able to route the Jingle stream from the browser
over WebRTC. If the server modifications won't be needed at all - then of
course it'll simplify things. Also, clients don't always use SRTP - there can
be other methods like ZRTP for example.

~~~
jallmann
ejabberd already supports BOSH. The rest is up to the client since it's P2P.

------
untog
Fantastic news. I feel like the basic videochat model we see in WebRTC demos
is only the beginning of the possibilities here.

When all browsers support WebGL and WebRTC I'll be fascinated to see what
people more creative than myself can create.

~~~
nwh
Chrome now has WebGL enabled for everyone that supports it, which is a big
leap towards getting the majority of users on compatible browsers.

------
taeric
I have a terrible confession to make. I can't bring myself to be too excited
about this, yet. I can already make a video chat from my Linux box running
either Firefox or Chrome to my mother running IE. What, exactly, are the
benefits of this?

~~~
macleanjr
No third party plugin is required to be installed.

~~~
taeric
I get that, though I do not necessarily get what makes that so awesome.
Essentially, my browser is already a third party plugin to my computer.

I think I would be more excited if this were distinct plugins running in the
respective browsers. Would be much more indicative of a truly free
environment, instead of just two of the top contestants doing something.

~~~
hayksaakian
It's so that if you tell your mother to get google chrome, she does not also
have to get a separate plugin.

~~~
taeric
You aren't exactly making this sound more free. I would honestly prefer it if
I could just buy her a large TV and we could setup video calls with it. (They
already have cameras built in nowdays.) Hell, why stop at the TV. Her phone
likely has all that is needed for this. Does this go any further to making
that happen?

I guess I can see how it does. I mean, the idea is that this protocol can be
used to communicate between two vendors. But, that can already be done. It is
done, on a regular basis. What, exactly, makes this special?

~~~
Bjartr
At a technical features level? Absolutely nothing. This provides nothing to an
end user that they couldn't already get. The only thing this changes, from an
end user perspective, is the number of steps it takes to do things.

tl;dr: This is an evolution of browser standards, not a revolution in consumer
software (from an average end-user POV)

From a developer POV, this is pretty cool because now it is (or at least, is
well on its way to being) significantly easier to build an app that relies on
real-time media shared between peers with only the only onus on the end-user
being having an up-to-date browser. The simplest and most obviously useful
application of this is a basic VoIP tool.

~~~
taeric
I think this is ultimately my confusion. I'm at the point now where I'm
actually usually advising family members on devices that rely less on
browsers. Why not show a chat from gmail/whatever in a browser to a regular
app on an android/ipad device? Even better, include another app in there. Just
to really drive home how "open" this is.

Also, why is this stuff better than SIP related technology from a while back?

~~~
STRML
I believe gchat would do that, google hangouts might integrate with the
ios/android app as well (I have not tried this).

The excitement here is that this is a non-flash solution, so technically it
will work on any device that can run Chrome, regardless of whether or not it
can / wants to run Flash. So in the near future this may make it into Chrome
for Android and iOS.

WebRTC is a very necessary step in removing Flash's hooks into the modern
internet; after this, there will be very few reasons to support it at all
anymore. And that is a very good thing for speed, compatibility, and security.

~~~
taeric
I guess I'm just confused by two points. First, the odd belief that non-flash
automatically equals good. Second, that non-flash for some reason necessitated
"in browser." Why?

Neither of these automatically grants any additional security. If anything, it
is just tying us to fewer vendors that can do this. I guess it doesn't matter,
but I can recall a time when I was able to choose which application handled
certain content type. We seem to be saying we do not want that for video now.

------
kaolinite
Awesome technology but christ that conversation was awkward. Can't wait to
play with it though.

------
hellopat
I haven't really been keeping up on WebRTC, so forgive this fairly ignorant
question.

Will the framework allow me to create a one to many connection? ie.
presentation mode where one person could broadcast their audio / video to many
viewers? Or is it simple a 1:1 connection?

------
bitwize
"Hello, Mike."

"Hello, Joe! System working?"

"Seems to be."

"Okay, fine."

------
UnoriginalGuy
Looks neat.

One thing I wonder about tech' like this, is that it is encrypted from you to
the service, but there is no assurance of privacy.

Someone who runs a service like this can easy drop in on your calls and ease-
drop. Which is a legitimate concern if someone wanted to use this either in a
corporate environment or for very private calling (e.g. husband and wife,
doctor and patient, etc).

No current video tech' really offers much in the way of assured privacy. Skype
used to but it has been largely rolled back since Microsoft took over.

~~~
untog
My understanding is that it's possible to not have a 'service' and instead
form connections from one person directly to another. That decentralization
would be a privacy boon.

~~~
taeric
Well, without knowing the details of how they think two computers can reliably
form a secure link without foreknowledge of each other, this doesn't exactly
sound bullet proof. Self signed certs or something similar can only go so far.
Hell, CA verified certs don't exactly go as far as most should be comfortable
with.

------
cmatthieu
We are in the process of adding persistent chat and conferencing to Twelephone
(<http://twelephone.com>). These features, in addition to our existing
audio/video calling and presence using Twitter as a directory service, should
put our free service near feature parity with Skype. We're using HTML5 WebRTC
with encrypted peerconnections and soon datachannels. Stay tuned...

------
Finster
Very cool, but there's still a lot that each group needs to do to be truly
interoperable. You can see a rundown of the issues on webrtc.org:

<http://www.webrtc.org/interop>

Most of it can be worked around, but for a web developer, there's still a lot
of wiring that has to get untangled for it all to work as seamlessly as it
appears in the video demos.

Definitely some cool technology, though.

------
davidw
What kind of video codec/protocol/format/platform/whatever does it use? I was
having a devil of a time trying to get something up that's real time-ish,
lately:

[http://stackoverflow.com/questions/14623963/stream-low-
laten...](http://stackoverflow.com/questions/14623963/stream-low-latency-
video-to-chrome-on-nexus-7)

------
borplk
Does this mean direct peer 2 peer connection within browser? Under what
conditions can there be direct peer-to-peer connection? For example is it
possible to have a chat application that is purely peer-to-peer?

------
christiangenco
I was very amused at how Hugh Fenning just read the script the whole time.

------
sunwooz
I was really looking forward to this! Would it be possible to have more than
one person connected in a html5 mmo game?

------
j45
It looks like it works very smoothly and the fact that no account or
additional software is needed is great!

------
gkhnarik
It is also supposed to work Chrome to Chrome right? It says the room is full.
Anybody get same error?

------
kumail_hemani
Looks great, is the Google Dart team working on getting this integrated?

------
tocomment
I'm not following what this is. Can someone explain it like I'm five?

~~~
benaiah
The first guy is talking to the second guy, even though they're very far
apart. We used to have to use a special part of the computer for this, but now
we can use the regular part that we use for most of our other stuff.

We also used to have to ask another person every time we wanted to talk to
each other this way. Now, some of the time, we can talk to each other without
asking him first.

Explaining it like you're ten might be more useful:

You know Skype? Well, now we can do that on the Internet [Ed: I know, but
you're ten, so bear with me]. Also, we can send the video straight from one
computer to another. We used to have to send it far away, to another computer,
and then he would send it to the person we were talking to. We can also hide
what we are saying from other people.

Pretend you're mailing a letter to Grandma. Before, we had to mail a postcard
to our mean aunt, who would send it to Grandma. Now, we can put it in an
envelope and send it straight to Grandma's house.

------
tbenst
Phew, just restored equilibrium by upvoting only this submission

------
lifeguard
FF is not worried. Chrome has a conflict of interest when it comes to ad
blocking. FF will always do it better. And ad networks are a major infection
vector, so more users are needing ad blocking than ever before.

~~~
zanny
This has _nothing_ to do with the article. Though, since I just love me some
flame bait, Google will never take ad block out of Chrome because someone
would just fork Chromium and keep it in.

~~~
lifeguard
You are saying google is irrelevant to chrome? I disagree.

~~~
esrauch
Are you saying google is irrelevant to firefox?

~~~
lifeguard
I know that Netscape open sourced its code and that become Mozilla/FF.

------
dschiptsov
A final good bye to all those crappy flash-based chats.

------
pteredactyl
That's cute.

------
rsingel
Please don't let the DoJ see this video. They will want a backdoor at the
protocol layer.

