idnits 2.17.1 draft-ietf-avtcore-mprtp-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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Core Working Group V. Singh 3 Internet-Draft callstats.io 4 Intended status: Experimental T. Karkkainen 5 Expires: January 9, 2017 J. Ott 6 Technical University of Munich 7 S. Ahsan 8 Aalto University 9 L. Eggert 10 NetApp 11 July 8, 2016 13 Multipath RTP (MPRTP) 14 draft-ietf-avtcore-mprtp-03 16 Abstract 18 The Real-time Transport Protocol (RTP) is used to deliver real-time 19 content and, along with the RTP Control Protocol (RTCP), forms the 20 control channel between the sender and receiver. However, RTP and 21 RTCP assume a single delivery path between the sender and receiver 22 and make decisions based on the measured characteristics of this 23 single path. Increasingly, endpoints are becoming multi-homed, which 24 means that they are connected via multiple Internet paths. Network 25 utilization can be improved when endpoints use multiple parallel 26 paths for communication. The resulting increase in reliability and 27 throughput can also enhance the user experience. This document 28 extends the Real-time Transport Protocol (RTP) so that a single 29 session can take advantage of the availability of multiple paths 30 between two endpoints. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 9, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 40 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . 6 72 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6 73 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . 7 75 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8 76 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . 8 77 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9 78 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10 79 7. Available Mechanisms within the Functional Blocks . . . . . . 11 80 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11 82 7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 12 83 7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12 84 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13 85 7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . 13 86 7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14 87 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . 14 88 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 89 8.1.1. Gather or Discovering Candidates . . . . . . . . . . 15 90 8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 15 91 8.1.3. Choosing between In-band (in RTCP) and Out-of-band 92 (in SDP) Interface Advertisement . . . . . . . . . . 16 93 8.1.4. In-band Interface Advertisement . . . . . . . . . . . 16 94 8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17 95 8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17 96 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . 18 97 8.3. Playout Considerations at the Receiver . . . . . . . . . 18 98 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18 99 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19 100 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 101 9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . 19 102 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 21 103 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21 104 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . 23 105 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 25 106 9.3. MPRTCP Extension for Interface advertisement . . . . . . 27 107 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 28 108 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 29 109 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 29 110 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 29 111 11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 30 112 11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 30 113 11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 31 114 11.5.1. In-band Signaling Example . . . . . . . . . . . . . 31 115 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 116 12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . 32 117 12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . 32 118 12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 33 119 12.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . 33 120 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 121 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 122 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 123 15.1. Normative References . . . . . . . . . . . . . . . . . . 35 124 15.2. Informative References . . . . . . . . . . . . . . . . . 36 125 Appendix A. Interoperating with Legacy Applications . . . . . . 37 126 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38 127 B.1. Changes in draft-ietf-avtcore-mprtp-03 . . . . . . . . . 38 128 B.2. Changes in draft-ietf-avtcore-mprtp-01, and -02 . . . . . 38 129 B.3. Changes in draft-ietf-avtcore-mprtp-00 . . . . . . . . . 38 130 B.4. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 38 131 B.5. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 38 132 B.6. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 38 133 B.7. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 39 134 B.8. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 39 135 B.9. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 39 136 B.10. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 39 137 B.11. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 40 138 B.12. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 40 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 141 1. Introduction 143 Multi-homed endpoints are becoming common in today's Internet, e.g., 144 devices that support multiple wireless access technologies such as 3G 145 and Wireless LAN. This means that there is often more than one 146 network path available between two endpoints. Transport protocols, 147 such as RTP, have not been designed to take advantage of the 148 availability of multiple concurrent paths and therefore cannot 149 benefit from the increased capacity and reliability that can be 150 achieved by pooling their respective capacities. 152 Multipath RTP (MPRTP) is an extension to RTP [RFC3550] which splits a 153 single RTP Stream [RFC7656] (At any given point in time, an RTP 154 stream can have one and only one SSRC) into multiple subflows that 155 are transmitted over different network interfaces paths (i.e., 2- out 156 of the 5-tuples are different). In effect, this pools the resource 157 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 158 to RTCP, it is used along with MPRTP to report sender and receiver 159 characteristics for each subflow. 161 Other IETF transport protocols that are capable of using multiple 162 paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533]. 163 However, these protocols are not suitable for real-time 164 communications. 166 1.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 1.2. Terminology 174 o Endpoint: corresponds to a single host either initiating or 175 terminating a communication session [RFC7656]. 177 o Interface: logical or physical component that is capable of 178 acquiring a unique IP address. 180 o Path: sequence of links between a sender and a receiver. 181 Typically, defined by a set of source and destination addresses. 182 In the context of RTP taxonomy [RFC7656] it best matches a media 183 transports. 185 o Multipath RTP Stream: An RTP Stream that makes use of one or more 186 paths, i.e., simultaneously makes use of multiple media transports 187 to send and receive from a particular RTP Stream. In cases, where 188 a single path is available, an MPRTP Stream will appear to be an 189 RTP Stream. 191 o MPRTP Subflow: The RTP packets from a single RTP Stream that are 192 sent or received over a particular media transport are identified 193 as a subflow. Therefore, an MPRTP Stream has several subflows, 194 each subflow is associated to a particular media transport. 196 o Subflow Identifier: within a communication session, the subflow 197 identifier denotes the RTP packets belonging to a RTP Stream sent 198 over a particular media transport. There are two design choices: 200 * Each media transport at an endpoint chooses a unique identifier 201 for itself, and the Subflow RTP Streams use the chosen 202 identifier. 204 * The RTP Stream chooses distinct identifiers for each Subflow 205 RTP stream 207 1.3. Use-cases 209 The primary use-case for MPRTP is transporting high bit-rate 210 streaming multimedia content between endpoints, where at least one is 211 multi-homed. Such endpoints could be residential IPTV devices that 212 connect to the Internet through two different Internet service 213 providers (ISPs), or mobile devices that connect to the Internet 214 through 3G and WLAN interfaces. By allowing a single RTP Stream to 215 use multiple paths for transmission, the following gains can be 216 achieved: 218 o Higher quality: Pooling the resource capacity of multiple Internet 219 paths allows higher bit-rate and higher quality codecs to be used. 220 From the application perspective, the available bandwidth between 221 the two endpoints increases. 223 o Load balancing: Transmitting a single RTP stream (or several RTP 224 streams) over multiple paths reduces the bandwidth usage on each 225 path, which in turn reduces the impact of the media stream(s) on 226 other traffic on those paths. 228 o Fault tolerance: When multiple paths are used in conjunction with 229 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 230 one path have less impact on the overall perceived quality of the 231 media stream. 233 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 234 calls to a device with multiple interfaces. Again, such an endpoint 235 could be a mobile device with multiple wireless interfaces. In this 236 case, little is to be gained from resource pooling, i.e., higher 237 capacity or load balancing, because a single path should be easily 238 capable of handling the required load. However, using multiple 239 concurrent subflows can improve fault tolerance, because traffic can 240 shift between the subflows when path outages occur. This results in 241 very fast transport-layer handovers that do not require support from 242 signaling. 244 2. Goals 246 This section outlines the basic goals that multipath RTP aims to 247 meet. These are broadly classified as Functional goals and 248 Compatibility goals. 250 2.1. Functional goals 252 Allow an unicast RTP Stream to be split into multiple subflows in 253 order to be carried over multiple paths. This may prove beneficial 254 in case of video streaming. 256 o Increased Throughput: Cumulative capacity of the two paths may 257 meet the requirements of the multimedia session. Therefore, MPRTP 258 MUST support concurrent use of the multiple paths. 260 o Improved Reliability: MPRTP SHOULD be able to send redundant 261 packets or re-transmit packets along any available path to 262 increase reliability. 264 The protocol SHOULD be able to open new subflows for an existing 265 multimedia session when new paths appear and MUST be able to close 266 subflows when paths disappear. 268 2.2. Compatibility goals 270 Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream 271 needs to fall back to be compatible with legacy RTP stacks if MPRTP 272 support is not successfully negotiated. 274 o Application Compatibility: MPRTP service model MUST be backwards 275 compatible with existing RTP applications, i.e., an MPRTP stack 276 MUST be able to work with legacy RTP applications and not require 277 changes to them. Therefore, the basic RTP APIs MUST remain 278 unchanged, but an MPRTP stack MAY provide extended APIs so that 279 the application can configure any additional features provided by 280 the MPRTP stack. 282 o Network Compatibility: individual MPRTP subflows MUST themselves 283 be flows of well-formed RTP packets, so that they are able to 284 traverse NATs and firewalls. This MUST be the case even when 285 interfaces appear after session initiation. Interactive 286 Connectivity Establishment (ICE) [RFC5245] MAY be used for 287 discovering new interfaces or performing connectivity checks. 289 3. RTP Topologies 291 RFC 5117 [RFC5117] describes a number of scenarios using mixers and 292 translators in single-party (point-to-point), and multi-party (point- 293 to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x) 294 discuss in detail the impact of mixers and translators on RTP and 295 RTCP packets. MPRTP assumes that if a mixer or translator exists in 296 the network, then either all of the multiple paths or none of the 297 multiple paths go via this component. 299 4. MPRTP Architecture 301 In a typical scenario, an RTP Stream uses a single path. In an MPRTP 302 scenario, an RTP Stream uses multiple subflows, those subflows may 303 each use a different path. Figure 1 shows the difference. 305 +--------------+ Signaling +--------------+ 306 | |------------------------------------>| | 307 | Client |<------------------------------------| Server | 308 | | Single RTP Stream | | 309 +--------------+ +--------------+ 311 +--------------+ Signaling +--------------+ 312 | |------------------------------------>| | 313 | Client |<------------------------------------| Server | 314 | |<------------------------------------| | 315 +--------------+ MPRTP subflows +--------------+ 317 Figure 1: Comparison between traditional RTP streaming and MPRTP 319 +-----------------------+ +-------------------------------+ 320 | Application | | Application | 321 +-----------------------+ +-------------------------------+ 322 | | | RTP | 323 + RTP + +- - - - - - - -+- - - - - - - -+ 324 | | | MPRTP subflow | MPRTP subflow | 325 +-----------------------+ +---------------+---------------+ 326 | UDP | | UDP | UDP | 327 +-----------------------+ +---------------+---------------+ 328 | IP | | IP | IP | 329 +-----------------------+ +---------------+---------------+ 331 Figure 2: MPRTP Architecture 333 Figure 2 illustrates the differences between the standard RTP stack 334 and the MPRTP stack. MPRTP receives a normal RTP Stream from the 335 application and splits it into multiple RTP subflows. Each subflow 336 is then sent along a different path to the receiver. To the network, 337 each subflow appears as an independent flow of well-formed RTP 338 packets. At the receiver, the subflows are combined to recreate the 339 original RTP Stream. The MPRTP layer performs the following 340 functions: 342 o Path Management: The layer is aware of alternate paths to the 343 other host, which may, for example, be the peer's multiple 344 interfaces. This enables the endpoint to transmit differently 345 marked packets along separate paths. MPRTP also selects 346 interfaces to send and receive data. Furthermore, it manages the 347 port and IP address pair bindings for each subflow. 349 o Packet Scheduling: the layer splits a single RTP Stream into 350 multiple subflows and sends them across multiple interfaces 351 (paths). The splitting MAY BE done using different path 352 characteristics. 354 o Subflow recombination: the layer creates the original RTP stream 355 by recombining the independent subflows associated with the RTP 356 Stream. Therefore, the subflows are eventually presented as a 357 single RTP stream to the applications. 359 5. Example Media Flow Diagrams 361 There may be many complex technical scenarios for MPRTP, however, 362 this memo only considers the following two scenarios: 1) a 363 unidirectional media stream that represents the streaming use-case, 364 and 2) a bidirectional media stream that represents a conversational 365 use-case. 367 5.1. Streaming use-case 369 In the unidirectional scenario, the receiver (client) initiates a 370 multimedia session with the sender (server). The receiver or the 371 sender may have multiple interfaces and both endpoints are MPRTP- 372 capable. Figure 3 shows this scenario. In this case, host A has 373 multiple interfaces. Host B performs connectivity checks on host A's 374 multiple interfaces. If the interfaces are reachable, then host B 375 streams multimedia data along multiple paths to host A. Moreover, 376 host B also Sends RTCP Sender Reports (SR) for the overall session 377 and for each subflow and host A responds with a normal RTCP Receiver 378 Report (RR) for the overall session as well as the receiver 379 statistics for each subflow. Host B distributes the packets across 380 the subflows based on the individually measured path characteristics. 382 Alternatively, to reduce media startup time, host B may start 383 streaming multimedia data to host A's initiating interface and then 384 perform connectivity checks for the other interfaces. This method of 385 updating a single path session to a multipath session is called 386 "multipath session upgrade". 388 Host A Host B 389 ----------------------- ---------- 390 Interface A1 Interface A2 Interface B1 391 ----------------------- ---------- 392 | | 393 |------------------------------------->| Session setup with 394 |<-------------------------------------| multiple interfaces 395 | | | 396 | | | 397 | (RTP data B1->A1, B1->A2) | 398 |<=====================================| 399 | |<========================| 400 | | | 401 Note: there may be more scenarios. 403 Figure 3: Unidirectional media flow 405 5.2. Conversational use-case 407 In the bidirectional scenario, multimedia data flows in both 408 directions. The two hosts exchange their lists of interfaces with 409 each other and perform connectivity checks. Communication begins 410 after each host finds suitable address, port pairs. Interfaces that 411 receive data send back RTCP receiver statistics for that path (based 412 on the 5-tuple). The hosts balance their multimedia stream across 413 multiple paths based on the per path reception statistics and its own 414 volume of traffic. Figure 4 describes an example of a bidirectional 415 flow. 417 Host A Host B 418 --------------------------- --------------------------- 419 Interface A1 Interface A2 Interface B1 Interface B2 420 --------------------------- --------------------------- 421 | | | | 422 | | | |Session setup 423 |----------------------------------->| |with multiple 424 |<-----------------------------------| |interfaces 425 | | | | 426 | | | | 427 | (RTP data B1<->A1, B2<->A2) | | 428 |<===================================| | 429 | |<===================================| 430 |===================================>| | 431 | |===================================>| 432 | | | | 433 Note: the address pairs may have other permutations, 434 and they may be symmetric or asymmetric combinations. 436 Figure 4: Bidirectional flow 438 6. MPRTP Functional Blocks 440 This section describes some of the functional blocks needed for 441 MPRTP. We then investigate each block and consider available 442 mechanisms in the next section. 444 1. Session Setup: Interfaces may appear or disappear at anytime 445 during the communication session. To preserve backward 446 compatibility with legacy applications, a MPRTP session MUST look 447 like a bundle of individual RTP sessions. A MPRTP session may 448 start using a single path, later start using multiple paths as 449 and when new interfaces appear or disappear. However, it is also 450 possible to setup a MPRTP session from the beginning, if multiple 451 interfaces are available at the start of the multimedia session. 453 2. Expanding RTP: For a MPRTP Stream, each subflow MUST look like an 454 independent flow of RTP packets, so that individual RTCP messages 455 can be generated for each subflow. Consequently, MPRTP may split 456 the RTP Stream into multiple subflows based on path 457 characteristics (e.g. RTT, fractional losses, receiver rate, 458 bandwidth-delay product, etc.), i.e., dynamically adjusts the 459 load on each subflow. 461 3. Adding Interfaces: Interfaces on the host need to be regularly 462 discovered and advertised. This can be done when the MPRTP 463 session is set up and/or during the communication session. 464 Discovering interfaces is outside the scope of this document. 466 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 467 monitoring the quality of the path, for load balancing, or for 468 congestion control, etc. To maintain backward compatibility with 469 legacy applications, the receiver MUST also send aggregate RTCP 470 reports along with the per-path reports. 472 5. Maintenance and Failure Handling: In a multi-homed endpoint 473 interfaces may appear and disappear. If this occurs at the 474 sender, it has to re-adjust the load on the available paths. On 475 the other hand, if this occurs at the receiver, then the 476 multimedia data transmitted by the sender to those interfaces is 477 lost. This data may be re-transmitted along a different path 478 i.e., to a different interface on the receiver. Furthermore, the 479 endpoint has to either explicitly signal the disappearance of an 480 interface, or the other endpoint has to detect it (by lack of 481 media packets, RTCP feedback, or keep-alive packets). 483 6. Teardown: The MPRTP layer releases the occupied ports on the 484 interfaces. 486 7. Available Mechanisms within the Functional Blocks 488 This section discusses some of the possible alternatives for each 489 functional block mentioned in the previous section. 491 7.1. Session Setup 493 MPRTP session can be set up in many possible ways e.g., during 494 handshake, or upgraded mid-session. The capability exchange may be 495 done using out-of-band signaling (e.g., Session Description Protocol 496 (SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real- 497 Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in- 498 band signaling (e.g., RTP/RTCP header extension, Session Traversal 499 Utilities for NAT (STUN) messages). 501 [Editor's Note: , with continuous ICE Nomination.] 503 7.1.1. Connectivity Checks 505 The endpoint SHOULD be capable of performing connectivity checks 506 (e.g., using ICE [RFC5245]). If the IP addresses of the endpoints 507 are reachable (e.g., globally addressable, same network etc) then 508 connectivity checks are not needed. 510 7.1.2. Adding New or Updating Interfaces 512 Interfaces can appear and disappear during a MPRTP session, the 513 endpoint MUST be capable of advertising the changes in its set of 514 usable interfaces. Additionally, the application or OS may define a 515 policy on when and/or what interfaces are usable. However, MPRTP 516 requires a method to advertise or notify the other endpoint about the 517 updated set of usable interfaces. 519 7.1.3. In-band vs. Out-of-band Signaling 521 MPRTP nodes will generally use a signaling protocol to establish 522 their MPRTP session. With the existence of such a signaling 523 relationship, two alternatives become available to exchange 524 information about the available interfaces on each side for extending 525 RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and 526 out-of-band signaling. 528 In-band signaling refers to using mechanisms of RTP/RTCP itself to 529 communicate interface addresses, e.g., a dedicated RTCP extensions 530 along the lines of the one defined to communicate information about 531 the feedback target for RTP over SSM [RFC5760]. In-band signaling 532 does not rely on the availability of a separate signaling connection 533 and the information flows along the same path as the media streams, 534 thus minimizing dependencies. Moreover, if the media channel is 535 secured (e.g., by means of SRTP), the signaling is implicitly 536 protected as well if SRTCP encryption and authentication are chosen. 537 In-band signaling is also expected to take a direct path to the peer, 538 avoiding any signaling overlay-induced indirections and associated 539 processing overheads in signaling elements -- avoiding such may be 540 especially worthwhile if frequent updates may occur as in the case of 541 mobile users. Finally, RTCP is usually sent sufficiently frequently 542 (in point-to-point settings) to provide enough opportunities for 543 transmission and (in case of loss) retransmission of the 544 corresponding RTCP packets. 546 Examples for in-band signaling include RTCP extensions as noted above 547 or suitable extensions to STUN [I-D.wing-mmusic-ice-mobility]. 549 Out-of-band signaling refers to using a separate signaling connection 550 (via SIP, RTSP, or HTTP) to exchange interface information, e.g., 551 expressed in SDP. Clear benefits are that signaling occurs at setup 552 time anyway and that experience and SDP syntax (and procedures) are 553 available that can be re-used or easily adapted to provide the 554 necessary capabilities. In contrast to RTCP, SDP offers a reliable 555 communication channel so that no separate retransmissions logic is 556 necessary. In SDP, especially when combined with ICE, connectivity 557 check mechanisms including sophisticated rules are readily available. 559 While SDP is not inherently protected, suitable security may need to 560 be applied anyway to the basic session setup. 562 Examples for out-of-band signaling are dedicated extensions to SDP; 563 those may be combined with ICE. 565 Both types of mechanisms have their pros and cons for middleboxes. 566 With in-band signaling, control packets take the same path as the 567 media packets and they can be directly inspected by middleboxes so 568 that the elements operating on the signaling channel do not need to 569 understand new SDP. With out-of-band signaling, only the middleboxes 570 processing the signaling need to be modified and those on the data 571 forwarding path can remain untouched. 573 Overall, it may appear sensible to provide a combination of both 574 mechanisms: out-of-band signaling for session setup and initial 575 interface negotiation and in-band signaling to deal with frequent 576 changes in interface state (and for the potential case, albeit rather 577 theoretical case of MPRTP communication without a signaling channel). 579 In its present version, this document explores both options to 580 provide a broad understanding of how the corresponding mechanisms 581 would look like. 583 7.2. Expanding RTP 585 RTCP [RFC3550] is generated per media session. However, with MPRTP, 586 the media sender spreads the RTP load across several interfaces. The 587 media sender SHOULD make the path selection, load balancing and fault 588 tolerance decisions based on the characteristics of each path. 589 Therefore, apart from normal RTP sequence numbers defined in 590 [RFC3550], the MPRTP sender MUST add the following within the SSRC 591 scope, subflow-specific sequence numbers to help calculate fractional 592 losses, jitter, RTT, playout time, etc., for each subflow, and a 593 subflow identifier to associate the characteristics with a path. The 594 RTP header extension for MPRTP is shown in Section 9.1. 596 7.3. Expanding RTCP 598 To provide accurate per path information an MPRTP endpoint MUST send 599 (SR/RR) report for each unique subflow along with the overall session 600 RTCP report. Therefore, the additional subflow reporting affects the 601 RTCP bandwidth and the RTCP reporting interval. RTCP report 602 scheduling for each subflow may cause a problem for RTCP 603 recombination and reconstruction in cases when 1) RTCP for a subflow 604 is lost, and 2) RTCP for a subflow arrives later than the other 605 subflows. (There may be other cases as well.) 606 The sender distributes the media across different paths using the per 607 path RTCP reports. However, this document doesn't cover algorithms 608 for congestion control or load balancing. 610 7.4. Failure Handling and Teardown 612 An MPRTP endpoint MUST keep alive subflows that have been negotiated 613 but no media is sent on them. Moreover, using the information in the 614 subflow reports, a sender can monitor an active subflow for failure 615 (errors, unreachability, congestion) and decide not to use (make the 616 active subflow passive), or teardown the subflow. 618 If an interface disappears, the endpoint MUST send an updated 619 interface advertisement without the interface and release the 620 associated subflows. 622 8. MPRTP Protocol 624 Host A Host B 625 ----------------------- ----------------------- 626 Interface A1 Interface A2 Interface B1 Interface B2 627 ----------------------- ----------------------- 628 | | | | 629 | | (1) | | 630 |--------------------------------------->| | 631 |<---------------------------------------| | 632 | | (2) | | 633 |<=======================================| | 634 |<=======================================| (3) | 635 | | (4) | | 636 |<- - - - - - - - - - - - - - - - - - - -| | 637 |<- - - - - - - - - - - - - - - - - - - -| | 638 |<- - - - - - - - - - - - - - - - - - - -| | 639 | | (5) | | 640 |- - - - - - - - - - - - - - - - - - - ->| | 641 |<=======================================| (6) | 642 |<=======================================| | 643 | |<========================================| 644 |<=======================================| | 645 | |<========================================| 647 Key: 648 | Interface 649 ---> Signaling Protocol 650 <=== RTP Packets 651 - -> RTCP Packet 653 Figure 5: MPRTP New Interface 655 8.1. Overview 657 The bullet points explain the different steps shown in Figure 5 for 658 upgrading a single path multimedia session to multipath session. 660 (1) The first two interactions between the hosts represents the 661 establishment of a normal RTP session. This may performed e.g. 662 using SIP or RTSP. 664 (2) When the RTP session has been established, host B streams 665 media using its interface B1 to host A at interface A1. 667 (3) Host B supports sending media using MPRTP and becomes aware of 668 an additional interface B2. 670 (4) Host B advertises the multiple interface addresses. 672 (5) Host A supports receiving media using MPRTP and becomes aware 673 of an additional interface A2. 675 Side note, even if an MPRTP-capable host has only one interface, 676 it MUST respond to the advertisement with its single interface. 678 (6) Each host receives information about the additional interfaces 679 and the appropriate endpoints starts to stream the multimedia 680 content using the additional paths. 682 If needed, each endpoint will need to independently perform 683 connectivity checks (not shown in figure) and ascertain 684 reachability before using the paths. 686 8.1.1. Gather or Discovering Candidates 688 The endpoint periodically polls the operating system or is notified 689 when an additional interface appears. If the endpoint wants to use 690 the additional interface for MPRTP it MUST advertise it to the other 691 peers. The endpoint may also use ICE [RFC5245] to gather additional 692 candidates. 694 8.1.2. NAT Traversal 696 After gathering their interface candidates, the endpoints decide 697 internally if they wish to perform connectivity checks. 699 [note-iceornot] 701 If the endpoint chooses to perform connectivity checks then it MUST 702 first advertise the gathered candidates as ICE candidates in SDP 703 during session setup and let ICE perform the connectivity checks. As 704 soon as a sufficient number of connectivity checks succeed, the 705 endpoint can use the successful candidates to advertise its MPRTP 706 interface candidates. 708 Alternatively, if the endpoint supports mobility extensions for ICE 709 [I-D.wing-mmusic-ice-mobility], it can let the ICE agent gather and 710 perform the connectivity checks. When the connectivity checks 711 succeed, the ICE agent should notify the MPRTP layer of these new 712 paths (5-tuples), these new paths are then used by MPRTP to send 713 media packets depending on the scheduling algorithm. 715 If an endpoint supports Interface selection via PCP Flow Extension 716 [I-D.reddy-mmusic-ice-best-interface-pcp], it will receive 717 notifications when new interfaces become available and additionally 718 when the link quality of a currently available interface changes. 719 The application can advertise and perform connectivity checks with 720 the new interface and in the case of changes in link quality pass the 721 information to the scheduling algorithm for better application 722 performance. 724 [Editors note: The interaction between the RTP agent and ICE agent is 725 needed for implementing a scheduling algorithm or congestion control. 726 See details of a scheduling algorithm in [ACM-MPRTP].] 728 8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP) 729 Interface Advertisement 731 If there is no media flowing at the moment and the application wants 732 to use the interfaces from the start of the communication session, it 733 should advertise them in SDP (See 734 [I-D.singh-mmusic-mprtp-sdp-extension]). Alternatively, the endpoint 735 can setup the session as a single path communication session and 736 upgrade the session to multipath by advertising the session in-band 737 (See Section 8.1.4 or [I-D.wing-mmusic-ice-mobility]). Moreover, if 738 an interface appears and disappears, the endpoint SHOULD prefer to 739 advertise it in-band because the endpoint would not have to wait for 740 a response from the other endpoint before starting to use the 741 interface. However, if there is a conflict between an in-band and 742 out-of-band advertisement, i.e., the endpoint receives an in-band 743 advertisement while it has a pending out-of-band advertisement, or 744 vice versa then the session is setup using out-of-band mechanisms. 746 8.1.4. In-band Interface Advertisement 748 To advertise the multiple interfaces in RTCP, an MPRTP-capable 749 endpoint SHOULD add the MPRTP Interface Advertisement defined in 750 Figure 13 with an RTCP Sender Report (SR) or RTCP Receiver Report 751 (RR). If reduced-size [RFC5506] RTCP is used, the interface 752 advertisements can be sent separately depending on the RTCP timing 753 rules. 755 Each unique address is encapsulated in an Interface Advertisement 756 block and contains the IP address, RTP port addresses. The Interface 757 Advertisement blocks are ordered based on a decreasing priority 758 level. On receiving the MPRTP Interface Advertisement, an MPRTP- 759 capable receiver MUST respond with the set of interfaces (subset or 760 all available) it wants to use. 762 If the sender and receiver have only one interface, then the 763 endpoints MUST indicate the negotiated single path IP, RTP port 764 addresses. 766 [Editor: Do we still need this: could use passive/aggressive 767 nomination? or perform an ice restart?] 769 8.1.5. Subflow ID Assignment 771 After interface advertisements have been exchanged, the endpoint MUST 772 associate a Subflow ID to each unique subflow. Each combination of 773 sender and receiver IP addresses and port pairs (5-tuple) is a unique 774 subflow. If the connectivity checks have been performed then the 775 endpoint MUST only use the subflows for which the connectivity checks 776 have succeeded. 778 8.1.6. Active and Passive Subflows 780 To send and receive data an endpoint MAY use any number of subflows 781 from the set of available subflows. The subflows that carry media 782 data are called active subflows, while those subflows that don't send 783 any media packets (fallback paths) are called passive subflows. 785 An endpoint MUST multiplex the subflow specific RTP and RTCP packets 786 on the same port to keep the NAT bindings alive. This is inline with 787 the recommendation made in RFC6263[RFC6263]. Moreover, if an 788 endpoint uses ICE, multiplexing RTP and RTCP reduces the number of 789 components from 2 to 1 per media stream. If no MPRTP or MPRTCP 790 packets are received on a particular subflow at a receiver, the 791 receiver SHOULD remove the subflow from active and passive lists and 792 not send any MPRTCP reports for that subflow. It may keep the 793 bindings in a dead-pool, so that if the 5-tuple or subflow reappears, 794 it can quickly reallocate it based on past history. 796 8.2. RTP Transmission 798 If both endpoints are MPRTP-capable and if they want to use their 799 multiple interfaces for sending the media stream then they MUST use 800 the MPRTP header extensions. They MAY use normal RTP with legacy 801 endpoints (see Appendix A). 803 An MPRTP endpoint sends RTP packets with an MPRTP extension that maps 804 the media packet to a specific subflow (see Figure 8). The MPRTP 805 layer SHOULD associate an RTP packet with a subflow based on a 806 scheduling strategy. The scheduling strategy may either choose to 807 augment the paths to create higher throughput or use the alternate 808 paths for enhancing resilience or error-repair. Due to the changes 809 in path characteristics, the endpoint should be able to change its 810 scheduling strategy during an ongoing session. The MPRTP sender MUST 811 also populate the subflow specific fields described in the MPRTP 812 extension header (see Section 9.1.1). 814 [ACM-MPRTP] describes and evaluates a scheduling algorithm for video 815 over multiple interfaces. The video is encoded at a single target 816 bit rate and is evaluated in various network scenarios, as discussed 817 in [I-D.ietf-rmcat-eval-criteria]. 819 8.3. Playout Considerations at the Receiver 821 A media receiver, irrespective of MPRTP support or not, should be 822 able to playback the media stream because the received RTP packets 823 are compliant to [RFC3550], i.e., a non-MPRTP receiver will ignore 824 the MPRTP header and still be able to playback the RTP packets. 825 However, the variation of jitter and loss per path may affect proper 826 playout. The receiver can compensate for the jitter by modifying the 827 playout delay (i.e., by calculating skew across all paths) of the 828 received RTP packets. For example, an adaptive playout algorithm is 829 discussed in [ACM-MPRTP]. 831 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 833 Aggregate RTCP provides the overall media statistics and follows the 834 normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific 835 RTCP provides the per path media statistics because the aggregate 836 RTCP report may not provide sufficient per path information to an 837 MPRTP scheduler. Specifically, the scheduler should be aware of each 838 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 840 The aggregate RTCP report (i.e., the regularly scheduled RTCP report) 841 MUST be sent compounded as described in [RFC5506], however, the 842 subflow-specific RTCP reports MAY be sent non-compounded (reduced- 843 size). Further, each subflow and the aggregate RTCP report MUST 844 follow the timing rules defined in [RFC4585]. 846 The RTCP reporting interval is locally implemented and the scheduling 847 of the RTCP reports may depend on the behavior of each path. For 848 instance, the RTCP interval may be different for a passive path than 849 an active path to keep port bindings alive. Additionally, an 850 endpoint may decide to share the RTCP reporting bit rate equally 851 across all its paths or schedule based on the receiver rate on each 852 path. 854 8.5. RTCP Transmission 856 The sender sends an RTCP Subflow SR (SSR) on each active path. For 857 each SR the receiver gets, it echoes one back to the same IP address- 858 port pair that sent the SR. The receiver tries to choose the 859 symmetric path and if the routing is symmetric then the per-path RTT 860 calculations will work out correctly. However, even if the paths are 861 not symmetric, the sender would at maximum, under-estimate the RTT of 862 the path by a factor of half of the actual path RTT. 864 9. Packet Formats 866 In this section we define the protocol structures described in the 867 previous sections. 869 9.1. RTP Header Extension for MPRTP 871 The MPRTP header extension is used to distribute a single RTP stream 872 over multiple subflows. 874 The header conforms to the one-byte RTP header extension defined in 875 [RFC5285]. The header extension contains a 16-bit length field that 876 counts the number of 32-bit words in the extension, excluding the 877 four-octet extension header (therefore zero is a valid length, see 878 Section 5.3.1 of [RFC3550] for details). 880 The RTP header for each subflow is defined below: 882 0 1 2 3 883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 |V=2|P|1| CC |M| PT | sequence number | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | timestamp | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | synchronization source (SSRC) identifier | 890 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 891 | 0xBE | 0xDE | length=N-1 | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | ID | LEN | MPID |LENGTH | MPRTP header data | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 895 | .... | 896 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 897 | RTP payload | 898 | .... | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Figure 6: Generic MPRTP header extension 903 MPID: 905 The MPID field corresponds to the type of MPRTP packet. 906 Namely: 908 +---------------+--------------------------------------------------+ 909 | MPID ID | Use | 910 | Value | | 911 +---------------+--------------------------------------------------+ 912 | 0x0 | Subflow RTP Header. For this case the Length is | 913 | | set to 4 | 914 +---------------+--------------------------------------------------+ 916 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 918 Length 920 The 4-bit length field is the length of extension data in bytes 921 not including the H-Ext ID and length fields. The value zero 922 indicates there is no data following. 924 MPRTP header data 926 Carries the MPID specific data as described in the following 927 sub-sections. 929 9.1.1. MPRTP RTP Extension for a Subflow 931 The RTP header for each subflow is defined below: 933 0 1 2 3 934 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 |V=2|P|1| CC |M| PT | sequence number | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | timestamp | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | synchronization source (SSRC) identifier | 941 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 942 | 0xBE | 0xDE | length=2 | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | ID | LEN=4 | 0x0 | LEN=4 | Subflow ID | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 947 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 948 | RTP payload | 949 | .... | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Figure 8: MPRTP header for subflow 954 MP ID = 0x0 956 Indicates that the MPRTP header extension carries subflow 957 specific information. 959 Length = 4 961 Subflow ID: Identifier of the subflow. Every RTP packet belonging 962 to the same subflow carries the same unique subflow identifier. 964 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 965 the subflow. Each subflow has its own strictly monotonically 966 increasing sequence number space. 968 9.2. RTCP Extension for MPRTP (MPRTCP) 970 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 971 per subflow to determine the characteristics of each path, and 2) 972 advertise each interface. 974 0 1 2 3 975 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | SSRC of packet sender | 980 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 981 | SSRC_1 (SSRC of first source) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | MPRTCP_Type | block length | | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP Reports | 985 | ... | 986 | ... | 987 | ... | 988 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 990 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 991 normal SR/RR] 993 MPRTCP: 8 bits 995 Contains the constant 211 to identify this as an Multipath RTCP 996 packet. 998 encaps_length: 16 bits 1000 As described for the RTCP packet (see Section 6.4.1 of the RTP 1001 specification [RFC3550]), the length of this is in 32-bit words 1002 minus one, including the header and any padding. 1004 The encaps_length covers all MPRTCP_Type report blocks included 1005 within this report. 1007 MPRTCP_Type: 8-bits 1009 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 1010 packet. Namely: 1012 +---------------+--------------------------------------------------+ 1013 | MPRTCP_Type | Use | 1014 | Value | | 1015 +---------------+--------------------------------------------------+ 1016 | 0 | Subflow Specific Report | 1017 | 1 | Interface Advertisement (IPv4 Address) | 1018 | 2 | Interface Advertisement (IPv4 Address) | 1019 | 3 | Interface Advertisement (DNS Address) | 1020 +---------------+--------------------------------------------------+ 1022 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 1024 block length: 8-bits 1026 The 8-bit length field is the length of the encapsulated MPRTCP 1027 reports in 32-bit word length (i.e., length * 4 bytes) 1028 including the MPRTCP_Type and length fields. The value zero is 1029 invalid and the report block MUST be ignored. 1031 MPRTCP Reports: variable size 1033 Defined later in 9.2.1 and 9.3. 1035 9.2.1. MPRTCP Extension for Subflow Reporting 1037 When sending a report for a specific subflow the sender or receiver 1038 MUST add only the reports associated with that 5-tuple. Each subflow 1039 is reported independently using the following MPRTCP Feedback header. 1041 0 1 2 3 1042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | SSRC of packet sender | 1047 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1048 | SSRC_1 (SSRC of first source) | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Subflow-specific reports | 1053 | .... | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Subflow-specific reports | 1058 | .... | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 Figure 11: MPRTCP Subflow Reporting Header 1063 MPRTCP_Type: 0 1065 The value indicates that the encapsulated block is a subflow 1066 report. 1068 block length: 8-bits 1070 The 8-bit length field is the length of the encapsulated subflow- 1071 specific reports in 32-bit word length not including the 1072 MPRTCP_Type and length fields. 1074 Subflow ID: 16 bits 1076 Subflow identifier is the value associated with the subflow the 1077 endpoint is reporting about. If it is a sender it MUST use the 1078 Subflow ID associated with the 5-tuple. If it is a receiver it 1079 MUST use the Subflow ID received in the Subflow-specific Sender 1080 Report. 1082 Subflow-specific reports: variable 1084 Subflow-specific report contains all the reports associated with 1085 the Subflow ID. For a sender, it MUST include the Subflow- 1086 specific Sender Report (SSR). For a receiver, it MUST include 1087 Subflow-specific Receiver Report (SRR). Additionally, if the 1088 receiver supports subflow-specific extension reports then it MUST 1089 append them to the SRR. 1091 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 1093 [note-rtcp-reuse] 1095 Example: 1097 0 1 2 3 1098 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | SSRC of packet sender | 1103 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1104 | SSRC_1 (SSRC of first source) | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1107 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1108 |V=2|P| RC | PT=SR=200 | length | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | SSRC of sender | 1111 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1112 | NTP timestamp, most significant word | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | NTP timestamp, least significant word | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | RTP timestamp | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | subflow's packet count | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | subflow's octet count | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1123 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1124 |V=2|P| RC | PT=RR=201 | length | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | SSRC of packet sender | 1127 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1128 | fraction lost | cumulative number of packets lost | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | extended highest sequence number received | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | inter-arrival jitter | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | last SR (LSR) | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | delay since last SR (DLSR) | 1137 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1138 | Subflow specific extension reports | 1139 | .... | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1143 (Bi-directional use-case, in case of uni-directional flow the subflow 1144 will only send an SR or RR). 1146 9.3. MPRTCP Extension for Interface advertisement 1148 This sub-section defines the RTCP header extension for in-band 1149 interface advertisement by the receiver. The interface advertisement 1150 block describes a method to represent IPv4, IPv6 and generic DNS-type 1151 addresses in a block format. It is based on the sub-reporting block 1152 in [RFC5760]. The interface advertisement SHOULD immediately follow 1153 the Receiver Report. If the Receiver Report is not present, then it 1154 MUST be appended to the Sender Report. 1156 The endpoint MUST advertise the interfaces it wants to use whenever 1157 an interface appears or disappears and also when it receives an 1158 Interface Advertisement. 1160 0 1 2 3 1161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | SSRC of packet sender | 1166 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1167 | SSRC_1 (SSRC of first source) | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | MPRTCP_Type | block length | RTP Port | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Interface Address #1 | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | MPRTCP_Type | block length | RTP Port | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Interface Address #2 | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | MPRTCP_Type | block length | RTP Port | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Interface Address #.. | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | MPRTCP_Type | block length | RTP Port | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Interface Address #m | 1184 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1186 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1188 MPRTCP_Type: 8 bits 1190 The MPRTCP_Type corresponds to the type of interface address. 1191 Namely: 1193 1: IPv4 address 1194 2: IPv6 address 1196 3: DNS name 1198 block length: 8 bits 1200 The length of the Interface Advertisement block in 32-bit word 1201 lengths. 1203 For an IPv4 address, this should be 2 (8 octets including = 1204 2 + 2 + 4). 1206 For an IPv6 address, this should be 5 (20 octets = 2 +2 + 1207 16). 1209 For a DNS name, the length field indicates the number of 1210 word lengths making up the address string plus 1 (32-bit 1211 word for the 2 byte port number and 2 byte header). 1213 RTP Port: 2 octets 1215 The port number to which the sender sends RTP data. A port 1216 number of 0 is invalid and MUST NOT be used. 1218 Interface Address: 4 octets (IPv4), 16 octets (IPv6), or n octets 1219 (DNS name) 1221 The address to which receivers send feedback reports. For IPv4 1222 and IPv6, fixed-length address fields are used. A DNS name is 1223 an arbitrary-length string. The string MAY contain 1224 Internationalizing Domain Names in Applications (IDNA) domain 1225 names and MUST be UTF-8 [RFC3629] encoded. 1227 10. RTCP Timing reconsiderations for MPRTCP 1229 MPRTP endpoints MUST conform to the timing rule imposed in [RFC4585], 1230 i.e., the total RTCP rate between the participants MUST NOT exceed 5% 1231 of the media rate. For each endpoint, a subflow MUST send the 1232 aggregate and subflow-specific report. The endpoint SHOULD schedule 1233 the RTCP reports for the active subflows based on the share of the 1234 transmitted or received bit rate to the average media bit rate, this 1235 method ensures fair sharing of the RTCP bandwidth. Alternatively, 1236 the endpoint MAY schedule the reports in round-robin. 1238 11. SDP Considerations 1240 11.1. Signaling MPRTP Header Extension in SDP 1242 To indicate the use of the MPRTP header extensions (see Section 9) in 1243 SDP, the sender MUST use the following URI in extmap: 1244 urn:ietf:params:rtp-hdrext:mprtp. This is a media level parameter. 1245 Legacy RTP (non-MPRTP) clients will ignore this header extension, but 1246 can continue to parse and decode the packet (see Appendix A). 1248 Example: 1250 v=0 1251 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1252 s= 1253 c=IN IP4 192.0.2.1 1254 t=0 0 1255 m=video 49170 RTP/AVP 98 1256 a=rtpmap:98 H264/90000 1257 a=fmtp:98 profile-level-id=42A01E; 1258 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1260 11.2. Signaling MPRTP capability in SDP 1262 A participant of a media session MUST use SDP to indicate that it 1263 supports MPRTP. Not providing this information will make the other 1264 endpoint ignore the RTCP extensions. 1266 mprtp-attrib = "a=" "mprtp" [ 1267 SP mprtp-optional-parameter] 1268 CRLF ; flag to enable MPRTP 1270 The endpoint MUST use 'a=mprtp', if it is able to send and receive 1271 MPRTP packets. Generally, senders and receivers MUST indicate this 1272 capability if they support MPRTP and would like to use it in the 1273 specific media session being signaled. To exchange the additional 1274 interfaces, the endpoint SHOULD use the in-band signaling (See 1275 Section 9.3). Alternatively, advertise in SDP (See 1276 [I-D.singh-mmusic-mprtp-sdp-extension]). 1278 MPRTP endpoint multiplexes RTP and RTCP on a single port, sender MUST 1279 indicate support by adding "a=rtcp-mux" in SDP [RFC5761]. If an 1280 endpoint receives an SDP without "a=rtcp-mux" but contains "a=mprtp", 1281 then the endpoint MUST infer support for multiplexing. 1283 MPRTP endpoint uses Reduced-Size RTCP [RFC5506] for reporting path 1284 characterisitcs per subflow (MPRTCP). An MPRTP endpoint MUST 1285 indicate support by adding "a=rtcp-rsize" in SDP [RFC5761]. If an 1286 endpoint receives an "a=rtcp-rsize" but contains "a=mprtp", then the 1287 endpoint MUST infer support for Reduced-Size RTCP. 1289 [note-rtp-rtcp-mux] 1291 11.3. MPRTP with ICE 1293 If the endpoints intend to use ICE [RFC5245] for discovering 1294 interfaces and running connectivity checks then the endpoint MUST 1295 advertise its ICE candidates in the initial OFFER, as defined in ICE 1296 [RFC5245]. Thereafter the endpoints run connectivity checks. 1298 When an endpoint uses ICE's regular nomination [RFC5245] procedure, 1299 it chooses the best ICE candidate as the default path. In the case 1300 of an MPRTP endpoint, if more than one ICE candidate succeeded the 1301 connectivity checks then an MPRTP endpoint MAY advertise (some of) 1302 these in-band in RTCP as MPRTP interfaces. 1304 When an endpoint uses ICE's aggressive nomination [RFC5245] 1305 procedure, the selected candidate may change as more ICE checks 1306 complete. Instead of sending updated offers as additional ICE 1307 candidates appear (transience), the endpoint it MAY use in-band 1308 signaling to advertise its interfaces, as defined in Section 9.3. 1310 If the default interface disappears and the paths used for MPRTP are 1311 different from the one in the c= and m= lines then the an alternate 1312 interface for which the ICE checks were successful should be promoted 1313 to the c= and m= lines in the updated offer. 1315 When a new interface appears then the application/endpoint should 1316 internally decide if it wishes to use it and sends an updated offer 1317 with ICE candidates of the all its interfaces including the new 1318 interface. The receiving endpoint responds to the offer with all its 1319 ICE candidates in the answer and starts connectivity checks between 1320 all its candidates and the offerer's ICE candidates. Similarly, the 1321 initiating endpoint starts connectivity checks between the its 1322 interfaces (incl. the new interface) and all the received ICE 1323 candidates in the answer. If the connectivity checks succeed, the 1324 initiating endpoint MAY use in-band signaling (See Section 9.3) to 1325 advertise its new set of interfaces. 1327 11.4. Increased Throughput 1329 The MPRTP layer MAY choose to augment paths to increase throughput. 1330 If the desired media rate exceeds the current media rate, the 1331 endpoints MUST renegotiate the application specific ("b=AS:xxx") 1332 [RFC4566] bandwidth. 1334 11.5. Offer/Answer 1336 When SDP [RFC4566] is used to negotiate MPRTP sessions following the 1337 offer/answer model [RFC3264], the "a=mprtp" attribute (see 1338 Section 11.2) indicates the desire to use multiple interfaces to send 1339 or receive media data. The initial SDP offer MUST include this 1340 attribute at the media level. If the answerer wishes to also use 1341 MPRTP, it MUST include a media-level "a=mprtp" attribute in the 1342 answer. If the answer does not contain an "a=mprtp" attribute, the 1343 offerer MUST NOT stream media over multiple paths and the offerer 1344 MUST NOT advertise additional MPRTP interfaces in-band or out-of- 1345 band. 1347 When SDP is used in a declarative manner, the presence of an 1348 "a=mprtp" attribute signals that the sender can send or receive media 1349 data over multiple interfaces. The receiver SHOULD be capable to 1350 stream media to the multiple interfaces and be prepared to receive 1351 media from multiple interfaces. 1353 The following sections shows examples of SDP offer and answer for in- 1354 band and out-of-band signaling. 1356 11.5.1. In-band Signaling Example 1358 The following offer/answer shows that both the endpoints are MPRTP 1359 capable and SHOULD use in-band signaling for interfaces 1360 advertisements. 1362 Offer: 1363 v=0 1364 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1365 s= 1366 c=IN IP4 192.0.2.1 1367 t=0 0 1368 m=video 49170 RTP/AVP 98 1369 a=rtpmap:98 H264/90000 1370 a=fmtp:98 profile-level-id=42A01E; 1371 a=rtcp-mux 1372 a=mprtp 1374 Answer: 1375 v=0 1376 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1377 s= 1378 c=IN IP4 192.0.2.2 1379 t=0 0 1380 m=video 4000 RTP/AVP 98 1381 a=rtpmap:98 H264/90000 1382 a=fmtp:98 profile-level-id=42A01E; 1383 a=rtcp-mux 1384 a=mprtp 1386 The endpoint MAY now use in-band RTCP signaling to advertise its 1387 multiple interfaces. Alternatively, it MAY make another offer with 1388 the interfaces in SDP (out-of-band signaling) 1389 [I-D.singh-mmusic-mprtp-sdp-extension]. 1391 12. IANA Considerations 1393 The following contact information shall be used for all registrations 1394 in this document: 1396 Contact: Varun Singh 1397 mailto:varun.singh@iki.fi 1398 tel:+358-9-470-24785 1400 Note to the RFC-Editor: When publishing this document as an RFC, 1401 please replace "RFC XXXX" with the actual RFC number of this document 1402 and delete this sentence. 1404 12.1. MPRTP Header Extension 1406 This document defines a new extension URI to the RTP Compact Header 1407 Extensions sub-registry of the Real-Time Transport Protocol (RTP) 1408 Parameters registry, according to the following data: 1410 Extension URI: urn:ietf:params:rtp-hdrext:mprtp 1411 Description: Multipath RTP 1412 Reference: RFC XXXX 1414 12.2. MPRTCP Packet Type 1416 A new RTCP packet format has been registered with the RTCP Control 1417 Packet type (PT) Registry: 1419 Name: MPRTCP 1420 Long name: Multipath RTCP 1421 Value: 211 1422 Reference: RFC XXXX. 1424 This document defines a substructure for MPRTCP packets. A new sub- 1425 registry has been set up for the sub-report block type (MPRTCP_Type) 1426 values for the MPRTCP packet, with the following registrations 1427 created initially: 1429 Name: Subflow Specific Report 1430 Long name: Multipath RTP Subflow Specific Report 1431 Value: 0 1432 Reference: RFC XXXX. 1434 Name: IPv4 Address 1435 Long name: IPv4 Interface Address 1436 Value: 1 1437 Reference: RFC XXXX. 1439 Name: IPv6 Address 1440 Long name: IPv6 Interface Address 1441 Value: 2 1442 Reference: RFC XXXX. 1444 Name: DNS Name 1445 Long name: DNS Name indicating Interface Address 1446 Value: 3 1447 Reference: RFC XXXX. 1449 Further values may be registered on a first come, first served basis. 1450 For each new registration, it is mandatory that a permanent, stable, 1451 and publicly accessible document exists that specifies the semantics 1452 of the registered parameter as well as the syntax and semantics of 1453 the associated sub-report block. The general registration procedures 1454 of [RFC4566] apply. 1456 12.3. SDP Attributes 1458 This document defines a new SDP attribute, "mprtp", within the 1459 existing IANA registry of SDP Parameters. 1461 12.3.1. "mprtp" attribute 1463 o Attribute Name: MPRTP 1465 o Long Form: Multipath RTP 1466 o Type of Attribute: media-level 1468 o Charset Considerations: The attribute is not subject to the 1469 charset attribute. 1471 o Purpose: This attribute is used to indicate support for Multipath 1472 RTP. It can also provide one of many possible interfaces for 1473 communication. These interface addresses may have been validated 1474 using ICE procedures. 1476 o Appropriate Values: See Section 11.2 of RFC XXXX. 1478 13. Security Considerations 1480 TBD 1482 All drafts are required to have a security considerations section. 1483 See RFC 3552 [RFC3552] for a guide. 1485 14. Acknowledgements 1487 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1488 Trilogy (http://www.trilogy-project.org), a research project (ICT- 1489 216372) partially funded by the European Community under its Seventh 1490 Framework Program. The views expressed here are those of the 1491 author(s) only. The European Commission is not liable for any use 1492 that may be made of the information in this document. 1494 The work of Varun Singh and Joerg Ott from Aalto University has been 1495 partially supported by the European Institute of Innovation and 1496 Technology (EIT) ICT Labs activity RCLD 11882. 1498 Lars Eggert has received funding from the European Union's Horizon 1499 2020 research and innovation program 2014-2018 under grant agreement 1500 No. 644866. This document reflects only the authors' views and the 1501 European Commission is not responsible for any use that may be made 1502 of the information it contains. 1504 Thanks to Roni Even , Miguel A. Garcia , Ralf Globisch , Christer 1505 Holmberg , and Frederic Maze for providing valuable feedback on 1506 earlier versions of this draft. 1508 15. References 1509 15.1. Normative References 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1513 RFC2119, March 1997, 1514 . 1516 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1517 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1518 2003, . 1520 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1521 Protocol (RTCP) Extensions for Single-Source Multicast 1522 Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/ 1523 RFC5760, February 2010, 1524 . 1526 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1527 (ICE): A Protocol for Network Address Translator (NAT) 1528 Traversal for Offer/Answer Protocols", RFC 5245, DOI 1529 10.17487/RFC5245, April 2010, 1530 . 1532 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1533 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 1534 2008, . 1536 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1537 Jacobson, "RTP: A Transport Protocol for Real-Time 1538 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1539 July 2003, . 1541 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1542 Real-Time Transport Control Protocol (RTCP): Opportunities 1543 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 1544 2009, . 1546 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1547 "Extended RTP Profile for Real-time Transport Control 1548 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1549 10.17487/RFC4585, July 2006, 1550 . 1552 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1553 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 1554 RFC5761, April 2010, 1555 . 1557 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1558 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1559 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1560 DOI 10.17487/RFC7656, November 2015, 1561 . 1563 15.2. Informative References 1565 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1566 Text on Security Considerations", BCP 72, RFC 3552, DOI 1567 10.17487/RFC3552, July 2003, 1568 . 1570 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1571 Iyengar, "Architectural Guidelines for Multipath TCP 1572 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 1573 . 1575 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1576 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1577 . 1579 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1580 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1581 June 2009, . 1583 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1584 DOI 10.17487/RFC5117, January 2008, 1585 . 1587 [I-D.ietf-mmusic-rfc2326bis] 1588 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1589 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1590 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 1591 progress), February 2014. 1593 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1594 A., Peterson, J., Sparks, R., Handley, M., and E. 1595 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1596 DOI 10.17487/RFC3261, June 2002, 1597 . 1599 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1600 with Session Description Protocol (SDP)", RFC 3264, DOI 1601 10.17487/RFC3264, June 2002, 1602 . 1604 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1605 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1606 July 2006, . 1608 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1609 Keeping Alive the NAT Mappings Associated with RTP / RTP 1610 Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/ 1611 RFC6263, June 2011, 1612 . 1614 [I-D.singh-mmusic-mprtp-sdp-extension] 1615 Singh, V., Ott, J., Karkkainen, T., Globisch, R., and T. 1616 Schierl, "Multipath RTP (MPRTP) attribute in Session 1617 Description Protocol", draft-singh-mmusic-mprtp-sdp- 1618 extension-04 (work in progress), September 2014. 1620 [I-D.reddy-mmusic-ice-best-interface-pcp] 1621 Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun, 1622 "Improving ICE Interface Selection Using Port Control 1623 Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice- 1624 best-interface-pcp-00 (work in progress), October 2013. 1626 [I-D.wing-mmusic-ice-mobility] 1627 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 1628 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 1629 mobility-07 (work in progress), June 2014. 1631 [I-D.ietf-rmcat-eval-criteria] 1632 Varun, V., Ott, J., and S. Holmer, "Evaluating Congestion 1633 Control for Interactive Real-time Media", draft-ietf- 1634 rmcat-eval-criteria-05 (work in progress), March 2016. 1636 [ACM-MPRTP] 1637 Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath 1638 considerations for real-time media", in Proc. of ACM 1639 Multimedia Systems, MMSys, 2013. 1641 Appendix A. Interoperating with Legacy Applications 1643 Some legacy endpoints may abort processing incoming packets, if they 1644 are received from different source address. This may occur due to 1645 the loop detection algorithm. Additionally, it is also possible for 1646 the receiver to reset processing of the stream if the jump in packet 1647 sequence numbers received over multiple interface is large. Both of 1648 these errors are based on implementation-specific details. 1650 An MPRTP sender can use its multiple interfaces to send media to a 1651 legacy RTP client. The legacy receiver will ignore the subflow RTP 1652 header extension and the receiver's de-jitter buffer will attempt to 1653 compensate for any mismatch in per-path latency. However, the 1654 receiver will only send the overall or aggregate RTCP report which 1655 may be insufficient for an MPRTP sender to adequately schedule 1656 packets over multiple paths or detect if a path disappeared. 1658 An MPRTP receiver can only use one of its interface when 1659 communicating with a legacy sender. 1661 Appendix B. Change Log 1663 Note to the RFC-Editor: please remove this section prior to 1664 publication as an RFC. 1666 B.1. Changes in draft-ietf-avtcore-mprtp-03 1668 o Incorporating review comments from Frederic Maze on incorporating 1669 new RTP Taxonomy. 1671 B.2. Changes in draft-ietf-avtcore-mprtp-01, and -02 1673 o Keep-alive versions, document needs review. 1675 o Updated authors' affiliations. 1677 B.3. Changes in draft-ietf-avtcore-mprtp-00 1679 o Submitted as a WG item. 1681 B.4. Changes in draft-singh-avtcore-mprtp-10 1683 o Editorial updates based on review comments. 1685 o Renamed length to encaps_length. 1687 B.5. Changes in draft-singh-avtcore-mprtp-09 1689 o Editorial updates based on review comments. 1691 o Clarified use of a=rtcp-rsize. 1693 o Fixed bug in block length of interface advertisements. 1695 B.6. Changes in draft-singh-avtcore-mprtp-08 1697 o Added reference to use of PCP for discovering new interfaces. 1699 B.7. Changes in draft-singh-avtcore-mprtp-06 and -07 1701 o Added reference to Mobility ICE. 1703 B.8. Changes in draft-singh-avtcore-mprtp-05 1705 o SDP extensions moved to draft-singh-mmusic-mprtp-sdp-extension-00. 1706 Kept only the basic 'a=mprtp' attribute in this document. 1708 o Cleaned up ICE procedures for advertising only using in-band 1709 signaling. 1711 B.9. Changes in draft-singh-avtcore-mprtp-04 1713 o Fixed missing 0xBEDE header in MPRTP header format. 1715 o Removed connectivity checks and keep-alives from in-band 1716 signaling. 1718 o MPRTP and MPRTCP are multiplexed on a single port. 1720 o MPRTCP packet headers optimized. 1722 o Made ICE optional 1724 o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6. 1726 o Added how to use MPRTP in RTSP (Section 12). 1728 o Updated IANA Considerations section. 1730 B.10. Changes in draft-singh-avtcore-mprtp-03 1732 o Added this change log. 1734 o Updated section 6, 7 and 8 based on comments from MMUSIC. 1736 o Updated section 11 (SDP) based on comments of MMUSIC. 1738 o Updated SDP examples with ICE and non-ICE in out-of-band signaling 1739 scenario. 1741 o Added Appendix A on interop with legacy. 1743 o Updated IANA Considerations section. 1745 B.11. Changes in draft-singh-avtcore-mprtp-02 1747 o MPRTCP protocol extensions use only one PT=210, instead of 210 and 1748 211. 1750 o RTP header uses 1-byte extension instead of 2-byte. 1752 o Added section on RTCP Interval Calculations. 1754 o Added "mprtp-interface" attribute in SDP considerations. 1756 B.12. Changes in draft-singh-avtcore-mprtp-01 1758 o Added MPRTP and MPRTCP protocol extensions and examples. 1760 o WG changed from -avt to -avtcore. 1762 Editorial Comments 1764 [note-iceornot] Editor: Legacy applications do not require ICE for 1765 session establishment, therefore, MPRTP should not 1766 require it as well. 1768 [note-rtcp-reuse] Editor: inside the context of subflow specific reports 1769 can we reuse the payload type code for Sender Report 1770 (PT=200), Receiver Report (PT=201), Extension Report 1771 (PT=207). Transport and Payload specific RTCP 1772 messages are session specific and SHOULD be used as 1773 before. 1775 [note-rtp-rtcp-mux] Editor: If a=mprtp is indicated, does the endpoint 1776 need to indicate a=rtcp-mux and a=rtcp-rsize? 1777 because MPRTP mandates the use of RTP and RTCP 1778 multiplexing, and Reduced-Size RTCP. 1780 Authors' Addresses 1782 Varun Singh 1783 Nemu Dialogue Systems Oy 1784 Runeberginkatu 4c A 4 1785 Helsinki 00100 1786 Finland 1788 Email: varun.singh@iki.fi 1789 URI: http://www.callstats.io/ 1790 Teemu Karkkainen 1791 Technical University of Munich 1792 Faculty of Informatics 1793 Boltzmannstrasse 3 1794 Garching bei Muenchen, DE 85748 1795 Germany 1797 Email: kaerkkae@in.tum.de 1799 Joerg Ott 1800 Technical University of Munich 1801 Faculty of Informatics 1802 Boltzmannstrasse 3 1803 Garching bei Muenchen, DE 85748 1804 Germany 1806 Email: ott@in.tum.de 1808 Saba Ahsan 1809 Aalto University 1810 School of Electrical Engineering 1811 Otakaari 5 A 1812 Espoo, FIN 02150 1813 Finland 1815 Email: saba.ahsan@aalto.fi 1817 Lars Eggert 1818 NetApp 1819 Sonnenallee 1 1820 Kirchheim 85551 1821 Germany 1823 Phone: +49 151 12055791 1824 Email: lars@netapp.com 1825 URI: http://eggert.org/