idnits 2.17.1 draft-wu-avtcore-multiplex-multisource-endpoint-01.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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To achieve this, the sender which is multi-source endpoint SHOULD not send Reception reports (e.g., SR/RR RTCP packets) from all local sources to each remote source in the receiving side, Similarly the Receiver which is multi-source endpoint SHOULD not receive reception reports(e.g., SR/RR RTCP packets from each remote source in the sending side to all local sources. Instead, one designated local source from the senders within multi-source endpoint should be chosen as reporting source for other local sources within the sender. -- The document date (October 22, 2012) is 4198 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: 'RFC3556' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-avtcore-multi-media-rtp-session-00' is defined on line 467, but no explicit reference was found in the text == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-01 == Outdated reference: A later version (-13) exists of draft-ietf-avtcore-multi-media-rtp-session-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Q. Wu 3 Internet-Draft R. Even 4 Intended status: Standards Track Huawei 5 Expires: April 25, 2013 October 22, 2012 7 Bandwidth and RTCP timing issues for multi-source endpoint 8 draft-wu-avtcore-multiplex-multisource-endpoint-01.txt 10 Abstract 12 This document discusses bandwidth issues and RTCP timing rule issues 13 that arise when the multi-source endpoint multiplexing all the media 14 type in one RTP session and follows RFC3550 timing rules. It 15 provides recommendations for multi-source host sending multiple media 16 types in the same session. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Use Cases for multi-source host communications . . . . . . . . 5 56 3.1. One to one Communication between multi-source endpoints . 5 57 3.2. Multi-party Communication between multi-source 58 endpoints . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Communication between multi-source endpoint 60 multiplexing each medium in separate RTP session and 61 multiple-source endpoint multiplexing all mediums in 62 one RTP session . . . . . . . . . . . . . . . . . . . . . 7 63 4. Discuss . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Choosing RTCP Bandwidth . . . . . . . . . . . . . . . . . 10 66 5.2. Maintaining the number of session members and senders . . 11 67 5.3. RTCP Reporting Interval calculation . . . . . . . . . . . 12 68 5.4. RTCP reception report . . . . . . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 Multiplexing is a method by which multiple streams are combined into 79 one stream over a shared medium. In RTP, multiplexing is provided by 80 the destination transport address (network address and port number) 81 which is different for each RTP session. Given each media type 82 having different requirement for bandwidth, multiple media types 83 (e.g., Separate audio and video streams) are usually not carried in a 84 single RTP session. 86 However for some applications that use unicast transport, e.g., in 87 RTCWeb application, multiple-source hosts may use a different SSRC 88 for each medium but sending them in the same RTP session, which 89 reduces communication failure due to NAT and firewall when using 90 multiple RTP sessions or multiple transport flow. If these multi- 91 source hosts still follow RFC3550 timing rules, audio and video are 92 multiplexed onto a single RTP session and share a common session 93 bandwidth, the audio flows sending at much lower rates will waste a 94 large amount of bandwidth. 96 This document provides recommendations for multi-source host sending 97 multiple media types in the same session. 99 2. Terminology 101 2.1. Standards Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 Multi-Source Endpoint 109 End system with multiple sources generated from one host and 110 running on that host. One example of multi-source endpoint is an 111 RTP endpoint which has multiple capture devices of the same media 112 type and characteristics. 114 Single-Source Endpoint 115 End system with single source generated from one host described in 116 RFC3550. 118 3. Use Cases for multi-source host communications 120 3.1. One to one Communication between multi-source endpoints 122 Multiple-Source Multiple-Source 123 Endpoint1 Endpoint2 124 +--------+ +--------+ 125 | | Common Transport | | 126 | | | | 127 | |Transport flow1(v1,a1) | 128 SSRC-V1---| |------------------>| |--- SSRC-V2 129 | | | | 130 | | | | 131 | | | | 132 | | | | 133 SSRC-A1---| |Transport flow1(v2,a2) | 134 | |<------------------| +----SSRC-A2 135 | | | | 136 | | | | 137 | | | | 138 +--------+ +--------+ 140 Figure 1 142 In the figure 1, one to one communication between multiple-source 143 endpoint1 and multiple-source endpoint2 takes place. In order to 144 reduce unicast transport flow to facilitate NAT/FW traversal, 145 Multiple-Source endpoint 1 and multiple-source endpoint2 in one to 146 one communication share the same transport. Both video stream v1 and 147 audio stream a1 from multiple-source endpoint 1 are multiplexed in 148 the RTP session1 and transmitted over the transport flow1 to 149 multiple-source endpoint 2. Similarly, both video stream v2 and 150 audio stream a2 from multiple-source endpoint2 are multiplexed in the 151 RTP session 2 and transmitted over the same transmitted over the same 152 transport flow 1 as multiple source endpoint1. 154 Multiple-source endpoint1 sends RTCP SR and RR packets for every 155 active media stream it's receiving (i.e.,v2,a2) from every local 156 source (i.e.,v1,a1), which wastes a lot of bandwidth for redundant 157 statistics reports. So does multiple-source endpoint2. 159 Also the bandwidth usage for each stream is limited by its media data 160 rate and audio stream usually consumes lower bandwidth than video 161 stream (e.g.,high quality audio with 80kbps and high quality video 162 with 350 kbps). When audio stream and video stream share the same 163 transport, i.e., sharing the common session bandwidth between audio 164 and video, audio stream will still be sent at its own media data rate 165 far below the common session bandwidth and therefore waste lots of 166 bandwidth provided by the transport. Further when reception reports 167 are used for audio stream and follows RFC3550 timing rule, RTCP SR 168 and RR packets for active audio stream will be reported more frequent 169 than when audio and video are carried in separate transports since 170 more RTCP bandwidth are allocated to audio stream reporting when more 171 session bandwidth are allocated to audio stream. 173 3.2. Multi-party Communication between multi-source endpoints 175 +---+ 176 | | 177 Transport flow 1(v1,a1)-----------+ 178 Transport flow 1(v2,a2) | 179 +--+ c +--------> | 180 | | e | | Multiple |-----SSRC-V2 181 | | n | | Source | 182 +-----------+ | | t | | Endpoint2 | 183 | <---| | e | | | 184 SSRC-V1---| | | r | | +-----SSRC-A2 185 | Multiple | | | +-----------+ 186 | Source | | s | 187 | Endpoint1 | | e | 188 SSRC-A1---| <---| | r | +-----------+ 189 | | | | v | | | 190 +-----------+ | | e | | | 191 | | r | | Multiple |-----SSRC-V3 192 | | Source | 193 Transport flow 2(v1,a1) Endpoint3 | 194 Transport flow 2(v3,a3) | 195 ---| +--------> +-----SSRC-A3 196 | | +-----------+ 197 | | 198 | | 199 +---+ 201 Figure 2 203 In figure 2, multiple-source endpoint1 communicates with multiple- 204 source endpoint2 and multiple-source endpoint3 in the same session. 205 In order to reduce unicast transport flow to facilitate NAT/FW 206 traversal, multiple-source endpoint 1 shares the same transport flow 207 1 with multiple-source endpoint2 to send video stream v1 and audio 208 stream a1 and receive video stream v2 and audio stream v2 209 simultaneously. Similarly, multiple-source endpoint 1 shares the 210 same transport flow 2 with multiple-source endpoint3 to send video 211 stream v1 and audio stream a1 and receive video stream v3 and audio 212 stream a3 simultaneously. 214 Multiple-source endpoint1 sends RTCP SR and RR packets for every 215 active media stream it's receiving (i.e.,v2,a2,v3,a3) from every 216 local source (i.e.,v1,a1), which wastes a lot of bandwidth for 217 redundant statistics reports. So does multiple-source endpoint2. 219 Also the bandwidth usage for each stream is limited by its media data 220 rate and audio stream usually consumes lower bandwidth than video 221 stream (e.g.,high quality audio with 80kbps and high quality video 222 with 350 kbps). When audio stream and video stream share the same 223 transport, i.e., sharing the common session bandwidth between audio 224 and video, audio stream will still be sent at its own media data rate 225 far below the common session bandwidth and therefore waste lots of 226 bandwidth provided by the transport. Further when reception reports 227 are used for audio stream and follows RFC3550 timing rule, RTCP SR 228 and RR packets for active audio stream will be reported more frequent 229 than when audio and video are carried in separate transports since 230 more RTCP bandwidth are allocated to audio stream reporting when more 231 session bandwidth are allocated to audio stream. 233 3.3. Communication between multi-source endpoint multiplexing each 234 medium in separate RTP session and multiple-source endpoint 235 multiplexing all mediums in one RTP session 237 Multiple-Source Multiple-Source 238 Endpoint1 Endpoint2 239 +--------+ +--------+ 240 | | Various Transports| | 241 | | | | 242 | |Transport flow1(v1,a1) | 243 SSRC-V1---| |------------------>| |--- SSRC-V2 244 | | | | 245 | |Transport flow2(v2)| | 246 | |<------------------| | 247 | | | | 248 SSRC-A1---| |Transport flow3(a2)| | 249 | |<------------------| +----SSRC-A2 250 | | | | 251 | | | | 252 | | | | 253 +--------+ +--------+ 255 In the figure 3, multiple-source endpoint1 residing outside of the 256 firewall communicates with multiple-source endpoint2 residing inside 257 of the firewall. Unlike one to one communication described in 258 section 3.1, multiple-source endpoint2 multiplexes each medium 259 (i.e.,v2,a2) in separate transports (i.e.,transport flow2,transport 260 flow3)to multiple-source endpoint1 while multiple-source endpoint1 261 multiplexes all mediums(ie.,v1,a1) in one unicast 262 transport(i.e.,transport flow1)to multiple-source endpoint2. 264 4. Discuss 266 The RTCP bandwidth fraction is derived from the media data rate. If 267 audio and video are sent as two separate RTP sessions, they would 268 naturally have different RTCP bandwidth fractions, since the two 269 media types have different rates. 271 However, if audio and video are multiplexed onto a single RTP 272 session, a common session bandwidth would have to be chosen. This 273 common bandwidth will likely be inappropriate for one of the media 274 types, leading to the situation where some media flows use their 275 allocation, while some flows send at a rate that is quite different 276 to the session bandwidth. In the common case, the video sends at the 277 session bandwidth, while the audio flows send at much lower rates. 278 The RTCP bandwidth is derived from the session bandwidth, which means 279 it's appropriate for the video, but is too high for the audio. In 280 the worst case, the audio flows can have more RTCP than video flows, 281 which is very wasteful. Fixing this is potentially difficult, since 282 the session bandwidth concept is baked into all the RTCP timing 283 rules. 285 5. Recommendations 287 Senders and receivers which are not multi-source endpoints are not 288 affected by bandwidth issues associated with multi-source endpoint 289 and should follow RFC3550 timing rules[RFC3550], no special 290 accommodation is required. 292 Senders and receivers which are multi-source endpoints and sending or 293 receiving multiple media types over different transport should be 294 treated in the same way as single source endpoints dealing with 295 multiple streams in the same media type. 297 Senders and receivers which are multi-source endpoints and sending or 298 receiving multiple media types MAY multiplex/demultiplex each media 299 type in separate RTP session or multiplex/demultiplex all media types 300 in one RTP session. The multiplexing/demultiplexing mode to be 301 employed in two directions between senders and receivers should be 302 configurable. It is RECOMMENDED that 304 1. As the default behavior, Senders and receivers use the media 305 bundling mechanism [BUNDLE] in two directions between senders and 306 receivers, i.e., multiplexing/demulplexing separate media types 307 in one RTP session over the same lower layer transport. 309 2. Configuration or local policy on the senders or receivers can 310 override the default Mechanism specified in Option 1 above in one 311 or two direction. Therefore senders and receivers MAY be 312 configured with the different multiplexing mode. 314 3. Dynamic multiplexing negotiation mechanism [BUNDLE] can be used 315 to signal which multiplexing mechanism is used between senders 316 and receivers and override the default mechanism specified in 317 Option 1 and 2 above. The employed multiplexing negotiation 318 mechanism is outside the scope of this document. 320 Multi-source endpoints multiplexing each media type in separate RTP 321 session SHOULD be treated as multiple endpoints for each media type. 323 Editor's Note: It will be useful to discuss why we recommend to have 324 a specific algorithm and see how it works with mixers and translators 325 in the future version. 327 5.1. Choosing RTCP Bandwidth 329 Multi-source endpoint multiplexing multiple media types in the same 330 RTP session SHOULD specify RTCP bandwidth using SDP, in a "b=RS" line 331 or a "b=RR" line rather than choosing 5% of session bandwidth for 332 RTCP bandwidth, especially when audio stream and video stream are 333 sent over the same transport and the media data rate of audio stream 334 is far less than video stream. 336 RTCP bandwidth for video stream MAY still follow RFC3550 337 recommendation, i.e., the fraction of the session bandwidth added for 338 RTCP be fixed at 5%. 340 RTCP bandwidth for video = session bandwidth *5% 342 However given lower bandwidth usage of audio stream, RTCP bandwidth 343 for audio stream is RECOMMENDED to be specified using SDP in a "b=RS" 344 line or a "b=RR" line. 346 RTCP bandwidth for audio stream SHOULD be calculated based on the 347 following formula: 349 RTCP bandwidth for audio = ((audio codec maximum bitrate*20%)+ audio 350 codec maximum bitrate)*5% 352 Here a 20% RTP packet overhead is added to the data rate to calculate 353 the required RTCP bandwidth. 355 5.2. Maintaining the number of session members and senders 357 As described in section 6.2.1 of RFC3550, Calculation of the RTCP 358 packet interval mainly depends upon the number of members. For an 359 endpoint with multiple sources multiplexing all media types in the 360 same RTP session, it is more desirable to set the number of sender 361 for such endpoint as one and the number of receiver as one. However 362 according to RFC3550, each source within such endpoint is considered 363 valid until multiple packets carrying the new SSRC have been 364 received, or until an SDES RTCP packet containing a CNAME for that 365 SSRC has been received. 367 To achieve this, the sender which is multi-source endpoint SHOULD not 368 send Reception reports (e.g., SR/RR RTCP packets) from all local 369 sources to each remote source in the receiving side, Similarly the 370 Receiver which is multi-source endpoint SHOULD not receive reception 371 reports(e.g., SR/RR RTCP packets from each remote source in the 372 sending side to all local sources. Instead, one designated local 373 source from the senders within multi-source endpoint should be chosen 374 as reporting source for other local sources within the sender. 376 When multi-Source endpoints multiplexing each media type in separated 377 RTP session join the session, they SHOULD treated as multiple single- 378 source endpoint multiplexing for each media type and SHOULD be 379 counted as multiple active senders. The number of active senders 380 within multi-source endpoint is decided by the number of local source 381 which is sending reception reports. 383 For the number of session members, it depends on the number of 384 multiple-source endpoints E and the number of local source in each 385 multiple-source endpoint S. It can be estimated or calculated 386 according to the rules in RFC 3550 section 6.2.1, based on received 387 valid SSRC in the SDES packet or RTP packets. 389 5.3. RTCP Reporting Interval calculation 391 The RTCP packet interval calculation SHOULD consider RTCP bandwidth 392 estimation and signaling in section 5.1 and active sender estimation 393 in section 5.2. The RTCP reporting interval for audio stream and 394 video stream should be calculated according to the rules in RFC3550 395 section 6.2 respectively. When RTCP reception reports for audio 396 stream and video stream are sent in different intervals, in order to 397 decrease the number of RTCP packet to be sent, it is more desirable 398 to transmit reception report for audio stream and reception report 399 for video stream in the same compound RTCP packet and set RTCP 400 reporting interval for audio stream as a multiple of RTCP reporting 401 intervals for video stream. 403 For example, if the RTCP Reporting Interval for audio stream is more 404 than one RTCP Reporting Interval for video but less than two RTCP 405 Reporting Intervals for video, it is RECOMMENDED the RTCP Reporting 406 Interval for audio stream be chosen as one RTCP Reporting Interval 407 for video. 409 If the RTCP Reporting Interval for audio stream is more than two RTCP 410 Reporting Intervals for video but less than three RTCP Reporting 411 Intervals for video, it is RECOMMENDED the RTCP Reporting Interval 412 for audio stream be chosen as two RTCP Reporting Intervals for video. 414 If the RTCP Reporting Interval for audio stream is more than three 415 RTCP Reporting Intervals for video but less than four RTCP Reporting 416 Intervals for video, it is RECOMMENDED the RTCP Reporting Interval 417 for audio stream be chosen as three RTCP Reporting Intervals for 418 video. 420 Editor's Note: The problem is not as simple as just varying the RTCP 421 bandwidth fraction for the audio sources in an RTP session. Varying 422 the reporting interval in this way for some participants can lead to 423 timeouts. You'd also need to revise the timeout rules, 424 reconsideration rules, etc. 426 5.4. RTCP reception report 428 Multiple-Source Endpoint SHOULD NOT send reception reports from one 429 of its source about all the other local sources of its own. RTP 430 application SHOULD provide a means to identify multiple-source 431 endpoint as in fact being sources from the same RTP node. 433 Multiple-Source Endpoint SHOULD combine RTCP reception reports into a 434 single compound RTCP packet without exceeding the maximum 435 transmission unit (MTU) of the network path. 437 6. Security Considerations 439 TBC. 441 7. IANA Considerations 443 This document has no actions for IANA. 445 8. References 447 8.1. Normative References 449 [BUNDLE] Holmberg, C. and H. Alvestrand, "Extended RTP Profile for 450 Real-time Transport Control Protocol (RTCP)-Based Feedback 451 (RTP/AVPF)", 452 ID draft-ietf-mmusic-sdp-bundle-negotiation-01, 453 August 2012. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", March 1997. 458 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 459 Applications", RFC 3550, July 2003. 461 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 462 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 463 RFC 3556, July 2003. 465 8.2. Informative References 467 [I-D.ietf-avtcore-multi-media-rtp-session-00] 468 Westerlund, M., "Multiple Media Types in an RTP Session", 469 ID draft-ietf-avtcore-multi-media-rtp-session-00, 470 October 2012. 472 Authors' Addresses 474 Qin Wu 475 Huawei 476 101 Software Avenue, Yuhua District 477 Nanjing, Jiangsu 210012 478 China 480 Email: sunseawq@huawei.com 482 Roni Even 483 Huawei 484 14 David Hamelech 485 Tel, Aviv 64953 486 Israel 488 Email: ron.even.tlv@gmail.com