Internet DRAFT - draft-alvestrand-rtcweb-gateways
draft-alvestrand-rtcweb-gateways
RTCWeb Working Group H. Alvestrand
Internet-Draft Google
Intended status: Standards Track U. Rauschenbach
Expires: September 10, 2015 Nokia Networks
March 09, 2015
WebRTC Gateways
draft-alvestrand-rtcweb-gateways-02
Abstract
This document specifies conformance requirements for a class of
WebRTC-compatible endpoints called "WebRTC gateways", which
interconnect between WebRTC endpoints and devices that are not WebRTC
endpoints.
Requirements Language
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].
Status of This Memo
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 September 10, 2015.
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction
1.1. Implications of the gateway environment
1.2. Signalling model
2. WebRTC non-browser requirements that can be relaxed
3. Additional WebRTC gateway requirements
4. IANA Considerations
5. Security Considerations
6. Acknowledgements
7. Change history
8. Normative References
Authors' Addresses
1. Introduction
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 WebRTC endpoints
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 WebRTC-compatible endpoints
which enable the exchange of media streams between WebRTC endpoints
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 WebRTC endpoints that can be
relaxed and the additional requirements that need to be applied.
A WebRTC gateway is a WebRTC-compatible endpoint, and will thus not
be conformant with all requirements for a WebRTC endpoint (it does
not do everything a WebRTC endpoint does), but is able to
interoperate with WebRTC endpoints.
1.1. Implications of the gateway environment
A gateway will be limited in the functionality it can offer by the
system or class of devices 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 endpoints are not
mandatory on gateways; the requirement on the gateway is that it is
able to negotiate those features away correctly.
1.2. Signalling model
The WebRTC model is that signalling is outside the scope of the
specification. This document does not change that.
Nevertheless, any practical gateway needs to deal with signalling.
For that, this document assumes that the overall system consists of
an application running in the WebRTC browser, possibly one or more
signalling relays that mediate signalling and thereby enable
communication between the application and the gateway, and the actual
gateway that is responsible for handling the media flows.
The application, the signalling relays (if any) and the gateway
together need to be able to:
o adhere to the offer/answer semantics
o deal with the description of configuration coming from the
browser; this is specified in SDP format in the WebRTC browser API
o generate the information that is needed by the browser to set up
the session, and express that information in the form of SDP.
The shorthand notation "The gateway MUST/SHOULD/MAY support <SDP
function xxx>" used below means that an application running in the
Web browser, the signalling relays, and the gateway together
MUST/SHOULD/MAY support this functionality; it is not a requirement
that this happens at the media gateway itself.
2. WebRTC non-browser requirements that can be relaxed
WebRTC gateways are intended to communicate with WebRTC endpoints.
WebRTC gateways are no User Agents. They are therefore expected to
conform to the requirements for WebRTC non-browsers 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 consent
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 WebRTC endpoints.
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.
3. Additional WebRTC gateway requirements
(nothing yet)
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
A WebRTC gateway may operate in two security modes: Security-context
termination and security-context relaying.
Relaying is only possible where 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.
6. Acknowledgements
Several comments from Christer Holmberg were included.
7. Change history
Changes from draft-alvestrand-rtcweb-gateways-00
o Aligned terminology with draft-rtcweb-overview-12
o Rewrote text on signaling to improve clarity
o Editorial nits
Changes from draft-alvestrand-rtcweb-gateways-01
o Aligned terminology with draft-rtcweb-overview-13 ("non-browser")
o Nits
8. Normative References
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Harald Alvestrand
Google
Email: harald@alvestrand.no
Uwe Rauschenbach
Nokia Networks
Email: uwe.rauschenbach@nokia.com
