dagingaa

You might want to consider a different CDN in that case.

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)

Check out: - https://appear.in/ - https://talky.io/ - https://screenhero.com/ - https://github.com/feross/webtorrent - https://peercdn.com/ - https://sharefest.me/ - ...and lots, lots more. Sorry to the ones I forgot to mention/don't know about.

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.

Opera and the newly released Vivaldi also works, but they are based on chromium/blink engines so.

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!

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.

We will investigate further. Thank you for reporting this! We definitely want graceful degradation for iOS clients.

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.

This is probably related to a known bug with Firefox 26 on Ubuntu 13.10 (and apparently other, similar Linux setups). Track progress here: https://bugzilla.mozilla.org/show_bug.cgi?id=750011

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.

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

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.

This is unfortunately a bug internally in Firefox which affects certain builds of Linux. See related bug: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/12170...

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."

Bias warning: I work for appear.in.

Appear.in itself is all WebRTC, built with AngularJS and Node. As far as I understand it, the red cross solution is built with MeteorJS, and they have built a custom queueing system into that application. The Red Cross page has nothing to do with WebRTC, but the video solution (appear.in) is.

It all comes down to the model being fairly obvious for WebRTC based video chat systems I guess. Copy, paste and appear without login and registration is the core strength of WebRTC, and there are a lot of services similar to this. I think the service that wins going forward is going to be the one that can differentiate, not in the core user model in itself, but create real user retention for the product, without breaking that core model. Monetization is also a huge issue which needs to be solved.

Bias warning: I work for appear.in.

Not yet, neither does Safari. Maybe with IE12?

Actually, they do have that. Check it out on http://iswebrtcready.appear.in/, or try to create a room on https://appear.in/