idnits 2.17.1 draft-ietf-rtcweb-gateways-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3189 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-09 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Standards Track U. Rauschenbach 5 Expires: January 7, 2016 Nokia Networks 6 July 6, 2015 8 WebRTC Gateways 9 draft-ietf-rtcweb-gateways-01 11 Abstract 13 This document describes interoperability considerations for a class 14 of WebRTC-compatible endpoints called "WebRTC gateways", which 15 interconnect between WebRTC endpoints and devices that are not WebRTC 16 endpoints. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 7, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Implications of the gateway environment . . . . . . . . . 3 60 1.2. Signalling model . . . . . . . . . . . . . . . . . . . . 3 61 2. WebRTC non-browser requirements that can be relaxed . . . . . 4 62 3. Additional WebRTC gateway requirements . . . . . . . . . . . 4 63 4. Considerations for SDP-using networks . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Change history . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The WebRTC model described in [I-D.ietf-rtcweb-overview] is focused 76 on direct browser to browser communication as its primary use case. 77 Nevertheless, it is clearly interesting to have WebRTC endpoints 78 connect to other types of devices, including but not limited to SIP 79 phones, legacy phones, CLUE-based teleconferencing systems, XMPP- 80 based conferencing systems, and entirely proprietary devices or 81 systems. 83 WebRTC gateways are middle boxes which enable the exchange of media 84 streams between WebRTC endpoints on one side, and the other types of 85 devices mentioned above on the other side. To a WebRTC endpoint, the 86 gateway appears as a WebRTC-compatible endpoint. 88 This document describes the requirements that need to be placed on 89 such gateways, both the requirements on WebRTC endpoints that can be 90 relaxed and the additional requirements that need to be applied. 92 A WebRTC gateway appears as a WebRTC-compatible endpoint, and will 93 thus not be conformant with all requirements for a WebRTC endpoint 94 (it does not do everything a WebRTC endpoint does), but is able to 95 interoperate with WebRTC endpoints. 97 NOTE IN DRAFT: There is still not a WG consensus called on whether 98 this document is Informational or standards-track. If it becomes 99 informational, the use of RFC 2119 language is used to call attention 100 to features where non-conformance will render a gateway unable to 101 interoperate with WebRTC-based endpoints. 103 1.1. Implications of the gateway environment 105 A gateway will be limited in the functionality it can offer by the 106 system or class of devices it is gatewaying to. For instance, a 107 gateway into the telephone system will not be able to relay data or 108 video, no matter how much it is required. Therefore, a number of 109 functions that are mandatory to support in WebRTC endpoints are not 110 mandatory on gateways; the requirement on the gateway is that it is 111 able to negotiate those features away correctly. 113 1.2. Signalling model 115 The WebRTC model is that signalling is outside the scope of the 116 specification. This document does not change that. 118 Nevertheless, any practical gateway needs to deal with signalling. 119 For that, this document assumes that the overall system consists of 120 an application running in the WebRTC browser, possibly one or more 121 signalling relays that mediate signalling and thereby enable 122 communication between the application and the gateway, and the actual 123 gateway that is responsible for handling the media flows. 125 The application, the signalling relays (if any) and the gateway 126 together need to be able to: 128 o adhere to the offer/answer semantics 130 o deal with the description of configuration coming from the 131 browser; this is specified in SDP format in the WebRTC browser API 133 o generate the information that is needed by the browser to set up 134 the session, and express that information in the form of SDP. 136 The shorthand notation "The gateway MUST/SHOULD/MAY support " used below means that an application running in the 138 Web browser, the signalling relays, and the gateway together 139 MUST/SHOULD/MAY support this functionality; it is not a requirement 140 that this happens at the media gateway itself. 142 2. WebRTC non-browser requirements that can be relaxed 144 WebRTC gateways are intended to communicate with WebRTC 145 endpoints[I-D.ietf-rtcweb-overview]. Some features that typical 146 WebRTC endpoints are required to support may be meaningless or 147 unneccesary for WebRTC gateways; some such things are noted in this 148 section. This lack of conformance means that a gateway is considered 149 a WebRTC-compatible endpoint, not a WebRTC endpoint (unless a 150 particular gateway claims to be a WebRTC endpoint, which it is of 151 course allowed to do). 153 A WebRTC gateway which is expected to be deployed where it can be 154 reached with a static IP address (as seen from the client) does not 155 need to support full ICE; it therefore MAY implement ICE-Lite only. 157 ICE-Lite implementations do not send consent checks, so a gateway MAY 158 choose not to send consent checks too, but MUST respond to consent 159 checks it receives. 161 A gateway with a static IP address is expected to not need to hide 162 its location, so it does not need to support functionality for 163 operating only via a TURN server; instead it MAY choose to produce 164 Host ICE candidates only. 166 If a gateway serves as a media relay into another RTP domain, it MAY 167 choose to support only features available in that network. This 168 means that it MAY choose to not support Bundle and any of the RTP/ 169 RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the 170 gateway MUST support DTLS-SRTP, since this is required for 171 interworking with WebRTC endpoints. 173 Note that non-support of BUNDLE means that "bundle-only" tracks are 174 not supported. This means that applications using an RTCBundlePolicy 175 other than "max-compat" ([I-D.ietf-rtcweb-jsep] section 4.1.1) can 176 only use one track of each media type. 178 If a gateway serves as a media relay into a network or to devices not 179 implementing the WebRTC Datachannel, it MAY choose to not support the 180 Datachannel. 182 3. Additional WebRTC gateway requirements 184 (nothing yet) 186 4. Considerations for SDP-using networks 188 Some networks that are gatewayed into, such as SIP networks, will 189 also use SDP to represent the media configurations. Gateways will, 190 however, need to inspect and probably modify the SDP passed between 191 the SDP-using network and the WebRTC endpoints to achieve maximum 192 interoperability. 194 Considerations include: 196 o If a correspondent does not offer the features WebRTC depends on, 197 connections will not complete. The support for dtls-srtp, shown 198 by the "fingerprint" attribute, is the most obvious example. The 199 gateway is probably better off either ending such calls early or 200 acting as a full B2BUA (as defined in [RFC3261]) with media 201 gatewaying. 203 o If a correspondent makes an offer using features that are not 204 required by JSEP, these may not be understood by the WebRTC 205 implementation. The gateway may choose to strip out some such 206 features. 208 o Certain ancient practices (such as using port 0 to place a media 209 section on hold with the intent of resuming it later) are not 210 conformant with the SDP offer/answer spec ([RFC3264] section 8.2). 211 Since WebRTC implementations are expected to be SDP offer/answer 212 conformant, such practices may need to be stripped out by the 213 gateway 215 [NOTE IN DRAFT: This section may need expanding.] 217 5. IANA Considerations 219 This document makes no request of IANA. 221 Note to RFC Editor: this section may be removed on publication as an 222 RFC. 224 6. Security Considerations 226 A WebRTC gateway may operate in two security modes: Security-context 227 termination and security-context relaying. 229 Relaying is only possible where signed and encrypted content can be 230 passed through unchanged, and where keys can be exchanged directly 231 between the endpoints. 233 When the gateway terminates the security context, it means that the 234 WebRTC user has to place trust in the gateway to perform all 235 verification of identity and protection of content in the realm on 236 the other side of the gateway; there is no way the end-user can 237 detect a man-in-the-middle attack, an identity spoofing attack or a 238 recording done at the gateway. For many scenarios, this is not going 239 to be seen as a problem, but needs to be considered when one decides 240 to use a gatewayed service. 242 7. Acknowledgements 244 Several comments from Christer Holmberg and Andrew Hutton were 245 included. 247 8. Change history 249 Changes from draft-alvestrand-rtcweb-gateways-00 251 o Aligned terminology with draft-rtcweb-overview-12 253 o Rewrote text on signaling to improve clarity 255 o Editorial nits 257 Changes from draft-alvestrand-rtcweb-gateways-01 259 o Aligned terminology with draft-rtcweb-overview-13 ("non-browser") 261 o Nits 263 Changes from draft-alvestrand-rtcweb-gateways-02 265 o Re-submitted as WG draft 267 o Addressed a comment from Andrew Hutton that deployment in open 268 internet is an option, not a fact. 270 Changes from draft-ietf-rtcweb-gateways-00 272 o Added note about impllications of non-support of BUNDLE 274 o Added "Considerations for SDP-using networks" section 276 9. References 277 9.1. Normative References 279 [I-D.ietf-rtcweb-jsep] 280 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 281 Session Establishment Protocol", draft-ietf-rtcweb-jsep-09 282 (work in progress), March 2015. 284 [I-D.ietf-rtcweb-overview] 285 Alvestrand, H., "Overview: Real Time Protocols for 286 Browser-based Applications", draft-ietf-rtcweb-overview-13 287 (work in progress), November 2014. 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 9.2. Informative References 294 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 295 A., Peterson, J., Sparks, R., Handley, M., and E. 296 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 297 June 2002. 299 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 300 with Session Description Protocol (SDP)", RFC 3264, June 301 2002. 303 Authors' Addresses 305 Harald Alvestrand 306 Google 308 Email: harald@alvestrand.no 310 Uwe Rauschenbach 311 Nokia Networks 313 Email: uwe.rauschenbach@nokia.com