| Network Working Group | H. Alvestrand |
| Internet-Draft | |
| Intended status: Standards Track | August 15, 2014 |
| Expires: February 16, 2015 |
WebRTC Gateways
draft-alvestrand-rtcweb-gateways-00
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 16, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The WebRTC model described in [I-D.ietf-rtcweb-overview] 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:
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.
(nothing yet)
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.
| [I-D.ietf-rtcweb-overview] | Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Internet-Draft draft-ietf-rtcweb-overview-10, June 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |