idnits 2.17.1 draft-cbran-rtcweb-protocols-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (June 5, 2011) is 4706 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) == Missing Reference: 'Section 4' is mentioned on line 146, but not defined == Missing Reference: 'Section 8' is mentioned on line 204, but not defined == Missing Reference: 'Section 10' is mentioned on line 246, but not defined == Missing Reference: 'Section 23' is mentioned on line 235, but not defined == Missing Reference: 'Section 13' is mentioned on line 244, but not defined == Missing Reference: 'I-D.westin-payload-vp8' is mentioned on line 349, but not defined == Missing Reference: 'SECTION' is mentioned on line 737, but not defined -- No information found for draft-ekr-security-considerations-for-rtc-web - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ekr-security-considerations-for-rtc-web' ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Downref: Normative reference to an Experimental RFC: RFC 4828 ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bran 3 Internet-Draft C. Jennings 4 Intended status: Standards Track Cisco 5 Expires: December 7, 2011 June 5, 2011 7 RTC-Web Communications Protocols 8 draft-cbran-rtcweb-protocols-00 10 Abstract 12 The real time communications web (RTC-Web) will enable applications 13 such as web browsers to natively support real time interactive voice 14 and video. This document outlines the communication protocols for 15 realizing RTC-Web functionality within applications such as web 16 browsers. In addition to communications protocols, this document 17 proposes a set of application programming interface requirements for 18 controlling the protocol stack. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 7, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Connection Management Requirements . . . . . . . . . . . . 4 60 3.2. Signaling Protocol Requirements . . . . . . . . . . . . . 5 61 3.2.1. Client Application SIP Requirements . . . . . . . . . 5 62 3.2.2. Client Application Optional SIP Support . . . . . . . 5 63 3.2.3. Required SIP Methods . . . . . . . . . . . . . . . . . 6 64 3.2.4. Multipart SIP Message Requirements . . . . . . . . . . 6 65 3.2.5. SIP Identity Requirements . . . . . . . . . . . . . . 6 66 3.2.6. SIP Network Address Traversal . . . . . . . . . . . . 7 67 3.3. Codec Requirements . . . . . . . . . . . . . . . . . . . . 7 68 3.3.1. Audio Codec Requirements . . . . . . . . . . . . . . . 7 69 3.3.2. Video Codec Requirements . . . . . . . . . . . . . . . 8 70 3.4. Real-Time Media Transport Requirements . . . . . . . . . . 8 71 3.4.1. RTP Profile . . . . . . . . . . . . . . . . . . . . . 9 72 3.4.2. RTP Optimizations . . . . . . . . . . . . . . . . . . 9 73 3.4.3. RTP Extensions . . . . . . . . . . . . . . . . . . . . 11 74 3.4.4. RTP Transport Robustness . . . . . . . . . . . . . . . 12 75 3.4.5. RTP Rate Control . . . . . . . . . . . . . . . . . . . 13 76 3.5. Non-Media Data Transport Requirements . . . . . . . . . . 13 77 3.5.1. Non-Media Data In RTP . . . . . . . . . . . . . . . . 14 78 3.5.2. Transporting Non-Media Data . . . . . . . . . . . . . 14 79 4. API Requirements . . . . . . . . . . . . . . . . . . . . . . . 16 80 5. Legacy VoIP Interoperability . . . . . . . . . . . . . . . . . 16 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 84 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 The Internet was, from very early in its lifetime, considered a 90 possible vehicle for the deployment of real-time, interactive 91 applications - with the most easily imaginable being audio 92 conversations (aka "Internet telephony") and videoconferencing. 94 The first attempts to build this were dependent on special networks, 95 special hardware and custom-built software, often at very high prices 96 or at low quality, placing great demands on the infrastructure. 98 As the available bandwidth has increased, and as processors and other 99 hardware has become ever faster, the barriers to participation have 100 decreased, and it is possible to deliver a satisfactory experience on 101 commonly available computing hardware. 103 Still, there are a number of barriers to the ability to communicate 104 universally - one of these is that there are, as of yet, no single 105 set of communication protocols that all agree should be made 106 available for communication; another is the sheer lack of universal 107 identification systems (such as is served by telephone numbers or 108 email addresses in other communications systems). 110 Development of "The Universal Solution" has proved hard, however, for 111 all the usual reasons. This memo aims to take a more building-block- 112 oriented approach, and try to find consensus on a set of substrate 113 components that we think will be useful in any real-time 114 communications systems. 116 The last few years have also seen a new platform rise for deployment 117 of services: The browser-embedded application, or "Web application". 118 It turns out that as long as the browser platform has the necessary 119 interfaces, it is possible to deliver almost any kind of service on 120 it. 122 Traditionally, these interfaces have been delivered by plugins, which 123 had to be downloaded and installed separately from the browser; in 124 the development of HTML5, much promise is seen by the possibility of 125 making those interfaces available in a standardized way within the 126 browser. 128 Other efforts, for instance the W3C Web Applications and Device API 129 working groups, focus on making standardized APIs and interfaces 130 available, within or alongside the HTML5 effort, for those functions; 131 this memo concentrates on specifying the protocols and subprotocols 132 that are needed to specify the interactions that happen across the 133 network. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Protocol Requirements 143 The section defines the set of protocols and selected subset profiles 144 of these protocols that RTC-WEB client applications will need to 145 implement. This set of protocols forms the requirements for the 146 controlling APIs in [Section 4]. At a high level this section is 147 split into five subsections that address requirements for RTC-WEB 148 client application: connection management, signaling protocols, codec 149 requirements, transports for real time media such as audio and video 150 and transports for non media data . 152 3.1. Connection Management Requirements 154 It is quite probable that many RTC-WEB client applications, such as 155 web browsers will be deployed behind a NAT. To set up secure data 156 plane sessions, all RTC-WEB client application implementations will 157 use ICE [RFC5245] or ICE-Lite Section 2.7 of [RFC5245]. ICE is 158 leveraged here to address the security concerns discussed in 159 [section] Section 7. 161 There are two deployment scenarios for RTC-WEB client applications. 162 The first scenario is when applications are deployed behind NAT and 163 have to worry about NAT traversal. The second scenario is when the 164 application is not behind a NAT, such as an RTC-WEB application that 165 is always connected to the public Internet. As stated in section 2.7 166 of [RFC5245], ICE requires that both endpoints to support it in order 167 for ICE to be used on a call. 169 With regards to RTC-WEB client applications, all applications that 170 are deployed behind a NAT or do not have a public IP address are 171 REQUIRED to support ICE [RFC5245], applications that are not behind a 172 NAT and have a public IP address are REQUIRED to support ICE-Lite and 173 MAY fully support ICE. RTC-WEB client applications that fully 174 support ICE are REQUIRED to support AGGRESSIVE NOMINATION, and MAY 175 support REGULAR NOMINATION. 177 Implicit to supporting ICE, all RTC-WEB client applications are 178 REQUIRED to implement Simple Traversal of User Datagram Protocol 179 (UDP) Through Network Address Translators (NATs) (STUN) [RFC3489] and 180 Traversal Using Relays around NAT (TURN) [RFC5766]. 182 [Open Issue: there is a strong interest to define a TURN-like 183 protocol that looks like HTTP to intermediaries, so that media can be 184 tunneled over HTTP. Should this be done?] 186 3.2. Signaling Protocol Requirements 188 This section covers the signaling protocol to be used by RTC-WEB 189 applications. To ensure interoperability not just between RTC-WEB 190 applications, but with legacy IPPBX phone systems as well, a small 191 subset of SIP will be REQUIRED for all RTC-WEB client application 192 implementations. In addition to the subset of SIP specification 193 [RFC3261], RTC-WEB client application implementations will be 194 REQUIRED to support DNS resolutions as specified in [RFC3263] and the 195 offer/answer model with SDP as specified in [RFC3264]. 197 3.2.1. Client Application SIP Requirements 199 This section focuses on the subset of SIP functionality that will 200 exist within all RTC-WEB client applications. The following User 201 Agent Client (UAC) subset of the SIP specification [RFC3261] is 202 REQUIRED. 204 o General User Agent Behavior - [Section 8] 206 o Registration - [Section 10] 208 o Client Transaction - [Section 17.1] 210 o Canceling a Request - [Section 9.1] 212 o Terminating a Session - [Section 15.1], [Section 15.1.1] 214 o 3.XX Redirect Responses - [Section 8.1.3.4] 216 o TLS - [Section 26.3.1] 218 o Outbound Proxy 220 3.2.2. Client Application Optional SIP Support 222 In the SIP specification [RFC3261], the SIP features listed below are 223 required for all UAC implementations. RTC-WEB client applications 224 are not a fully featured SIP UAC and will only be implementing a 225 subset of the SIP specification. Thusly, unlike SIP UACs, the 226 following list of SIP features is to be considered OPTIONAL for RTC- 227 WEB client application implementations. 229 o INVITEs without an offer 231 o re-INVITEs - [Section 14.1] 233 o forking - [Section 19.3] 235 o S/MIME - [Section 23] 237 o SIPS URI Scheme - [Section 26.2.2] 239 3.2.3. Required SIP Methods 241 This section outlines the REQUIRED SIP methods for all RTC-WEB client 242 applications. 244 o INVITE - [RFC3261] [Section 13] 246 o REGISTER - [RFC3261] [Section 10] 248 o ACK - [RFC3261] [Section 13.2] 250 o CANCEL - [RFC3261] [Section 13.2] 252 o BYE - [RFC3261] [Section 13.2] 254 o UPDATE - [RFC3311] 256 3.2.4. Multipart SIP Message Requirements 258 For handling SIP messages RTC-WEB client applications are required to 259 implement the multipart MIME handling scheme as specified in 260 [RFC5621]. 262 3.2.5. SIP Identity Requirements 264 Identity, for the purposes of this section, is defined as a SIP URI. 265 There are two areas concerning SIP identity this specification will 266 address. 268 The first area covers validation of the message originator. To 269 securely validate a the identity of a SIP message originator, all 270 RTC-WEB client applications are REQUIRED to implement the mechanism 271 specified in [RFC4474]. 273 To support cases were the identify of a caller/callee may change, 274 such as when a call is parked and transferred from the original 275 callee to another party, all RTC-WEB client applications are REQUIRED 276 to implement the identity mechanism specified in [RFC4916]. 278 [RFC3261]implicitly REQUIRES the implementation of the UPDATE method 279 as specified in [RFC3311] 281 3.2.6. SIP Network Address Traversal 283 RTC-WEB client applications MUST support Network Address Translator 284 (NAT) traversal. This section will address SIP-related areas to 285 support NAT traversal. 287 As called for in [3.1] RTC-WEB client applications will implement 288 STUN. To support client-managed connections, STUN-based keep-alives 289 as specified in [RFC5626] are REQUIRED. 291 When SIP is used with UDP, responses to requests are returned to the 292 source address the request came from, and to the port written into 293 the topmost Via header field value of the request. This behavior is 294 not desirable when the RTC-WEB client application is behind a Network 295 Address Translator (NAT). To address UDP traversal problem the 296 "rport" extension as specified in [RFC3581] is REQUIRED. 298 3.3. Codec Requirements 300 This section covers the audio and video codec requirements for RTC- 301 WEB client applications. To ensure a baseline level of 302 interoperability between RTC-Web applications, a minimum set of 303 required codes is specified below. While this section specifies the 304 codecs that will be supported by all RTC-Web application 305 implementations, it leaves the question of supporting additional 306 codecs to the will of the implementer. 308 3.3.1. Audio Codec Requirements 310 RTC-WEB applications are REQUIRED to implement the following audio 311 codecs. 313 o PCMA/PCMU - see section 4.5.14 of [RFC3551] 315 o Telephone-event - [RFC4734] 317 o Opus [draft-ietf-codec-opus] 319 Implementations of the PCMU and PMCA codecs are REQUIRED to support 1 320 channel with a rate of 8000 and a ptime of 20. 322 The following codecs are OPTIONAL for RTC-WEB application 323 implementations. 325 o G729 327 o G722 329 o G722.1 331 o G723 333 o AMR 335 o AMR-WB 337 o iLBC 339 o L16 341 [Open Issue: minimum profile and identifying any additional mandatory 342 to implement audio codecs.] 344 3.3.2. Video Codec Requirements 346 RTC-WEB applications are REQUIRED to implement the following video 347 codecs. 349 o VP8 [I-D.westin-payload-vp8] 351 The following codecs are OPTIONAL for RTC-WEB application 352 implementations. 354 o H.263 356 o H.264-AVC 358 o H.264-SVC 360 [Open Issue: For the mandatory to implement video codec(s) what is 361 the minimum profile?] 363 3.4. Real-Time Media Transport Requirements 365 This section defines the real-time media transport requirements for 366 RTC-Web client application implementation. This section breaks down 367 the RTC-WEB RTP requirements into several sections. The sections 368 cover the RTP requirements for: profile, optimizations, extensions, 369 transport robustness and rate control. 371 [OPEN ISSUE: identify missing requirements] 373 3.4.1. RTP Profile 375 RTC-Web applications to will need to provide a secure, interoperable, 376 bandwidth friendly, media transport profile. The Secure Audio-visual 377 Profile Feedback (SAVPF) as defined in [RFC5124] will meet the needs 378 of RTC-Web applications by providing media encryption, 379 interoperability and a flexible, bandwidth conscious RTCP packet 380 transmission model. All RTC-Web applications are REQUIRED to 381 implement SAVPF. Requiring the implementation of SAVPF also means 382 that RTC-Web applications MUST implicitly support Audio-visual 383 Profile Feedback (AVPF) [RFC4585], Audio-visual Profile (AVP) 384 [RFC3551] and Secure Audio-visual Profile (SAVP) [RFC3711]. 386 3.4.1.1. Profile Encryption Mechanism 388 SAVPF supports SRTP by providing media encryption, integrity 389 protection, replay protection and a limited form of source 390 authentication. Though the SAVPF profile does support secure media 391 transport, it does not specify an encryption keying mechanism. To 392 support keying for SRTP, WEB-RTC application implementors are 393 REQUIRED to implement DTLS-SRPT [RFC5764]. 395 3.4.2. RTP Optimizations 397 This section describes the optimization requirements for RTP within 398 RTC-Web applications. 400 3.4.2.1. RTP and RTCP Multiplexing 402 Historically, RTP and RTCP have been run on separate UDP ports. With 403 the increased use of Network Address Port Translation (NAPT) so have 404 the problems increased for maintaining multiple, costly NAT bindings 405 for each UDP port. This dual UDP port paradigm also complicates 406 firewall administration, since multiple ports must be opened to allow 407 for RTP traffic. To reduce these costs and session setup times, 408 support for multiplexing RTP data packets and RTCP control packets on 409 a single port [RFC5761] is REQUIRED. 411 Note that the use of RTP and RTCP multiplexed on a single port 412 ensures that there is occasional traffic sent on that port, even if 413 there is no active media traffic. This may be useful to keep-alive 414 NAT bindings. 416 3.4.2.2. Reduced-Size RTCP 418 RTCP packets are usually sent as compound RTCP packets and [RFC3550] 419 demands that the RTCP compound packets always start with a Sender 420 Report (SR) or Receiver Report (RR) packet. The SR and RR packets 421 provide reception quality statistics and increase the mean RTCP 422 packet size. Because the mean compound RTCP packet size is larger, 423 the frequency at which RTCP packets can be sent within the RTCP 424 bandwidth share decreases. The decreased transmission frequency 425 creates a performance bottleneck that is especially noticeable when 426 using frequent feedback messages. 428 As mentioned in section [Add ref] RTC-Web applications will be 429 required to implement SAVPF, which implicitly requires feedback. 430 [RFC5506] specifies how to reduce the mean RTCP message and allow for 431 more frequent feedback. Frequent feedback, in turn, is essential to 432 make real-time application quickly aware of changing network 433 conditions and allow them to adapt their transmission and encoding 434 behavior. Support for [RFC5506] is REQUIRED 436 3.4.2.3. Symmetric RTP/RTCP 438 RTP entities choose the RTP and RTCP transport addresses (IP 439 addresses and port numbers), to bind to and receive packets on. 440 However when sending RTP and RTCP packets, senders may use an IP 441 address or port number that is different than the one specified for 442 receiving packets. Using different transport addresses is 443 problematic with regards to NAT traversal. The NAT traversal problem 444 can be alleviated using symmetric RTP/RTCP [RFC4961]. Symmetric RTP/ 445 RTCP requires that the transport addresses for sending and receiving 446 RTP/RTCP packets are identical. All RTC-WEB client applications are 447 REQUIRED to implement Symmetric RTP/RTCP [RFC4961]. 449 3.4.2.4. CNAME Generation 451 The RTCP Canonical Name (CNAME) provides a persistent transport-level 452 identifier for an RTP endpoint. While the Synchronization Source 453 (SSRC) identifier for an RTP endpoint may change if a collision is 454 detected, or when the RTP application is restarted, it's RTCP CNAME 455 is meant to stay unchanged, so that RTP endpoints can be uniquely 456 identified and associated with their RTP media streams. For proper 457 functionality, RTCP CNAMEs should be unique within the participants 458 of an RTP session. 460 The RTP specification [RFC3550] includes guidelines for choosing a 461 unique RTP CNAME. These guidelines are not sufficient in the 462 presence of NAT devices or with regards to addressing privacy 463 concerns resulting from the long-term, persistent identifiers. 465 To address the shortcomings of CNAME selection in[RFC3550], it is 466 RECOMMENDED that RTP CNAME generation follows the approach specified 467 in section 5 of [RFC6222]. 469 For RTC-WEB client applications, such as a web browser, it may not be 470 possible to retrieve the EUI-64 identifier or the host system's MAC 471 address which is needed to fulfill the CNAME generation procedure 472 outlined in section 5 of [RFC6222]. As an alternative to the EUI-64/ 473 MAC address, RTC-WEB client applications MAY generate and use a 474 random number for the unique CNAME generation procedure. 476 3.4.3. RTP Extensions 478 .This section describes the RTP extensions that could be very useful 479 within the RTC-WEB context. 481 3.4.3.1. Conferencing Extensions 483 RTC-Web applications will support conferencing capabilities. While 484 this document remains silent regarding what conferencing topology 485 should be supported for RTC-Web applications, the following section 486 will provide guidance around RTP extensions to support centralized 487 conferencing. 489 For more information on RTP conferencing topologies please refer to 490 [RFC5117] 492 3.4.3.1.1. FIR RTCP Feedback Message 494 The Full Intra Request (FIR) command and message are defined in 495 sections 3.5.1 and 4.3.1 of [RFC5104]. FIR messages will request 496 that the currently distributed session participants send new intra 497 coded pictures to the mixer. FIR is used when switching between 498 sources to ensure that the receivers can decode the video or other 499 predicted media encoding with long prediction chains. It is 500 RECOMMENDED that the FIR message is supported. 502 3.4.3.1.2. PLI RTCP Feedback Message 504 The Picture Loss Indicator (PLI) is defined in Section 6.3.1 of 505 [RFC4585]. PLI messages tell the encoder that a receiver has lost 506 the decoder context and would like it repaired. It is RECOMMENDED 507 that the PLI message is supported. 509 3.4.3.1.3. TMMBR RTCP Feedback Message 511 The Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber") 512 message is defined in sections 3.5.4 and 4.2.1 of [RFC5104]. A 513 receiver, translator, or mixer uses the TMMBR to request a sender to 514 limit the maximum bit rate for a media stream to, or below, the 515 provided value. An example of using TMMBR would be for an RTP mixer 516 to constrain the media sender's bit rate to fit within the lower bit 517 rate range of other session participants. It is RECOMMENDED that the 518 TMMBR message be supported. 520 3.4.3.2. Header Extensions 522 This section describes the requirements for RTC-WEB RTP header 523 extensions. For all RTC-WEB RTP header extensions it is REQUIRED 524 that they are formatted and signaled according to the general 525 mechanism defined in [RFC5285]. 527 [Open Issue: should any of the following headers be added to the 528 list: 530 o Transmission time offsets[RFC5450] 532 o Associating time-codes with RTP streams [RFC5484] [Remove?] 534 Open Issue: There is also ongoing work to define RTP header 535 extensions for providing audio levels: 537 o From the media sender to the mixer [I-D.ietf-avtext-client-to- 538 mixer-audio-level] 540 o From a mixer to a receiver [I-D.ietf-avtext-mixer-to-client-audio- 541 level] 543 Which, if any of the above should be required? optional? 545 ] 547 3.4.3.2.1. Rapid Synchronization 549 Basic RTP session synchronization as described in [RFC3550] can be 550 slow. To improve synchronization performance and maintain relative 551 backwards compatibility it is RECOMMENDED that the rapid RTP 552 synchronization extensions described in [RFC6051] be implemented. 554 3.4.4. RTP Transport Robustness 556 This section identifies tools that can be used to add robustness to 557 the RTP flows. Adding robustness to the RTP flow can reduce packet 558 loss and thus have a positive impact upon media quality. 560 3.4.4.1. RTP Retransmission 562 The retransmission scheme in RTP allows for flexibility of 563 retransmissions. From the receiving side, only selected missing 564 packets can be requested. From the sending side, packets can be 565 prioritized based upon the senders knowledge of the receiver's 566 missing packets. Support for RTP retransmission as defined by 567 [RFC4588] is RECOMMENDED. 569 [Open Issue: is [RFC4588] the way we want to tackle this issue?] 571 3.4.4.2. Forward Error Correction 573 [Open issue - should there be a FEC scheme recommendation?] 575 3.4.4.3. Multicast 577 RTC-WEB client applications support for multicast RTP is NOT 578 REQUIRED. 580 3.4.5. RTP Rate Control 582 [OPEN ISSUE - There are currently no available, standardized RTP rate 583 control mechanism that uses media adaptation. Having a mechanism in 584 place will be REQUIRED for RTC-WEB applications and which means there 585 is a need for the IETF to produce this specification. 587 A potential starting point for defining a solution is "RTP with TCP 588 Friendly Rate Control" [rtp-tfrc].] 590 3.5. Non-Media Data Transport Requirements 592 The RTC-WEB will enable for rich voice and video communications from 593 client applications, such as a web browser. One of the natural 594 extensions of the RTC-WEB and the work emerging from the HTML5 595 community is video games. Video games have a similar stringent real- 596 time requirement for exchanging non-media data types such as a 597 player's screen position. 599 The question of how best to handle non-media data types has been 600 raised. There have been proposals to address this problem. Common 601 to all proposals is how the data transport session is set up, using 602 ICE [RFC5245] in a similar manner to that of RTP [RFC3550]. The 603 proposals vary from once the session is set up; one proposal is just 604 to use a thin shim on top of UDP or DTLS to de-multiplex the packets 605 from other packets such as RTP on the same connection. Another 606 proposal is DTLS over DCCP over UDP with some appropriate congestion 607 control scheme chosen for DCCP. Lastly there has been a proposal to 608 define a data codec to carry the data in RTP. 610 3.5.1. Non-Media Data In RTP 612 This section will answer the question regarding the addition of non- 613 media data types into an RTC-WEB client application initiated RTP 614 session. 616 RTP by design adheres to the application level framing architectural 617 principle. This principle requires that RTP payload formats be 618 specified. By requiring specific payload formats RTP provides a 619 mechanism to optimize the transmission of encoded media. Other than 620 this optimization there is no congestion control mechanisms for RTP. 622 This principle also implies that if a payload format cannot be 623 specified, as the case is with generic data, it breaks one of the 624 fundamental architectural principles of RTP and makes optimization 625 impossible. Given that the ability to optimize the transmission of 626 non-media data types is lost and there are no capabilities for 627 congestion control within RTP, it follows that there is no benefit to 628 using RTP instead of a more general data transport such as UDP. 629 Until non-media data payload formats are created, the use of RTP as a 630 non-media data transport SHALL NOT be used in conjunction with any 631 RTC-WEB client application implementation. 633 [Open issue: There has been mention of actually creating new payload 634 formats for non-media data types. If new payload formats are 635 actually created for specific types of non-media data, the 636 requirement above would still stand as the application level framing 637 principle would be preserved and the new formats would have to adhere 638 to the principle. Any new formats would be specified outside of this 639 document but referred to] 641 3.5.2. Transporting Non-Media Data 643 [OPEN issue: need further discussion around this area] 645 There have been some ideas proposed but nothing has emerged as the 646 dominant paradigm. The current thinking is that, for RTC-WEB client 647 applications, RTP is not an option for non-media data types that do 648 not have a payload format specification. Without a payload format 649 specification a workable solution would resemble something that 650 allows datagrams to be transmitted via a secure, congestion- 651 controlled, unreliable transport mechanism. 653 3.5.2.1. Proposed Solutions for Non-Media Data Transport 655 One of the current proposed solutions could meet the requirements for 656 a non-media data type transport for RTC-WEB client application is to 657 use a DCCP via the following specifications: 659 o DCCP [RFC4340] using TCP [RFC4341] or TFRC [RFC4342] for 660 congestion control 662 o DTLS for DCCP [RFC5238] 664 o DCCP over UDP [draft-ietf-dccp-udpencap] 666 The maturity of available implementations of DCCP is of concern along 667 with the partiality of this proposed solution. Another way of 668 tackling the problem of non-media data transport is to push the 669 requirements into the RTC-WEB client application implementation. 671 The following is a proposed set of REQUIRED RTC-WEB client 672 application non-media data transport requirements. 674 o Support for a broad congestion control constraints are REQUIRED, 675 it is RECOMMENDED that implementors support either TFRC [RFC5348] 676 or TFRC-SP [RFC4828]. 678 o Support for full congestion control is RECOMMENDED, the specific 679 implementation is left to the RTC-WEB client application 680 implementor. 682 o Support for DTLS over UDP is REQUIRED 684 As an example of how these proposed requirements could be implemented 685 within an RTC-WEB client application, lets explore a web browser- 686 based implementation. In this specific implementation, the web 687 browser would provide DTLS over UDP and implement a broad congestion 688 control solution such as TFRC or TFRC-SP. This implementation will 689 yield a coarse-grained congestion controlled non-media data transport 690 solution that is accessible via JavaScript API calls. These non- 691 media data transport capabilities would provide a flexible solution 692 for web developers to build a full congestion control solution into 693 their WEB-RTC client application. 695 [Open Issue: Given that there is no consensus with regards to a 696 transport solution, this topic needs further discussion. 698 Open Issue: Areas for further discussion: 700 o Unreliable datagram transport - should this be UDP, SCTP or DCCP? 702 o Congestion control mechanisms - DCCP and SCTP something else? 704 o Protection of data confidentiality and integrity - DTLS 705 o Receiver consent mechanisms for data transmission 707 ] 709 4. API Requirements 711 NOT Ready - need to decide on protocols first, API comes after that 713 RTP 715 The API needs to allow the DSCP REF for each RTP or media stream to 716 be set. 718 The API needs to allow the browser app to observer and control the 719 SSRC values in the RTP. 721 Codec 723 The API needs to support the following OPTIONAL codecs: H263-2000, 724 H264, H264-SVC, raw and VP8. 726 The API needs to support the following OPTIONAL codecs: G729, G722, 727 G7221, G723, AMR, AMR-WB, iLBC, L16 and opus. 729 5. Legacy VoIP Interoperability 731 There is no way to meet all the security requirements and maintain 732 comparability with all legacy VoIP equipment. This draft tries to 733 minimize the impedance mismatch. The requirements here would allow 734 interoperability with legacy VoIP equipment as long as that equipment 735 either directly supported, or was fronted by an SBC that supported, 736 the following: a CORS [W3C.WD-cors-20090317] extension for SIP, ICE 737 or ICE-Lite, the mandatory to implement codecs in [SECTION], 738 supported SIP invites containing an offer, and supported DTMF over 739 RTP with telephone events. 741 Of the items listed above, support for ICE-Lite has historically been 742 lacking in VoIP equipment, this is changing and ICE-Lite becoming 743 increasingly prevalent, particularly on devices designed to sit on 744 the edge of a domain and connect to remote user agents that may be 745 behind NATs. Given the increasing adoption of ICE-Lite, it could be 746 conjectured that a substantial fraction of VoIP equipment meets the 747 RTC-WEB interoperability list except for the CORS extensions. 749 For an edge device that was willing to receive SIP call from others, 750 implementing the CORS is pretty trivial. When the UAS receives a SIP 751 options request with an Origin header, it checks whether the header 752 field value is on the white list, and if it is then the UAS copies 753 the value to the Access-Control-Allow-Origin header field value in 754 the response. For many situations the white list would be 755 everything, while for others it would be just the list of websites 756 that are expected to originate calls to this SIP device. 758 6. IANA Considerations 760 This document makes no request of IANA. 762 Note to RFC Editor: this section may be removed on publication as an 763 RFC. 765 7. Security Considerations 767 Because there are a number of security issues, considerations and 768 requirements for RTC-WEB client applications there is a draft that 769 specifically addresses the RTC-WEB application security 770 considerations. This draft defers it's security considerations and 771 requirements to the security considerations for RTC-Web draft 772 [I-D.ekr-security-considerations-for-rtc-web]. 774 8. Acknowledgements 776 Many thanks to Harald Alvestrand, Magnus Westerlund, Colin Perkins, 777 Joerg Ott for a signifcant amount of text and contributed ideas on 778 this topic. 780 9. Normative References 782 [I-D.ekr-security-considerations-for-rtc-web] 783 Rescorla, E., "Security Considerations for RTC-Web", 784 May 2011. 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 790 A., Peterson, J., Sparks, R., Handley, M., and E. 791 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 792 June 2002. 794 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 795 Protocol (SIP): Locating SIP Servers", RFC 3263, 796 June 2002. 798 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 799 with Session Description Protocol (SDP)", RFC 3264, 800 June 2002. 802 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 803 UPDATE Method", RFC 3311, October 2002. 805 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 806 "STUN - Simple Traversal of User Datagram Protocol (UDP) 807 Through Network Address Translators (NATs)", RFC 3489, 808 March 2003. 810 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 811 Jacobson, "RTP: A Transport Protocol for Real-Time 812 Applications", STD 64, RFC 3550, July 2003. 814 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 815 Video Conferences with Minimal Control", STD 65, RFC 3551, 816 July 2003. 818 [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the 819 Session Initiation Protocol (SIP) for Symmetric Response 820 Routing", RFC 3581, August 2003. 822 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 823 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 824 RFC 3711, March 2004. 826 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 827 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 829 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 830 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 831 Congestion Control", RFC 4341, March 2006. 833 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 834 Datagram Congestion Control Protocol (DCCP) Congestion 835 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 836 March 2006. 838 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 839 Authenticated Identity Management in the Session 840 Initiation Protocol (SIP)", RFC 4474, August 2006. 842 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 843 "Extended RTP Profile for Real-time Transport Control 844 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 845 July 2006. 847 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 848 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 849 July 2006. 851 [RFC4734] Schulzrinne, H. and T. Taylor, "Definition of Events for 852 Modem, Fax, and Text Telephony Signals", RFC 4734, 853 December 2006. 855 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 856 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 857 April 2007. 859 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 860 Protocol (SIP)", RFC 4916, June 2007. 862 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 863 BCP 131, RFC 4961, July 2007. 865 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 866 "Codec Control Messages in the RTP Audio-Visual Profile 867 with Feedback (AVPF)", RFC 5104, February 2008. 869 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 870 January 2008. 872 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 873 Real-time Transport Control Protocol (RTCP)-Based Feedback 874 (RTP/SAVPF)", RFC 5124, February 2008. 876 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 877 the Datagram Congestion Control Protocol (DCCP)", 878 RFC 5238, May 2008. 880 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 881 (ICE): A Protocol for Network Address Translator (NAT) 882 Traversal for Offer/Answer Protocols", RFC 5245, 883 April 2010. 885 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 886 Header Extensions", RFC 5285, July 2008. 888 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 889 Friendly Rate Control (TFRC): Protocol Specification", 890 RFC 5348, September 2008. 892 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 893 RTP Streams", RFC 5450, March 2009. 895 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 896 RFC 5484, March 2009. 898 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 899 Real-Time Transport Control Protocol (RTCP): Opportunities 900 and Consequences", RFC 5506, April 2009. 902 [RFC5621] Camarillo, G., "Message Body Handling in the Session 903 Initiation Protocol (SIP)", RFC 5621, September 2009. 905 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 906 Initiated Connections in the Session Initiation Protocol 907 (SIP)", RFC 5626, October 2009. 909 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 910 Control Packets on a Single Port", RFC 5761, April 2010. 912 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 913 Security (DTLS) Extension to Establish Keys for the Secure 914 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 916 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 917 Relays around NAT (TURN): Relay Extensions to Session 918 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 920 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 921 Flows", RFC 6051, November 2010. 923 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 924 Choosing RTP Control Protocol (RTCP) Canonical Names 925 (CNAMEs)", RFC 6222, April 2011. 927 Authors' Addresses 929 Cary Bran 930 Cisco 931 170 West Tasman Drive 932 San Jose, CA 95134 933 USA 935 Phone: +1 206 256-3502 936 Email: cbran@cisco.com 937 Cullen Jennings 938 Cisco 939 170 West Tasman Drive 940 San Jose, CA 95134 941 USA 943 Phone: +1 408 421-9990 944 Email: fluffy@cisco.com