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.
It's still a bit annoying that Firefox is simultaneously pulling out advanced features and saying they should be left to extensions, and at the same thing adding things like this in core which seem a bit outside the browser purview.
They don't want to maintain esoteric user features they "feel" are marginal in mozilla central, but they really want WebRTC to capture a market, and they need it to be in your face for that to happen.
"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?
That's not the price for Firefox users. Firefox Hello is free. What you are quoting is the price to develop apps that use OpenTok. Disclaimer: I work for Tokbox
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.
While I generally agree, note that you can already trivially video chat with anyone who has a WebRTC-capable browser, without having to install anything extra, by simply sending them a link to https://chatb.org (or any other similar service).
Anyone with a WebRTC-capable browser (including Chrome users) can also chat with Firefox users using the link generated by Firefox Hello. The only thing that's built into Firefox (besides WebRTC support) is a convenient button to create a chat.
I don't think you need to depose skype or hangouts to be successful. I'd be happy with a fraction of their users. I'm in the process of creating an addon right now (firertc.com) that has a few features that the others lack. Unique DIDs, call recording, caller-id manipuation, browser integration, etc.
For those who really don't want it, I'd recommend Pale Moon. It's an optimized Firefox fork, has x64 builds on Windows and such even. I've made the switch in the past week and it's the most comfortable I've felt with a browser in quite a while.
From the developer:
> WebRTC. Apart from opening up a whole can of worms security/privacy-wise, "Web Real Time Chat" (comparable with Skype video calls and the likes) is not considered useful or desired functionality for Pale Moon (both according to the developers and the users of the browser at large). This is best left to dedicated programs or at most a browser plug-in.
The fact that the developer isn't aware that WebRTC is Web Real-Time Communication and not Chat is worrying. The WebRTC protocol can be used for a whole lot of stuff other than real time video chat, so if they're disabling it then that's a shame for their users. For one, you can use it to transfer files between two users without having to upload to a server in the middle - that's a privacy plus, not a threat.
Not to mention it adds another party you have to trust not to insert unwanted/malicious code into your browser.
When I get binaries from Mozilla, I only have to trust Mozilla. When I get binaries from my distro's repositories, I only have to trust Mozilla and my distro's maintainers. Both of those are entities I know and trust already, so I'm comfortable with that. But I don't know anything about Pale Moon.
My favourite ever comment about Pale Moon, for which I unfortunately can't remember the original source, is that it is "snake oil for users who are convinced that compiling with -O666 -funroll-all-loops will give them a better browser".
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.
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.
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
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.
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.
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.
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.
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.
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> for more information about the security architecture.
[1] DTLS is just TLS with the obvious extensions needed to work over UDP instead of TCP.
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
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?
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.
> 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.
I might be blind, but I thought it was only a open API to connect to their services. One couldn't run this without utilizing their servers and services. http://vimeo.com/48983878 reads like this too, and I can't find out how to setup an open tok media server, either.
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?
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
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.
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.
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.
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.
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.
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 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".
You can do that with SIP now. But with email, getting a bunch of spam can be handled in bulk, and letting a few slip by isn't disastrous. With phone calls, it could be much worse. As I understand, Google killed xmpp federation for precisely this reason.
You can say that, but Google has stated it's because federation was not used that much and that the spam aspect of it was the dominating usage. Which makes total sense and XMPP does not solve it, and in fact it's hard to see a solution for this problem that doesn't rely on a centralized solution.
Feel free to propose one. Because if you can solve it for XMPP, you can probably solve it for SMTP and become a billionaire for fixing spam.
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.
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.
> I just don't understand what it has to do with my browser.
Your browser, assuming Chrome-based or Firefox-based, already contains ~90% of a video call system in the form of WebRTC. This is Firefox deciding to implement the rest as a bundled extension.
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.
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.
Not to mention that I'm more likely to use Firefox than to sign up for a Facebook or Skype account. I think one browser (and potentially others) building on a feature is better than requiring someone to sign up for an account on a site/service that they otherwise may not want.
Either way, that's just my preference. Facebook and Google and Microsoft are perfectly welcome to build their video chat services on their respective networks and I think that Firefox is also welcome to try to build that functionality into their browser. As long as you can disable it if it causes issues (or better yet, need to enable it with a button making it opt-in rather than opt-out) I'll be glad to check it out and see if it's useful.
I remember using AIM and ICQ and other IM programs until Google built chat into the Gmail web interface. Starting that day I moved away from one service and started using another despite the fact that I hadn't really considered the option before.
If Firefox's implementation sucks or isn't enough to get people to adopt it (a la Google+ in the minds of most potential users) then nothing will change. If it turns out to be useful and well made then maybe people will find something superior to their current chat platform.
That said, I don't think their main roadblock will be resistance to using a particular browser. It will be from people in the general userbase wanting a chat platform that works on mobile as well as in the browser or on the desktop. I use GTalk/Hangouts specifically because it's the same across my home computers, my work computer, my Nexus 5, and my iPad. I know plenty of people who use Facebook or Skype for the same reasons.
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.
Nothing, but we long crossed that threshold. The browser has largely usurped the operating system itself for end users (with the nasty side effect that you're no longer relying on self-contained desktop applications, but on entire networks of machines even for the most trivial of tasks), and according to Ohloh/Openhub Chromium is almost as big as the Linux kernel, just a million lines short.
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.
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.
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.
Back in the day when you didn't have support for FTP in Windows (XP), you needed IRC just once to visit some obscure chat room or you downloaded torrents only every once in a while, Opera could be all this for you. No need to download stuff for one-time use.
Gone now though, along with magnificent Dev tools, mouse gestures and tab groups and previews. Had to switch to Firefox (not to say its bad, its quite good, but I liked Opera's experience better).
Right, cycles. Firefox was really a slimmer Mozilla, but the web world has changed and Firefox is a vessel for new usages. I wonder what it's descendant will look like though.
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.