Is WebRTC ready yet?

Browser support scorecard

Chrome Canary Chrome Opera Firefox Nightly Firefox Bowser Edge Safari
Canary Chrome Opera Nightly Firefox Bowser Edge 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.
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 and mute tracks it possible to do audio processing and control bandwidth consumption.
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.
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.
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
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, in Firefox there is a whitelist maintained by Mozilla. 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.
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.
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 is obsoleted in the standard and leaks streams until the document dies).
Promise based getUserMedia
GetUserMedia has moved to mediaDevices (instead of hanging directly on navigator), and uses Promises instead of callbacks. In Chrome this is shimmed by adapter.js.
Promise based PeerConnection API
According to the latest W3C specification Promises should be used instead of callbacks. Chrome shims this when using adapter.js.
WebAudio Integration
Support for modifying audio using WebAudio on both input and output is important.
Canvas Integration
Support for inserting generated or modified video into a MediaStream from a canvas. Important for funny hats (and sharing games, etc).
Test support
Support for commandline or javascript flags that use fake devices or files for getUserMedia and allow bypassing user prompts. This allows for automatic testing using services such as travis-ci which is described here.

See an error? This site is open source on Github, so 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.