
Firefox 34 includes WebRTC videochat client “Firefox Hello” - hobarrera
http://www.tokbox.com/blog/firefox-hello-mozilla-enhances-opentok-powered-video-chat-service/
======
hayksaakian
I see many of you complaining that this should not be built in to Firefox,
that it should be a plugin or extension.

I disagree for the fundamental reason that there is no realistic way to depose
Skype or hangouts with WebRTC unless your thing has absolutely massive
adoption (network effect).

Now I can trivially video chat with someone who has Firefox, and they don't
have to install anything extra.

This will push adoption and recognition of webrtc as a technology, and enable
competitive WebRTC based platforms to succeed as well.

~~~
acqq
[https://tokbox.com/pricing](https://tokbox.com/pricing)

"After your free trial, our base monthly fee is $50"

50 unbelievable dollars per month. That's 600 USD per year, for a lot of users
more expensive than the computer they use. How can that "depose" Skype which
is free? Am I missing something?

~~~
pharaohgeek
Tokbox provides a SaaS option for managing webRTC sessions. It is separate
from Firefox including webRTC support in its browser. There's nothing stopping
a company or site from implementing session handling on their own, and
bypassing Tokbox. Lots of places do it, and there are other options in the
service provider space anyway.

~~~
acqq
> Lots of places do it, and there are other options in the service provider
> space anyway.

Anybody knows what the current places and options actually are? Thanks.

------
Confiks
So this feature has landed in Firefox 34, but you might not be able to use it
yet, because apparently the WebRTC initiator infrastructure that Mozilla uses
(Loop) has been rate limited to include only a random 10% of users [1].

If you want to try Talk, and you're eager to 'help' Mozilla stress-test Loop a
bit:

1\. Go to about:config and set loop.throttled to false

2\. Restart Firefox

3\. Go to the right 'hamburger' menu, click customize and add Talk to the
menu. If Talk doesn't show up, you might need to do a 'Restore defaults' first

I just tried it, and it works wonderfully, even on mobile and in an older
Firefox version. The noise cancellation is not on par with Skype however.

[1]
[https://wiki.mozilla.org/Loop/Load_Handling](https://wiki.mozilla.org/Loop/Load_Handling)

~~~
padenot
Yep, we have plans to improve the noise and echo cancellation. It kind of
works at the moment, but should be much better. Also the quality is not
uniform across the platform, which is another thing we want to fix.

~~~
vr000m
For connectivity and quality issues, we built callstats.js. Which provides
google analytics type of service for WebRTC apps. Not only business metrics
but analysing ICE connectivity issues and media quality from the stats-api

------
chatmasta
I like Mozilla's new strategy of partnering with popular open source projects,
e.g. Tor, now this. It's a good strategy because Mozilla's proprietary
competitors, namely Google, might have trouble fully integrating and
partnering with open source initiatives. Further, the decision makers of open
source projects are presumably far more interested in partnering with Mozilla
than Google.

There is a lot of value for Mozilla to extract from open source, and as long
as it remains an open source company itself, it will have a "leg up" on its
competitors, and a much easier time in negotiations with open source
stakeholders. I suspect we'll see more integrations of large, popular open
source projects into the Mozilla browser.

------
AdmiralAsshat
So since this is evidently going to be baked into the browser, what security
measures will be put in place to prevent some nefarious coding from turning on
my laptop's webcam as soon as I visit a bogus site?

This is not meant to disparage Mozilla, it's honestly the first thing that
came to mind when I read the article.

EDIT: Why not answer my question instead of simply downvoting me? This is an
honest question, coming from a vocal Mozilla supporter.

~~~
bri3d
HTML5 has a provision ( getUserMedia / Stream API ) for accessing the user's
webcam and has for some time (supported for at least 2 years in Chrome and
quite a long time in Firefox as well).

This feature ("Loop") leverages this existing functionality along with WebRTC
(a web standard for peer-to-peer real-time streaming between browsers) to
create a video chat solution.

So, there's no new avenue / attack vector by which a nefarious site could
hijack your webcam, as far as I know.

The Stream API has required a user affirmation to activate the webcam and mic
in both Chrome and Firefox since its introduction.

~~~
jgrowl
Yeah, it would take a browser vulnerability for sites to just take control
without the user accepting access to the camera. In chrome, there isn't even a
way for you to accept camera access indefinitely to non-https sites. You will
be prompted each and every time.

------
higherpurpose
I hope Mozilla isn't wasting an opportunity to bring end-to-end videochat
encryption to the masses here. I know WebRTC is supposed to be peer-to-peer,
but I don't know about how they actually implemented it. So is it end-to-end
encrypted? The fact that it's backwards compatible with legacy phone networks
already makes me think it's not.

~~~
derf_
It is.

DTLS-SRTP is required for media. The SCTP data channels are also layered on
top of DTLS [1].

Now, obviously one "end" might be a conference mixer with unencrypted access
to the PSTN, but direct browser-to-browser connections will be encrypted and
there is always the DTLS fingerprint to guarantee that you're not being
MITM'd. See <[https://tools.ietf.org/html/draft-ietf-rtcweb-security-
arch>](https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch>) for more
information about the security architecture.

[1] DTLS is just TLS with the obvious extensions needed to work over UDP
instead of TCP.

------
Osmose
Repo for the server-side element: [https://github.com/mozilla-services/loop-
server](https://github.com/mozilla-services/loop-server)

------
EdSharkey
This feels very much like a pre-emptive strike by Firefox. I wonder what
maneuvering is really going on behind the scenes.

Like, is this some nuke-from-orbit reaction by Mozilla and Telefonica to
counter Microsoft's WebRTC successor proposal? Is this an attempt to force
Microsoft's hand and drive them into Embrace-Extend-Destroy-proof, true 100%
backwards compatibility with the simpler WebRTC 1.0 spec?

When I saw the over-complexity in that WebRTC 2.0 spec (or ORTC or whatever it
will be called) it made my Embrace-Extend-Destroy spidey sense tingle. (Not to
mention stoking my centralize-all-the-skype-super-nodes fears for the browser
at-large.)

Mozilla, even if I'm tilting at windmills here, you are so super! XOXO

------
dlrush
OpenTok -> TokBox -> $50/month. Really?
[https://tokbox.com/pricing](https://tokbox.com/pricing)

Reminder to self: If a telcom company is involved, a customer pricing bait-
and-switch is never very far away.

Expounding a bit further, the pricing they are proposing measures usage in
'millions of messages'. Nothing like an arbitrary large metric to confuse
consumers about their actual potential usage. How many 'signalling messages'
did you use last month fellow consumer?

~~~
wodenokoto
So an open source project is evil because a company is selling it as a
service?

The pricing structure is obviously aimed at enterprises. The free level
includes 7 days of non-stop streaming a month. I don't know anybody who
literally spends a quarter of their time on video chat.

~~~
abcd_f
> So an open source project is evil because a company is selling it as a
> service?

No, not evil. Disingenuous. The O/S project is used as a marketing ploy for
the service. There's nothing wrong with it, Google does this all the time,
just as many other companies. But if you re-read the press release it really
stresses the "we are just like Mozilla" point. They are trying to piggy-back
on Mozilla's reputation and borrow its established goodwill as a non-profit,
all the while being a commercial entity and having a distinctly different set
of interest.

------
hobarrera
Even though the article says firefox beta, this is included in the stable
release from today: [https://www.mozilla.org/en-
US/firefox/34.0/releasenotes/](https://www.mozilla.org/en-
US/firefox/34.0/releasenotes/)

~~~
01Michael10
It may be listed as included in the stable release but unless I am blind I
don't see chat as an option anywhere????

~~~
scott_karana
See here:
[https://news.ycombinator.com/item?id=8683830](https://news.ycombinator.com/item?id=8683830)

------
davidw
Speaking of which... I'm going to take a moment to ask a question in the hopes
that someone has a suggestion.

I want to do something very similar to WebRTC: transport video from a PC to an
Android phone, in real time. I need to do it with open source components and
standard Android components that can be integrated into an app. I've been
fiddling with gstreamer's RTSP server, and... so far no dice. Anyone got
something like that functioning?

~~~
woah
Webrtc?

~~~
davidw
But I don't need all the top layers, the SSL, the handshake... any of it.

------
securingsincity
We may finally be reaching the point where building WebRTC applications are
viable options. I've been interested for the last few years and every
meetup,conference, document warns about how "we're almost there." This could
be a great sign of life for those who have wanted WebRTC adoption for awhile

------
hendry
It's a real shame that they couldn't make a SIP client and leverage VOIP. VOIP
is used by a lot of businesses and I believe it would really improve Web
adoption if the Web could support it.

~~~
MichaelGG
WebRTC is sort of a hack up of SIP-similar technologies, and is definitely
VoIP.

SIP and SDP are also clusterfucks of protocols with some really, really,
terrible design decisions. (Hey, let's specify UDP _AND_ TCP, and require
clients to flip between transport on a per-message level! Why not? It's easy
to spec idiotic stuff on paper...)

Anyways, SIP does not NAT well as it assumes, like it's the 1980s, that you
are on a public IP and can directly send to any port on anyone's public IP.
Then it goes and embeds your IP all over the place, because they were too cool
for simple symmetric pipes. To make it more fun, all sorts of firewall and
router vendors try to "fix" SIP and generally just screw things up even more.

As I understand, a lot of WebRTC effort went into dealing with NAT and some
other niceties. (And apparently, arguing about codecs.) Otherwise, you're
right, there's not a whole lot to be done. Despite the terribleness of SIP, it
generally works, and VoIP engineers have figured out how to make it work
pretty well.

However, it's unlikely that re-using parts of SIP/SDP in WebRTC makes _any_
difference in adoption of things. Almost no one runs SIP openly, they lock it
down like a traditional telephony system. Best is in fact to firewall it off,
because you're rather naive if you trust all this C/C++ code parsing strings
like mad. Plus, since SIP systems are often connected to other telephone
networks with billing, even protocol-level hackery can lead to a lot of
financial loss.

So in short, it'd be super duper unlikely you'd ever be able to point your web
browser at "sip:someone@somebusiness.com", even if it had SIP built-in.

~~~
vladimirralev
SIP and SDP are not clusterfucks. Pretty much everything is done for a reason.
Often it has to do with scaling and load balancing. Flipping transports is
just a side effect of a useful feature where you send INVITE through a proxy
that doesn't record-route so it's bypassed on the next message meaning you
will have to use the transport of the next node in the chain. You never change
the transport between the original endpoints just randomly for no reason. You
are simply connecting to another server which prefers the other transport (or
is not under your control). TCP or UDP have significant differences and
tradeoffs in load balancing and tunneling traffic, each has a place. If you
are building huge telecom systems most of this makes total sense in one
situation or another.

No signalling protocol can be used "openly", there is simply too much
potential for abuse. Integration and especially selective integration on the
other hand is quite good with SIP.

~~~
MichaelGG
Well I'm, on my third pass around writing a SIP parser/stack, and I'd have to
say, no, things are not done for a reason. The silly date format ("Thu, 25
November, 1921") is a relic from the _70s_ and only there because that's what
someone happened to be doing on some private little mail system. And the IETF
just blindly copies nonsense like that, even though there's zero benefit to an
English-specific long-date format in a protocol.

SIP headers, in the wild, cannot be unambiguously parsed. This is because the
whole \r\n thing to end lines combined with the SIP RFC's instructions that
implementations should "infer meaning" ends up with some implementations
considering \n\n to be start of data, and some not. Good luck.

Not to mention idiocy like "comments in headers", "line wrapping". Or my
favourite "put headers in the querystring". Because nothing makes ensuring
your implementation is correctly following messaging (on which tons of money
may ride) than specifying not only _two_ ways to define a common header, but
adding _two distinct locations_ to find the same data.

Or the awesomeness of deciding "IP fragmentation is broken" (???) and deciding
on an arbitrary MTU size at which point you've gotta flip to TCP. Literally,
on a message-by-message basis, they see nothing wrong with requiring you to
read from both a UDP and TCP socket to get the next message for a transaction.
I'd go as far as saying they think they're being clever. The only point of
using UDP (complete with their own retransmission system to deal with
packetloss) is if you think _maybe_ you're gonna shave off 1xRTT by avoiding a
TCP handshake. Except since most calls are going between well defined
endpoints, that's not an issue. And secure calling requires TCP (TLS) anyways.
The real result is that plenty of implementations end up doing UDP only, or
only really supporting UDP. And why MS decided this was idiotic, and went TCP
only because "most of our messages will exceed the MTU". Oh, and the kicker?
IP fragmentation works fine. I analyzed a VoIP network (several terabytes of
SIP signalling) and found about 1-2% of SIP messages were IP frag'd (MTU
around 576) and never did IP frag mess anything up. All this crazy complexity
because Rosenberg et al thought they were oh-so-clever about a non-existent
problem.

The routing stuff is moronic, like IP's source routing which the Internet
decided was a terrible idea, but the IETF kept insisting on for IPv6 anyways.

I could go on, but this is direct result of writing SIP software and
implementing SIP networks for around a decade.

~~~
vladimirralev
These issues seem to be focused on the phone-side of things. Robust and high
capacity servers and load balancers have other use-cases. Unless I
misunderstand, all of these Date format, the header parsing, the commends in
headers, querystring headers come straight from HTTP itself. Can't blame SIP
for it.

Unless you want to commit fully to TCP, then the fragmentation must be taken
care of in the protocol, no way around it. Yes most networks are fine, but the
protocol has to deal with the worst-case scenarios.

UDP has a lot of advantages - two most used - the retransmissions are faster
and it's stateless. It allows to have a fully stateless SIP server devices,
reduced chance of DoS attacks or session/fd leaks. UDP allows you to play with
the queue design on the server side since you can drop messages and wait for
the faster retransmissions. UDP block parsers vs TCP stream parsers have
advantages in certain cases to optimize for memory on high traffic devices.
UDP allows for multicast and broadcast SIP functions. There are many other
little things that make UDP easier and cheaper to deal with on the server
side.

The routing stuff, some of it comes from HTTP again, and then they added a
bunch of extra stuff to accomodate some use-cases in federated environments
and chain-systems. The source routing feature is not a problem like in IP
because each server is allowed to challenge any request at any time. I've used
source routing to establish sticky sessions in a cluster so I don't force
replication everywhere for the same user and to create test calls that
exercise specific paths in a multinode system.

~~~
MichaelGG
The scenarios I worked on were for load balancers, proxies, and analyzers. All
very high performance (at peak, 5TB/day of SIP on a single quad core
processor). SIP parsing is terrible for this and leads to ugly hacky code.
Same as HTTP (look at nginx's parsing code - all sorts of crazy compares).
This is also why the HTTP replacement protocols ditched this nonsense.

Yes, a lot of stuff came from HTTP, which likewise has no excuse other than
copying previous mistakes (the date example being a prime example). Except,
SIP isn't HTTP compatible, and no implementation is going to be sharing code.
It'd beyond bizarre wishful thinking that an implementation is going to share
any nontrivial amount of code. One of the folks from the RFC explained they
aimed to make it HTTP compatible to use HTTP proxies, than gave up part way
through but didn't fix up the rest of it.

At any rate, you can blame SIP for it - no need to copy previous mistakes. And
HTTP deserves a ton of blame, and I'd be absolutely surprised to find out that
most software follows the HTTP spec. Most likely, they follow something sort
of looking like HTTP, and test on the Internet to see which subset is actually
being followed. Just like no one puts comments into email URIs because it's
stupid.

Fragmentation does _not_ need to be taken care of in protocol. IP already does
fragmentation and it works. As I noted: 1-2% of all our customers had MTUs of
~576 bytes, so their SIP UDP packets were already IP fragemented. No one
experienced problems with this, and some broken IP fragmentation issue would
also affect TCP. UDP has a limit, but they could specify a switch to TCP at
64K. Could you clarify what you mean?

UDP actually makes DoS harder to deal with as there's no handshake for
determining the other IP actually exists. Whereas with TCP syn cookies, that
particular problem is totally solved. Also, any benefits of UDP in this case
are totally negated because _implementations "MUST" support both_. Any client
or server that only uses UDP is broken. So embedded devices and the other
scenarios you mention have to handle both protocols, on a message-by-message
basis. There's no case where this is beneficial. Oh, also, since most VoIP
systems today rely on IP authentication, UDP combined with the SIP routing
rules means almost all of them are trivially exploitable. Despite this being a
rather obvious attack, I've yet to see any SIP stacks explicitly harden for
this. Larger companies hope firewalling is good enough (hint: it's not
really). Look up Cloudflare's handling of DNS-based DDoS's for another example
of why it's a bad decision.

AFAIK HTTP doesn't allow "triangle" paths, like SIP. That is, in SIP, A talks
to proxy B, which talks to client C. Then client C _sends directly back to A_.
Of course, in reality, everyone turns on record route to make it act sane, but
it's one more thing that's in the protocol and is lying in wait to screw
someone over or just make things more complicated than necessary. But in SIP,
this is not only possible, it's celebrated and drawn into diagrams, showing
off how fantastic an idea they think it is.

These kind of things arise when people act clever when writing stuff out on
paper. When you're just writing a spec, your imagination is the limit. Actual
implementation considerations are a detail that doesn't bother you. Actually,
SIP requires an AI to be properly implemented, as the RFCs suggest
implementation "infer" the "intent" of messages, which sounds like a job for
GAI. Likewise, comments in headers, headers in querystring, multi-protocol
flip-flopping, inane rewrite-TCP-inside-UDP, etc. etc. are all just a few
keystrokes away when you're making up a spec.

After all, SIP even says maybe someone would use it to start a chess game,
that's their actual example. Despite having "Call-ID" as a mandatory header,
they want to make it clear they're not about just calls! Oh no, they've
implemented a general purpose session protocol.

Look up the RFC for SIP torture tests. They revel in the fact they've created
a terrible grammar with special syntax for various headers (multiple headers
are separate, unless they're Accept, in which case combine them into a single
value). There's no need for that and it just shows what a terrible idea it is
to have text protocols without strict grammars.

For a humorous take on this: [https://tools.ietf.org/id/draft-kaplan-sip-four-
oh-00.txt](https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt) In which
he mocks the SIP design decisions, but in a very accurate way reflecting what
real-world networks actually do. My favourite line: "But this is not the real
world, this is the IETF".

------
maaaats
I have to say I don't completely understand the use case for this?

~~~
forgotpasswd3x
You don't understand the use case of a video conferencing program?

~~~
maaaats
I do, I just don't understand what it has to do with my browser. I also don't
understand why my honest question ended up with so many down votes..

~~~
simlevesque
Let me explain it to you : modern browsers have WebRTC, which enables you to
create P2P web pages. Personally I think it is has many real-world use, it
will make the web a little less hacky and it will remove some loads on servers
which is good. It is a good technology to have in the browser. Now, about
Mozilla Hello : The code added to your browser is really really small. In fact
it's not much more than address book and a visual signal that you have a
conversation going on. All the great stuff is actually on Mozilla's website.
They generate a new session for each conversation you start and you just need
to go on the site and then you give the url to someone else and they can join
the conversation on both Firefox and Chrome. I think that it is a move in the
right direction, since they are just adding some sugar to leverage a great web
technology that they helped to build and this makes a great showcase of the
power of this new technology. I also like it because I trust Mozilla much more
than say Hangout or Facebook Messenger. I know that all of my friends use
either Chrome or Firefox so there is no barrier. No signup, no installation.

~~~
hackuser
> enables you to create P2P web pages ... All the great stuff is actually on
> Mozilla's website.

That doesn't sound like P2P. Could Mozilla access call content and metadata?

EDIT: Others say it's P2P and end-to-end encrypted; so what does Mozilla's
website have to do with it? Can't they at least access metadata?

~~~
simlevesque
The website is just an interface that displays the stream and the webserver
only signals user connect and disconnect to every listeners, everything else
is P2P.

------
enimodas
Sadly all the WebRTC implementations I've seen so far require voice and/or
video, people who simply want to listen/watch and use text for chatting
themselves are not allowed.

------
bastawhiz
So wait...Yahoo! is the default search engine but you can only import contacts
for Firefox Hello from Google? I don't even.

------
bad_user
So why doesn't it do text chat as well? I often paste links or other stuff in
the middle of a conversation.

------
brooklynberger
Looks like we crashed it. I hope the Firefox integration can handle more user
than the Tokbox site.

------
LukeB_UK
This should have been created as an extension or a service that anyone can
use, not just Firefox users.

My friends are more likely to have Skype or Facebook than use Firefox.

~~~
bigtones
That is short sited. Just because you and your friends won't use it does not
mean it should not be included in a product used by hundreds of millions of
people in both business and personal applications.

~~~
LukeB_UK
It's useless if people can't communicate with who they want to. They're more
likely to use a service that they won't need to change the environment
(browser) that they're used to.

You may think I'm short sighted, but you seemed to miss this.

~~~
ChrisGranger
This service works with any WebRTC-enabled browser, not just Firefox, so
people using Chrome/Chromium and derivatives and Opera can use it as well.

------
kzrdude
Is there a good WebRTC app for Android?

~~~
derf_
Yes. I believe it is called "Firefox".

------
fotbr
What's wrong with a web browser being just a web browser?

~~~
rrradical
Ironically, Phoenix, as Firefox was originally named, was initially created as
a slim alternative to the then bloated Mozilla browser. I'm sure we'll see
history repeat itself in a few years.

~~~
JohnTHaller
In fairness, it was created as an alternative to the Mozilla Suite, so-named
because it was a browser plus a full email+newsgroup client (now Thunderbird)
plus a full calendar client (now the Thunderbird extension Lightning,
previously the now-defunct standalone calendar Sunbird) plus an IRC client all
in one suite.

~~~
bzbarsky
You forgot the HTML editor, complete with code to publish via FTP. ;)

~~~
JohnTHaller
I did indeed forget about the HTML editor, thanks! It was later split off into
the now-defunct Nvu as part of Linspire and then forked to the now-defunct
KompoZer.

------
vinothtimes
this is exciting integration from mozilla, webrtc supports only mozilla and
chrome... peer to peer , skype killer

------
mike-cardwell
I assume the video and audio will be transmitted in the clear, over the
Internet, without any sort of encryption? Somebody please correct me.

~~~
sirsar
Encryption is part of the WebRTC specification. It is actually impossible to
send WebRTC communication in cleartext.

~~~
mike-cardwell
I am shocked. Thanks for the info.

