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.
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. Chrome doesn't allow WebAudio input from a remote WebRTC Mediastream yet.
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.
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.
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.
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.
H.264 video
Support for H.264 video. A WebRTC compliant browser should support both H.264 and VP8 video.
VP8 video
Support for VP8 video. A WebRTC compliant browser should support both H.264 and VP8 video.
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.
srcObject in media element
srcObject is the way to indicate to a video or audio element that it should play a MediaStream (createObjectURL obsoleted in std).
Promise based getUserMedia
GetUserMedia has moved to mediaDevices (instead of hanging directly on navigator), and uses Promises instead of callbacks.
Promise based PeerConnection API
According to the latest W3C specification Promises should be used instead of callbacks.

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

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.