Overview: Real-Time Protocols for Browser-Based Applications
Extracted elements (23)
The first three functionality groups (data transport, data framing, data formats) form a 'media transport infrastructure' that can be embedded in browsers with standard interfaces, while the last three groups form a 'media service' layer where innovation is encouraged.
The goal of having a mandatory-to-implement function set is to prevent negotiation failure, not to preempt or prevent negotiation. It gives a guarantee of successful communication as long as both parties conform to the specification.
When a new codec's SDP is specified, no other standardization should be required for it to be usable in web browsers; adding new codecs should not change the browser-JavaScript API, allowing old applications to automatically use new codecs.
At publication time, the majority of WebRTC implementations support ICE as described in RFC 5245 and use a pre-standard version of Trickle ICE (RFC 8838). The 'ice2' attribute defined in RFC 8445 can be used to detect the version in use and provide a smooth transition.
The protocol specification does not assume all implementations use the JavaScript API; it is not necessary for interoperation to know whether the entity one is communicating with is a browser or another device implementing the protocol specification.
WebRTC media negotiations are designed to be capable of representing the same SDP offer/answer semantics (RFC 3264) used in SIP, enabling signaling gateways between SIP and WebRTC. It will be possible to gateway between legacy SIP devices that support ICE without using a media gateway.
WebRTC session setup typically occurs over TLS-secured web technologies using application-specific protocols; operational techniques that insert network elements to interpret SDP (SIP ALGs or DHCP SIP server discovery via RFC 3361) will not work with such signaling.
Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations.
Privacy concerns MUST be satisfied; for instance, if remote control of a camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera and possibly decide to revoke the permission for camera usage.
WebRTC browsers MUST implement RFC 8829 (JSEP — JavaScript Session Establishment Protocol).
WebRTC browsers MUST implement the W3C peer connection API [W3C.WD-webrtc] and the media capture API [W3C.WD-mediacapture-streams].
WebRTC endpoints MUST implement RFC 8831 (WebRTC Data Channels) and RFC 8832 (WebRTC Data Channel Establishment Protocol).
WebRTC endpoints MUST implement RFC 8834, RFC 8826, RFC 8827, and the requirements they include, covering media transport, security considerations, and security architecture.
WebRTC endpoints MUST implement the audio processing functions in RFC 7874, which covers echo cancellation and AGC requirements.
WebRTC endpoints MUST implement the transport protocols described in RFC 8835.
WebRTC endpoints MUST implement those functions described in RFC 8829 that relate to the network layer (e.g., BUNDLE [RFC8843], rtcp-mux [RFC5761], and Trickle ICE [RFC8838]), but these endpoints do not need to support the API functionality described in RFC 8829.
WebRTC endpoints that support audio and/or video MUST implement the codecs and profiles required in RFC 7874 (audio) and RFC 7742 (video).
A Data Channel is an abstraction allowing data to be sent between WebRTC endpoints as messages; two endpoints can have multiple data channels between them.
Data framing uses RTP (RFC 3550) as the format for media transport, with SRTP (RFC 3711) required for all implementations. Non-RTP data transfer is covered by RFC 8831 and RFC 8832.
Data transport covers sending and receiving data over network interfaces, including congestion management, retransmission, in-order delivery, and interaction with TURN relays for NAT traversal.
The media path ('low path') goes directly between browsers and must conform to the WebRTC protocol suite; the signaling path ('high path') goes via servers that can modify, translate, or manipulate signals as needed.
The WebRTC architecture is structured around six functionality groups: data transport, data framing, data formats, connection management, presentation and control, and local system support functions.
WebRTC security covers three areas: security of the components (browsers and servers, aiming to introduce no additional vulnerability), security of communication channels (verifying crypto parameters), and security of partner identities (positive identification or anonymity as needed). The security analysis and requirements are in RFC 8826.