The Internet was, from very early in its lifetime, considered a
possible vehicle for the deployment of real-time, interactive
applications -- with the most easily imaginable being audio conversations
(aka "Internet telephony") and video conferencing.
The first attempts to build such applications were dependent on special networks,
special hardware, and custom-built software, often at very high prices or
of low quality, placing great demands on the infrastructure.
As the available bandwidth has increased, and as processors and other
hardware have become ever faster, the barriers to participation have
decreased, and it has become possible to deliver a satisfactory
experience on commonly available computing hardware.
Still, there are a number of barriers to the ability to communicate
universally -- one of these is that there is, as of yet, no single set of
communication protocols that all agree should be made available for
communication; another is the sheer lack of universal identification
systems (such as is served by telephone numbers or email addresses in
other communications systems).
Development of "The Universal Solution" has, however, proved hard.
The last few years have also seen a new platform rise for deployment
of services: the browser-embedded application, or "web application". It
turns out that as long as the browser platform has the necessary
interfaces, it is possible to deliver almost any kind of service
on it.
Traditionally, these interfaces have been delivered by plugins, which
had to be downloaded and installed separately from the browser; in the
development of HTML5
HTML5
, application developers see much promise in the
possibility of making those interfaces available in a standardized way
within the browser.
This memo describes a set of building blocks that (1) can be made
accessible and controllable through a JavaScript API in a browser and
(2) together form a sufficient set of functions to allow the use of
interactive audio and video in applications that communicate directly
between browsers across the Internet. The resulting protocol suite is
intended to enable all the applications that are described as required
scenarios in the WebRTC "use cases" document
RFC7478
Other efforts -- for instance, the W3C Web Real-Time Communications,
Web Applications Security, and Devices and Sensors Working Groups -- focus
on making standardized APIs and interfaces available, within or
alongside the HTML5 effort, for those functions. This memo concentrates
on specifying the protocols and subprotocols that are needed to specify
the interactions over the network.
Operators should note that deployment of WebRTC will result in a
change in the nature of signaling for real-time media on the network
and may result in a shift in the kinds of devices used to create and
consume such media. In the case of signaling, WebRTC session setup
will typically occur over TLS-secured web technologies using
application-specific protocols. Operational techniques that involve
inserting network elements to interpret the Session Description Protocol
(SDP) -- through either (1) the endpoint asking the network for a SIP server
RFC3361
or (2) the transparent
insertion of SIP Application Layer Gateways (ALGs) -- will not work
with such signaling. In the case of networks using cooperative
endpoints, the approaches defined in
RFC8155
may serve
as a suitable replacement for
RFC3361
. The increase in
browser-based communications may also lead to a shift away from
dedicated real-time-communications hardware, such as SIP
desk phones. This will diminish the efficacy of operational
techniques that place dedicated real-time devices on their own
network segment, address range, or VLAN for purposes such as
applying traffic filtering and QoS. Applying the markings
described in
RFC8837
may be
appropriate replacements for such techniques.
While this document formally relies on
RFC8445
at the time of its publication, the majority of WebRTC implementations
support the version of Interactive Connectivity Establishment (ICE)
that is described in
RFC5245
and use a
pre-standard version of the Trickle ICE mechanism described in
RFC8838
. The "ice2" attribute defined in
RFC8445
can be used to detect the version in use by a
remote endpoint and to provide a smooth transition from the older
specification to the newer one.
This memo uses the term "WebRTC" (note the case used) to refer to the
overall effort consisting of both IETF and W3C efforts.