idnits 2.17.1 draft-thomson-rtcweb-api-reqs-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 9, 2012) is 4271 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) == Unused Reference: 'RFC6455' is defined on line 451, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-03 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-02 == Outdated reference: A later version (-03) exists of draft-westerlund-avtext-rtcp-sdes-srcname-00 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Thomson 3 Internet-Draft B. Aboba 4 Intended status: Standards Track Microsoft 5 Expires: January 10, 2013 July 9, 2012 7 Media API Requirements for Real-Time Interoperation of Web User Agents 8 draft-thomson-rtcweb-api-reqs-00 10 Abstract 12 Direct, real-time communications between web user agents (browsers) 13 requires two points of standardization. The first describes the on- 14 the-wire protocol that is used. The second is the API that controls 15 and configures what gets put on the wire and how. The capabilities 16 of the protocol determines the nature of the API. This document 17 outlines how the constraints imposed upon the API by the protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Peer-to-Peer Transport . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Overview of ICE Operation . . . . . . . . . . . . . . . . 4 57 2.2. Transport ICE Requirements . . . . . . . . . . . . . . . . 5 58 2.3. Established Flow Requirements . . . . . . . . . . . . . . 6 59 3. Securing Media . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Sending Peer-to-Peer Media . . . . . . . . . . . . . . . . . . 7 61 5. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The exchange of media - audio and video - between peers is a basic 73 foundation of telecommunications. The fact that the web platform has 74 successfully managed to avoid this fundamental feature for so long is 75 a testament to the usefulness of its other features. The WebRTC/ 76 rtcweb effort attempts to remedy this shortcoming. 78 Figure 1 shows the architecture for real-time communications on the 79 web. 81 _________ 82 (( )) 83 .-(( The Cloud ))-. 84 ? / ((_________)) \ ? 85 / \ 86 +------------/----+ +--\--------------+ 87 | +---------/---+ | | +-\-----------+ | 88 | | Javascript | | | | Javascript | | 89 | | | | | | | | 90 | +----+ | IETF | +----+ | 91 | === protocols === | 92 | Web User Agent | | Web User Agent | 93 +-----------------+ +-----------------+ 95 Figure 1: Architecture for the Real-Time Web 97 Two points of interoperation are necessary in this architecture: API 98 and peer-to-peer protocols. Critically, the points marked with a '?' 99 are not subject to standardization. These points are effectively 100 internal to the application that exists both in "The Cloud" and in 101 the Javascript virtual machine provided by the web user agent. 103 The IETF rtcweb working group has settled on Real-Time Transport 104 Protocol (RTP) [RFC3550], Secure RTP (SRTP) [RFC3711] and Interactive 105 Connectivity Establishment (ICE) [RFC5245] for the peer to peer 106 protocol components. Use of RTP is documented in 107 [I-D.ietf-rtcweb-rtp-usage]; use of SRTP and ICE is described in the 108 rtcweb security architecture [I-D.ietf-rtcweb-security-arch]. 110 ICE and RTP are unable to operate without an out-of-band 111 communications channel. For ICE this provides bootstrapping 112 information; for RTP, a common understanding of the key protocol 113 parameters. Though SRTP can operate without an out-of-band channel 114 if certain assumptions are made, many uses depend on some form of 115 out-of-band communication. The out-of-band channel is provided by 116 the web application. The necessary information passes through the 117 API to the browser. 119 This document describes what information must pass between a web 120 application and a web user agent in order to successfully establish 121 peer-to-peer media communications. No attempt is made to constrain 122 what the API looks like. After all: 124 [...] when [a] IETF documents start telling you how to build 125 Javascript APIs, you should run far away... quickly. :) 126 -- [I-D.kaplan-rtcweb-api-reqs] 128 1.1. Terminology 130 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 131 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 132 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 133 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 134 levels for compliant implementations. 136 2. Peer-to-Peer Transport 138 ICE [RFC5245] provides a mechanism for establishing peer-to-peer 139 communications using UDP. 141 The ICE process applies to a single UDP flow from a source address 142 and port to a destination address and port. Where multiple flows are 143 required, the process is applied once for each flow. 145 2.1. Overview of ICE Operation 147 In ICE, for each UDP flow, each peer performs the following steps: 149 o Candidate gathering. A candidate is an UDP port with associated 150 session authentication parameters. Candidates are attributed to 151 the peer, but they can be collected from the local host, by 152 querying servers about the server perspective of the peer address, 153 or a TURN [RFC5766] relay can allocate server-based ports that 154 forward packets to the peer. 156 o Candidate exchange. Each peer learns of the candidates gathered 157 by the other peer. 159 o Candidate pair testing. Candidates are paired, one local against 160 one remote. A connectivity check is performed where a STUN 161 [RFC5389] packet is sent from the local candidate to the remote. 162 The pair is valid if a response arrives. Packets might be lost, 163 so this process is repeated. 165 o Candidate pair selection. As soon as one or more candidates are 166 marked as valid, one of these can be selected and used. 168 2.2. Transport ICE Requirements 170 The following requirements ensure that an application is able to 171 establish a UDP flow between peers with proper consent: 173 ICE-1 The application MUST be able to request the gathering of host 174 candidates. Candidates are comprised of an IP address (v4 or 175 v6), a UDP port number, an ICE username fragment and an ICE 176 password. 178 ICE-2 The application MUST be able to request the gathering of 179 server reflexive address information using STUN. Input to 180 this is the identity of a STUN server and any credentials 181 required by the server. 183 ICE-3 The application MUST be able to request the allocation of TURN 184 relay candidates. Input to this is the identity of a TURN 185 server and any credentials required by the server. 187 ICE-4 The application MUST be able to request that a connectivity 188 check be sent to a remote candidate and to be informed of 189 success. Input to this is a choice of local candidate and 190 details of the remote candidate. 192 This establishes: whether the UDP packet is able to reach the 193 remote peer and whether the remote peer consents to the 194 receipt of packets from this peer. 196 ICE-5 The application MUST be able to add STUN attributes to the 197 STUN messages that are sent for connectivity checks. 199 ICE-6 The application MUST be able to examine STUN attributes 200 received on successful responses to connectivity checks. 202 ICE-7 The application MUST be able to retrieve peer reflexive 203 addresses that are discovered when connectivity checks are 204 successful. 206 ICE-8 The application MUST be able to request the creation of a UDP 207 flow on a valid candidate pair. 209 ICE-9 The application MUST be notified when a successful 210 connectivity check is received from remote peer. The 211 notification MUST include peer addressing information. 213 2.3. Established Flow Requirements 215 The following requirements apply to established flows: 217 UDP-1 The application MUST be able to send connectivity checks on an 218 active UDP flow to test liveness of the flow. 220 UDP-2 The application MUST be notified when consent for an active 221 UDP flow expires. 223 UDP-3 The application MUST be able to retrieve the bandwidth that 224 the remote peer consents to receive for the UDP flow. 226 UDP-4 The application MUST be able to learn the bandwidth limit that 227 the browser has detected for the flow based on feedback from 228 the network. 230 UDP-5 The application MUST be notified when the browser detects 231 changes in the available bandwidth for the UDP flow. 233 UDP-6 The application MUST be notified when the browser detects 234 network congestion that affects the UDP flow. 236 UDP-7 The application MUST be notified when changes in network 237 connectivity occur. 239 UDP-8 The application MUST be able to pause connectivity checking on 240 an active UDP flow. 242 This allows an application to conserve resources for inactive 243 flows, especially for battery-powered devices. 245 3. Securing Media 247 SRTP [RFC3711] provides confidentiality, message authentication and 248 replay protection for RTP media. 250 SRTP requires external key negotiation. Two methods are possible: 251 Datagram Transport Layer Security (DTLS) can be used for key 252 negotiation (DTLS-SRTP) [RFC5764], or the SRTP master keys can be 253 provided directly. The application chooses which of these modes the 254 application uses. [[Ed: requirement for second option not 255 established]] 257 With DTLS key negotiation, the asymmetry of the DTLS handshake means 258 that out-of-band methods must be used to determine whether peers act 259 in the server or client roles. DTLS offers a means for peer 260 authentication, allowing the application to learn of the identity of 261 the peer through the certificate they offer during the handshake. 263 Without DTLS key negotiation, the SRTP master keys are determined 264 out-of-band and provided to the browser through the API (e.g., 265 [RFC4568]). SRTP does not offer any method for peer authentication. 267 The following requirements apply: 269 SEC-1 The application MUST be able to select how SRTP key 270 negotiation is performed, either DTLS-SRTP or through the API. 272 SEC-2 Where DTLS-SRTP is chosen, the application MUST be able to 273 specify whether the browser is to take the client or server 274 role. 276 SEC-3 Where DTLS-SRTP is chosen, the application MUST be able to 277 view the certificate offered by the peer. 279 SEC-4 Where DTLS-SRTP is chosen, the application MUST be able to 280 discover if the peer certificate is a trusted certificate for 281 an identified domain. 283 SEC-5 Where DTLS-SRTP is chosen, the application MUST be able to 284 reject communication with peers based on information presented 285 in their certificate. 287 SEC-6 Where SRTP is chosen without DTLS for key negotiation, the 288 application MUST be able to set SRTP parameters, including: 289 the encryption, key generation and authentication algorithms; 290 key and parameter size; key and salt value; key usage 291 lifetime; key derivation interval; and an optional master key 292 identifier. 294 4. Sending Peer-to-Peer Media 296 RTP [RFC3550] sends real-time data - media - from a source to a sink. 298 An RTP stream is the manifestation of media as packets. Most media 299 is a single stream, though layered codecs (such as H.264 SVC 300 [RFC6190]) can be split into multiple streams. Browser need to 301 handle RTP streams in two directions: outbound from a local source, 302 and inbound toward a local sink. 304 The following requirements apply: 306 MED-1 The application MUST be able to select the UDP flow that an 307 RTP stream uses. 309 MED-2 The application MUST be able select the UDP flow that RTCP 310 for a given RTP stream uses. 312 MED-3 The application MUST be able to move RTP streams (or 313 associated RTCP) between UDP flows without losing packets. 315 MED-4 The application MUST be able to specify the SSRC for RTP 316 streams, both outbound and inbound. 318 MED-5 The application MUST be able to discover the CNAME that will 319 be used for streams that it generates. 321 MED-6 The application MUST be able to discover the SRCNAME 322 [I-D.westerlund-avtext-rtcp-sdes-srcname] that will be used 323 for streams that it generates. [[Ed: conditional on 324 acceptance of SRCNAME]] 326 MED-7 The application MUST be able to specify the RTP packet type 327 that is used to identify codecs in RTP streams, both inbound 328 and outbound. 330 MED-8 The application MUST be able to select the codecs that are 331 used for outbound RTP streams and to specify the codecs that 332 are present in inbound RTP streams. 334 MED-9 The application MUST be able to limit the bandwidth allocated 335 to a single outbound RTP stream. 337 MED-10 The application MUST be able to specify the number of audio 338 channels used for an audio stream. 340 MED-11 The application MUST be able to specify codec parameters 341 (such as appear in SDP [RFC4566] "a=fmtp" lines). 343 MED-12 The application MUST be able to mark the priority of an RTP 344 stream. 346 This lets the browser choose appropriate packet marking using 347 DiffServ and the relative sensitivity of streams to 348 congestion. 350 MED-13 The application MUST be able to update the configuration for 351 an active RTP stream. 353 5. DTMF Tones 355 Dual-Tone Multifrequency (DTMF) is commonly used by legacy telephony 356 applications. DTMF tones are typically interleaved/mixed with audio 357 streams. 359 The following requirements apply: 361 DTMF-1 The application MUST be able to insert DTMF tones into an 362 audio stream. 364 DTMF-2 The application MUST be able to be informed of the existence 365 of DTMF tone events on an audio stream. 367 6. IANA Considerations 369 This document has no IANA actions. 371 [RFC Editor: please remove this section prior to publication.] 373 7. Security Considerations 375 The security of your precious bodily fluids can only be achieved 376 through purity of essence. 378 8. Acknowledgments 380 This document takes ideas from [I-D.kaplan-rtcweb-api-reqs], 381 including the short title you see on each page. 383 9. References 385 9.1. Normative References 387 [I-D.ietf-rtcweb-rtp-usage] 388 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 389 Communication (WebRTC): Media Transport and Use of RTP", 390 draft-ietf-rtcweb-rtp-usage-03 (work in progress), 391 June 2012. 393 [I-D.ietf-rtcweb-security-arch] 394 Rescorla, E., "RTCWEB Security Architecture", 395 draft-ietf-rtcweb-security-arch-02 (work in progress), 396 June 2012. 398 [I-D.westerlund-avtext-rtcp-sdes-srcname] 399 Westerlund, M., Burman, B., and P. Sandgren, "RTCP SDES 400 Item SRCNAME to Label Individual Sources", 401 draft-westerlund-avtext-rtcp-sdes-srcname-00 (work in 402 progress), October 2011. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 408 Jacobson, "RTP: A Transport Protocol for Real-Time 409 Applications", STD 64, RFC 3550, July 2003. 411 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 412 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 413 RFC 3711, March 2004. 415 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 416 (ICE): A Protocol for Network Address Translator (NAT) 417 Traversal for Offer/Answer Protocols", RFC 5245, 418 April 2010. 420 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 421 Security (DTLS) Extension to Establish Keys for the Secure 422 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 424 9.2. Informative References 426 [I-D.kaplan-rtcweb-api-reqs] 427 Kaplan, H., Stratford, N., and T. Panton, "API 428 Requirements for WebRTC-enabled Browsers", 429 draft-kaplan-rtcweb-api-reqs-01 (work in progress), 430 October 2011. 432 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 433 Description Protocol", RFC 4566, July 2006. 435 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 436 Description Protocol (SDP) Security Descriptions for Media 437 Streams", RFC 4568, July 2006. 439 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 440 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 441 October 2008. 443 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 444 Relays around NAT (TURN): Relay Extensions to Session 445 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 447 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 448 "RTP Payload Format for Scalable Video Coding", RFC 6190, 449 May 2011. 451 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 452 RFC 6455, December 2011. 454 Authors' Addresses 456 Martin Thomson 457 Microsoft 458 3210 Porter Drive 459 Palo Alto, CA 94304 460 US 462 Phone: +1 650-353-1925 463 Email: martin.thomson@skype.net 465 Bernard Aboba 466 Microsoft 467 One Microsoft Way 468 Redmond, WA 98052 469 US 471 Email: bernard_aboba@hotmail.com