WebRTC (Web Real-Time Communication) is a technology which enables Web applications and sites to capture and optionally stream audio and/or video media, as well as to exchange arbitrary data between browsers without requiring an intermediary. The set of standards that comprise WebRTC makes it possible to share data and perform teleconferencing peer-to-peer, without requiring that the user install plug-ins or any other third-party software.
WebRTC consists of several interrelated APIs and protocols which work together to achieve this. The documentation you'll find here will help you understand the fundamentals of WebRTC, how to set up and use both data and media connections, and more.
Because implementations of WebRTC are still evolving, and because each browser has different levels of support for codecs and WebRTC features, you should strongly consider making use of the Adapter.js library provided by Google before you begin to write your code.
Adapter.js uses shims and polyfills to smooth over the differences among the WebRTC implementations across the environments supporting it. Adapter.js also handles prefixes and other naming differences to make the entire WebRTC development process easier, with more broadly compatible results. The library is also available as an NPM package.
To learn more about Adapter.js, see Improving compatibility using WebRTC adapter.js.
WebRTC serves multiple purposes; together with the Media Capture and Streams API, they provide powerful multimedia capabilities to the Web, including support for audio and video conferencing, file exchange, screen sharing, identity management, and interfacing with legacy telephone systems including support for sending DTMF (touch-tone dialing) signals. Connections between peers can be made without requiring any special drivers or plug-ins, and can often be made without any intermediary servers.
Connections between two peers are represented by the
RTCPeerConnection interface. Once a connection has been established and opened using
RTCPeerConnection, media streams (
MediaStreams) and/or data channels (
RTCDataChannels) can be added to the connection.
Media streams can consist of any number of tracks of media information; tracks, which are represented by objects based on the
MediaStreamTrack interface, may contain one of a number of types of media data, including audio, video, and text (such as subtitles or even chapter names). Most streams consist of at least one audio track and likely also a video track, and can be used to send and receive both live media or stored media information (such as a streamed movie).
You can also use the connection between two peers to exchange arbitrary binary data using the
RTCDataChannel interface. This can be used for back-channel information, metadata exchange, game status packets, file transfers, or even as a primary channel for data transfer.
more details and links to relevant guides and tutorials needed
Because WebRTC provides interfaces that work together to accomplish a variety of tasks, we have divided up the reference by category. Please see the sidebar for an alphabetical list.
These interfaces, dictionaries, and types are used to set up, open, and manage WebRTC connections. Included are interfaces representing peer media connections, data channels, and interfaces used when exchanging information on the capabilities of each peer in order to select the best possible configuration for a two-way media connection.
RTCPeerConnection. The only event sent with this interface is
RTCSessionDescriptionconsists of a description
typeindicating which part of the offer/answer negotiation process it describes and of the SDP descriptor of the session.
RTCPeerConnection.getStats(). Details about using WebRTC statistics can be found in WebRTC Statistics API.
RTCPeerConnection. Only one event is of this type:
trackevent, which indicates that an
RTCRtpReceiverobject was added to the
RTCPeerConnectionobject, indicating that a new incoming
MediaStreamTrackwas created and added to the
RTCPeerConnection's data channels are sent and received.
bufferedAmountproperty—has decreased to be at or below the channel's minimum buffered data size, as specified by
closedstate. Its underlying data transport is completely closed at this point. You can be notified before closing completes by watching for the
RTCDataChannelhas transitioned to the
closingstate, indicating that it will be closed soon. You can detect the completion of the closing process by watching for the
connectionState, has changed.
RTCDataChannelis available following the remote peer opening a new data channel. This event's type is
RTCErrorEventindicating that an error occurred on the data channel.
RTCErrorEventindicating that an error occurred on the
RTCDtlsTransport. This error will be either
RTCIceTransport's gathering state has changed.
RTCPeerConnectionIceEventwhich is sent whenever the local device has identified a new ICE candidate which needs to be added to the local peer by calling
RTCPeerConnectionIceErrorEventindicating that an error has occurred while gathering ICE candidates.
RTCPeerConnectionwhen its ICE connection's state—found in the
RTCPeerConnectionwhen its ICE gathering state—found in the
RTCPeerConnectionthat it needs to perform session negotiation by calling
RTCDataChannelhas been successfully opened or re-opened.
RTCIceTransporton which the event is fired.
trackevent, of type
RTCTrackeventis sent to an
RTCPeerConnectionwhen a new track is added to the connection following the successful negotiation of the media's streaming.
signalingstatehas changed. This happens as a result of a call to either
RTCPeerConnectionobject when requesting it to create offers or answers.
These APIs are used to manage user identity and security, in order to authenticate the user for a connection.
null. Once set it can't be changed.
RTCPeerConnection. The only event sent with this type is
RTCPeerConnection. Two events are sent with this type:
RTCPeerConnectionuses to authenticate.
These interfaces and events are related to interactivity with Public-Switched Telephone Networks (PTSNs). They're primarily used to send tone dialing sounds—or packets representing those tones—across the network to the remote peer.
tonechangeevent to indicate that a DTMF tone has either begun or ended. This event does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated).
toneBufferhas been sent and the buffer is now empty. The event's type is
RTCDataChannelto exchange arbitrary data between two peers.
RTCDTMFSenderinterface. This guide shows how to do so.
RTCDataChannelinterface is a feature which lets you open a channel between two peers over which you may send and receive arbitrary data. The API is intentionally similar to the WebSocket API, so that the same programming model can be used for each.
|WebRTC 1.0: Real-time Communication Between Browsers||Candidate Recommendation||The initial definition of the API of WebRTC.|
|Media Capture and Streams||Candidate Recommendation||The initial definition of the object conveying the stream of media content.|
|Media Capture from DOM Elements||Working Draft||The initial definition on how to obtain stream of content from DOM Elements|
In additions to these specifications defining the API needed to use WebRTC, there are several protocols, listed under resources.