Working for a major player in the WebRTC space certainly gives me a bias, but "noone cares" is pretty far from the truth. There are millions of WebRTC users already, hell, we might even be approaching the billion now if you count Snapchat and Hangouts as WebRTC services. (Yes, Snapchat uses WebRTC for their video chat features)
For some pure WebRTC experiences. http://simplewebrtc.com/ if you want to build something yourself.
The thing is, you don't know that the service you're using uses WebRTC, quite frankly because the technology doesn't matter, the user experience does. Also, the sheer fact that we seem to have standardised a very good (and very secure) way of doing peer to peer transfers, and that's getting implemented in browsers, with client libraries for iOS and Android is HUGE.
No, not exactly. WebRTC has no concept of interoperability between services, only between clients. You need a signalling server to communicate the initial call between clients, and if you wish to connect clients across services, then those two services would need to connect to each other in some way, which is not detailed in the spec.
There are efforts to use SIP and XMPP for this, but that only solves the WebRTC-part. If you want SIP-clients to interconnect, you need expensive hardware/software to transcode the streams, and you loose the P2P-part. WebRTC is not a golden cow of interoperability between services.
Developer @ appear.in here. I've been following this thread today, answering some questions and reporting bugs back to the team. I would just like to say a big and sincere thank you for this comment. I just posted it to our internal mailing list. In all honesty, feedback like yours truly make our day, motivates us, and makes us work even harder to create a kickass service. So again, thank you!
Which browser and OS are you on? Depending on that, it should be somewhere near the top. Firefox has a tendency to close the accept dialogue if you change tabs, and you can retrieve it by clicking the camera icon in the address bar. Unfortunately there is no way for us to improve this UX from our end, but we are working on more informative "waiting" pages.
Same here. Firefox 26 on Windows 7. No popups, no messages, no camera icon, no clues whatsoever as to how to "grant camera an access to use appear.in".
We have some guys working on FirefoxOS at our office actually (Telenor Digital does many things). We tested appear.in on a recent build of master, and it worked! Hopefully it will make it out to consumers soon. You can track support through this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=750011
I just talked to the FxOS guys, and they hope the support will be out around 1.4 or 1.5, but no promises. I don't know much more than that unfortunately.
Developer @ appear.in here. For lack of better ways of communicating, at which page did you experience this? We tested it on our own devices but couldn't replicate.
http://appear.in - just tried on iPad and got the same dark gray page with absolutely nothing on it. Not running iOS 7 on either of the devices though, perhaps check that?
I've just checked, and the (Linux Firefox) camera/mic permissions menu fails to appear on the other WebRTC conferencing sites linked in this thread, too. So it's definitely not just appear.in.
[Edited to add:] For others suffering from the same problem, the bug report linked in parent suggests it may be fixed in FF 27, which will apparently be released during the week of Feb 4th.
Developer on appear.in here: Everything between peers is encrypted using SRTP end-to-end by default. From our FAQ:
"All communication between your browser and appear.in is transmitted over an encrypted connection (SSL). Video and audio transmitted in the service is sent directly between the participants in a room and is encrypted (SRTP) with client generated encryption keys. In some cases, due to NAT/firewall restrictions, the encrypted data content will be relayed through our server."
At this point in time, all chat messages are relayed through our server. These messages are sent over an encrypted socket to our server, then relayed. This means that we do have the ability to read the messages (they're not encrypted), but we do not store them, read them, or in any way allow your privacy to be compromised knowingly.
We have strict access controls to the server, but the messages are sent via Amazon. We realise that this is not ideal, and we want to, when the DataChannels API has matured a bit, move message sending to a strict P2P model as well. There are some issues with that (total ordering of messages for one) which need to be solved first, but we're positive that those challenges can be solved.
