idnits 2.17.1 draft-rosenberg-dispatch-ript-webrtc-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 7, 2020) is 1539 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Rosenberg 3 Internet-Draft Five9 4 Intended status: Standards Track February 7, 2020 5 Expires: August 10, 2020 7 RealTime Internet Peering for Telephony (RIPT) Compatibility with webRTC 8 draft-rosenberg-dispatch-ript-webrtc-00 10 Abstract 12 The Real-Time Internet Peering for Telephony (RIPT) Protocol defines 13 a technique for establishing, terminating and otherwise managing 14 calls between entities in differing administrative domains. The RIPT 15 Inbound extension brings this to end clients, such as a browser. 16 However, it defines a different technique for media that cannot 17 directly use the webRTC APIs, and require a change to them. This 18 specification provides an extension to RIPT for webRTC compatibility, 19 enabling media to flow from browser to server as is done with RIPT, 20 or from browser to browser as is done with webRTC. It also discusses 21 techniques for sending e2e encrypted media. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 2 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 62 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1. Introduction 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Overview of Operation 73 Basic idea: The TG indicates that this compatibility mode is 74 supported on the TG. The handler is also indicates that this mode is 75 supported. The handler includes its own ICE candidates. This means 76 we provide the ICE candidates at "registration" time and not before 77 the call. This is necessary to facilitate the many call move and 78 other operations in RIPT-inbound. This also means the browser needs 79 to keep them fresh all of the time, rather than just before the call 80 [[is this posible with current API??]]. 82 Since the media is sent by DTLS-SRTP and not embedded as media chunks 83 in a client-to-server HTTPS connection, the browser includes its 84 fingerprint in the handler as well. 86 To initiate this compatibility mode for media, the server indicates 87 as such in the directive. It can only put it in a directive if the 88 handler that is selected, supports the mode. The directive includes 89 the ICE candidates from the peer. This will trigger the client to 90 perform ICE and send media (which will be DTLS-SRTP). 92 RIPT itself doesnt convey the ICE candidates in the server to server 93 link, since its only through handler whih is static for a device and 94 not per-call. So we'd either need to move them, develop a separate 95 way to convey them, or assume SIP or some other technique is used for 96 server to server calls. 98 Suggest we also require a well-known port for media, and we'll need 99 an RTP headr extension to convey the callID since its included inband 100 in RIPT. 102 3. IANA Considerations 104 TODO 106 4. Security Considerations 108 TODO 110 5. Acknowledgements 112 Thanks to Justin Uberti and Cullen Jennings for the discussion on 113 this concept. 115 6. Normative References 117 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 118 Requirement Levels", BCP 14, RFC 2119, 119 DOI 10.17487/RFC2119, March 1997, 120 . 122 Author's Address 124 Jonathan Rosenberg 125 Five9 127 Email: jdrosen@jdrosen.net