Firefox 34 includes WebRTC videochat client “Firefox Hello”
tokbox.com
tokbox.com
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.
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.
It's also incompatible with many extensions.
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.
Skype and Hangouts are both moving towards using WebRTC.
https://gigaom.com/2014/07/06/so-long-plug-ins-google-hangou...
http://www.pcworld.idg.com.au/article/559901/does-skype-web-...
EDIT: wow, relevant and factual information is downvote-worthy?
that's the main benefit (in my opinion) of adopting a common standard.
if they're doing it for other reasons, that doesn't solve the problem of easily talking to any other person online.
Hell, no. This has a major risk of a user leak.
"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?
Anybody knows what the current places and options actually are? Thanks.
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
Google is a business, and an advertising business at that. It's literally their job to try and make us believe what they say, regardless of the truth.
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.
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.
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.
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".
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?
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.
My friends are more likely to have Skype or Facebook than use Firefox.
You may think I'm short sighted, but you seemed to miss this.
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.
They assume because they are happy relying on a browser and who knows how many webapps to get the job that the whole world is too.
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).
I've played around with WebRTC in the past and I didn't know that, they really should be emphasising it more.