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.
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 [RFC 3361
] 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 [RFC 8155
] may serve as a suitable replacement for [RFC 3361
]. 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 [RFC 8837
] may be appropriate replacements for such techniques.
While this document formally relies on [RFC 8445
], at the time of its publication, the majority of WebRTC implementations support the version of Interactive Connectivity Establishment (ICE) that is described in [RFC 5245
] and use a pre-standard version of the Trickle ICE mechanism described in [RFC 8838
]. The "ice2" attribute defined in [RFC 8445
] 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.