Is WebRTC ready yet?

Browser support scorecard

Chrome Canary Chrome Opera Firefox Nightly Firefox Bowser Internet Explorer Safari
Canary Chrome Opera Nightly Firefox Bowser IE Safari
PeerConnection API
The basic building block for connecting to peers. Defined by the W3C WebRTC Working Group.
getUserMedia
The ability to request access to a user's webcam and microphone.
The ability to request access to a MediaStream of the computer screen. This is crucial for feature parity with existing communication solutions. In Chrome, this requires an extension, unless you're using Google Hangouts which seems to be whitelisted for access to the API.
WebAudio Integration
WebAudio enables processing of raw audio. For WebRTC applications it's important that this capability not only exist, but that it's capable of being used with a MediaStream as a source.
dataChannels
Data channel support comes in two flavors: "reliable" means they are guaranteed to arrive and arrive in the correct order, "unreliable" means that order doesn't matter and dropped messages are acceptable.
TURN support
TURN servers are necessary for situations where STUN fails to produce two addressable endpoints. Which is a fancy way of saying, "getting around firewalls."
Echo cancellation
This may be the most subjective item in this list. 3 or 4 users should be able to use a service like Talky without headphones on and not experience feedback problems.
MediaStream API
When you request user media or get media from a peer it's held in a MediaStream object. Having the ability to add/remove tracks, mute, and apply constraints makes it possible to do audio processing and control bandwidth consumption.
Multiple Streams
The ability to transport multiple audio and video streams on the same peerconnection. This is important for transporting multiple streams from a centralized server or rebroadcasting streams from other peers. Dear Firefox, doing the same on multiple connections as suggested here is not sufficient.
Simulcast
The ability to acquire media streams at multiple resolutions and framerates and send them to the peer. Chrome allows this through undocumented SDP mangling.
Screen Sharing
Current extensions require an extension or a flag. It's understandable there are some security and privacy concerns around screen sharing as a feature, so browser vendors are stepping cautiously as they try to work out how this should be implemented.
mediaConstraints
The ability to specify restricted video sizes. This is important for bandwidth control. There are two aspects to this. The first is being able to specify constraints when first requesting access. The second is allowing you to apply constraints to an existing MediaStream.
Stream re-broadcasting
In order to support some of the more interesting topologies for routing data, we need to be able to take a MediaStream object from one peer and add it to another PeerConneciton. Without this, the only way of doing multi-user is a mesh network or a centralized server.
getStats API
The Statistics API allows to query various information about the PeerConnection like the current bitrate, round trip time or the number of video frames decoded.
ORTC API
An alternative to the PeerConnection API defined by the W3C ORTC Community Group. A prototype plugin for Chrome and Internet Explorer is available from MS Open Tech. This will be superseeded by native integration in Internet Explorer at some point.
Solid interoperability
Multiple browsers consistently being able to talk to each other is essential to making WebRTC a true web technology and not just something that makes for a nice demo.

See an error? This site is open source on Github, please let us know by opening an issue.

Recent conversation quality

Human reported feedback based on the last conversations.

Chrome

High Quality:

Good video:

Good audio:

Firefox

High Quality:

Good video:

Good audio:

This data gathered from the feedback form on Talky

You can help make WebRTC better for everyone—by using it.

WebRTC is one of the most transformative additions to the web platform, but it's still early days.

There's a big difference between technology that makes for an interesting demo and what's needed for something that could work on par with existing video chat products.

That gap can be closed—and data can help browser developers championing these great features to close it faster.

Here's how you can help:

Use Talky the next time you have need for a web video chat, then submit the feedback form.

All statistics are collected anonymously and will be reported publicly on this site.