draft-ietf-rtcweb-gateways-00.txt   draft-ietf-rtcweb-gateways-01.txt 
RTCWeb Working Group H. Alvestrand RTCWeb Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track U. Rauschenbach Intended status: Standards Track U. Rauschenbach
Expires: November 28, 2015 Nokia Networks Expires: January 7, 2016 Nokia Networks
May 27, 2015 July 6, 2015
WebRTC Gateways WebRTC Gateways
draft-ietf-rtcweb-gateways-00 draft-ietf-rtcweb-gateways-01
Abstract Abstract
This document specifies conformance requirements for a class of This document describes interoperability considerations for a class
WebRTC-compatible endpoints called "WebRTC gateways", which of WebRTC-compatible endpoints called "WebRTC gateways", which
interconnect between WebRTC endpoints and devices that are not WebRTC interconnect between WebRTC endpoints and devices that are not WebRTC
endpoints. endpoints.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at line 38 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Implications of the gateway environment 1.1. Implications of the gateway environment . . . . . . . . . 3
1.2. Signalling model 1.2. Signalling model . . . . . . . . . . . . . . . . . . . . 3
2. WebRTC non-browser requirements that can be relaxed 2. WebRTC non-browser requirements that can be relaxed . . . . . 4
3. Additional WebRTC gateway requirements 3. Additional WebRTC gateway requirements . . . . . . . . . . . 4
4. IANA Considerations 4. Considerations for SDP-using networks . . . . . . . . . . . . 5
5. Security Considerations 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Change history 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References 8. Change history . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused
on direct browser to browser communication as its primary use case. on direct browser to browser communication as its primary use case.
Nevertheless, it is clearly interesting to have WebRTC endpoints Nevertheless, it is clearly interesting to have WebRTC endpoints
connect to other types of devices, including but not limited to SIP connect to other types of devices, including but not limited to SIP
phones, legacy phones, CLUE-based teleconferencing systems, XMPP- phones, legacy phones, CLUE-based teleconferencing systems, XMPP-
based conferencing systems, and entirely proprietary devices or based conferencing systems, and entirely proprietary devices or
systems. systems.
WebRTC gateways are a specific type of WebRTC-compatible endpoints WebRTC gateways are middle boxes which enable the exchange of media
which enable the exchange of media streams between WebRTC endpoints streams between WebRTC endpoints on one side, and the other types of
on one side, and the other types of devices mentioned above on the devices mentioned above on the other side. To a WebRTC endpoint, the
other side. gateway appears as a WebRTC-compatible endpoint.
This document describes the requirements that need to be placed on This document describes the requirements that need to be placed on
such gateways, both the requirements on WebRTC endpoints that can be such gateways, both the requirements on WebRTC endpoints that can be
relaxed and the additional requirements that need to be applied. relaxed and the additional requirements that need to be applied.
A WebRTC gateway is a WebRTC-compatible endpoint, and will thus not A WebRTC gateway appears as a WebRTC-compatible endpoint, and will
be conformant with all requirements for a WebRTC endpoint (it does thus not be conformant with all requirements for a WebRTC endpoint
not do everything a WebRTC endpoint does), but is able to (it does not do everything a WebRTC endpoint does), but is able to
interoperate with WebRTC endpoints. interoperate with WebRTC endpoints.
NOTE IN DRAFT: There is still not a WG consensus called on whether
this document is Informational or standards-track. If it becomes
informational, the use of RFC 2119 language is used to call attention
to features where non-conformance will render a gateway unable to
interoperate with WebRTC-based endpoints.
1.1. Implications of the gateway environment 1.1. Implications of the gateway environment
A gateway will be limited in the functionality it can offer by the 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 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 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 video, no matter how much it is required. Therefore, a number of
functions that are mandatory to support in WebRTC endpoints are not functions that are mandatory to support in WebRTC endpoints are not
mandatory on gateways; the requirement on the gateway is that it is mandatory on gateways; the requirement on the gateway is that it is
able to negotiate those features away correctly. able to negotiate those features away correctly.
skipping to change at line 134 skipping to change at page 4, line 7
the session, and express that information in the form of SDP. the session, and express that information in the form of SDP.
The shorthand notation "The gateway MUST/SHOULD/MAY support <SDP The shorthand notation "The gateway MUST/SHOULD/MAY support <SDP
function xxx>" used below means that an application running in the function xxx>" used below means that an application running in the
Web browser, the signalling relays, and the gateway together Web browser, the signalling relays, and the gateway together
MUST/SHOULD/MAY support this functionality; it is not a requirement MUST/SHOULD/MAY support this functionality; it is not a requirement
that this happens at the media gateway itself. that this happens at the media gateway itself.
2. WebRTC non-browser requirements that can be relaxed 2. WebRTC non-browser requirements that can be relaxed
WebRTC gateways are intended to communicate with WebRTC endpoints. WebRTC gateways are intended to communicate with WebRTC
WebRTC gateways are no User Agents. They are therefore expected to endpoints[I-D.ietf-rtcweb-overview]. Some features that typical
conform to the requirements for WebRTC non-browsers in [I-D.ietf- WebRTC endpoints are required to support may be meaningless or
rtcweb-overview], with the exceptions defined in this section. unneccesary for WebRTC gateways; some such things are noted in this
section. This lack of conformance means that a gateway is considered
a WebRTC-compatible endpoint, not a WebRTC endpoint (unless a
particular gateway claims to be a WebRTC endpoint, which it is of
course allowed to do).
A WebRTC gateway which is expected to be deployed where it can be A WebRTC gateway which is expected to be deployed where it can be
reached with a static IP address (as seen from the client) does not reached with a static IP address (as seen from the client) does not
need to support full ICE; it therefore MAY implement ICE-Lite only. need to support full ICE; it therefore MAY implement ICE-Lite only.
ICE-Lite implementations do not send consent checks, so a gateway MAY ICE-Lite implementations do not send consent checks, so a gateway MAY
choose not to send consent checks too, but MUST respond to consent choose not to send consent checks too, but MUST respond to consent
checks it receives. checks it receives.
A gateway is expected to not need to hide its location, so it does A gateway with a static IP address is expected to not need to hide
not need to support functionality for operating only via a TURN its location, so it does not need to support functionality for
server; instead it MAY choose to produce Host ICE candidates only. 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 If a gateway serves as a media relay into another RTP domain, it MAY
choose to support only features available in that network. This choose to support only features available in that network. This
means that it MAY not (need to) support Bundle and any of the RTP/ means that it MAY choose to not support Bundle and any of the RTP/
RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the
gateway MUST support DTLS-SRTP, since this is required for gateway MUST support DTLS-SRTP, since this is required for
interworking with WebRTC endpoints. interworking with WebRTC endpoints.
Note that non-support of BUNDLE means that "bundle-only" tracks are
not supported. This means that applications using an RTCBundlePolicy
other than "max-compat" ([I-D.ietf-rtcweb-jsep] section 4.1.1) can
only use one track of each media type.
If a gateway serves as a media relay into a network or to devices not 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 implementing the WebRTC Datachannel, it MAY choose to not support the
Datachannel. Datachannel.
3. Additional WebRTC gateway requirements 3. Additional WebRTC gateway requirements
(nothing yet) (nothing yet)
4. IANA Considerations 4. Considerations for SDP-using networks
Some networks that are gatewayed into, such as SIP networks, will
also use SDP to represent the media configurations. Gateways will,
however, need to inspect and probably modify the SDP passed between
the SDP-using network and the WebRTC endpoints to achieve maximum
interoperability.
Considerations include:
o If a correspondent does not offer the features WebRTC depends on,
connections will not complete. The support for dtls-srtp, shown
by the "fingerprint" attribute, is the most obvious example. The
gateway is probably better off either ending such calls early or
acting as a full B2BUA (as defined in [RFC3261]) with media
gatewaying.
o If a correspondent makes an offer using features that are not
required by JSEP, these may not be understood by the WebRTC
implementation. The gateway may choose to strip out some such
features.
o Certain ancient practices (such as using port 0 to place a media
section on hold with the intent of resuming it later) are not
conformant with the SDP offer/answer spec ([RFC3264] section 8.2).
Since WebRTC implementations are expected to be SDP offer/answer
conformant, such practices may need to be stripped out by the
gateway
[NOTE IN DRAFT: This section may need expanding.]
5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
5. Security Considerations 6. Security Considerations
A WebRTC gateway may operate in two security modes: Security-context A WebRTC gateway may operate in two security modes: Security-context
termination and security-context relaying. termination and security-context relaying.
Relaying is only possible where signed and encrypted content can be Relaying is only possible where signed and encrypted content can be
passed through unchanged, and where keys can be exchanged directly passed through unchanged, and where keys can be exchanged directly
between the endpoints. between the endpoints.
When the gateway terminates the security context, it means that the When the gateway terminates the security context, it means that the
WebRTC user has to place trust in the gateway to perform all WebRTC user has to place trust in the gateway to perform all
verification of identity and protection of content in the realm on 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 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 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 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 be seen as a problem, but needs to be considered when one decides
to use a gatewayed service. to use a gatewayed service.
6. Acknowledgements 7. Acknowledgements
Several comments from Christer Holmberg and Andrew Hutton were Several comments from Christer Holmberg and Andrew Hutton were
included. included.
7. Change history 8. Change history
Changes from draft-alvestrand-rtcweb-gateways-00 Changes from draft-alvestrand-rtcweb-gateways-00
o Aligned terminology with draft-rtcweb-overview-12 o Aligned terminology with draft-rtcweb-overview-12
o Rewrote text on signaling to improve clarity o Rewrote text on signaling to improve clarity
o Editorial nits o Editorial nits
Changes from draft-alvestrand-rtcweb-gateways-01 Changes from draft-alvestrand-rtcweb-gateways-01
skipping to change at line 219 skipping to change at page 6, line 42
o Nits o Nits
Changes from draft-alvestrand-rtcweb-gateways-02 Changes from draft-alvestrand-rtcweb-gateways-02
o Re-submitted as WG draft o Re-submitted as WG draft
o Addressed a comment from Andrew Hutton that deployment in open o Addressed a comment from Andrew Hutton that deployment in open
internet is an option, not a fact. internet is an option, not a fact.
8. Normative References Changes from draft-ietf-rtcweb-gateways-00
o Added note about impllications of non-support of BUNDLE
o Added "Considerations for SDP-using networks" section
9. References
9.1. Normative References
[I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-09
(work in progress), March 2015.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
Authors' Addresses Authors' Addresses
Harald Alvestrand Harald Alvestrand
Google Google
Email: harald@alvestrand.no Email: harald@alvestrand.no
Uwe Rauschenbach Uwe Rauschenbach
Nokia Networks Nokia Networks
 End of changes. 19 change blocks. 
37 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/