idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3611' is defined on line 969, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-06 == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-rtp-multi-stream-optimisation-00 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-04 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-18 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-12 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE J. Lennox 3 Internet-Draft Vidyo 4 Updates: 3550, 4585 (if approved) M. Westerlund 5 Intended status: Standards Track Ericsson 6 Expires: April 30, 2015 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 October 27, 2014 12 Sending Multiple Media Streams in a Single RTP Session 13 draft-ietf-avtcore-rtp-multi-stream-06 15 Abstract 17 This memo expands and clarifies the behaviour of Real-time Transport 18 Protocol (RTP) endpoints that use multiple synchronization sources 19 (SSRCs). This occurs, for example, when an endpoint sends multiple 20 media streams in a single RTP session. This memo updates RFC 3550 21 with regards to handling multiple SSRCs per endpoint in RTP sessions, 22 with a particular focus on RTCP behaviour. It also updates RFC 4585 23 to update and clarify the calculation of the timeout of SSRCs and the 24 inclusion of feedback messages. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 30, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Use Cases For Multi-Stream Endpoints . . . . . . . . . . . . 3 63 3.1. Endpoints with Multiple Capture Devices . . . . . . . . . 3 64 3.2. Multiple Media Types in a Single RTP Session . . . . . . 3 65 3.3. Multiple Stream Mixers . . . . . . . . . . . . . . . . . 4 66 3.4. Multiple SSRCs for a Single Media Source . . . . . . . . 4 67 4. Use of RTP by endpoints that send multiple media streams . . 5 68 5. Use of RTCP by Endpoints that send multiple media streams . . 5 69 5.1. RTCP Reporting Requirement . . . . . . . . . . . . . . . 5 70 5.2. Initial Reporting Interval . . . . . . . . . . . . . . . 5 71 5.3. Aggregation of Reports into Compound RTCP Packets . . . . 6 72 5.3.1. Maintaining AVG_RTCP_SIZE . . . . . . . . . . . . . . 7 73 5.3.2. Scheduling RTCP with Multiple Reporting SSRCs . . . . 8 74 5.4. Use of RTP/AVPF Feedback . . . . . . . . . . . . . . . . 10 75 5.4.1. Choice of SSRC for Feedback Packets . . . . . . . . . 10 76 5.4.2. Scheduling an RTCP Feedback Packet . . . . . . . . . 11 77 6. RTCP Considerations for Streams with Disparate Rates . . . . 12 78 6.1. Timing out SSRCs . . . . . . . . . . . . . . . . . . . . 13 79 6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter . 13 80 6.1.2. Avoiding Premature Timeout . . . . . . . . . . . . . 14 81 6.1.3. Interoperability Between RTP/AVP and RTP/AVPF . . . . 15 82 6.1.4. Updated SSRC Timeout Rules . . . . . . . . . . . . . 15 83 6.2. Tuning RTCP transmissions . . . . . . . . . . . . . . . . 16 84 6.2.1. RTP/AVP and RTP/SAVP . . . . . . . . . . . . . . . . 16 85 6.2.2. RTP/AVPF and RTP/SAVPF . . . . . . . . . . . . . . . 18 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 91 10.2. Informative References . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 95 At the time the Real-Time Transport Protocol (RTP) [RFC3550] was 96 originally designed, and for quite some time after, endpoints in RTP 97 sessions typically only transmitted a single media stream, and thus 98 used a single synchronization source (SSRC) per RTP session, where 99 separate RTP sessions were typically used for each distinct media 100 type. Recently, however, a number of scenarios have emerged in which 101 endpoints wish to send multiple RTP media streams, distinguished by 102 distinct RTP synchronization source (SSRC) identifiers, in a single 103 RTP session. These are outlined in Section 3. Although the initial 104 design of RTP did consider such scenarios, the specification was not 105 consistently written with such use cases in mind. The specifications 106 are thus somewhat unclear. 108 This memo updates [RFC3550] to clarify behaviour in use cases where 109 endpoints use multiple SSRCs. It also updates [RFC4585] in regards 110 to the timeout of inactive SSRCs to resolve problematic behaviour as 111 well as clarifying the inclusion of feedback messages. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in RFC 118 2119 [RFC2119] and indicate requirement levels for compliant 119 implementations. 121 3. Use Cases For Multi-Stream Endpoints 123 This section discusses several use cases that have motivated the 124 development of endpoints that sends RTP data using multiple SSRCs in 125 a single RTP session. 127 3.1. Endpoints with Multiple Capture Devices 129 The most straightforward motivation for an endpoint to send multiple 130 simultaneous RTP streams in a session is the scenario where an 131 endpoint has multiple capture devices, and thus media sources, of the 132 same media type and characteristics. For example, telepresence 133 endpoints, of the type described by the CLUE Telepresence Framework 134 [I-D.ietf-clue-framework], often have multiple cameras or microphones 135 covering various areas of a room, and hence send several RTP streams. 137 3.2. Multiple Media Types in a Single RTP Session 139 Recent work has updated RTP 140 [I-D.ietf-avtcore-multi-media-rtp-session] and SDP 141 [I-D.ietf-mmusic-sdp-bundle-negotiation] to remove the historical 142 assumption in RTP that media sources of different media types would 143 always be sent on different RTP sessions. In this work, a single 144 endpoint's audio and video RTP media streams (for example) are 145 instead sent in a single RTP session to reduce the number of 146 transport layer flows used. 148 3.3. Multiple Stream Mixers 150 There are several RTP topologies which can involve a central device 151 that itself generates multiple RTP media streams in a session. An 152 example is a mixer providing centralized compositing for a multi- 153 capture scenario like that described in Section 3.1. In this case, 154 the centralized node is behaving much like a multi-capturer endpoint, 155 generating several similar and related sources. 157 A more complex example is the selective forwarding middlebox, 158 described in Section 3.7 of [I-D.ietf-avtcore-rtp-topologies-update]. 159 This is a middlebox that receives media streams from several 160 endpoints, and then selectively forwards modified versions of some 161 RTP streams toward the other endpoints to which it is connected. For 162 each connected endpoint, a separate media source appears in the 163 session for every other source connected to the middlebox, 164 "projected" from the original streams, but at any given time many of 165 them can appear to be inactive (and thus are receivers, not senders, 166 in RTP). This sort of device is closer to being an RTP mixer than an 167 RTP translator, in that it terminates RTCP reporting about the mixed 168 streams, and it can re-write SSRCs, timestamps, and sequence numbers, 169 as well as the contents of the RTP payloads, and can turn sources on 170 and off at will without appearing to be generating packet loss. Each 171 projected stream will typically preserve its original RTCP source 172 description (SDES) information. 174 3.4. Multiple SSRCs for a Single Media Source 176 There are also several cases where a single media source results in 177 the usage of multiple SSRCs within the same RTP session. Transport 178 robustness tools like RTP Retransmission [RFC4588] result in multiple 179 SSRCs, one with source data, and another with the repair data. 180 Scalable encoders and their RTP payload formats, like H.264's 181 extension for Scalable Video Coding(SVC) [RFC6190] can be transmitted 182 in a configuration where the scalable layers are distributed over 183 multiple SSRCs within the same session, to enable RTP packet stream 184 level (SSRC) selection and routing in conferencing middleboxes. 186 4. Use of RTP by endpoints that send multiple media streams 188 Every RTP endpoint will have an allocated share of the available 189 session bandwidth, as determined by signalling and congestion 190 control. The endpoint MUST keep its total media sending rate within 191 this share. However, endpoints that send multiple media streams do 192 not necessarily need to subdivide their share of the available 193 bandwidth independently or uniformly to each media stream and its 194 SSRCs. In particular, an endpoint can vary the allocation to 195 different streams depending on their needs, and can dynamically 196 change the bandwidth allocated to different SSRCs (for example, by 197 using a variable rate codec), provided the total sending rate does 198 not exceed its allocated share. This includes enabling or disabling 199 media streams and their redundancy streams as more or less bandwidth 200 becomes available. 202 5. Use of RTCP by Endpoints that send multiple media streams 204 The RTP Control Protocol (RTCP) is defined in Section 6 of [RFC3550]. 205 The description of the protocol is phrased in terms of the behaviour 206 of "participants" in an RTP session, under the assumption that each 207 endpoint is a participant with a single SSRC. However, for correct 208 operation in cases where endpoints can send multiple media streams, 209 the specification needs to be interpreted with each SSRC counting as 210 a participant in the session, so that an endpoint that has multiple 211 SSRCs counts as multiple participants. The following describes 212 several concrete cases where this applies. 214 5.1. RTCP Reporting Requirement 216 An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a 217 separate participant in the RTP session, sending RTCP reports for 218 each of its SSRCs in every RTCP reporting interval. If the mechanism 219 in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is not used, then 220 each SSRC will send RTCP reports for all other SSRCs, including those 221 co-located at the same endpoint. 223 If the endpoint has some SSRCs that are sending data and some that 224 are only receivers, then they will receive different shares of the 225 RTCP bandwidth and calculate different base RTCP reporting intervals. 226 Otherwise, all SSRCs at an endpoint will calculate the same base RTCP 227 reporting interval. The actual reporting intervals for each SSRC are 228 randomised in the usual way, but reports can be aggregated as 229 described in Section 5.3. 231 5.2. Initial Reporting Interval 232 When a participant joins a unicast session, the following text from 233 Section 6.2 of [RFC3550] applies: "For unicast sessions... the delay 234 before sending the initial compound RTCP packet MAY be zero." This 235 also applies to the individual SSRCs of an endpoint that has multiple 236 SSRCs, and such endpoints MAY send an initial RTCP packet for each of 237 their SSRCs immediately upon joining a unicast session. 239 Caution has to be exercised, however, when an endpoint (or middlebox) 240 with a large number of SSRCs joins a unicast session, since immediate 241 transmission of many RTCP reports can create a significant burst of 242 traffic, leading to transient congestion and packet loss due to queue 243 overflows. Implementers are advised to consider sending immediate 244 RTCP packets for only a small number of SSRCs (e.g., the one or two 245 SSRCs they consider most important), with the initial RTCP packets 246 for their other SSRCs being sent after the calculated initial RTCP 247 reporting interval, to avoid self congestion. 249 (TBD: is this recommendation sufficiently strong?) 251 5.3. Aggregation of Reports into Compound RTCP Packets 253 As outlined in Section 5.1, an endpoint with multiple SSRCs has to 254 treat each SSRC as a separate participant when it comes to sending 255 RTCP reports. This will lead to each SSRC sending a compound RTCP 256 packet in each reporting interval. Since these packets are coming 257 from the same endpoint, it might reasonably be expected that they can 258 be aggregated to reduce overheads. Indeed, Section 6.1 of [RFC3550] 259 allows RTP translators and mixers to aggregate packets in similar 260 circumstances: 262 "It is RECOMMENDED that translators and mixers combine individual 263 RTCP packets from the multiple sources they are forwarding into 264 one compound packet whenever feasible in order to amortize the 265 packet overhead (see Section 7). An example RTCP compound packet 266 as might be produced by a mixer is shown in Fig. 1. If the 267 overall length of a compound packet would exceed the MTU of the 268 network path, it SHOULD be segmented into multiple shorter 269 compound packets to be transmitted in separate packets of the 270 underlying protocol. This does not impair the RTCP bandwidth 271 estimation because each compound packet represents at least one 272 distinct participant. Note that each of the compound packets MUST 273 begin with an SR or RR packet." 275 The allows RTP translators and mixers to generate compound RTCP 276 packets that contain multiple SR or RR packets from different SSRCs, 277 as well as any of the other packet types. There are no restrictions 278 on the order in which the RTCP packets can occur within the compound 279 packet, except the regular rule that the compound RTCP packet starts 280 with an SR or RR packet. Due to this rule, correctly implemented RTP 281 endpoints will be able to handle compound RTCP packets that contain 282 RTCP packets relating to multiple SSRCs. 284 Accordingly, endpoints that use multiple SSRCs MAY aggregate the RTCP 285 packets sent by their different SSRCs into compound RTCP packets, 286 provided 1) the resulting compound RTCP packets begin with an SR or 287 RR packet; 2) they maintain the average RTCP packet size as described 288 in Section 5.3.1; and 3) they schedule packet transmission and manage 289 aggregation as described in Section 5.3.2. 291 5.3.1. Maintaining AVG_RTCP_SIZE 293 The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis. 294 Each SSRC sends a single compound RTCP packet in each RTCP reporting 295 interval. When an endpoint uses multiple SSRCs, it is desirable to 296 aggregate the compound RTCP packets sent by its SSRCs, reducing the 297 overhead by forming a larger compound RTCP packet. This aggregation 298 can be done as described in Section 5.3.2, provided the average RTCP 299 packet size calculation is updated as follows. 301 Participants in an RTP session update their estimate of the average 302 RTCP packet size (avg_rtcp_size) each time they send or receive an 303 RTCP packet (see Section 6.3.3 of [RFC3550]). When a compound RTCP 304 packet that contains RTCP packets from several SSRCs is sent or 305 received, the avg_rtcp_size estimate for each SSRC that is reported 306 upon is updated using div_packet_size rather than the actual packet 307 size: 309 avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size 311 where div_packet_size is packet_size divided by the number of SSRCs 312 reporting in that compound packet. The number of SSRCs reporting in 313 a compound packet is determined by counting the number of different 314 SSRCs that are the source of Sender Report (SR) or Receiver Report 315 (RR) RTCP packets within the compound RTCP packet. Non-compound RTCP 316 packets (i.e., RTCP packets that do not contain an SR or RR packet 317 [RFC5506]) are considered report on a single SSRC. 319 An SSRC doesn't follow the above rule, and instead uses the full RTCP 320 compound packet size to calculate avg_rtcp_size, will derive an RTCP 321 reporting interval that is overly large by a factor that is 322 proportional to the number of SSRCs aggregated into compound RTCP 323 packets and the size of set of SSRCs being aggregated relative to the 324 total number of participants. This increased RTCP reporting interval 325 can cause premature timeouts if it is more than five times the 326 interval chosen by the SSRCs that understand compound RTCP that 327 aggregate reports from many SSRCs. A 1500 octet MTU can fit six 328 typical size reports into a compound RTCP packet, so this is a real 329 concern if endpoints aggregate RTCP reports from multiple SSRCs. If 330 compatibility with non-updated endpoints is a concern, the number of 331 reports from different SSRCs aggregated into a single compound RTCP 332 packet SHOULD be limited. 334 5.3.2. Scheduling RTCP with Multiple Reporting SSRCs 336 When implementing RTCP packet scheduling for cases where multiple 337 reporting SSRCs are aggregating their RTCP packets in the same 338 compound packet there are a number of challenges. First of all, we 339 have the goal of not changing the general properties of the RTCP 340 packet transmissions, which include the general inter-packet 341 distribution, and the behaviour for dealing with flash joins as well 342 as other dynamic events. 344 The below specified mechanism deals with: 346 o That one can't have a-priori knowledge about which RTCP packets 347 are to be sent, or their size, prior to generating the packets. 348 In which case, the time from generation to transmission ought to 349 be as short as possible to minimize the information that becomes 350 stale. 352 o That one has an MTU limit, that one ought to avoid exceeding, as 353 that requires lower-layer fragmentation (e.g., IP fragmentation) 354 which impacts the packets' probability of reaching the 355 receiver(s). 357 Schedule all the endpoint's local SSRCs individually for transmission 358 using the regular calculation of Tn for the profile being used. Each 359 time a SSRC's Tn timer expires, do the regular reconsideration. If 360 the reconsideration indicates that an RTCP packet is to be sent: 362 1. Consider if an additional SSRC can be added. That consideration 363 is done by picking the SSRC which has the Tn value closest in 364 time to now (Tc). 366 2. Calculate how much space for RTCP packets would be needed to add 367 that SSRC. 369 3. If the considered SSRC's RTCP Packets fit within the lower layer 370 datagram's Maximum Transmission Unit, taking the necessary 371 protocol headers into account and the consumed space by prior 372 SSRCs, then add that SSRC's RTCP packets to the compound packet 373 and go again to Step 1. 375 4. If the considered SSRC's RTCP Packets will not fit within the 376 compound packet, then transmit the generated compound packet. 378 5. Update the RTCP Parameters for each SSRC that has been included 379 in the sent RTCP packet. The Tp value for each SSRC MUST be 380 updated as follows: 382 For the first SSRC: As this SSRC was the one that was 383 reconsidered the tp value is set to the tc as defined in 384 RTP [RFC3550]. 386 For any additional SSRC: The tp value SHALL be set to the 387 transmission time this SSRC would have had it not been 388 aggregated and given the current existing session context. 389 This value is derived by taking this SSRC's Tn value and 390 performing reconsideration and updating tn until tp + T <= 391 tn. Then set tp to this tn value. 393 6. For the sent SSRCs calculate new tn values based on the updated 394 parameters and reschedule the timers. 396 Reverse reconsideration needs to be performed as specified in RTP 397 [RFC3550]. It is important to note that under the above algorithm 398 when performing reconsideration, the value of tp can actually be 399 larger than tc. However, that still has the desired effect of 400 proportionally pulling the tp value towards tc (as well as tn) as the 401 group size shrinks in direct proportion the reduced group size. 403 The above algorithm has been shown in simulations to maintain the 404 inter-RTCP-packet transmission distribution for the SSRCs and consume 405 the same amount of bandwidth as non-aggregated packets in RTP 406 sessions with static sets of participants. With this algorithm the 407 actual transmission interval for any SSRC triggering an RTCP compound 408 packet transmission is following the regular transmission rules. It 409 also handles the cases where the number of SSRCs that can be included 410 in an aggregated packet varies. An SSRC that previously was 411 aggregated and fails to fit in a packet still has its own 412 transmission scheduled according to normal rules. Thus, it will 413 trigger a transmission in due time, or the SSRC will be included in 414 another aggregate. 416 The algorithm's behaviour under SSRC group size changes is under 417 investigation. However, it is expected to be well behaved based on 418 the following analyses. 420 RTP sessions where the number of SSRC are growing: When the group 421 size is growing, the Td values grow in proportion to the number of 422 new SSRCs in the group. The reconsideration when the timer for 423 the tn expires, that SSRC will reconsider the transmission and 424 with a certain probability reschedule the tn timer. This part of 425 the reconsideration algorithm is only impacted by the above 426 algorithm by having tp values that are in the future instead of 427 set to the time of the actual last transmission at the time of 428 updating tp. Thus the scheduling causes in worst case a plateau 429 effect for that SSRC. That effect depends on how far into the 430 future tp can advance. 432 RTP sessions where the number of SSRC are shrinking: When the group 433 shrinks, reverse reconsideration moves the tp and tn values 434 towards tc proportionally to the number of SSRCs that leave the 435 session compared to the total number of participants when they 436 left. Thus the also group size reductions need to be handled. 438 In general the potential issue that might exist depends on how far 439 into the future the tp value can drift compared to the actual packet 440 transmissions that occur. That drift can only occur for an SSRC that 441 never is the trigger for RTCP packet transmission and always gets 442 aggregated and where the calculated packet transmission interval 443 randomly occurs so that tn - tp for this SSRC is on average larger 444 than the ones that gets transmitted. 446 5.4. Use of RTP/AVPF Feedback 448 This section discusses the transmission of RTP/AVPF feedback packets 449 when the transmitting endpoint has multiple SSRCs. 451 5.4.1. Choice of SSRC for Feedback Packets 453 When an RTP/AVPF endpoint has multiple SSRCs, it can choose what SSRC 454 to use as the source for the RTCP feedback packets it sends. Several 455 factors can affect that choice: 457 o RTCP feedback packets relating to a particular media type SHOULD 458 be sent by an SSRC that receives that media type. For example, 459 when audio and video are multiplexed onto a single RTP session, 460 endpoints will use their audio SSRC to send feedback on the audio 461 received from other participants. 463 o RTCP feedback packets and RTCP codec control messages that are 464 notifications or indications regarding RTP data processed by an 465 endpoint MUST be sent from the SSRC used by that RTP data. This 466 includes notifications that relate to a previously received 467 request or command. 469 o If separate SSRCs are used to send and receive media, then the 470 corresponding SSRC SHOULD be used for feedback, since they have 471 differing RTCP bandwidth fractions. This can also effect the 472 consideration if the SSRC can be used in immediate mode or not. 474 o Some RTCP feedback packet types requires consistency in the SSRC 475 used. For example, if one sets a TMMBR limitation, the same SSRC 476 needs to be used to remove the limitation. 478 When an RTCP feedback packet is sent as part of a compound RTCP 479 packet that aggregates reports from multiple SSRCs, there is no 480 requirement that the compound packet contains an SR or RR packet 481 generated by the sender of the RTCP feedback packet. For reduced- 482 size RTCP packets, aggregation of RTCP feedback packets from multiple 483 sources is not limited further than Section 4.2.2 of [RFC5506]. 485 5.4.2. Scheduling an RTCP Feedback Packet 487 When an SSRC has a need to transmit a feedback packet in early mode 488 it follows the scheduling rules defined in Section 3.5 in RTP/AVPF 489 [RFC4585]. When following these rules the following clarifications 490 need to be taken into account: 492 o That a session is considered to be point-to-point or multiparty 493 not based on the number of SSRCs, but the number of endpoints 494 directly seen in the RTP session by the endpoint. TBD: Clarify 495 what is considered to "see" an endpoint? 497 o Note that when checking if there is already a scheduled compound 498 RTCP packet containing feedback messages (Step 2 in 499 Section 3.5.2), that check is done considering all local SSRCs. 501 TBD: The above does not allow an SSRC that is unable to send either 502 an early or regular RTCP packet with the feedback message within the 503 T_max_fb_delay to trigger another SSRC to send an early packet to 504 which it could piggyback. Nor does it allow feedback to piggyback on 505 even regular RTCP packet transmissions that occur within 506 T_max_fb_delay. A question is if either of these behaviours ought to 507 be allowed. The latter appears simple and straight forward. Instead 508 of discarding a FB message in step 4a: alternative 2, one could place 509 such messages in a cache with a discard time equal to T_max_fb_delay, 510 and in case any of the SSRCs schedule an RTCP packet for transmission 511 within that time, it includes this message. The former case can have 512 more widespread impact on the application, and possibly also on the 513 RTCP bandwidth consumption as it allows for more massive bursts of 514 RTCP packets. Still, on a time scale of a regular reporting 515 interval, it ought to have no effect on the RTCP bandwidth as the 516 extra feedback messages increase the avg_rtcp_size. 518 6. RTCP Considerations for Streams with Disparate Rates 520 An RTP session has a single set of parameters that configure the 521 session bandwidth. These are the RTCP sender and receiver fractions 522 (e.g., the SDP "b=RR:" and "b=RS:" lines), and the parameters of the 523 RTP/AVPF profile [RFC4585] (e.g., trr-int) if that profile (or its 524 secure extension, RTP/SAVPF [RFC5124]) is used. As a consequence, 525 the base RTCP reporting interval, before randomisation, will be the 526 same for every sending SSRC in an RTP session. Similarly, every 527 receiving SSRC in an RTP session will have the same base reporting 528 interval, although this can differ from the reporting interval chosen 529 by sending SSRCs. This uniform RTCP reporting interval for all SSRCs 530 can result in RTCP reports being sent more often than is considered 531 desirable for a particular media type. 533 For example, consider a scenario when an audio flow sending at tens 534 of kilobits per second is multiplexed into an RTP session with a 535 multi-megabit high quality video flow. If the session bandwidth is 536 configured based on the video sending rate, and the default RTCP 537 bandwidth fraction of 5% of the session bandwidth is used, it is 538 likely that the RTCP bandwidth will exceed the audio sending rate. 539 If the reduced minimum RTCP interval described in Section 6.2 of 540 [RFC3550] is then used in the session, as appropriate for video where 541 rapid feedback on damaged I-frames is wanted, the uniform reporting 542 interval for all senders could mean that audio sources are expected 543 to send RTCP packets more often than they send audio data packets. 544 This bandwidth mismatch can be reduced by careful tuning of the RTCP 545 parameters, especially trr_int when the RTP/AVPF profile is used, 546 cannot be avoided entirely, as it is inherent in the design of the 547 RTCP timing rules, and affects all RTP sessions that contain flows 548 with greatly mismatched bandwidth. 550 Sending multiple media types in a single RTP session causes that 551 session to contain more SSRCs than if each media type was sent in a 552 separate RTP session. For example, if two participants each send an 553 audio and a video flow in a single RTP session, that session will 554 comprise four SSRCs, but if separate RTP sessions had been used for 555 audio and video, each of those two RTP sessions would comprise only 556 two SSRCs. Sending multiple media streams in an RTP session hence 557 increases the amount of cross reporting between the SSRCs, as each 558 SSRC reports on all other SSRCs in the session. This increases the 559 size of the RTCP reports, causing them to be sent less often than 560 would be the case if separate RTP sessions where used for a given 561 RTCP bandwidth. 563 Finally, when an RTP session contains multiple media types, it is 564 important to note that the RTCP reception quality reports, feedback 565 messages, and extended report blocks used might not be applicable to 566 all media types. Endpoints will need to consider the media type of 567 each SSRC only send or process reports and feedback that apply to 568 that particular SSRC and its media type. Signalling solutions might 569 have shortcomings when it comes to indicating that a particular set 570 of RTCP reports or feedback messages only apply to a particular media 571 type within an RTP session. 573 From an RTCP perspective, therefore, it can be seen that there are 574 advantages to using separate RTP sessions for each media stream, 575 rather than sending multiple media streams in a single RTP session. 576 However, these are frequently offset by the need to reduce port use, 577 to ease NAT/firewall traversal, achieved by combining media streams 578 into a single RTP session. The following sections consider some of 579 the issues with using RTCP in sessions with multiple media streams in 580 more detail. 582 6.1. Timing out SSRCs 584 Various issues have been identified with timing out SSRC values when 585 sending multiple media streams in an RTP session. 587 6.1.1. Problems with RTP/AVPF the T_rr_interval Parameter 589 The RTP/AVPF profile includes a method to prevent RTCP reports from 590 being sent too often. This mechanism is described in Section 3.5.3 591 of [RFC4585], and is controlled by the T_rr_interval parameter. It 592 works as follows. When a regular RTCP report is sent, a new random 593 value, T_rr_current_interval, is generated, drawn evenly in the range 594 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is to be 595 sent earlier then T_rr_current_interval seconds after the previous 596 regular RTCP packet, and there are no feedback messages to be sent, 597 then that regular RTCP packet is suppressed, and the next regular 598 RTCP packet is scheduled. The T_rr_current_interval is recalculated 599 each time a regular RTCP packet is sent. The benefit of suppression 600 is that it avoids wasting bandwidth when there is nothing requiring 601 frequent RTCP transmissions, but still allows utilization of the 602 configured bandwidth when feedback is needed. 604 Unfortunately this suppression mechanism skews the distribution of 605 the RTCP sending intervals compared to the regular RTCP reporting 606 intervals. The standard RTCP timing rules, including reconsideration 607 and the compensation factor, result in the intervals between sending 608 RTCP packets having a distribution that is skewed towards the upper 609 end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the 610 deterministic calculated RTCP reporting interval. With Td = 5s this 611 distribution covers the range [2.052s, 6.156s]. In comparison, the 612 RTP/AVPF suppression rules act in an interval that is 0.5 to 1.5 613 times T_rr_interval; for T_rr_interval = 5s this is [2.5s, 7.5s]. 615 The effect of this is that the time between consecutive RTCP packets 616 when using T_rr_interval suppression can become large. The maximum 617 time interval between sending one regular RTCP packet and the next, 618 when T_rr_interval is being used, occurs when T_rr_current_interval 619 takes its maximum value and a regular RTCP packet is suppressed at 620 the end of the suppression period, then the next regular RTCP packet 621 is scheduled after its largest possible reporting interval. Taking 622 the worst case of the two intervals gives a maximum time between two 623 RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td. 625 This behaviour can be surprising when Td and T_rr_interval have the 626 same value. That is, when T_rr_interval is configured to match the 627 regular RTCP reporting interval. In this case, one might expect that 628 regular RTCP packets are sent according to their usual schedule, but 629 feedback packets can be sent early. However, the above-mentioned 630 issue results in the RTCP packets actually being sent in the range 631 [0.5*Td, 2.731*Td] with a highly non-uniform distribution, rather 632 than the range [0.41*Td, 1.23*Td]. This is perhaps unexpected, but 633 is not a problem in itself. However, when coupled with packet loss, 634 it raises the issue of premature timeout. 636 6.1.2. Avoiding Premature Timeout 638 In RTP/AVP [RFC3550] the timeout behaviour is simple, and is 5 times 639 Td, where Td is calculated with a Tmin value of 5 seconds. In other 640 words, if the configured RTCP bandwidth allows for an average RTCP 641 reporting interval shorter than 5 seconds, the timeout is 25 seconds 642 of no activity from the SSRC (RTP or RTCP), otherwise the timeout is 643 5 average reporting intervals. 645 RTP/AVPF [RFC4585] introduces different timeout behaviours depending 646 on the value of T_rr_interval. When T_rr_interval is 0, it uses the 647 same timeout calculation as RTP/AVP. However, when T_rr_interval is 648 non-zero, it replaces Tmin in the timeout calculation, most likely to 649 speed up detection of timed out SSRCs. However, using a non-zero 650 T_rr_interval has two consequences for RTP behaviour. 652 First, due to suppression, the number of RTP and RTCP packets sent by 653 an SSRC that is not an active RTP sender can become very low, because 654 of the issue discussed in Section 6.1.1. As the RTCP packet interval 655 can be as long as 2.73*Td, then during a 5*Td time period an endpoint 656 might in fact transmit only a single RTCP packet. The long intervals 657 result in fewer RTCP packets, to a point where a single RTCP packet 658 loss can sometimes result in timing out an SSRC. 660 Second, the RTP/AVPF changes to the timeout rules reduce robustness 661 to misconfiguration. It is common to use RTP/AVPF configured such 662 that RTCP packets can be sent frequently, to allow rapid feedback, 663 however this makes timeouts very sensitive to T_rr_interval. For 664 example, if two SSRCs are configured one with T_rr_interval = 0.1s 665 and the other with T_rr_interval = 0.6s, then this small difference 666 will result in the SSRC with the shorter T_rr_interval timing out the 667 other if it stops sending RTP packets, since the other RTCP reporting 668 interval is more than five times its own. When RTP/AVP is used, or 669 RTP/AVPF with T_rr_interval = 0, this is a non-issue, as the timeout 670 period will be 25s, and differences between configured RTCP bandwidth 671 can only cause premature timeouts when the reporting intervals are 672 greater than 5s and differ by a factor of five. To limit the scope 673 for such problematic misconfiguration, we propose an update to the 674 RTP/AVPF timeout rules in Section 6.1.4. 676 6.1.3. Interoperability Between RTP/AVP and RTP/AVPF 678 If endpoints implementing the RTP/AVP and RTP/AVPF profiles (or their 679 secure variants) are combined within a single RTP session, and the 680 RTP/AVPF endpoints use a non-zero T_rr_interval that is significantly 681 below 5 seconds, there is a risk that the RTP/AVPF endpoints will 682 prematurely timeout the SSRCs of the RTP/AVP endpoints, due to their 683 different RTCP timeout rules. Conversely, if the RTP/AVPF endpoints 684 use a T_rr_interval that is significant larger than 5 seconds, there 685 is a risk that the RTP/AVP endpoints will timeout the SSRCs of the 686 RTP/AVPF endpoints. 688 Mixing endpoints using two different RTP profiles within a single RTP 689 session is NOT RECOMMENDED. However, if mixed RTP profiles are used, 690 and the RTP/AVPF endpoints are not updated to follow Section 6.1.4 of 691 this memo, then the RTP/AVPF session SHOULD be configured to use 692 T_rr_interval = 4 seconds to avoid premature timeouts. 694 The choice of T_rr_interval = 4 seconds for interoperability might 695 appear strange. Intuitively, this value ought to be 5 seconds, to 696 make both the RTP/AVP and RTP/AVPF use the same timeout period. 697 However, the behaviour outlined in Section 6.1.1 shows that actual 698 RTP/AVPF reporting intervals can be longer than expected. Setting 699 T_rr_interval = 4 seconds gives actual RTCP intervals near to those 700 expected by RTP/AVP, ensuring interoperability. 702 6.1.4. Updated SSRC Timeout Rules 704 To ensure interoperability and avoid premature timeouts, all SSRCs in 705 an RTP session MUST use the same timeout behaviour. However, 706 previous specification are inconsistent in this regard. To avoid 707 interoperability issues, this memo updates the timeout rules as 708 follows: 710 o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the 711 timeout interval SHALL be calculated using a multiplier of five 712 times the deterministic RTCP reporting interval. That is, the 713 timeout interval SHALL be 5*Td. 715 o For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, 716 calculation of Td SHALL be done using a Tmin value of 5 seconds 717 and not the reduced minimal interval, even if the reduced minimum 718 interval is used to calculate RTCP packet transmission intervals. 720 This changes the behaviour for the RTP/AVPF or RTP/SAVPF profiles 721 when T_rr_interval != 0, a behaviour defined in Section 3.5.4 of RFC 722 4585, i.e. Tmin in the Td calculation is the T_rr_interval. 724 6.2. Tuning RTCP transmissions 726 This sub-section discusses what tuning can be done to reduce the 727 downsides of the shared RTCP packet intervals. First, it is 728 considered what possibilities exist for the RTP/AVP [RFC3551] 729 profile, then what additional tools are provided by RTP/AVPF 730 [RFC4585]. 732 6.2.1. RTP/AVP and RTP/SAVP 734 When using the RTP/AVP or RTP/SAVP profiles, the options for tuning 735 the RTCP reporting intervals are limited to the RTCP sender and 736 receiver bandwidth, and whether the minimum RTCP interval is scaled 737 according to the bandwidth. As the scheduling algorithm includes 738 both randomisation and reconsideration, one cannot simply calculate 739 the expected average transmission interval using the formula for Td 740 given in Section 6.3.1 of [RFC3550]. However, by considering the 741 inputs to that expression, and the randomisation and reconsideration 742 rules, we can begin to understand the behaviour of the RTCP 743 transmission interval. 745 Let's start with some basic observations: 747 a. Unless the scaled minimum RTCP interval is used, then Td prior to 748 randomization and reconsideration can never be less than Tmin. 749 The default value of Tmin is 5 seconds. 751 b. If the scaled minimum RTCP interval is used, Td can become as low 752 as 360 divided by RTP Session bandwidth in kilobits per second. 753 In SDP the RTP session bandwidth is signalled using a "b=AS" 754 line. An RTP Session bandwidth of 72kbps results in Tmin being 5 755 seconds. An RTP session bandwidth of 360kbps of course gives a 756 Tmin of 1 second, and to achieve a Tmin equal to once every frame 757 for a 25 frame-per-second video stream requires an RTP session 758 bandwidth of 9Mbps. Use of the RTP/AVPF or RTP/SAVPF profile 759 allows more frequent RTCP reports for the same bandwidth, as 760 discussed below. 762 c. The value of Td scales with the number of SSRCs and the average 763 size of the RTCP reports, to keep the overall RTCP bandwidth 764 constant. 766 d. The actual transmission interval for a Td value is in the range 767 [0.5*Td/1.21828,1.5*Td/1.21828], and the distribution is skewed, 768 due to reconsideration, with the majority of the probability mass 769 being above Td. This means, for example, that for Td = 5s, the 770 actual transmission interval will be distributed in the range 771 [2.052s, 6.156s], and tending towards the upper half of the 772 interval. Note that Tmin parameter limits the value of Td before 773 randomisation and reconsideration are applied, so the actual 774 transmission interval will cover a range extending below Tmin. 776 Given the above, we can calculate the number of SSRCs, n, that an RTP 777 session with 5% of the session bandwidth assigned to RTCP can support 778 while maintaining Td equal to Tmin. This will tell us how many media 779 streams we can report on, keeping the RTCP overhead within acceptable 780 bounds. We make two assumptions that simplify the calculation: that 781 all SSRCs are senders, and that they all send compound RTCP packets 782 comprising an SR packet with n-1 report blocks, followed by an SDES 783 packet containing a 16 octet CNAME value [RFC7022] (such RTCP packets 784 will vary in size between 54 and 798 octets depending on n, up to the 785 maximum of 31 report blocks that can be included in an SR packet). 786 If we put this packet size, and a 5% RTCP bandwidth fraction into the 787 RTCP interval calculation in Section 6.3.1 of [RFC3550], and 788 calculate the value of n needed to give Td = Tmin for the scaled 789 minimum interval, we find n=9 SSRCs can be supported (irrespective of 790 the interval, due to the way the reporting interval scales with the 791 session bandwidth). We see that to support more SSRCs, we need to 792 increase the RTCP bandwidth fraction from 5%; changing the session 793 bandwidth does not help due to the limit of Tmin. 795 To conclude, with RTP/AVP and RTP/SAVP the key limitation for small 796 unicast sessions is going to be the Tmin value. Thus the RTP session 797 bandwidth configured in RTCP has to be sufficiently high to reach the 798 reporting goals the application has following the rules for the 799 scaled minimal RTCP interval. 801 6.2.2. RTP/AVPF and RTP/SAVPF 803 When using RTP/AVPF or RTP/SAVPF, we have a powerful additional tool 804 for tuning RTCP transmissions: the T_rr_interval parameter. Use of 805 this parameter allows short RTCP reporting intervals; alternatively 806 it gives the ability to sent frequent RTCP feedback without sending 807 frequent regular RTCP reports. 809 The use of the RTP/AVPF or RTP/SAVPF profile with T_rr_interval set 810 to a value greater than zero allows more frequent RTCP feedback than 811 the RTP/AVP or RTP/SAVP profiles, for a given RTCP bandwidth. This 812 happens because Tmin is set to zero after the transmission of the 813 initial RTCP report, causing the reporting interval for later packet 814 to be determined by the usual RTCP bandwidth-based calculation, with 815 Tmin=0, and the T_rr_interval. This has the effect that we are no 816 longer restricted by the minimal interval (whether the default 5 817 second minimum, or the reduced minimum interval). Rather, the RTCP 818 bandwidth and the T_rr_interval are the governing factors, allowing 819 faster feedback. Applications that care about rapid regular RTCP 820 feedback ought to consider using the RTP/AVPF or RTP/SAVPF profile, 821 even if they don't use the feedback features of that profile. 823 The use of the RTP/AVPF or RTP/SAVPF profile allows RTCP feedback 824 packets to be sent frequently, without also requiring regular RTCP 825 reports to be sent frequently, since T_rr_interval limits the rate at 826 which regular RTCP packets can be sent, while still permitting RTCP 827 feedback packets to be sent. Applications that can use feedback 828 packets for some media streams, e.g., video streams, but don't want 829 frequent regular reporting for other media streams, can configure the 830 T_rr_interval to a value so that the regular reporting for both audio 831 and video is at a level that is considered acceptable for the audio. 832 They could then use feedback packets, which will include RTCP SR/RR 833 packets unless reduced size RTCP feedback packets [RFC5506] are used, 834 for the video reporting. This allows the available RTCP bandwidth to 835 be devoted on the feedback that provides the most utility for the 836 application. 838 Using T_rr_interval still requires one to determine suitable values 839 for the RTCP bandwidth value. Indeed, it might make this choice even 840 more important, as this is more likely to affect the RTCP behaviour 841 and performance than when using the RTP/AVP or RTP/SAVP profile, as 842 there are fewer limitations affecting the RTCP transmission. 844 When T_rr_interval is non-zero, there are configurations that need to 845 be avoided. If the RTCP bandwidth chosen is such that the Td value 846 is smaller than, but close to, T_rr_interval, then the actual regular 847 RTCP packet transmission interval can become very large, as discussed 848 in Section 6.1.1. Therefore, for configuration where one intends to 849 have Td smaller than T_rr_interval, then Td is RECOMMENDED to be 850 targeted at values less than 1/4th of T_rr_interval which results in 851 that the range becomes [0.5*T_rr_interval, 1.81*T_rr_interval]. 853 With the RTP/AVPF or RTP/SAVPF profile, using T_rr_interval = 0 with 854 another low value significantly lower than Td still has utility, and 855 different behaviour compared to the RTP/AVP profile. This avoids the 856 Tmin limitations of RTP/AVP, thus allowing more frequent regular RTCP 857 reporting. In fact this will result that the RTCP traffic becomes as 858 high as the configured values. 860 (TBD: a future version of this memo will include examples of how to 861 choose RTCP parameters for common scenarios) 863 There exists no method for using different regular RTCP reporting 864 intervals depending on the media type or individual media stream, 865 other than using a separate RTP session for the other stream. 867 7. Security Considerations 869 When using the secure RTP protocol (RTP/SAVP) [RFC3711], or the 870 secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the 871 cryptographic context of a compound secure RTCP packet is the SSRC of 872 the sender of the first RTCP (sub-)packet. This could matter in some 873 cases, especially for keying mechanisms such as Mikey [RFC3830] which 874 allow use of per-SSRC keying. 876 Otherwise, the standard security considerations of RTP apply; sending 877 multiple media streams from a single endpoint in a single RTP session 878 does not appear to have different security consequences than sending 879 the same number of media streams spread across different RTP 880 sessions. 882 8. IANA Considerations 884 No IANA actions are required. 886 9. Open Issues 888 At this stage this document contains a number of open issues. The 889 below list tries to summarize the issues: 891 1. Do we need to provide a recommendation for unicast session 892 joiners with many sources to not use 0 initial minimal interval 893 from bit-rate burst perspective? 895 2. RTCP parameters for common scenarios in Section 6.2? 896 3. Is scheduling algorithm working well with dynamic changes? 898 4. Are the scheduling algorithm changes impacting previous 899 implementations in such a way that the report aggregation has to 900 be agreed on, and thus needs to be considered as an optimization? 902 5. An open question is if any improvements or clarifications ought 903 to be allowed regarding FB message scheduling in multi-SSRC 904 endpoints. 906 10. References 908 10.1. Normative References 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 914 Jacobson, "RTP: A Transport Protocol for Real-Time 915 Applications", STD 64, RFC 3550, July 2003. 917 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 918 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 919 RFC 3711, March 2004. 921 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 922 "Extended RTP Profile for Real-time Transport Control 923 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 924 2006. 926 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 927 Real-time Transport Control Protocol (RTCP)-Based Feedback 928 (RTP/SAVPF)", RFC 5124, February 2008. 930 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 931 Real-Time Transport Control Protocol (RTCP): Opportunities 932 and Consequences", RFC 5506, April 2009. 934 10.2. Informative References 936 [I-D.ietf-avtcore-multi-media-rtp-session] 937 Westerlund, M., Perkins, C., and J. Lennox, "Sending 938 Multiple Types of Media in a Single RTP Session", draft- 939 ietf-avtcore-multi-media-rtp-session-06 (work in 940 progress), October 2014. 942 [I-D.ietf-avtcore-rtp-multi-stream-optimisation] 943 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 944 "Sending Multiple Media Streams in a Single RTP Session: 945 Grouping RTCP Reception Statistics and Other Feedback ", 946 draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work 947 in progress), July 2013. 949 [I-D.ietf-avtcore-rtp-topologies-update] 950 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 951 ietf-avtcore-rtp-topologies-update-04 (work in progress), 952 August 2014. 954 [I-D.ietf-clue-framework] 955 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 956 for Telepresence Multi-Streams", draft-ietf-clue- 957 framework-18 (work in progress), October 2014. 959 [I-D.ietf-mmusic-sdp-bundle-negotiation] 960 Holmberg, C., Alvestrand, H., and C. Jennings, 961 "Negotiating Media Multiplexing Using the Session 962 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 963 negotiation-12 (work in progress), October 2014. 965 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 966 Video Conferences with Minimal Control", STD 65, RFC 3551, 967 July 2003. 969 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 970 Protocol Extended Reports (RTCP XR)", RFC 3611, November 971 2003. 973 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 974 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 975 August 2004. 977 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 978 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 979 July 2006. 981 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 982 Eleftheriadis, "RTP Payload Format for Scalable Video 983 Coding", RFC 6190, May 2011. 985 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 986 "Guidelines for Choosing RTP Control Protocol (RTCP) 987 Canonical Names (CNAMEs)", RFC 7022, September 2013. 989 Authors' Addresses 990 Jonathan Lennox 991 Vidyo, Inc. 992 433 Hackensack Avenue 993 Seventh Floor 994 Hackensack, NJ 07601 995 USA 997 Email: jonathan@vidyo.com 999 Magnus Westerlund 1000 Ericsson 1001 Farogatan 6 1002 SE-164 80 Kista 1003 Sweden 1005 Phone: +46 10 714 82 87 1006 Email: magnus.westerlund@ericsson.com 1008 Qin Wu 1009 Huawei 1010 101 Software Avenue, Yuhua District 1011 Nanjing, Jiangsu 210012 1012 China 1014 Email: sunseawq@huawei.com 1016 Colin Perkins 1017 University of Glasgow 1018 School of Computing Science 1019 Glasgow G12 8QQ 1020 United Kingdom 1022 Email: csp@csperkins.org