WebRTC Gateways
Google
harald@alvestrand.no
This document specifies conformance requirements for a class of
WebRTC devices called "WebRTC gateways".
This type of device forms interconnects between WebRTC browsers and
devices that are not WebRTC browsers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The WebRTC model described in is focused on direct browser to
browser communication as its primary use case. Nevertheless, it is
clearly interesting to have applications that run in WebRTC browsers
connect to other types of devices, including but not limited to SIP
phones, legacy phones, CLUE-based teleconferencing systems, XMPP-based
conferencing systems, and entirely proprietary devices or systems.
WebRTC gateways are a specific type of devices which enable the
exchange of media streams between WebRTC browsers on one side, and the
other types of devices mentioned above on the other side.
This document describes the requirements that need to be placed on
such gateways, both the requirements on generic WebRTC devices that can
be relaxed and the additional requirements that need to be applied.
A WebRTC gateway will thus not be conformant with all requirements
for a WebRTC device (it does not do everything a WebRTC device does),
but is able to interoperate with WebRTC browsers and WebRTC devices.
A gateway will be limited in the functionality it can offer by the
thing it is gatewaying to. For instance, a gateway into the telephone
system will not be able to relay data or video, no matter how much it
is required. Therefore, a number of functions that are mandatory to
support in WebRTC devices are not mandatory on gateways; the
requirement on the gateway is that it is able to negotiate those
features away correctly.
The WebRTC model is that signalling is outside of the
specification. This specification does not change that.
Nevertheless, any practical gateway needs to deal with signalling,
in two senses:
The application, the signalling relays (if any) and the gateway
need to be able to, together, adhere to the offer/answer semantics
and deal with the description of configuration coming from the
browser; this is specified in SDP format in the WebRTC browser
API.
The application, the signalling relays (if any) and the gateway
need to be able to, together, generate the information that is
needed by the browser to set up the session, and express that
information in the form of SDP, and adhere to the offer/answer
semantics.
In this document, the shorthand notation "The gateway
MUST/SHOULD/MAY support <SDP function xxx>" is used. This means
that an application running in the Web browser, the signalling relays
that mediate signalling and thereby enable communication between the
application and the gateway, and the gateway together MUST/SHOULD/MAY
support this functionality; it is not a requirement that this happen
at the media gateway itself.
WebRTC gateways are intended to communicate with WebRTC devices; they
are therefore expected to conform to the requirements in
[I-D.ietf-rtcweb-overview], with the exceptions defined in this
section.
Since a gateway is expected to be deployed where it can be reached
with a static IP address (as seen from the client), a WebRTC gateway
does not need to support full ICE; it therefore MAY implement ICE-Lite
only.
ICE-Lite implementations do not send consent checks, so a gateway MAY
choose not to send consent checks too, but MUST respond to connectivity
checks it receives.
A gateway is expected to not need to hide its location, so it does
not need to support functionality for operating only via a TURN server;
instead it MAY choose to produce Host ICE candidates only.
If a gateway serves as a media relay into another RTP domain, it MAY
choose to support only features available in that network. This means
that it MAY not (need to) support Bundle and any of the RTP/RTCP
extensions related to it, RTCP-Mux, or Trickle Ice. However, the gateway
MUST support DTLS-SRTP, since this is required for interworking with
conformant WebRTC devices.
If a gateway serves as a media relay into a network or to devices not
implementing the WebRTC Datachannel, it MAY choose to not support the
Datachannel.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
A WebRTC gateway may operate in two security modes: Security-context
termination and security-context relaying.
Relaying is only possible when signed and encrypted content can be
passed through unchanged, and where keys can be exchanged directly
between the endpoints.
When the gateway terminates the security context, it means that the
WebRTC user has to place trust in the gateway to perform all
verification of identity and protection of content in the realm on the
other side of the gateway; there is no way the end-user can detect a
man-in-the-middle attack, an identity spoofing attack or a recording
done at the gateway. For many scenarios, this is not going to be seen as
a problem, but needs to be considered when one decides to use a
gatewayed service.
Several contributions from Uwe Rauschenbach were made in this
version, and also some comments from Christer Holmberg.