idnits 2.17.1 draft-ietf-rtcweb-rtp-usage-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 264: '...for RTP and RTCP MUST be signalled for...' RFC 2119 keyword, line 266: '...RTCP flows, this MUST be signalled (se...' RFC 2119 keyword, line 268: '...layer flow, this MUST also be signalle...' RFC 2119 keyword, line 321: '... The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be...' RFC 2119 keyword, line 325: '...protocol, and is REQUIRED to be implem...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4426 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 (-05) exists of draft-ietf-avtcore-srtp-encrypted-header-ext-00 == Outdated reference: A later version (-04) exists of draft-ietf-avtcore-srtp-vbr-audio-03 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-02 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-01 ** Downref: Normative reference to an Informational draft: draft-jesup-rtp-congestion-reqs (ref. 'I-D.jesup-rtp-congestion-reqs') == Outdated reference: A later version (-01) exists of draft-perkins-avtcore-rtp-circuit-breakers-00 == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-00 ** Downref: Normative reference to an Informational draft: draft-westerlund-avtcore-multiplex-architecture (ref. 'I-D.westerlund-avtcore-multiplex-architecture') ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) == Outdated reference: A later version (-03) exists of draft-begen-mmusic-redundancy-grouping-01 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Intended status: Standards Track M. Westerlund 5 Expires: September 13, 2012 Ericsson 6 J. Ott 7 Aalto University 8 March 12, 2012 10 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 11 draft-ietf-rtcweb-rtp-usage-02 13 Abstract 15 The Web Real-Time Communication (WebRTC) framework provides support 16 for direct interactive rich communication using audio, video, text, 17 collaboration, games, etc. between two peers' web-browsers. This 18 memo describes the media transport aspects of the WebRTC framework. 19 It specifies how the Real-time Transport Protocol (RTP) is used in 20 the WebRTC context, and gives requirements for which RTP features, 21 profiles, and extensions need to be supported. 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 http://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 September 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Discussion and Rationale . . . . . . . . . . . . . . . . . . . 4 60 3.1. Supported RTP Topologies . . . . . . . . . . . . . . . . . 4 61 3.2. Signalling Requirements . . . . . . . . . . . . . . . . . 7 62 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 8 63 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Choice of RTP Profile . . . . . . . . . . . . . . . . . . 8 65 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 9 66 4.4. RTP Session Multiplexing . . . . . . . . . . . . . . . . . 10 67 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 68 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10 69 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 11 70 4.8. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11 71 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12 72 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12 73 5.1.1. Full Intra Request . . . . . . . . . . . . . . . . . . 13 74 5.1.2. Picture Loss Indication . . . . . . . . . . . . . . . 13 75 5.1.3. Slice Loss Indication . . . . . . . . . . . . . . . . 13 76 5.1.4. Reference Picture Selection Indication . . . . . . . . 13 77 5.1.5. Temporary Maximum Media Stream Bit Rate Request . . . 13 78 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 79 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14 80 5.2.2. Client to Mixer Audio Level . . . . . . . . . . . . . 14 81 5.2.3. Mixer to Client Audio Level . . . . . . . . . . . . . 15 82 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15 83 6.1. Retransmission . . . . . . . . . . . . . . . . . . . . . . 15 84 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 16 85 6.2.1. Basic Redundancy . . . . . . . . . . . . . . . . . . . 17 86 6.2.2. Block Based FEC . . . . . . . . . . . . . . . . . . . 18 87 6.2.3. Recommendations for FEC . . . . . . . . . . . . . . . 19 88 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . . 19 89 7.1. Congestion Control Requirements . . . . . . . . . . . . . 20 90 7.2. RTCP Limiations . . . . . . . . . . . . . . . . . . . . . 20 91 7.3. Legacy Interop Limitations . . . . . . . . . . . . . . . . 21 92 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 The Real-time Transport Protocol (RTP) [RFC3550] provides a framework 104 for delivery of audio and video teleconferencing data and other real- 105 time media applications. Previous work has defined the RTP protocol, 106 plus numerous profiles, payload formats, and other extensions. When 107 combined with appropriate signalling, these form the basis for many 108 teleconferencing systems. 110 The Web Real-Time communication (WebRTC) framework is a new activity 111 that provides support for direct, interactive, and rich communication 112 using audio, video, collaboration, games, etc., between two peers' 113 web-browsers. This memo describes how the RTP framework is used in 114 the WebRTC context. It proposes a baseline set of RTP features that 115 should be implemented by all WebRTC-aware browsers, along with some 116 suggested extensions for enhanced functionality. 118 The WebRTC overview [I-D.ietf-rtcweb-overview] outlines the complete 119 WebRTC framework, of which this memo is a part. 121 2. Terminology 123 This memo is structured into different topics. For each topic, one 124 or several recommendations from the authors are given. When it comes 125 to the importance of extensions, or the need for implementation 126 support, we use three requirement levels to indicate the importance 127 of the feature to the WebRTC specification: 129 REQUIRED: Functionality that is absolutely needed to make the WebRTC 130 solution work well, or functionality of low complexity that 131 provides high value. 133 RECOMMENDED: Should be included as its brings significant benefit, 134 but the solution can potentially work without it. 136 OPTIONAL: Something that is useful in some cases, but not always a 137 benefit. 139 3. Discussion and Rationale 141 3.1. Supported RTP Topologies 143 RTP supports both unicast and group communication, with participants 144 being connected using wide range of transport-layer topologies. Some 145 of these topologies involve only the end-points, while others use RTP 146 translators and mixers to provide in-network processing. Properties 147 of some RTP topologies are discussed in [RFC5117], and we further 148 describe those expected to be useful for WebRTC in the following. 150 +---+ +---+ 151 | A |<------->| B | 152 +---+ +---+ 154 Figure 1: Point to Point 156 The point to point topology (Figure 1) is going to be very common in 157 any single user to single user applications. 159 +---+ +---+ 160 | A |<---->| B | 161 +---+ +---+ 162 ^ ^ 163 \ / 164 \ / 165 v v 166 +---+ 167 | C | 168 +---+ 170 Figure 2: Multi-unicast 172 For small multiparty sessions it is practical enough to create RTP 173 sessions by letting every participant send individual unicast RTP/UDP 174 flows to each of the other participants. This is called multi- 175 unicast (Figure 2), and is unfortunately not discussed in the RTP 176 Topologies [RFC5117]. This topology has the benefit of not requiring 177 central nodes. The downside is that it increases the used bandwidth 178 at each sender by requiring one copy of the media streams for each 179 participant that are part of the same session beyond the sender 180 itself. Thus this is limited to scenarios with few end-points unless 181 the media is very low bandwidth. 183 This topology may be implemented as a single RTP session, spanning 184 multiple peer to peer transport layer connections, or as several 185 pairwise RTP sessions, one between each pair of peers. The later 186 approach simplifies rate adaptation, but reduces the effectiveness of 187 RTCP for debugging purposes, by limiting the ability to send third- 188 party RTCP reports. 190 +---+ +------------+ +---+ 191 | A |<---->| |<---->| B | 192 +---+ | | +---+ 193 | Mixer | 194 +---+ | | +---+ 195 | C |<---->| |<---->| D | 196 +---+ +------------+ +---+ 198 Figure 3: RTP Mixer with Only Unicast Paths 200 An RTP mixer (Figure 3) is a centralised point that selects or mixes 201 content in a conference to optimise the RTP session so that each end- 202 point only needs connect to one entity, the mixer. The mixer also 203 reduces the bit-rate needs as the media sent from the mixer to the 204 end-point can be optimised in different ways. These optimisations 205 include methods like only choosing media from the currently most 206 active speaker or mixing together audio so that only one audio stream 207 is required in stead of 3 in the depicted scenario. The downside of 208 the mixer is that someone is required to provide the actual mixer. 210 +---+ +------------+ +---+ 211 | A |<---->| |<---->| B | 212 +---+ | | +---+ 213 | Translator | 214 +---+ | | +---+ 215 | C |<---->| |<---->| D | 216 +---+ +------------+ +---+ 218 Figure 4: RTP Translator (Relay) with Only Unicast Paths 220 If one wants a less complex central node it is possible to use an 221 relay (called an Transport Translator) (Figure 4) that takes on the 222 role of forwarding the media to the other end-points but doesn't 223 perform any media processing. It simply forwards the media from all 224 other to all the other. Thus one endpoint A will only need to send a 225 media once to the relay, but it will still receive 3 RTP streams with 226 the media if B, C and D all currently transmits. 228 +------------+ 229 | | 230 +---+ | | +---+ 231 | A |<---->| Translator |<---->| B | 232 +---+ | | +---+ 233 | | 234 +------------+ 236 Figure 5: Translator towards Legacy end-point 238 To support legacy end-point (B) that don't fulfil the requirements of 239 WebRTC it is possible to insert a Translator (Figure 5) that takes on 240 the role to ensure that from A's perspective B looks like a fully 241 compliant end-point. Thus it is the combination of the Translator 242 and B that looks like the end-point B. The intention is that the 243 presence of the translator is transparent to A, however it is not 244 certain that is possible. Thus this case is include so that it can 245 be discussed if any mechanism specified to be used for WebRTC results 246 in such issues and how to handle them. 248 3.2. Signalling Requirements 250 RTP is built with the assumption of an external signalling channel 251 that can be used to configure the RTP sessions and their features. 252 The basic configuration of an RTP session consists of the following 253 parameters: 255 RTP Profile: The name of the RTP profile to be used in session. The 256 RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate 257 on basic level, as can their secure variants RTP/SAVP [RFC3711] 258 and RTP/SAVPF [RFC5124]. The secure variants of the profiles do 259 not directly interoperate with the non-secure variants, due to the 260 presence of additional header fields in addition to any 261 cryptographic transformation of the packet content. 263 Transport Information: Source and destination address(s) and ports 264 for RTP and RTCP MUST be signalled for each RTP session. If RTP 265 and RTCP multiplexing [RFC5761] is to be used, such that a single 266 port is used for RTP and RTCP flows, this MUST be signalled (see 267 Section 4.5). If several RTP sessions are to be multiplexed onto 268 a single transport layer flow, this MUST also be signalled (see 269 Section 4.4). 271 RTP Payload Types, media formats, and media format 272 parameters: The mapping between media type names (and hence the RTP 273 payload formats to be used) and the RTP payload type numbers must 274 be signalled. Each media type may also have a number of media 275 type parameters that must also be signalled to configure the codec 276 and RTP payload format (the "a=fmtp:" line from SDP). 278 RTP Extensions: The RTP extensions one intends to use need to be 279 agreed upon, including any parameters for each respective 280 extension. At the very least, this will help avoiding using 281 bandwidth for features that the other end-point will ignore. But 282 for certain mechanisms there is requirement for this to happen as 283 interoperability failure otherwise happens. 285 RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the 286 end-points will be necessary, as described in "Session Description 287 Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) 288 Bandwidth" [RFC3556], or something semantically equivalent. This 289 also ensures that the end-points have a common view of the RTCP 290 bandwidth, this is important as too different view of the 291 bandwidths may lead to failure to interoperate. 293 These parameters are often expressed in SDP messages conveyed within 294 an offer/answer exchange. RTP does not depend on SDP or on the 295 offer/answer model, but does require all the necessary parameters to 296 be agreed somehow, and provided to the RTP implementation. We note 297 that in RTCWEB context it will depend on the signalling model and API 298 how these parameters need to be configured but they will be need to 299 either set in the API or explicitly signalled between the peers. 301 4. WebRTC Use of RTP: Core Protocols 303 RTP and RTCP are flexible and extensible protocols that allow, on the 304 one hand, choosing from a variety of building blocks and combining 305 those to meet application needs, but on the other hand, offer the 306 ability to create extensions where existing mechanisms are not 307 sufficient. This memo requires a number of RTP and RTCP extensions 308 that have been shown to be provide important functionality in the 309 WebRTC context be implemented. It is possible that future extensions 310 will be needed: several documents provide guidelines for the use and 311 extension of RTP and RTCP, including Guidelines for Writers of RTP 312 Payload Format Specifications [RFC2736] and Guidelines for Extending 313 the RTP Control Protocol [RFC5968], and should be consulted before 314 extending this memo. 316 The following describe core features of RTP, and core extensions, 317 that must be supported in all WebRTC implementations. 319 4.1. RTP and RTCP 321 The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be 322 implemented as the media transport protocol for WebRTC. RTP itself 323 comprises two parts: the RTP data transfer protocol, and the RTP 324 control protocol (RTCP). RTCP is a fundamental and integral part of 325 the RTP protocol, and is REQUIRED to be implemented. 327 4.2. Choice of RTP Profile 329 The complete specification of RTP for a particular application domain 330 requires the choice of an RTP Profile. For WebRTC use, the "Extended 331 Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- 332 Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to be implemented. 333 This builds on the basic RTP/AVP profile [RFC3551], the RTP/AVPF 334 feedback profile [RFC4585], and the secure RTP/SAVP profile 335 [RFC3711]. 337 The RTP/AVPF part of RTP/SAVPF is required to get the improved RTCP 338 timer model, that allows more flexible transmission of RTCP packets 339 in response to events, rather than strictly according to bandwidth. 340 This also saves RTCP bandwidth and will commonly only use the full 341 amount when there is a lot of events on which to send feedback. This 342 functionality is needed to make use of the RTP conferencing 343 extensions discussed in Section 5.1. The improved RTCP timer model 344 defined by RTP/AVPF is backwards compatible with legacy systems that 345 implement only the RTP/AVP profile given some constraints on 346 parameter configuration such as RTCP banwidth and "trr-int". 348 The RTP/SAVP part of RTP/SAVPF is for support for Secure RTP (SRTP) 349 [RFC3711]. This provides media encryption, integrity protection, 350 replay protection and a limited form of source authentication. 352 (tbd: There is ongoing discussion on what keying mechanism is to be 353 required, what are the mandated cryptographic transforms, and whether 354 fallback to plain RTP should be supported. This section needs to be 355 updated based on the results of that discussion.) 357 4.3. Choice of RTP Payload Formats 359 (tbd: say something about the choice of RTP Payload Format for 360 WebRTC. If there is a mandatory to implement set of codecs, this 361 should reference them. In any case, it should reference a discussion 362 of signalling for the choice of codec, once that discussion reaches 363 closure.) 365 Endpoints may signal support for multiple media formats, or multiple 366 configurations of a single format, provided each uses a different RTP 367 payload type number. An endpoint that has signalled it's support for 368 multiple formats is REQUIRED to accept data in any of those formats 369 at any time, unless it has previously signalled limitations on it's 370 decoding capability (this is modified if several RTP sessions are to 371 be multiplexed onto one transport layer connection, such that an 372 endpoint must be prepared for a source to switch between formats of 373 the same media type at any time; see Section 4.4). To support rapid 374 rate adaptation, RTP does not require advance signalling for changes 375 between payload formats that were signalled during session setup. 377 4.4. RTP Session Multiplexing 379 An association amongst a set of participants communicating with RTP 380 is known as an RTP session. A participant may be involved in 381 multiple RTP sessions at the same time. In a multimedia session, 382 each medium has typically been carried in a separate RTP session with 383 its own RTCP packets (i.e., one RTP session for the audio, with a 384 separate RTP session running on a different transport connection for 385 the video; if SDP is used, this corresponds to one RTP session for 386 each "m=" line in the SDP). WebRTC implementations of RTP are 387 REQUIRED to implement support of multimedia sessions in this way, for 388 compatibility with legacy systems. 390 In today's networks, however, with the prolific use of Network 391 Address Translators (NAT) and Firewalls (FW), there is a desire to 392 reduce the number of transport layer ports used by real-time media 393 applications using RTP by combining multimedia traffic in a single 394 RTP session. (Details of how this is to be done are tbd, but see 395 [I-D.lennox-rtcweb-rtp-media-type-mux], 396 [I-D.holmberg-mmusic-sdp-bundle-negotiation] and 397 [I-D.westerlund-avtcore-multiplex-architecture].) WebRTC 398 implementations of RTP are REQUIRED to support multiplexing of 399 multimedia sessions onto a single RTP session according to (tbd). If 400 such RTP session multiplexing is to be used, this MUST be negotiated 401 during the signalling phase. 403 4.5. RTP and RTCP Multiplexing 405 Historically, RTP and RTCP have been run on separate UDP ports. With 406 the increased use of Network Address/Port Translation (NAPT) this has 407 become problematic, since maintaining multiple NAT bindings can be 408 costly. It also complicates firewall administration, since multiple 409 ports must be opened to allow RTP traffic. To reduce these costs and 410 session setup times, support for multiplexing RTP data packets and 411 RTCP control packets on a single port [RFC5761] is REQUIRED. 413 Note that the use of RTP and RTCP multiplexed on a single port 414 ensures that there is occasional traffic sent on that port, even if 415 there is no active media traffic. This may be useful to keep-alive 416 NAT bindings and is recommend method for application level keep- 417 alives of RTP sessions [RFC6263]. 419 4.6. Reduced Size RTCP 421 RTCP packets are usually sent as compound RTCP packets, and RFC 3550 422 requires that those compound packets start with an SR or RR packet. 423 When using frequent feedback messages, these general statistics are 424 not needed in every packet and unnecessarily increase the mean RTCP 425 packet size. This can limit the frequency at which RTCP packets can 426 be sent within the RTCP bandwidth share. 428 To avoid this problem, [RFC5506] specifies how to reduce the mean 429 RTCP message and allow for more frequent feedback. Frequent 430 feedback, in turn, is essential to make real-time application quickly 431 aware of changing network conditions and allow them to adapt their 432 transmission and encoding behaviour. Support for RFC5506 is 433 REQUIRED. 435 4.7. Symmetric RTP/RTCP 437 RTP entities choose the RTP and RTCP transport addresses, i.e., IP 438 addresses and port numbers, to receive packets on and bind their 439 respective sockets to those. When sending RTP packets, however, they 440 may use a different IP address or port number for RTP, RTCP, or both; 441 e.g., when using a different socket instance for sending and for 442 receiving. Symmetric RTP/RTCP requires that the IP address and port 443 number for sending and receiving RTP/RTCP packets are identical. 445 The reasons for using symmetric RTP is primarily to avoid issues with 446 NAT and Firewalls by ensuring that the flow is actually bi- 447 directional and thus kept alive and registered as flow the intended 448 recipient actually wants. In addition it saves resources in the form 449 of ports at the end-points, but also in the network as NAT mappings 450 or firewall state is not unnecessary bloated. Also the number of QoS 451 state are reduced. 453 Using Symmetric RTP and RTCP [RFC4961] is REQUIRED. 455 4.8. Generation of the RTCP Canonical Name (CNAME) 457 The RTCP Canonical Name (CNAME) provides a persistent transport-level 458 identifier for an RTP endpoint. While the Synchronisation Source 459 (SSRC) identifier for an RTP endpoint may change if a collision is 460 detected, or when the RTP application is restarted, it's RTCP CNAME 461 is meant to stay unchanged, so that RTP endpoints can be uniquely 462 identified and associated with their RTP media streams. For proper 463 functionality, RTCP CNAMEs should be unique among the participants of 464 an RTP session. 466 The RTP specification [RFC3550] includes guidelines for choosing a 467 unique RTP CNAME, but these are not sufficient in the presence of NAT 468 devices. In addition, some may find long-term persistent identifiers 469 problematic from a privacy viewpoint. Accordingly, support for 470 generating a short-term persistent RTCP CNAMEs following method (b) 471 as specified in Section 4.2 of "Guidelines for Choosing RTP Control 472 Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is REQUIRED, 473 since this addresses both concerns. 475 5. WebRTC Use of RTP: Extensions 477 There are a number of RTP extensions that could be very useful in the 478 WebRTC context. One set is related to conferencing, others are more 479 generic in nature. None of these are mandatory to implement, but 480 they are expected to be generally useful. 482 5.1. Conferencing Extensions 484 RTP is inherently a group communication protocol. Groups can be 485 implemented using a centralised server, multi-unicast, or IP 486 multicast. While IP multicast was popular in early deployments, in 487 today's practice, overlay-based conferencing dominates, typically 488 using one or more central servers to connect endpoints in a star or 489 flat tree topology. These central servers can be implemented in a 490 number of ways [RFC5117], of which the following are the most common: 492 1. RTP Translator (Relay) with Only Unicast Paths ([RFC5117], 493 section 3.3) 495 2. RTP Mixer with Only Unicast Paths ([RFC5117], section 3.4) 497 3. Point to Multipoint Using a Video Switching MCU ([RFC5117], 498 section 3.5) 500 4. Point to Multipoint Using Content Modifying MCUs ([RFC5117], 501 section 3.6) 503 As discussed in [RFC5117] section 3.5, the use of a video switching 504 MCU makes the use of RTCP for congestion control, or any type of 505 quality reports, very problematic. Also, as discussed in [RFC5117] 506 section 3.6, the use of a content modifying MCU with RTCP termination 507 breaks RTP loop detection and removes the ability for receivers to 508 identify active senders. According only the first two options are 509 recommended. 511 RTP protocol extensions to be used with conferencing are included 512 because they are important in the context of centralised 513 conferencing, where one RTP Mixer (Conference Focus) receives a 514 participants media streams and distribute them to the other 515 participants. These messages are defined in the Extended RTP Profile 516 for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 517 AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- 518 Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully 519 usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. 521 5.1.1. Full Intra Request 523 The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of CCM 524 [RFC5104]. It is used to have the mixer request from a session 525 participants a new Intra picture. This is used when switching 526 between sources to ensure that the receivers can decode the video or 527 other predicted media encoding with long prediction chains. It is 528 RECOMMENDED that this feedback message is supported. 530 5.1.2. Picture Loss Indication 532 The Picture Loss Indication is defined in Section 6.3.1 of the RTP/ 533 AVPF profile [RFC4585]. It is used by a receiver to tell the encoder 534 that it lost the decoder context and would like to have it repaired 535 somehow. This is semantically different from the Full Intra Request 536 above. It is RECOMMENDED that this feedback message is supported as 537 a loss tolerance mechanism. 539 5.1.3. Slice Loss Indication 541 The Slice Loss Indicator is defined in Section 6.3.2 of the RTP/AVPF 542 profile [RFC4585]. It is used by a receiver to tell the encoder that 543 it has detected the loss or corruption of one or more consecutive 544 macroblocks, and would like to have these repaired somehow. The use 545 of this feedback message is OPTIONAL as a loss tolerance mechanism. 547 5.1.4. Reference Picture Selection Indication 549 Reference Picture Selection Indication (RPSI) is defined in Section 550 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video coding standards 551 allow the use of older reference pictures than the most recent one 552 for predictive coding. If such a codec is in used, and if the 553 encoder has learned about a loss of encoder-decoder synchronicity, a 554 known-as-correct reference picture can be used for future coding. 555 The RPSI message allows this to be signalled. The use of this RTCP 556 feedback message is OPTIONAL as a loss tolerance mechanism. 558 5.1.5. Temporary Maximum Media Stream Bit Rate Request 560 This feedback message is defined in Section 3.5.4 and 4.2.1 in CCM 561 [RFC5104]. This message and its notification message is used by a 562 media receiver, to inform the sending party that there is a current 563 limitation on the amount of bandwidth available to this receiver. 564 This can be for various reasons, and can for example be used by an 565 RTP mixer to limit the media sender being forwarded by the mixer 566 (without doing media transcoding) to fit the bottlenecks existing 567 towards the other session participants. It is RECOMMENDED that this 568 feedback message is supported. 570 5.2. Header Extensions 572 The RTP specification [RFC3550] provides a capability to extend the 573 RTP header with in-band data, but the format and semantics of the 574 extensions are poorly specified. The use of header extensions is 575 OPTIONAL, but if are used, it is REQUIRED that they be formatted and 576 signalled according to the general mechanism of RTP header extensions 577 defined in [RFC5285]. 579 As noted in [RFC5285], the requirement from the RTP specification 580 that header extensions are "designed so that the header extension may 581 be ignored" [RFC3550] stands. To be specific, header extensions must 582 only be used for data that can safely be ignored by the recipient 583 without affecting interoperability, and must not be used when the 584 presence of the extension has changed the form or nature of the rest 585 of the packet in a way that is not compatible with the way the stream 586 is signalled (e.g., as defined by the payload type). Valid examples 587 might include metadata that is additional to the usual RTP 588 information. 590 The RTP rapid synchronisation header extension [RFC6051] is 591 recommended, as discussed in Section 5.2.1 we also recommend the 592 client to mixer audio level [RFC6464], and consider the mixer to 593 client audio level [RFC6465] as optional feature. 595 If the client-to-mixer or mixer-to-client audio level indications are 596 in use in SRTP encrypted sessions, it is REQUIRED that the extensions 597 are encrypted according to 598 [I-D.ietf-avtcore-srtp-encrypted-header-ext] since the information 599 contained in these header extensions may be considered sensitive. 601 5.2.1. Rapid Synchronisation 603 Many RTP sessions require synchronisation between audio, video, and 604 other content. This synchronisation is performed by receivers, using 605 information contained in RTCP SR packets, as described in the RTP 606 specification [RFC3550]. This basic mechanism can be slow, however, 607 so it is RECOMMENDED that the rapid RTP synchronisation extensions 608 described in [RFC6051] be implemented. The rapid synchronisation 609 extensions use the general RTP header extension mechanism [RFC5285], 610 which requires signalling, but are otherwise backwards compatible. 612 5.2.2. Client to Mixer Audio Level 614 The Client to Mixer Audio Level [RFC6464] is an RTP header extension 615 used by a client to inform a mixer about the level of audio activity 616 in the packet the header is attached to. This enables a central node 617 to make mixing or selection decisions without decoding or detailed 618 inspection of the payload. Thus reducing the needed complexity in 619 some types of central RTP nodes. 621 The Client to Mixer Audio Level [RFC6464] is RECOMMENDED to be 622 implemented. 624 5.2.3. Mixer to Client Audio Level 626 The Mixer to Client Audio Level header extension [RFC6465] provides 627 the client with the audio level of the different sources mixed into a 628 common mix from the RTP mixer. Thus enabling a user interface to 629 indicate the relative activity level of a session participant, rather 630 than just being included or not based on the CSRC field. This is a 631 pure optimisations of non critical functions and thus optional 632 functionality. 634 The Mixer to Client Audio Level [RFC6465] is OPTIONAL to implement. 636 6. WebRTC Use of RTP: Improving Transport Robustness 638 There are some tools that can make RTP flows robust against Packet 639 loss and reduce the impact on media quality. However they all add 640 extra bits compared to a non-robust stream. These extra bits needs 641 to be considered and the aggregate bit-rate needs to be rate 642 controlled. Thus improving robustness might require a lower base 643 encoding quality but has the potential to give that quality with 644 fewer errors in it. 646 6.1. Retransmission 648 Support for RTP retransmission as defined by "RTP Retransmission 649 Payload Format" [RFC4588] is RECOMMENDED. 651 The retransmission scheme in RTP allows flexible application of 652 retransmissions. Only selected missing packets can be requested by 653 the receiver. It also allows for the sender to prioritise between 654 missing packets based on senders knowledge about their content. 655 Compared to TCP, RTP retransmission also allows one to give up on a 656 packet that despite retransmission(s) still has not been received 657 within a time window. 659 "WebRTC Media Transport Requirements" [I-D.cbran-rtcweb-data] raises 660 two issues that they think makes RTP Retransmission unsuitable for 661 RTCWEB. We here consider these issues and explain why they are in 662 fact not a reason to exclude RTP retransmission from the tool box 663 available to RTCWEB media sessions. 665 The additional latency added by [RFC4588] will exceed the latency 666 threshold for interactive voice and video: RTP Retransmission will 667 require at least one round trip time for a retransmission request 668 and repair packet to arrive. Thus the general suitability of 669 using retransmissions will depend on the actual network path 670 latency between the end-points. In many of the actual usages the 671 latency between two end-points will be low enough for RTP 672 retransmission to be effective. Interactive communication with 673 end-to-end delays of 400 ms still provide a fair quality. Even 674 removing half of that in end-point delays allows functional 675 retransmission between end-points on the same continent. In 676 addition, some applications may accept temporary delay spikes to 677 allow for retransmission of crucial codec information such an 678 parameter sets, intra picture etc, rather than getting no media at 679 all. 681 The undesirable increase in packet transmission at the point when 682 congestion occurs: Congestion loss will impact the rate controls 683 view of available bit-rate for transmission. When using 684 retransmission one will have to prioritise between performing 685 retransmissions and the quality one can achieve with ones 686 adaptable codecs. In many use cases one prefer error free or low 687 rates of error with reduced base quality over high degrees of 688 error at a higher base quality. 690 The RTCWEB end-point implementations will need to both select when to 691 enable RTP retransmissions based on API settings and measurements of 692 the actual round trip time. In addition for each NACK request that a 693 media sender receives it will need to make a prioritisation based on 694 the importance of the requested media, the probability that the 695 packet will reach the receiver in time for being usable, the 696 consumption of available bit-rate and the impact of the media quality 697 for new encodings. 699 To conclude, the issues raised are implementation concerns that an 700 implementation needs to take into consideration, they are not 701 arguments against including a highly versatile and efficient packet 702 loss repair mechanism. 704 6.2. Forward Error Correction (FEC) 706 Support of some type of FEC to combat the effects of packet loss is 707 beneficial, but is heavily application dependent. However, some FEC 708 mechanisms are encumbered. 710 The main benefit from FEC is the relatively low additional delay 711 needed to protect against packet losses. The transmission of any 712 repair packets should preferably be done with a time delay that is 713 just larger than any loss events normally encountered. That way the 714 repair packet isn't also lost in the same event as the source data. 716 The amount of repair packets needed varies depending on the amount 717 and pattern of packet loss to be recovered, and on the mechanism used 718 to derive repair data. The later choice also effects the the 719 additional delay required to both encode the repair packets and in 720 the receiver to be able to recover the lost packet(s). 722 6.2.1. Basic Redundancy 724 The method for providing basic redundancy is to simply retransmit a 725 some time earlier sent packet. This is relatively simple in theory, 726 i.e. one saves any outgoing source (original) packet in a buffer 727 marked with a timestamp of actual transmission, some X ms later one 728 transmit this packet again. Where X is selected to be longer than 729 the common loss events. Thus any loss events shorter than X can be 730 recovered assuming that one doesn't get an another loss event before 731 all the packets lost in the first event has been received. 733 The downside of basic redundancy is the overhead. To provide each 734 packet with once chance of recovery, then the transmission rate 735 increases with 100% as one needs to send each packet twice. It is 736 possible to only redundantly send really important packets thus 737 reducing the overhead below 100% for some other trade-off is 738 overhead. 740 In addition the basic retransmission of the same packet using the 741 same SSRC in the same RTP session is not possible in RTP context. 742 The reason is that one would then destroy the RTCP reporting if one 743 sends the same packet twice with the same sequence number. Thus one 744 needs more elaborate mechanisms. 746 RTP Payload Format Support: Some RTP payload format do support basic 747 redundancy within the RTP paylaod format itself. Examples are 748 AMR-WB [RFC4867] and G.719 [RFC5404]. 750 RTP Payload for Redundant Audio Data: This audio and text redundancy 751 format defined in [RFC2198] allows for multiple levels of 752 redundancy with different delay in their transmissions, as long as 753 the source plus payload parts to be redundantly transmitted 754 together fits into one MTU. This should work fine for most 755 interactive audio and text use cases as both the codec bit-rates 756 and the framing intervals normally allow for this requirement to 757 hold. This payload format also don't increase the packet rate, as 758 original data and redundant data are sent together. This format 759 does not allow perfect recovery, only recovery of information 760 deemed necessary for audio, for example the sequence number of the 761 original data is lost. 763 RTP Retransmission Format: The RTP Retransmission Payload format 764 [RFC4588] can be used to pro-actively send redundant packets using 765 either SSRC or session multiplexing. By using different SSRCs or 766 a different session for the redundant packets the RTCP receiver 767 reports will be correct. The retransmission payload format is 768 used to recover the packets original data thus enabling a perfect 769 recovery. 771 Duplication Grouping Semantics in the Session Description Protocol: 772 This [I-D.begen-mmusic-redundancy-grouping] is proposal for new 773 SDP signalling to indicate media stream duplication using 774 different RTP sessions, or different SSRCs to separate the source 775 and the redundant copy of the stream. 777 6.2.2. Block Based FEC 779 Block based redundancy collects a number of source packets into a 780 data block for processing. The processing results in some number of 781 repair packets that is then transmitted to the other end allowing the 782 receiver to attempt to recover some number of lost packets in the 783 block. The benefit of block based approaches is the overhead which 784 can be lower than 100% and still recover one or more lost source 785 packet from the block. The optimal block codes allows for each 786 received repair packet to repair a single loss within the block. 787 Thus 3 repair packets that are received should allow for any set of 3 788 packets within the block to be recovered. In reality one commonly 789 don't reach this level of performance for any block sizes and number 790 of repair packets, and taking the computational complexity into 791 account there are even more trade-offs to make among the codes. 793 One result of the block based approach is the extra delay, as one 794 needs to collect enough data together before being able to calculate 795 the repair packets. In addition sufficient amount of the block needs 796 to be received prior to recovery. Thus additional delay are added on 797 both sending and receiving side to ensure possibility to recover any 798 packet within the block. 800 The redundancy overhead and the transmission pattern of source and 801 repair data can be altered from block to block, thus allowing a 802 adaptive process adjusting to meet the actual amount of loss seen on 803 the network path and reported in RTCP. 805 The alternatives that exist for block based FEC with RTP are the 806 following: 808 RTP Payload Format for Generic Forward Error Correction: This RTP 809 payload format [RFC5109] defines an XOR based recovery packet. 810 This is the simplest processing wise that an block based FEC 811 scheme can be. It also results in some limited properties, as 812 each repair packet can only repair a single loss. To handle 813 multiple close losses a scheme of hierarchical encodings are need. 814 Thus increasing the overhead significantly. 816 Forward Error Correction (FEC) Framework: This framework 817 [I-D.ietf-fecframe-framework] defines how not only RTP packets but 818 how arbitrary packet flows can be protected. Some solutions 819 produced or under development in FECFRAME WG are RTP specific. 820 There exist alternatives supporting block codes such as Reed- 821 Salomon and Raptor. 823 6.2.3. Recommendations for FEC 825 (tbd) 827 7. WebRTC Use of RTP: Rate Control and Media Adaptation 829 WebRTC will be used in very varied network environment with a 830 hetrogenous set of link technologies, including wired and wireless, 831 interconnecting peers at different topological locations resulting in 832 network paths with widely varying one way delays, bit-rate capacity, 833 load levels and traffic mixes. In addition individual end-points 834 will open one or more WebRTC sessions between one or more peers. 835 Each of these session may contain different mixes of media and data 836 flows. Assymetric usage of media bit-rates and number of media 837 streams is also to be expected. A single end-point may receive zero 838 to many simultanous media streams while itself transmitting one or 839 more streams. 841 The WebRTC application is very dependent from a quality perspective 842 on the media adapation working well so that an end-point doesn't 843 transmit significantly more than the path is capable of handling. If 844 it would, the result would be high levels of packet loss or delay 845 spikes causing media degradations. 847 WebRTC applications using more than a single media stream of any 848 media type or data flows has an additional concern. In this case the 849 different flows should try to avoid affecting each other negatively. 850 In addition in case there is a resource limiation, the available 851 resources needs to be shared. How to share them is something the 852 application should prioritize so that the limiation in quality or 853 capabilities are the ones that provide the least affect on the 854 application. 856 This hetrogenous situation results in a requirement to have 857 functionality that adapts to the available capacity and that competes 858 fairly with other network flows. If it would not compete fairly 859 enough WebRTC could be used as an attack method for starving out 860 other traffic on specific links as long as the attacker is able to 861 create traffic across a specific link. This is not far-fetched for a 862 web-service capable of attracting large number of end-points and use 863 the service, combined with BGP routing state a server could pick 864 client pairs to drive traffic to specific paths. 866 The above estalish a clear need based on several reasons why there 867 need to be a well working media adaptation mechanism. This mechanism 868 also have a number of requirements on what services it should provide 869 and what performance it needs to provide. 871 The biggest issue is that there are no standardised and ready to use 872 mechanism that can simply be included in WebRTC Thus there will be 873 need for the IETF to produce such a specification. Therefore the 874 suggested way forward is to specify requirements on any solution for 875 the media adaptation. These requirements is for now proposed to be 876 documented in this specification. In addition a proposed detailed 877 solution will be developed, but is expected to take longer time to 878 finalize than this document. 880 7.1. Congestion Control Requirements 882 Requirements for congestion control of WebRTC sessions are discussed 883 in [I-D.jesup-rtp-congestion-reqs]. 885 Implementations are REQUIRED to implement the RTP circuit breakers 886 described in [I-D.perkins-avtcore-rtp-circuit-breakers]. 888 7.2. RTCP Limiations 890 Experience with the congestion control algorithms of TCP [RFC5681], 891 TFRC [RFC5348], and DCCP [RFC4341], [RFC4342], [RFC4828], has shown 892 that feedback on packet arrivals needs to be sent roughly once per 893 round trip time. We note that the capabilities of real-time media 894 traffic to adapt to changing path conditions may be less rapid than 895 for the elastic applications TCP was designed for, but frequent 896 feedback is still required to allow the congestion control algorithm 897 to track the path dynamics. 899 The total RTCP bandwidth is limited in its transmission rate to a 900 fraction of the RTP traffic (by default 5%). RTCP packets are larger 901 than, e.g., TCP ACKs (even when non-compound RTCP packets are used). 902 The media stream bit rate thus limits the maximum feedback rate as a 903 function of the mean RTCP packet size. 905 Interactive communication may not be able to afford waiting for 906 packet losses to occur to indicate congestion, because an increase in 907 playout delay due to queuing (most prominent in wireless networks) 908 may easily lead to packets being dropped due to late arrival at the 909 receiver. Therefore, more sophisticated cues may need to be reported 910 -- to be defined in a suitable congestion control framework as noted 911 above -- which, in turn, increase the report size again. For 912 example, different RTCP XR report blocks (jointly) provide the 913 necessary details to implement a variety of congestion control 914 algorithms, but the (compound) report size grows quickly. 916 In group communication, the share of RTCP bandwidth needs to be 917 shared by all group members, reducing the capacity and thus the 918 reporting frequency per node. 920 Example: assuming 512 kbit/s video yields 3200 bytes/s RTCP 921 bandwidth, split across two entities in a point-to-point session. An 922 endpoint could thus send a report of 100 bytes about every 70ms or 923 for every other frame in a 30 fps video. 925 7.3. Legacy Interop Limitations 927 Congestion control interoperability with most type of legacy devices, 928 even using an translator could be difficult. There are numerous 929 reasons for this: 931 No RTCP Support: There exist legacy implementations that does not 932 even implement RTCP at all. Thus no feedback at all is provided. 934 RTP/AVP Minimal RTCP Interval of 5s: RTP [RFC3550] under the RTP/AVP 935 profile specifies a recommended minimal fixed interval of 5 936 seconds. Sending RTCP report blocks as seldom as 5 seconds makes 937 it very difficult for a sender to use these reports and react to 938 any congestion event. 940 RTP/AVP Scaled Minimal Interval: If a legacy device uses the scaled 941 minimal RTCP compound interval, the "RECOMMENDED value for the 942 reduced minimum in seconds is 360 divided by the session bandwidth 943 in kilobits/second" ([RFC3550], section 6.2). The minimal 944 interval drops below a second, still several times the RTT in 945 almost all paths in the Internet, when the session bandwidht 946 becomes 360 kbps. A session bandwidth of 1 Mbps still has a 947 minimal interval of 360 ms. Thus, with the exception for rather 948 high bandwidth sessions, getting frequent enough RTCP Report 949 Blocks to report on the order of the RTT is very difficult as long 950 as the legacy device uses the RTP/AVP profile. 952 RTP/AVPF Supporting Legacy Device: If a legacy device supports RTP/ 953 AVPF, then that enables negotation of important parameters for 954 frequent reporting, such as the "trr-int" parameter, and the 955 possibility that the end-point supports some useful feedback 956 format for congestion control purpose such as TMMBR [RFC5104]. 958 It has been suggested on the RTCWEB mailing list that if 959 interoperating with really limited legacy devices an WebRTC end-point 960 may not send more than 64 kbps of media streams, to avoid it causing 961 massive congestion on most paths in the Internet when communicating 962 with a legacy node not providing sufficient feedback for effective 963 congestion control. This warrants further discussion as there is 964 clearly a number of link layers that don't even provide that amount 965 of bit-rate consistently, and that assumes no competing traffic. 967 8. WebRTC Use of RTP: Performance Monitoring 969 RTCP does contains a basic set of RTP flow monitoring points like 970 packet loss and jitter. There exist a number of extensions that 971 could be included in the set to be supported. However, in most cases 972 which RTP monitoring that is needed depends on the application, which 973 makes it difficult to select which to include when the set of 974 applications is very large. 976 Exposing some metrics in the WebRTC API should be considered allowing 977 the application to gather the measurements of interest. However, 978 security implications for the different data sets exposed will need 979 to be considered in this. 981 9. IANA Considerations 983 This memo makes no request of IANA. 985 Note to RFC Editor: this section may be removed on publication as an 986 RFC. 988 10. Security Considerations 990 RTP and its various extensions each have their own security 991 considerations. These should be taken into account when considering 992 the security properties of the complete suite. We currently don't 993 think this suite creates any additional security issues or 994 properties. The use of SRTP [RFC3711] will provide protection or 995 mitigation against all the fundamental issues by offering 996 confidentiality, integrity and partial source authentication. A 997 mandatory to implement media security solution will be required to be 998 picked. We currently don't discuss the key-management aspect of SRTP 999 in this memo, that needs to be done taking the WebRTC communication 1000 model into account. 1002 The guidelines in [I-D.ietf-avtcore-srtp-vbr-audio] apply when using 1003 variable bit rate (VBR) audio codecs, for example Opus or the Mixer 1004 audio level header extensions. 1006 Security considerations for the WebRTC work are discussed in 1007 [I-D.ietf-rtcweb-security]. 1009 11. Acknowledgements 1011 The authors would like to thank Harald Alvestrand, Cary Bran, and 1012 Cullen Jennings for valuable feedback. 1014 12. References 1016 12.1. Normative References 1018 [I-D.holmberg-mmusic-sdp-bundle-negotiation] 1019 Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation 1020 Using Session Description Protocol (SDP) Port Numbers", 1021 draft-holmberg-mmusic-sdp-bundle-negotiation-00 (work in 1022 progress), October 2011. 1024 [I-D.ietf-avtcore-srtp-encrypted-header-ext] 1025 Lennox, J., "Encryption of Header Extensions in the Secure 1026 Real-Time Transport Protocol (SRTP)", 1027 draft-ietf-avtcore-srtp-encrypted-header-ext-00 (work in 1028 progress), June 2011. 1030 [I-D.ietf-avtcore-srtp-vbr-audio] 1031 Perkins, C. and J. Valin, "Guidelines for the use of 1032 Variable Bit Rate Audio with Secure RTP", 1033 draft-ietf-avtcore-srtp-vbr-audio-03 (work in progress), 1034 July 2011. 1036 [I-D.ietf-rtcweb-overview] 1037 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1038 based Applications", draft-ietf-rtcweb-overview-02 (work 1039 in progress), September 2011. 1041 [I-D.ietf-rtcweb-security] 1042 Rescorla, E., "Security Considerations for RTC-Web", 1043 draft-ietf-rtcweb-security-01 (work in progress), 1044 October 2011. 1046 [I-D.jesup-rtp-congestion-reqs] 1047 Jesup, R. and H. Alvestrand, "Congestion Control 1048 Requirements For Real Time Media", 1049 draft-jesup-rtp-congestion-reqs-00 (work in progress), 1050 March 2012. 1052 [I-D.lennox-rtcweb-rtp-media-type-mux] 1053 Lennox, J. and J. Rosenberg, "Multiplexing Multiple Media 1054 Types In a Single Real-Time Transport Protocol (RTP) 1055 Session", draft-lennox-rtcweb-rtp-media-type-mux-00 (work 1056 in progress), October 2011. 1058 [I-D.perkins-avtcore-rtp-circuit-breakers] 1059 Perkins, C. and V. Singh, "RTP Congestion Control: Circuit 1060 Breakers for Unicast Sessions", 1061 draft-perkins-avtcore-rtp-circuit-breakers-00 (work in 1062 progress), March 2012. 1064 [I-D.westerlund-avtcore-multiplex-architecture] 1065 Westerlund, M., Burman, B., and C. Perkins, "RTP 1066 Multiplexing Architecture", 1067 draft-westerlund-avtcore-multiplex-architecture-00 (work 1068 in progress), October 2011. 1070 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 1071 Payload Format Specifications", BCP 36, RFC 2736, 1072 December 1999. 1074 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1075 Jacobson, "RTP: A Transport Protocol for Real-Time 1076 Applications", STD 64, RFC 3550, July 2003. 1078 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1079 Video Conferences with Minimal Control", STD 65, RFC 3551, 1080 July 2003. 1082 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1083 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 1084 RFC 3556, July 2003. 1086 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1087 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1088 RFC 3711, March 2004. 1090 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1091 "Extended RTP Profile for Real-time Transport Control 1092 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1093 July 2006. 1095 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1096 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1097 July 2006. 1099 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1100 BCP 131, RFC 4961, July 2007. 1102 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1103 "Codec Control Messages in the RTP Audio-Visual Profile 1104 with Feedback (AVPF)", RFC 5104, February 2008. 1106 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 1107 Correction", RFC 5109, December 2007. 1109 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1110 Real-time Transport Control Protocol (RTCP)-Based Feedback 1111 (RTP/SAVPF)", RFC 5124, February 2008. 1113 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1114 Header Extensions", RFC 5285, July 2008. 1116 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1117 Real-Time Transport Control Protocol (RTCP): Opportunities 1118 and Consequences", RFC 5506, April 2009. 1120 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1121 Control Packets on a Single Port", RFC 5761, April 2010. 1123 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1124 Flows", RFC 6051, November 2010. 1126 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 1127 Choosing RTP Control Protocol (RTCP) Canonical Names 1128 (CNAMEs)", RFC 6222, April 2011. 1130 [RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time 1131 Transport Protocol (RTP) Header Extension for Client-to- 1132 Mixer Audio Level Indication", RFC 6464, December 2011. 1134 [RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time 1135 Transport Protocol (RTP) Header Extension for Mixer-to- 1136 Client Audio Level Indication", RFC 6465, December 2011. 1138 12.2. Informative References 1140 [I-D.begen-mmusic-redundancy-grouping] 1141 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 1142 Semantics in the Session Description Protocol", 1143 draft-begen-mmusic-redundancy-grouping-01 (work in 1144 progress), June 2011. 1146 [I-D.cbran-rtcweb-data] 1147 Bran, C. and C. Jennings, "RTC-Web Non-Media Data 1148 Transport Requirements", draft-cbran-rtcweb-data-00 (work 1149 in progress), July 2011. 1151 [I-D.ietf-fecframe-framework] 1152 Watson, M., Begen, A., and V. Roca, "Forward Error 1153 Correction (FEC) Framework", 1154 draft-ietf-fecframe-framework-15 (work in progress), 1155 June 2011. 1157 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1158 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1159 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1160 September 1997. 1162 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1163 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1164 Congestion Control", RFC 4341, March 2006. 1166 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1167 Datagram Congestion Control Protocol (DCCP) Congestion 1168 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1169 March 2006. 1171 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 1172 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 1173 April 2007. 1175 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 1176 "RTP Payload Format and File Storage Format for the 1177 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 1178 (AMR-WB) Audio Codecs", RFC 4867, April 2007. 1180 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1181 January 2008. 1183 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1184 Friendly Rate Control (TFRC): Protocol Specification", 1185 RFC 5348, September 2008. 1187 [RFC5404] Westerlund, M. and I. Johansson, "RTP Payload Format for 1188 G.719", RFC 5404, January 2009. 1190 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1191 Control", RFC 5681, September 2009. 1193 [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 1194 Control Protocol (RTCP)", RFC 5968, September 2010. 1196 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1197 Keeping Alive the NAT Mappings Associated with RTP / RTP 1198 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1200 Authors' Addresses 1202 Colin Perkins 1203 University of Glasgow 1204 School of Computing Science 1205 Glasgow G12 8QQ 1206 United Kingdom 1208 Email: csp@csperkins.org 1210 Magnus Westerlund 1211 Ericsson 1212 Farogatan 6 1213 SE-164 80 Kista 1214 Sweden 1216 Phone: +46 10 714 82 87 1217 Email: magnus.westerlund@ericsson.com 1219 Joerg Ott 1220 Aalto University 1221 School of Electrical Engineering 1222 Espoo 02150 1223 Finland 1225 Email: jorg.ott@aalto.fi