idnits 2.17.1 draft-perkins-rtcweb-rtp-usage-03.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 135: '...protocol, and is REQUIRED to be implem...' RFC 2119 keyword, line 303: '...that endpoint is REQUIRED to be prepar...' RFC 2119 keyword, line 311: '... Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to...' RFC 2119 keyword, line 361: '... RTCP control packets on a single port [RFC5761] is REQUIRED....' RFC 2119 keyword, line 387: '... Support for RFC5506 is REQUIRED....' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2011) is 4625 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 (-06) exists of draft-ietf-avtext-client-to-mixer-audio-level-03 == Outdated reference: A later version (-06) exists of draft-ietf-avtext-mixer-to-client-audio-level-03 ** 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: 3 errors (**), 0 flaws (~~), 6 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: February 29, 2012 Ericsson 6 J. Ott 7 Aalto University 8 August 28, 2011 10 RTP Requirements for RTC-Web 11 draft-perkins-rtcweb-rtp-usage-03 13 Abstract 15 This memo discusses use of RTP in the context of the RTC-Web 16 activity. It discusses important features of RTP that need to be 17 considered by other parts of the RTC-Web framework, describes which 18 RTP profile to use in this environment, and outlines what RTP 19 extensions should be supported. 21 This document is a candidate to become a work item of the RTCWEB 22 working group as . 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 29, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Expected Topologies . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements from RTP . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Signalling for RTP sessions . . . . . . . . . . . . . . . 6 62 2.2. (Lack of) Signalling for Payload Format Changes . . . . . 7 63 3. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. RTP and RTCP Guidelines . . . . . . . . . . . . . . . . . . . 8 65 5. RTP Optimisations . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 8 67 5.2. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 8 68 5.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . . 9 69 5.4. Generation of the RTCP Canonical Name (CNAME) . . . . . . 9 70 6. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. RTP Conferencing Extensions . . . . . . . . . . . . . . . 10 72 6.1.1. Full Intra Request . . . . . . . . . . . . . . . . . . 11 73 6.1.2. Picture Loss Indication . . . . . . . . . . . . . . . 11 74 6.1.3. Slice Loss Indication . . . . . . . . . . . . . . . . 11 75 6.1.4. Reference Picture Selection Indication . . . . . . . . 11 76 6.1.5. Temporary Maximum Media Stream Bit Rate Request . . . 11 77 6.2. RTP Header Extensions . . . . . . . . . . . . . . . . . . 12 78 6.3. Rapid Synchronisation Extensions . . . . . . . . . . . . . 13 79 6.4. Client to Mixer Audio Level . . . . . . . . . . . . . . . 13 80 6.5. Mixer to Client Audio Level . . . . . . . . . . . . . . . 13 81 7. Improving RTP Transport Robustness . . . . . . . . . . . . . . 13 82 7.1. RTP Retransmission . . . . . . . . . . . . . . . . . . . . 14 83 7.2. Forward Error Correction (FEC) . . . . . . . . . . . . . . 15 84 7.2.1. Basic Redundancy . . . . . . . . . . . . . . . . . . . 15 85 7.2.2. Block Based . . . . . . . . . . . . . . . . . . . . . 16 86 7.2.3. Recommendations for FEC . . . . . . . . . . . . . . . 17 87 8. RTP Rate Control and Media Adaptation . . . . . . . . . . . . 17 88 9. RTP Performance Monitoring . . . . . . . . . . . . . . . . . . 18 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 This memo discusses the Real-time Transport Protocol (RTP) [RFC3550] 100 in the context of the RTC-Web activity. The work in the IETF Audio/ 101 Video Transport Working Group, and it's successors, has been about 102 providing building blocks for real-time multimedia transport, and has 103 not specified who should use which building blocks. The selection of 104 building blocks and functionalities can really only be done in the 105 context of some application, for example RTC-Web. We have selected a 106 set of RTP features and extensions that are suitable for a number of 107 applications that fit the RTC-Web context. Thus, applications such 108 as VoIP, audio and video conferencing, and on-demand multimedia 109 streaming are considered. Applications that rely on IP multicast 110 have not been considered likely to be applicable to RTC-Web, thus 111 extensions related to multicast have been excluded. We believe that 112 RTC-Web will greatly benefit in interoperability if a reasonable set 113 of RTP functionalities and extensions are selected. This memo is 114 intended as a starting point for discussion of those features in the 115 RTC-Web framework. 117 This memo is structured into different topics. For each topic, one 118 or several recommendations from the authors are given. When it comes 119 to the importance of extensions, or the need for implementation 120 support, we use three requirement levels to indicate the importance 121 of the feature to the RTC-Web specification: 123 REQUIRED: Functionality that is absolutely needed to make the RTC- 124 Web solution work well, or functionality of low complexity that 125 provides high value. 127 RECOMMENDED: Should be included as its brings significant benefit, 128 but the solution can potentially work without it. 130 OPTIONAL: Something that is useful in some cases, but not always a 131 benefit. 133 When this memo discusses RTP, it includes the RTP Control Protocol 134 (RTCP) unless explicitly stated otherwise. RTCP is a fundamental and 135 integral part of the RTP protocol, and is REQUIRED to be implemented. 137 1.1. Expected Topologies 139 As RTC-Web is focused on peer to peer connections established from 140 clients in web browsers the following topologies further discussed in 141 RTP Topologies [RFC5117] are primarily considered. The topologies 142 are depicted and briefly explained here for ease of the reader. 144 +---+ +---+ 145 | A |<------->| B | 146 +---+ +---+ 148 Figure 1: Point to Point 150 The point to point topology (Figure 1) is going to be very common in 151 any single user to single user applications. 153 +---+ +---+ 154 | A |<---->| B | 155 +---+ +---+ 156 ^ ^ 157 \ / 158 \ / 159 v v 160 +---+ 161 | C | 162 +---+ 164 Figure 2: Multi-unicast 166 For small multiparty sessions it is practical enough to create RTP 167 sessions by letting every participant send individual unicast RTP/UDP 168 flows to each of the other participants. This is called multi- 169 unicast and is unfortunately not discussed in the RTP Topologies 170 [RFC5117]. This topology has the benefit of not requiring central 171 nodes. The downside is that it increases the used bandwidth at each 172 sender by requiring one copy of the media streams for each 173 participant that are part of the same session beyond the sender 174 itself. Thus this is limited to scenarios with few end-points unless 175 the media is very low bandwidth. 177 It needs to be noted that, if this topology is to be supported by the 178 RTC-Web framework, it needs to be possible to connect one RTP session 179 to multiple established peer to peer flows that are individually 180 established. 182 +---+ +------------+ +---+ 183 | A |<---->| |<---->| B | 184 +---+ | | +---+ 185 | Mixer | 186 +---+ | | +---+ 187 | C |<---->| |<---->| D | 188 +---+ +------------+ +---+ 190 Figure 3: RTP Mixer with Only Unicast Paths 192 An RTP mixer (Figure 3) is a centralised point that selects or mixes 193 content in a conference to optimise the RTP session so that each end- 194 point only needs connect to one entity, the mixer. The mixer also 195 reduces the bit-rate needs as the media sent from the mixer to the 196 end-point can be optimised in different ways. These optimisations 197 include methods like only choosing media from the currently most 198 active speaker or mixing together audio so that only one audio stream 199 is required in stead of 3 in the depicted scenario. The downside of 200 the mixer is that someone is required to provide the actual mixer. 202 +---+ +------------+ +---+ 203 | A |<---->| |<---->| B | 204 +---+ | | +---+ 205 | Translator | 206 +---+ | | +---+ 207 | C |<---->| |<---->| D | 208 +---+ +------------+ +---+ 210 Figure 4: RTP Translator (Relay) with Only Unicast Paths 212 If one wants a less complex central node it is possible to use an 213 relay (called an Transport Translator) (Figure 4) that takes on the 214 role of forwarding the media to the other end-points but doesn't 215 perform any media processing. It simply forwards the media from all 216 other to all the other. Thus one endpoint A will only need to send a 217 media once to the relay, but it will still receive 3 RTP streams with 218 the media if B, C and D all currently transmits. 220 +------------+ 221 | | 222 +---+ | | +---+ 223 | A |<---->| Translator |<---->| B | 224 +---+ | | +---+ 225 | | 226 +------------+ 228 Figure 5: Translator towards Legacy end-point 230 To support legacy end-point (B) that don't fulfil the requirements of 231 RTC-Web it is possible to insert a Translator (Figure 5) that takes 232 on the role to ensure that from A's perspective B looks like a fully 233 compliant end-point. Thus it is the combination of the Translator 234 and B that looks like the end-point B. The intention is that the 235 presence of the translator is transparent to A, however it is not 236 certain that is possible. Thus this case is include so that it can 237 be discussed if any mechanism specified to be used for RTC-Web 238 results in such issues and how to handle them. 240 2. Requirements from RTP 242 This section discusses some requirements RTP and RTCP [RFC3550] place 243 on their underlying transport protocol, the signalling channel, etc. 245 2.1. Signalling for RTP sessions 247 RTP is built with the assumption of an external to RTP/RTCP 248 signalling channel to configure the RTP sessions and its functions. 249 The basic configuration of an RTP session consists of the following 250 parameters: 252 RTP Profile: The name of the RTP profile to be used in session. The 253 RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate 254 on basic level, as can their secure variants RTP/SAVP [RFC3711] 255 and RTP/SAVPF [RFC5124]. The secure variants of the profiles do 256 not directly interoperate with the non-secure variants, due to the 257 presence of additional header fields in addition to any 258 cryptographic transformation of the packet content. 260 Transport Information: Source and destination address(s) and ports 261 for RTP and RTCP must be signalled for each RTP session. If RTP 262 and RTCP multiplexing [RFC5761] is to be used, such that a single 263 port is used for RTP and RTCP flows, this must be signalled. 265 RTP Payload Types, media formats, and media format parameters: The 266 mapping between media type names (and hence the RTP payload 267 formats to be used) and the RTP payload type numbers must be 268 signalled. Each media type may also have a number of media type 269 parameters that must also be signalled to configure the codec and 270 RTP payload format (the "a=fmtp:" line from SDP). 272 RTP Extensions: The RTP extensions one intends to use need to be 273 agreed upon, including any parameters for each respective 274 extension. At the very least, this will help avoiding using 275 bandwidth for features that the other end-point will ignore. But 276 for certain mechanisms there is requirement for this to happen as 277 interoperability failure otherwise happens. 279 RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the 280 end-points will be necessary, as described in "Session Description 281 Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) 282 Bandwidth" [RFC3556], or something semantically equivalent. This 283 also ensures that the end-points have a common view of the RTCP 284 bandwidth, this is important as too different view of the 285 bandwidths may lead to failure to interoperate. 287 These parameters are often expressed in SDP messages conveyed within 288 an offer/answer exchange. RTP does not depend on SDP or on the 289 offer/answer model, but does require all the necessary parameters to 290 be agreed somehow, and provided to the RTP implementation. We note 291 that in RTCWEB context it will depend on the signalling model and API 292 how these parameters need to be configured but they will be need to 293 either set in the API or explicitly signalled between the peers. 295 2.2. (Lack of) Signalling for Payload Format Changes 297 As discussed in Section 2.1, the mapping between media type name, and 298 its associated RTP payload format, and the RTP payload type number to 299 be used for that format must be signalled as part of the session 300 setup. An endpoint may signal support for multiple media formats, or 301 multiple configurations of a single format, each using a different 302 RTP payload type number. If multiple formats are signalled by an 303 endpoint, that endpoint is REQUIRED to be prepared to receive data 304 encoded in any of those formats at any time. RTP does not require 305 advance signalling for changes between formats that were signalled 306 during the session setup. This is needed for rapid rate adaptation. 308 3. RTP Profile 310 The "Extended Secure RTP Profile for Real-time Transport Control 311 Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is REQUIRED to 312 be implemented. This builds on the basic RTP/AVP profile [RFC3551], 313 the RTP/AVPF feedback profile [RFC4585], and the secure RTP/SAVP 314 profile [RFC3711]. 316 The RTP/AVPF part of RTP/SAVPF is required to get the improved RTCP 317 timer model, that allows more flexible transmission of RTCP packets 318 in response to events, rather than strictly according to bandwidth. 319 This also saves RTCP bandwidth and will commonly only use the full 320 amount when there is a lot of events on which to send feedback. This 321 functionality is needed to make use of the RTP conferencing 322 extensions discussed in Section 6.1. 324 The RTP/SAVP part of RTP/SAVPF is for support for Secure RTP (SRTP) 325 [RFC3711]. This provides media encryption, integrity protection, 326 replay protection and a limited form of source authentication. It 327 does not contain a specific keying mechanism, so that, and the set of 328 security transforms, will be required to be chosen. It is possible 329 that a security mechanism operating on a lower layer than RTP can be 330 used instead and that should be evaluated. However, the reasons for 331 the design of SRTP should be taken into consideration in that 332 discussion. 334 4. RTP and RTCP Guidelines 336 RTP and RTCP are two flexible and extensible protocols that allow, on 337 the one hand, choosing from a variety of building blocks and 338 combining those to meet application needs, and on the other hand, 339 create extensions where existing mechanisms are not sufficient: from 340 new payload formats to RTP extension headers to additional RTCP 341 control packets. 343 Different informational documents provide guidelines to the use and 344 particularly the extension of RTP and RTCP, including the following: 345 Guidelines for Writers of RTP Payload Format Specifications [RFC2736] 346 and Guidelines for Extending the RTP Control Protocol [RFC5968]. 348 5. RTP Optimisations 350 This section discusses some optimisations that makes RTP/RTCP work 351 better and more efficient and therefore are considered. 353 5.1. RTP and RTCP Multiplexing 355 Historically, RTP and RTCP have been run on separate UDP ports. With 356 the increased use of Network Address/Port Translation (NAPT) this has 357 become problematic, since maintaining multiple NAT bindings can be 358 costly. It also complicates firewall administration, since multiple 359 ports must be opened to allow RTP traffic. To reduce these costs and 360 session setup times, support for multiplexing RTP data packets and 361 RTCP control packets on a single port [RFC5761] is REQUIRED. 362 Supporting this specification is generally a simplification in code, 363 since it relaxes the tests in [RFC3550]. 365 Note that the use of RTP and RTCP multiplexed on a single port 366 ensures that there is occasional traffic sent on that port, even if 367 there is no active media traffic. This may be useful to keep-alive 368 NAT bindings. 370 5.2. Reduced Size RTCP 372 RTCP packets are usually sent as compound RTCP packets; and RFC 3550 373 demands that those compound packets always start with an SR or RR 374 packet. However, especially when using frequent feedback messages, 375 these general statistics are not needed in every packet and 376 unnecessarily increase the mean RTCP packet size and thus limit the 377 frequency at which RTCP packets can be sent within the RTCP bandwidth 378 share. 380 RFC5506 "Support for Reduced-Size Real-Time Transport Control 381 Protocol (RTCP): Opportunities and Consequences" [RFC5506] specifies 382 how to reduce the mean RTCP message and allow for more frequent 383 feedback. Frequent feedback, in turn, is essential to make real-time 384 application quickly aware of changing network conditions and allow 385 them to adapt their transmission and encoding behaviour. 387 Support for RFC5506 is REQUIRED. 389 5.3. Symmetric RTP/RTCP 391 RTP entities choose the RTP and RTCP transport addresses, i.e., IP 392 addresses and port numbers, to receive packets on and bind their 393 respective sockets to those. When sending RTP packets, however, they 394 may use a different IP address or port number for RTP, RTCP, or both; 395 e.g., when using a different socket instance for sending and for 396 receiving. Symmetric RTP/RTCP requires that the IP address and port 397 number for sending and receiving RTP/RTCP packets are identical. 399 The reasons for using symmetric RTP is primarily to avoid issues with 400 NAT and Firewalls by ensuring that the flow is actually bi- 401 directional and thus kept alive and registered as flow the intended 402 recipient actually wants. In addition it saves resources in the form 403 of ports at the end-points, but also in the network as NAT mappings 404 or firewall state is not unnecessary bloated. Also the number of QoS 405 state are reduced. 407 Using Symmetric RTP and RTCP [RFC4961] is REQUIRED. 409 5.4. Generation of the RTCP Canonical Name (CNAME) 411 The RTCP Canonical Name (CNAME) provides a persistent transport-level 412 identifier for an RTP endpoint. While the Synchronisation Source 413 (SSRC) identifier for an RTP endpoint may change if a collision is 414 detected, or when the RTP application is restarted, it's RTCP CNAME 415 is meant to stay unchanged, so that RTP endpoints can be uniquely 416 identified and associated with their RTP media streams. For proper 417 functionality, RTCP CNAMEs should be unique among the participants of 418 an RTP session. 420 The RTP specification [RFC3550] includes guidelines for choosing a 421 unique RTP CNAME, but these are not sufficient in the presence of NAT 422 devices. In addition, some may find long-term persistent identifiers 423 problematic from a privacy viewpoint. Accordingly, support for 424 generating a short-term persistent RTCP CNAMEs following method (b) 425 as specified in Section 4.2 of "Guidelines for Choosing RTP Control 426 Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222] is RECOMMENDED, 427 since this addresses both concerns. 429 6. RTP Extensions 431 There are a number of RTP extensions that could be very useful in the 432 RTC-Web context. One set is related to conferencing, others are more 433 generic in nature. 435 6.1. RTP Conferencing Extensions 437 RTP is inherently defined for group communications, whether using IP 438 multicast, multi-unicast, or based on a centralised server. In 439 today's practice, however, overlay-based conferencing dominates, 440 typically using one or a few so-called conference bridges or servers 441 to connect endpoints in a star or flat tree topology. Quite diverse 442 conferencing topologies can be created using the basic elements of 443 RTP mixers and translators as defined in RFC 3550. 445 An number of conferencing topologies are defined in [RFC5117] out of 446 the which the following ones are the more common (and most likely in 447 practice workable) ones: 449 1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section 450 3.3) 452 2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4) 454 3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section 455 3.5) 457 4) Point to Multipoint Using Content Modifying MCUs (RFC 5117, 458 section 3.6) 460 We note that 3 and 4 are not well utilising the functions of RTP and 461 in some cases even violates the RTP specifications. Thus we 462 recommend that one focus on 1 and 2. 464 RTP protocol extensions to be used with conferencing are included 465 because they are important in the context of centralised 466 conferencing, where one RTP Mixer (Conference Focus) receives a 467 participants media streams and distribute them to the other 468 participants. These messages are defined in the Extended RTP Profile 469 for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ 470 AVPF) [RFC4585] and the "Codec Control Messages in the RTP Audio- 471 Visual Profile with Feedback (AVPF)" (CCM) [RFC5104] and are fully 472 usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. 474 6.1.1. Full Intra Request 476 The Full Intra Request is defined in Sections 3.5.1 and 4.3.1 of CCM 477 [RFC5104]. It is used to have the mixer request from a session 478 participants a new Intra picture. This is used when switching 479 between sources to ensure that the receivers can decode the video or 480 other predicted media encoding with long prediction chains. It is 481 RECOMMENDED that this feedback message is supported. 483 6.1.2. Picture Loss Indication 485 The Picture Loss Indication is defined in Section 6.3.1 of the RTP/ 486 AVPF profile [RFC4585]. It is used by a receiver to tell the encoder 487 that it lost the decoder context and would like to have it repaired 488 somehow. This is semantically different from the Full Intra Request 489 above. It is RECOMMENDED that this feedback message is supported as 490 a loss tolerance mechanism. 492 6.1.3. Slice Loss Indication 494 The Slice Loss Indicator is defined in Section 6.3.2 of the RTP/AVPF 495 profile [RFC4585]. It is used by a receiver to tell the encoder that 496 it has detected the loss or corruption of one or more consecutive 497 macroblocks, and would like to have these repaired somehow. The use 498 of this feedback message is OPTIONAL as a loss tolerance mechanism. 500 6.1.4. Reference Picture Selection Indication 502 Reference Picture Selection Indication (RPSI) is defined in Section 503 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video coding standards 504 allow the use of older reference pictures than the most recent one 505 for predictive coding. If such a codec is in used, and if the 506 encoder has learned about a loss of encoder-decoder synchronicity, a 507 known-as-correct reference picture can be used for future coding. 508 The RPSI message allows this to be signalled. The use of this RTCP 509 feedback message is OPTIONAL as a loss tolerance mechanism. 511 6.1.5. Temporary Maximum Media Stream Bit Rate Request 513 This feedback message is defined in Section 3.5.4 and 4.2.1 in CCM 514 [RFC5104]. This message and its notification message is used by a 515 media receiver, to inform the sending party that there is a current 516 limitation on the amount of bandwidth available to this receiver. 517 This can be for various reasons, and can for example be used by an 518 RTP mixer to limit the media sender being forwarded by the mixer 519 (without doing media transcoding) to fit the bottlenecks existing 520 towards the other session participants. It is RECOMMENDED that this 521 feedback message is supported. 523 6.2. RTP Header Extensions 525 The RTP specification [RFC3550] provides a capability to extend the 526 RTP header with in-band data, but the format and semantics of the 527 extensions are poorly specified. Accordingly, if header extensions 528 are to be used, it is REQUIRED that they be formatted and signalled 529 according to the general mechanism of RTP header extensions defined 530 in [RFC5285]. 532 As noted in [RFC5285], the requirement from the RTP specification 533 that header extensions are "designed so that the header extension may 534 be ignored" [RFC3550] stands. To be specific, header extensions must 535 only be used for data that can safely be ignored by the recipient 536 without affecting interoperability, and must not be used when the 537 presence of the extension has changed the form or nature of the rest 538 of the packet in a way that is not compatible with the way the stream 539 is signalled (e.g., as defined by the payload type). Valid examples 540 might include metadata that is additional to the usual RTP 541 information. 543 The RTP rapid synchronisation header extension [RFC6051] is 544 recommended, as discussed in Section 6.3 we also recommend the client 545 to mixer audio level [I-D.ietf-avtext-client-to-mixer-audio-level], 546 and consider the mixer to client audio level 547 [I-D.ietf-avtext-mixer-to-client-audio-level] as optional feature. 549 It is RECOMMENDED that the mechanism to encrypt header extensions 550 [I-D.ietf-avtcore-srtp-encrypted-header-ext] is implemented when the 551 client-to-mixer and mixer-to-client audio level indications are in 552 use in SRTP encrypted sessions, since the information contained in 553 these header extensions may be considered sensitive. 555 Currently the other header extensions are not recommended to be 556 included at this time. But we do include a list of the available 557 ones for information below: 559 Transmission Time offsets: [RFC5450] defines a format for including 560 an RTP timestamp offset of the actual transmission time of the RTP 561 packet in relation to capture/display timestamp present in the RTP 562 header. This can be used to improve jitter determination and 563 buffer management. 565 Associating Time-Codes with RTP Streams: [RFC5484] defines how to 566 associate SMPTE times codes with the RTP streams. 568 6.3. Rapid Synchronisation Extensions 570 Many RTP sessions require synchronisation between audio, video, and 571 other content. This synchronisation is performed by receivers, using 572 information contained in RTCP SR packets, as described in the RTP 573 specification [RFC3550]. This basic mechanism can be slow, however, 574 so it is RECOMMENDED that the rapid RTP synchronisation extensions 575 described in [RFC6051] be implemented. The rapid synchronisation 576 extensions use the general RTP header extension mechanism [RFC5285], 577 which requires signalling, but are otherwise backwards compatible. 579 6.4. Client to Mixer Audio Level 581 The Client to Mixer Audio Level 582 [I-D.ietf-avtext-client-to-mixer-audio-level] is an RTP header 583 extension used by a client to inform a mixer about the level of audio 584 activity in the packet the header is attached to. This enables a 585 central node to make mixing or selection decisions without decoding 586 or detailed inspection of the payload. Thus reducing the needed 587 complexity in some types of central RTP nodes. 589 Assuming that the Client to Mixer Audio Level 590 [I-D.ietf-avtext-client-to-mixer-audio-level] is published as a 591 finished specification prior to RTCWEB's first RTP specification then 592 it is RECOMMENDED that this extension is included. 594 6.5. Mixer to Client Audio Level 596 The Mixer to Client Audio Level header extension 597 [I-D.ietf-avtext-mixer-to-client-audio-level] provides the client 598 with the audio level of the different sources mixed into a common mix 599 from the RTP mixer. Thus enabling a user interface to indicate the 600 relative activity level of a session participant, rather than just 601 being included or not based on the CSRC field. This is a pure 602 optimisations of non critical functions and thus optional 603 functionality. 605 Assuming that the Mixer to Client Audio Level 606 [I-D.ietf-avtext-client-to-mixer-audio-level] is published as a 607 finished specification prior to RTCWEB's first RTP specification then 608 it is OPTIONAL that this extension is included. 610 7. Improving RTP Transport Robustness 612 There are some tools that can make RTP flows robust against Packet 613 loss and reduce the impact on media quality. However they all add 614 extra bits compared to a non-robust stream. These extra bits needs 615 to be considered and the aggregate bit-rate needs to be rate 616 controlled. Thus improving robustness might require a lower base 617 encoding quality but has the potential to give that quality with 618 fewer errors in it. 620 7.1. RTP Retransmission 622 Support for RTP retransmission as defined by "RTP Retransmission 623 Payload Format" [RFC4588] is RECOMMENDED. 625 The retransmission scheme in RTP allows flexible application of 626 retransmissions. Only selected missing packets can be requested by 627 the receiver. It also allows for the sender to prioritise between 628 missing packets based on senders knowledge about their content. 629 Compared to TCP, RTP retransmission also allows one to give up on a 630 packet that despite retransmission(s) still has not been received 631 within a time window. 633 "RTC-Web Media Transport Requirements" [I-D.cbran-rtcweb-data] raises 634 two issues that they think makes RTP Retransmission unsuitable for 635 RTCWEB. We here consider these issues and explain why they are in 636 fact not a reason to exclude RTP retransmission from the tool box 637 available to RTCWEB media sessions. 639 The additional latency added by [RFC4588] will exceed the latency 640 threshold for interactive voice and video: RTP Retransmission will 641 require at least one round trip time for a retransmission request 642 and repair packet to arrive. Thus the general suitability of 643 using retransmissions will depend on the actual network path 644 latency between the end-points. In many of the actual usages the 645 latency between two end-points will be low enough for RTP 646 retransmission to be effective. Interactive communication with 647 end-to-end delays of 400 ms still provide a fair quality. Even 648 removing half of that in end-point delays allows functional 649 retransmission between end-points on the continent. In addition 650 in some applications one may accept temporary delay spikes to 651 allow for retransmission of crucial codec information such an 652 parameter sets, intra picture etc, rather than getting no media at 653 all. 655 The undesirable increase in packet transmission at the point when 656 congestion occurs: Congestion loss will impact the rate controls 657 view of available bit-rate for transmission. When using 658 retransmission one will have to prioritise between performing 659 retransmissions and the quality one can achieve with ones 660 adaptable codecs. In many use cases one prefer error free or low 661 rates of error with reduced base quality over high degrees of 662 error at a higher base quality. 664 The RTCWEB end-point implementations will need to both select when to 665 enable RTP retransmissions based on API settings and measurements of 666 the actual round trip time. In addition for each NACK request that a 667 media sender receives it will need to make a prioritisation based on 668 the importance of the requested media, the probability that the 669 packet will reach the receiver in time for being usable, the 670 consumption of available bit-rate and the impact of the media quality 671 for new encodings. 673 To conclude, the issues raised are implementation concerns that an 674 implementation needs to take into consideration, they are not 675 arguments against including a highly versatile and efficient packet 676 loss repair mechanism. 678 7.2. Forward Error Correction (FEC) 680 Support of some type of FEC to combat the effects of packet loss is 681 beneficial, but is heavily application dependent. However, some FEC 682 mechanisms are encumbered. 684 The main benefit from FEC is the relatively low additional delay 685 needed to protect against packet losses. The transmission of any 686 repair packets should preferably be done with a time delay that is 687 just larger than any loss events normally encountered. That way the 688 repair packet isn't also lost in the same event as the source data. 690 The amount of repair packets needed are also highly dynamically and 691 depends on two main factors, the amount and pattern of lost packets 692 to be recovered and the mechanism one use to derive repair data. The 693 later choice also effects the the additional delay required to both 694 encode the repair packets and in the receiver to be able to recover 695 the lost packet(s). 697 7.2.1. Basic Redundancy 699 The method for providing basic redundancy is to simply retransmit an 700 some time earlier sent packet. This is relatively simple in theory, 701 i.e. one saves any outgoing source (original) packet in a buffer 702 marked with a timestamp of actual transmission, some X ms later one 703 transmit this packet again. Where X is selected to be longer than 704 the common loss events. Thus any loss events shorter than X can be 705 recovered assuming that one doesn't get an another loss event before 706 all the packets lost in the first event has been received. 708 The downside of basic redundancy is the overhead. To provide each 709 packet with once chance of recovery, then the transmission rate 710 increases with 100% as one needs to send each packet twice. It is 711 possible to only redundantly send really important packets thus 712 reducing the overhead below 100% for some other trade-off is 713 overhead. 715 In addition the basic retransmission of the same packet using the 716 same SSRC in the same RTP session is not possible in RTP context. 717 The reason is that one would then destroy the RTCP reporting if one 718 sends the same packet twice with the same sequence number. Thus one 719 needs more elaborate mechanisms. 721 RTP Payload for Redundant Audio Data: This audio and text redundancy 722 format defined in [RFC2198] allows for multiple levels of 723 redundancy with different delay in their transmissions, as long as 724 the source plus payload parts to be redundantly transmitted 725 together fits into one MTU. This should work fine for most 726 interactive use cases as both the codec bit-rates and the framing 727 intervals normally allow for this requirement to hold. This 728 payload format also don't increase the packet rate, as original 729 data and redundant data are sent together. This format does not 730 allow perfect recovery, only recovery of information deemed 731 necessary for audio, for example the sequence number of the 732 original data is lost. 734 RTP Retransmission Format: The RTP Retransmission Payload format 735 [RFC4588] can be used to pro-actively send redundant packets using 736 either SSRC or session multiplexing. By using different SSRCs or 737 a different session for the redundant packets the RTCP receiver 738 reports will be correct. The retransmission payload format is 739 used to recover the packets original data thus enabling a perfect 740 recovery. 742 Duplication Grouping Semantics in the Session Description Protocol: 743 This [I-D.begen-mmusic-redundancy-grouping] is proposal for new 744 SDP signalling to indicate media stream duplication using 745 different RTP sessions, or different SSRCs to separate the source 746 and the redundant copy of the stream. 748 7.2.2. Block Based 750 Block based redundancy collects a number of source packets into a 751 data block for processing. The processing results in some number of 752 repair packets that is then transmitted to the other end allowing the 753 receiver to attempt to recover some number of lost packets in the 754 block. The benefit of block based approaches is the overhead which 755 can be lower than 100% and still recover one or more lost source 756 packet from the block. The optimal block codes allows for each 757 received repair packet to repair a single loss within the block. 758 Thus 3 repair packets that are received should allow for any set of 3 759 packets within the block to be recovered. In reality one commonly 760 don't reach this level of performance for any block sizes and number 761 of repair packets, and taking the computational complexity into 762 account there are even more trade-offs to make among the codes. 764 One result of the block based approach is the extra delay, as one 765 needs to collect enough data together before being able to calculate 766 the repair packets. In addition sufficient amount of the block needs 767 to be received prior to recovery. Thus additional delay are added on 768 both sending and receiving side to ensure possibility to recover any 769 packet within the block. 771 The redundancy overhead and the transmission pattern of source and 772 repair data can be altered from block to block, thus allowing a 773 adaptive process adjusting to meet the actual amount of loss seen on 774 the network path and reported in RTCP. 776 The alternatives that exist for block based FEC with RTP are the 777 following: 779 RTP Payload Format for Generic Forward Error Correction: This RTP 780 payload format [RFC5109] defines an XOR based recovery packet. 781 This is the simplest processing wise that an block based FEC 782 scheme can be. It also results in some limited properties, as 783 each repair packet can only repair a single loss. To handle 784 multiple close losses a scheme of hierarchical encodings are need. 785 Thus increasing the overhead significantly. 787 Forward Error Correction (FEC) Framework: This framework 788 [I-D.ietf-fecframe-framework] defines how not only RTP packets but 789 how arbitrary packet flows can be protected. Some solutions 790 produced or under development in FECFRAME WG are RTP specific. 791 There exist alternatives supporting block codes such as Reed- 792 Salomon and Raptor. 794 7.2.3. Recommendations for FEC 796 (tbd) 798 8. RTP Rate Control and Media Adaptation 800 It is REQUIRED to have an RTP Rate Control mechanism using Media 801 adaptation to ensure that the generated RTP flows are network 802 friendly, and maintain the user experience in the presence of network 803 problems. 805 The biggest issue is that there are no standardised and ready to use 806 mechanism that can simply be included in RTC-Web. Thus there will be 807 need for the IETF to produce such a specification. A potential 808 starting point for defining a solution is "RTP with TCP Friendly Rate 809 Control" [rtp-tfrc]. 811 9. RTP Performance Monitoring 813 RTCP does contains a basic set of RTP flow monitoring points like 814 packet loss and jitter. There exist a number of extensions that 815 could be included in the set to be supported. However, in most cases 816 which RTP monitoring that is needed depends on the application, which 817 makes it difficult to select which to include when the set of 818 applications is very large. 820 10. IANA Considerations 822 This memo makes no request of IANA. 824 Note to RFC Editor: this section may be removed on publication as an 825 RFC. 827 11. Security Considerations 829 RTP and its various extensions each have their own security 830 considerations. These should be taken into account when considering 831 the security properties of the complete suite. We currently don't 832 think this suite creates any additional security issues or 833 properties. The use of SRTP [RFC3711] will provide protection or 834 mitigation against all the fundamental issues by offering 835 confidentiality, integrity and partial source authentication. The 836 guidelines in [I-D.ietf-avtcore-srtp-vbr-audio] apply when using 837 variable bit rate (VBR) audio codecs, for example Opus. 839 We don't discuss the key-management aspect of SRTP in this memo, that 840 needs to be done taking the RTC-Web communication model into account. 842 In the context of RTC-Web the actual security properties required 843 from RTP are currently not fully understood. Until security goals 844 and requirements are specified it will be difficult to determine what 845 security features in addition to SRTP and a suitable key-management, 846 if any, that are needed. 848 12. Acknowledgements 849 13. References 851 13.1. Normative References 853 [I-D.ietf-avtcore-srtp-encrypted-header-ext] 854 Lennox, J., "Encryption of Header Extensions in the Secure 855 Real-Time Transport Protocol (SRTP)", 856 draft-ietf-avtcore-srtp-encrypted-header-ext-00 (work in 857 progress), June 2011. 859 [I-D.ietf-avtcore-srtp-vbr-audio] 860 Perkins, C. and J. Valin, "Guidelines for the use of 861 Variable Bit Rate Audio with Secure RTP", 862 draft-ietf-avtcore-srtp-vbr-audio-03 (work in progress), 863 July 2011. 865 [I-D.ietf-avtext-client-to-mixer-audio-level] 866 Lennox, J., Ivov, E., and E. Marocco, "A Real-Time 867 Transport Protocol (RTP) Header Extension for Client-to- 868 Mixer Audio Level Indication", 869 draft-ietf-avtext-client-to-mixer-audio-level-03 (work in 870 progress), July 2011. 872 [I-D.ietf-avtext-mixer-to-client-audio-level] 873 Ivov, E., Marocco, E., and J. Lennox, "A Real-Time 874 Transport Protocol (RTP) Header Extension for Mixer-to- 875 Client Audio Level Indication", 876 draft-ietf-avtext-mixer-to-client-audio-level-03 (work in 877 progress), July 2011. 879 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 880 Payload Format Specifications", BCP 36, RFC 2736, 881 December 1999. 883 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 884 Jacobson, "RTP: A Transport Protocol for Real-Time 885 Applications", STD 64, RFC 3550, July 2003. 887 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 888 Video Conferences with Minimal Control", STD 65, RFC 3551, 889 July 2003. 891 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 892 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 893 RFC 3556, July 2003. 895 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 896 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 897 RFC 3711, March 2004. 899 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 900 "Extended RTP Profile for Real-time Transport Control 901 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 902 July 2006. 904 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 905 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 906 July 2006. 908 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 909 BCP 131, RFC 4961, July 2007. 911 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 912 "Codec Control Messages in the RTP Audio-Visual Profile 913 with Feedback (AVPF)", RFC 5104, February 2008. 915 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 916 Correction", RFC 5109, December 2007. 918 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 919 Real-time Transport Control Protocol (RTCP)-Based Feedback 920 (RTP/SAVPF)", RFC 5124, February 2008. 922 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 923 Header Extensions", RFC 5285, July 2008. 925 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 926 RTP Streams", RFC 5450, March 2009. 928 [RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", 929 RFC 5484, March 2009. 931 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 932 Real-Time Transport Control Protocol (RTCP): Opportunities 933 and Consequences", RFC 5506, April 2009. 935 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 936 Control Packets on a Single Port", RFC 5761, April 2010. 938 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 939 Flows", RFC 6051, November 2010. 941 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 942 Choosing RTP Control Protocol (RTCP) Canonical Names 943 (CNAMEs)", RFC 6222, April 2011. 945 13.2. Informative References 947 [I-D.begen-mmusic-redundancy-grouping] 948 Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 949 Semantics in the Session Description Protocol", 950 draft-begen-mmusic-redundancy-grouping-01 (work in 951 progress), June 2011. 953 [I-D.cbran-rtcweb-data] 954 Bran, C. and C. Jennings, "RTC-Web Non-Media Data 955 Transport Requirements", draft-cbran-rtcweb-data-00 (work 956 in progress), July 2011. 958 [I-D.ietf-fecframe-framework] 959 Watson, M., Begen, A., and V. Roca, "Forward Error 960 Correction (FEC) Framework", 961 draft-ietf-fecframe-framework-15 (work in progress), 962 June 2011. 964 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 965 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 966 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 967 September 1997. 969 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 970 January 2008. 972 [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 973 Control Protocol (RTCP)", RFC 5968, September 2010. 975 [rtp-tfrc] 976 Gharai, L., "RTP with TCP Friendly Rate Control 977 (draft-gharai-avtcore-rtp-tfrc-00)", March 2011. 979 Authors' Addresses 981 Colin Perkins 982 University of Glasgow 983 School of Computing Science 984 Glasgow G12 8QQ 985 United Kingdom 987 Email: csp@csperkins.org 988 Magnus Westerlund 989 Ericsson 990 Farogatan 6 991 SE-164 80 Kista 992 Sweden 994 Phone: +46 10 714 82 87 995 Email: magnus.westerlund@ericsson.com 997 Joerg Ott 998 Aalto University 999 School of Electrical Engineering 1000 Espoo 02150 1001 Finland 1003 Email: jorg.ott@aalto.fi