idnits 2.17.1 draft-singh-avtcore-mprtp-10.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 (November 14, 2014) is 3451 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 (-04) exists of draft-singh-mmusic-mprtp-sdp-extension-03 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-06 == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-00 Summary: 2 errors (**), 0 flaws (~~), 4 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 T. Karkkainen 4 Intended status: Experimental J. Ott 5 Expires: May 18, 2015 S. Ahsan 6 Aalto University 7 L. Eggert 8 NetApp 9 November 14, 2014 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-10 14 Abstract 16 The Real-time Transport Protocol (RTP) is used to deliver real-time 17 content and, along with the RTP Control Protocol (RTCP), forms the 18 control channel between the sender and receiver. However, RTP and 19 RTCP assume a single delivery path between the sender and receiver 20 and make decisions based on the measured characteristics of this 21 single path. Increasingly, endpoints are becoming multi-homed, which 22 means that they are connected via multiple Internet paths. Network 23 utilization can be improved when endpoints use multiple parallel 24 paths for communication. The resulting increase in reliability and 25 throughput can also enhance the user experience. This document 26 extends the Real-time Transport Protocol (RTP) so that a single 27 session can take advantage of the availability of multiple paths 28 between two endpoints. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 18, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 39 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6 71 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . 6 73 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8 74 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . 8 75 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9 76 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10 77 7. Available Mechanisms within the Functional Blocks . . . . . . 11 78 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11 80 7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 11 81 7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12 82 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13 83 7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . 13 84 7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14 85 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1.1. Gather or Discovering Candidates . . . . . . . . . . 15 88 8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 15 89 8.1.3. Choosing between In-band (in RTCP) and Out-of-band 90 (in SDP) Interface Advertisement . . . . . . . . . . 16 91 8.1.4. In-band Interface Advertisement . . . . . . . . . . . 16 92 8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17 93 8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17 94 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . 17 95 8.3. Playout Considerations at the Receiver . . . . . . . . . 18 96 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18 97 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19 98 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 19 99 9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . 19 100 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 20 101 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21 102 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . 23 103 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 25 104 9.3. MPRTCP Extension for Interface advertisement . . . . . . 27 105 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 28 106 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 29 107 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 29 108 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 29 109 11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 30 110 11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 30 111 11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 31 112 11.5.1. In-band Signaling Example . . . . . . . . . . . . . 31 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 114 12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . 32 115 12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . 32 116 12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 33 117 12.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . 33 118 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 119 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 120 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 121 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 122 15.2. Informative References . . . . . . . . . . . . . . . . . 35 123 Appendix A. Interoperating with Legacy Applications . . . . . . 37 124 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37 125 B.1. Changes in draft-singh-avtcore-mprtp-10 . . . . . . . . . 37 126 B.2. Changes in draft-singh-avtcore-mprtp-09 . . . . . . . . . 37 127 B.3. Changes in draft-singh-avtcore-mprtp-08 . . . . . . . . . 37 128 B.4. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 37 129 B.5. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 38 130 B.6. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 38 131 B.7. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 38 132 B.8. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 38 133 B.9. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 39 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 136 1. Introduction 138 Multi-homed endpoints are becoming common in today's Internet, e.g., 139 devices that support multiple wireless access technologies such as 3G 140 and Wireless LAN. This means that there is often more than one 141 network path available between two endpoints. Transport protocols, 142 such as RTP, have not been designed to take advantage of the 143 availability of multiple concurrent paths and therefore cannot 144 benefit from the increased capacity and reliability that can be 145 achieved by pooling their respective capacities. 147 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [RFC3550] that 148 allows splitting a single RTP stream into multiple subflows that are 149 transmitted over different paths. In effect, this pools the resource 150 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 151 to RTCP, it is used along with MPRTP to report per-path sender and 152 receiver characteristics. 154 Other IETF transport protocols that are capable of using multiple 155 paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533]. 156 However, these protocols are not suitable for real-time 157 communications. 159 1.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 1.2. Terminology 167 o Endpoint: host either initiating or terminating an RTP flow. 169 o Interface: logical or physical component that is capable of 170 acquiring a unique IP address. 172 o Path: sequence of links between a sender and a receiver. 173 Typically, defined by a set of source and destination addresses. 175 o Subflow: flow of RTP packets along a specific path, i.e., a subset 176 of the packets belonging to an RTP stream. The combination of all 177 RTP subflows forms the complete RTP stream. Typically, a subflow 178 would map to a unique path, i.e., each combination of IP addresses 179 and port pairs (5-tuple, including protocol) is a unique subflow. 181 1.3. Use-cases 183 The primary use-case for MPRTP is transporting high bit-rate 184 streaming multimedia content between endpoints, where at least one is 185 multi-homed. Such endpoints could be residential IPTV devices that 186 connect to the Internet through two different Internet service 187 providers (ISPs), or mobile devices that connect to the Internet 188 through 3G and WLAN interfaces. By allowing RTP to use multiple 189 paths for transmission, the following gains can be achieved: 191 o Higher quality: Pooling the resource capacity of multiple Internet 192 paths allows higher bit-rate and higher quality codecs to be used. 193 From the application perspective, the available bandwidth between 194 the two endpoints increases. 196 o Load balancing: Transmitting an RTP stream over multiple paths 197 reduces the bandwidth usage on a single path, which in turn 198 reduces the impact of the media stream on other traffic on that 199 path. 201 o Fault tolerance: When multiple paths are used in conjunction with 202 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 203 one path have less impact on the overall perceived quality of the 204 stream. 206 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 207 calls to a device with multiple interfaces. Again, such an endpoint 208 could be a mobile device with multiple wireless interfaces. In this 209 case, little is to be gained from resource pooling, i.e., higher 210 capacity or load balancing, because a single path should be easily 211 capable of handling the required load. However, using multiple 212 concurrent subflows can improve fault tolerance, because traffic can 213 shift between the subflows when path outages occur. This results in 214 very fast transport-layer handovers that do not require support from 215 signaling. 217 2. Goals 219 This section outlines the basic goals that multipath RTP aims to 220 meet. These are broadly classified as Functional goals and 221 Compatibility goals. 223 2.1. Functional goals 225 Allow unicast RTP session to be split into multiple subflows in order 226 to be carried over multiple paths. This may prove beneficial in case 227 of video streaming. 229 o Increased Throughput: Cumulative capacity of the two paths may 230 meet the requirements of the multimedia session. Therefore, MPRTP 231 MUST support concurrent use of the multiple paths. 233 o Improved Reliability: MPRTP SHOULD be able to send redundant 234 packets or re-transmit packets along any available path to 235 increase reliability. 237 The protocol SHOULD be able to open new subflows for an existing 238 session when new paths appear and MUST be able to close subflows when 239 paths disappear. 241 2.2. Compatibility goals 243 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 244 back to be compatible with legacy RTP stacks if MPRTP support is not 245 successfully negotiated. 247 o Application Compatibility: MPRTP service model MUST be backwards 248 compatible with existing RTP applications, i.e., an MPRTP stack 249 MUST be able to work with legacy RTP applications and not require 250 changes to them. Therefore, the basic RTP APIs MUST remain 251 unchanged, but an MPRTP stack MAY provide extended APIs so that 252 the application can configure any additional features provided by 253 the MPRTP stack. 255 o Network Compatibility: individual RTP subflows MUST themselves be 256 well-formed RTP flows, so that they are able to traverse NATs and 257 firewalls. This MUST be the case even when interfaces appear 258 after session initiation. Interactive Connectivity Establishment 259 (ICE) [RFC5245] MAY be used for discovering new interfaces or 260 performing connectivity checks. 262 3. RTP Topologies 264 RFC 5117 [RFC5117] describes a number of scenarios using mixers and 265 translators in single-party (point-to-point), and multi-party (point- 266 to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x) 267 discuss in detail the impact of mixers and translators on RTP and 268 RTCP packets. MPRTP assumes that if a mixer or translator exists in 269 the network, then either all of the multiple paths or none of the 270 multiple paths go via this component. 272 4. MPRTP Architecture 274 In a typical scenario, an RTP session uses a single path. In an 275 MPRTP scenario, an RTP session uses multiple subflows that each use a 276 different path. Figure 1 shows the difference. 278 +--------------+ Signaling +--------------+ 279 | |------------------------------------>| | 280 | Client |<------------------------------------| Server | 281 | | Single RTP flow | | 282 +--------------+ +--------------+ 284 +--------------+ Signaling +--------------+ 285 | |------------------------------------>| | 286 | Client |<------------------------------------| Server | 287 | |<------------------------------------| | 288 +--------------+ MPRTP subflows +--------------+ 290 Figure 1: Comparison between traditional RTP streaming and MPRTP 292 +-----------------------+ +-------------------------------+ 293 | Application | | Application | 294 +-----------------------+ +-------------------------------+ 295 | | | MPRTP | 296 + RTP + +- - - - - - - -+- - - - - - - -+ 297 | | | RTP subflow | RTP subflow | 298 +-----------------------+ +---------------+---------------+ 299 | UDP | | UDP | UDP | 300 +-----------------------+ +---------------+---------------+ 301 | IP | | IP | IP | 302 +-----------------------+ +---------------+---------------+ 304 Figure 2: MPRTP Architecture 306 Figure 2 illustrates the differences between the standard RTP stack 307 and the MPRTP stack. MPRTP receives a normal RTP session from the 308 application and splits it into multiple RTP subflows. Each subflow 309 is then sent along a different path to the receiver. To the network, 310 each subflow appears as an independent, well-formed RTP flow. At the 311 receiver, the subflows are combined to recreate the original RTP 312 session. The MPRTP layer performs the following functions: 314 o Path Management: The layer is aware of alternate paths to the 315 other host, which may, for example, be the peer's multiple 316 interfaces. This enables the endpoint to transmit differently 317 marked packets along separate paths. MPRTP also selects 318 interfaces to send and receive data. Furthermore, it manages the 319 port and IP address pair bindings for each subflow. 321 o Packet Scheduling: the layer splits a single RTP flow into 322 multiple subflows and sends them across multiple interfaces 323 (paths). The splitting MAY BE done using different path 324 characteristics. 326 o Subflow recombination: the layer creates the original stream by 327 recombining the independent subflows. Therefore, the multipath 328 subflows appear as a single RTP stream to applications. 330 5. Example Media Flow Diagrams 332 There may be many complex technical scenarios for MPRTP, however, 333 this memo only considers the following two scenarios: 1) a 334 unidirectional media flow that represents the streaming use-case, and 335 2) a bidirectional media flow that represents a conversational use- 336 case. 338 5.1. Streaming use-case 340 In the unidirectional scenario, the receiver (client) initiates a 341 multimedia session with the sender (server). The receiver or the 342 sender may have multiple interfaces and both endpoints are MPRTP- 343 capable. Figure 3 shows this scenario. In this case, host A has 344 multiple interfaces. Host B performs connectivity checks on host A's 345 multiple interfaces. If the interfaces are reachable, then host B 346 streams multimedia data along multiple paths to host A. Moreover, 347 host B also sends RTCP Sender Reports (SR) for each subflow and host 348 A responds with a normal RTCP Receiver Report (RR) for the overall 349 session as well as the receiver statistics for each subflow. Host B 350 distributes the packets across the subflows based on the individually 351 measured path characteristics. 353 Alternatively, to reduce media startup time, host B may start 354 streaming multimedia data to host A's initiating interface and then 355 perform connectivity checks for the other interfaces. This method of 356 updating a single path session to a multipath session is called 357 "multipath session upgrade". 359 Host A Host B 360 ----------------------- ---------- 361 Interface A1 Interface A2 Interface B1 362 ----------------------- ---------- 363 | | 364 |------------------------------------->| Session setup with 365 |<-------------------------------------| multiple interfaces 366 | | | 367 | | | 368 | (RTP data B1->A1, B1->A2) | 369 |<=====================================| 370 | |<========================| 371 | | | 372 Note: there may be more scenarios. 374 Figure 3: Unidirectional media flow 376 5.2. Conversational use-case 378 In the bidirectional scenario, multimedia data flows in both 379 directions. The two hosts exchange their lists of interfaces with 380 each other and perform connectivity checks. Communication begins 381 after each host finds suitable address, port pairs. Interfaces that 382 receive data send back RTCP receiver statistics for that path (based 383 on the 5-tuple). The hosts balance their multimedia stream across 384 multiple paths based on the per path reception statistics and its own 385 volume of traffic. Figure 4 describes an example of a bidirectional 386 flow. 388 Host A Host B 389 --------------------------- --------------------------- 390 Interface A1 Interface A2 Interface B1 Interface B2 391 --------------------------- --------------------------- 392 | | | | 393 | | | |Session setup 394 |----------------------------------->| |with multiple 395 |<-----------------------------------| |interfaces 396 | | | | 397 | | | | 398 | (RTP data B1<->A1, B2<->A2) | | 399 |<===================================| | 400 | |<===================================| 401 |===================================>| | 402 | |===================================>| 403 | | | | 404 Note: the address pairs may have other permutations, 405 and they may be symmetric or asymmetric combinations. 407 Figure 4: Bidirectional flow 409 6. MPRTP Functional Blocks 411 This section describes some of the functional blocks needed for 412 MPRTP. We then investigate each block and consider available 413 mechanisms in the next section. 415 1. Session Setup: Interfaces may appear or disappear at anytime 416 during the session. To preserve backward compatibility with 417 legacy applications, a multipath session MUST look like a bundle 418 of individual RTP sessions. A multipath session may be upgraded 419 from a typical single path session, as and when new interfaces 420 appear or disappear. However, it is also possible to setup a 421 multipath session from the beginning, if the interfaces are 422 available at the start of the multimedia session. 424 2. Expanding RTP: For a multipath session, each subflow MUST look 425 like an independent RTP flow, so that individual RTCP messages 426 can be generated per subflow. Furthermore, MPRTP splits the 427 single multimedia stream into multiple subflows based on path 428 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 429 delay product etc.) and dynamically adjusts the load on each 430 link. 432 3. Adding Interfaces: Interfaces on the host need to be regularly 433 discovered and advertised. This can be done at session setup and 434 /or during the session. Discovering interfaces is outside the 435 scope of this document. 437 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 438 monitoring the quality of the path, for load balancing, or for 439 congestion control, etc. To maintain backward compatibility with 440 legacy applications, the receiver MUST also send aggregate RTCP 441 reports along with the per-path reports. 443 5. Maintenance and Failure Handling: In a multi-homed endpoint 444 interfaces may appear and disappear. If this occurs at the 445 sender, it has to re-adjust the load on the available links. On 446 the other hand, if this occurs at the receiver, then the 447 multimedia data transmitted by the sender to those interfaces is 448 lost. This data may be re-transmitted along a different path 449 i.e., to a different interface on the receiver. Furthermore, the 450 endpoint has to either explicitly signal the disappearance of an 451 interface, or the other endpoint has to detect it (by lack of 452 media packets, RTCP feedback, or keep-alive packets). 454 6. Teardown: The MPRTP layer releases the occupied ports on the 455 interfaces. 457 7. Available Mechanisms within the Functional Blocks 459 This section discusses some of the possible alternatives for each 460 functional block mentioned in the previous section. 462 7.1. Session Setup 464 MPRTP session can be set up in many possible ways e.g., during 465 handshake, or upgraded mid-session. The capability exchange may be 466 done using out-of-band signaling (e.g., Session Description Protocol 467 (SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real- 468 Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in- 469 band signaling (e.g., RTP/RTCP header extension, Session Traversal 470 Utilities for NAT (STUN) messages). 472 7.1.1. Connectivity Checks 474 The endpoint SHOULD be capable of performing connectivity checks 475 (e.g., using ICE [RFC5245]). If the IP addresses of the endpoints 476 are reachable (e.g., globally addressable, same network etc) then 477 connectivity checks are not needed. 479 7.1.2. Adding New or Updating Interfaces 481 Interfaces can appear and disappear during a session, the endpoint 482 MUST be capable of advertising the changes in its set of usable 483 interfaces. Additionally, the application or OS may define a policy 484 on when and/or what interfaces are usable. However, MPRTP requires a 485 method to advertise or notify the other endpoint about the updated 486 set of usable interfaces. 488 7.1.3. In-band vs. Out-of-band Signaling 490 MTRTP nodes will generally use a signaling protocol to establish 491 their MPRTP session. With the existence of such a signaling 492 relationship, two alternatives become available to exchange 493 information about the available interfaces on each side for extending 494 RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and 495 out-of-band signaling. 497 In-band signaling refers to using mechanisms of RTP/RTCP itself to 498 communicate interface addresses, e.g., a dedicated RTCP extensions 499 along the lines of the one defined to communicate information about 500 the feedback target for RTP over SSM [RFC5760]. In-band signaling 501 does not rely on the availability of a separate signaling connection 502 and the information flows along the same path as the media streams, 503 thus minimizing dependencies. Moreover, if the media channel is 504 secured (e.g., by means of SRTP), the signaling is implicitly 505 protected as well if SRTCP encryption and authentication are chosen. 506 In-band signaling is also expected to take a direct path to the peer, 507 avoiding any signaling overlay-induced indirections and associated 508 processing overheads in signaling elements -- avoiding such may be 509 especially worthwhile if frequent updates may occur as in the case of 510 mobile users. Finally, RTCP is usually sent sufficiently frequently 511 (in point-to-point settings) to provide enough opportunities for 512 transmission and (in case of loss) retransmission of the 513 corresponding RTCP packets. 515 Examples for in-band signaling include RTCP extensions as noted above 516 or suitable extensions to STUN [I-D.wing-mmusic-ice-mobility]. 518 Out-of-band signaling refers to using a separate signaling connection 519 (via SIP, RTSP, or HTTP) to exchange interface information, e.g., 520 expressed in SDP. Clear benefits are that signaling occurs at setup 521 time anyway and that experience and SDP syntax (and procedures) are 522 available that can be re-used or easily adapted to provide the 523 necessary capabilities. In contrast to RTCP, SDP offers a reliable 524 communication channel so that no separate retransmissions logic is 525 necessary. In SDP, especially when combined with ICE, connectivity 526 check mechanisms including sophisticated rules are readily available. 527 While SDP is not inherently protected, suitable security may need to 528 be applied anyway to the basic session setup. 530 Examples for out-of-band signaling are dedicated extensions to SDP; 531 those may be combined with ICE. 533 Both types of mechanisms have their pros and cons for middleboxes. 534 With in-band signaling, control packets take the same path as the 535 media packets and they can be directly inspected by middleboxes so 536 that the elements operating on the signaling channel do not need to 537 understand new SDP. With out-of-band signaling, only the middleboxes 538 processing the signaling need to be modified and those on the data 539 forwarding path can remain untouched. 541 Overall, it may appear sensible to provide a combination of both 542 mechanisms: out-of-band signaling for session setup and initial 543 interface negotiation and in-band signaling to deal with frequent 544 changes in interface state (and for the potential case, albeit rather 545 theoretical case of MPRTP communication without a signaling channel). 547 In its present version, this document explores both options to 548 provide a broad understanding of how the corresponding mechanisms 549 would look like. 551 7.2. Expanding RTP 553 RTCP [RFC3550] is generated per media session. However, with MPRTP, 554 the media sender spreads the RTP load across several interfaces. The 555 media sender SHOULD make the path selection, load balancing and fault 556 tolerance decisions based on the characteristics of each path. 557 Therefore, apart from normal RTP sequence numbers defined in 558 [RFC3550], the MPRTP sender MUST add subflow-specific sequence 559 numbers to help calculate fractional losses, jitter, RTT, playout 560 time, etc., for each path, and a subflow identifier to associate the 561 characteristics with a path. The RTP header extension for MPRTP is 562 shown in Section 9.1. 564 7.3. Expanding RTCP 566 To provide accurate per path information an MPRTP endpoint MUST send 567 (SR/RR) report for each unique subflow along with the overall session 568 RTCP report. Therefore, the additional subflow reporting affects the 569 RTCP bandwidth and the RTCP reporting interval. RTCP report 570 scheduling for each subflow may cause a problem for RTCP 571 recombination and reconstruction in cases when 1) RTCP for a subflow 572 is lost, and 2) RTCP for a subflow arrives later than the other 573 subflows. (There may be other cases as well.) 575 The sender distributes the media across different paths using the per 576 path RTCP reports. However, this document doesn't cover algorithms 577 for congestion control or load balancing. 579 7.4. Failure Handling and Teardown 581 An MPRTP endpoint MUST keep alive subflows that have been negotiated 582 but no media is sent on them. Moreover, using the information in the 583 subflow reports, a sender can monitor an active subflow for failure 584 (errors, unreachability, congestion) and decide not to use (make the 585 active subflow passive), or teardown the subflow. 587 If an interface disappears, the endpoint MUST send an updated 588 interface advertisement without the interface and release the the 589 associated subflows. 591 8. MPRTP Protocol 593 Host A Host B 594 ----------------------- ----------------------- 595 Interface A1 Interface A2 Interface B1 Interface B2 596 ----------------------- ----------------------- 597 | | | | 598 | | (1) | | 599 |--------------------------------------->| | 600 |<---------------------------------------| | 601 | | (2) | | 602 |<=======================================| | 603 |<=======================================| (3) | 604 | | (4) | | 605 |<- - - - - - - - - - - - - - - - - - - -| | 606 |<- - - - - - - - - - - - - - - - - - - -| | 607 |<- - - - - - - - - - - - - - - - - - - -| | 608 | | (5) | | 609 |- - - - - - - - - - - - - - - - - - - ->| | 610 |<=======================================| (6) | 611 |<=======================================| | 612 | |<========================================| 613 |<=======================================| | 614 | |<========================================| 616 Key: 617 | Interface 618 ---> Signaling Protocol 619 <=== RTP Packets 620 - -> RTCP Packet 622 Figure 5: MPRTP New Interface 624 8.1. Overview 626 The bullet points explain the different steps shown in Figure 5 for 627 upgrading a single path multimedia session to multipath session. 629 (1) The first two interactions between the hosts represents the 630 establishment of a normal RTP session. This may performed e.g. 631 using SIP or RTSP. 633 (2) When the RTP session has been established, host B streams 634 media using its interface B1 to host A at interface A1. 636 (3) Host B supports sending media using MPRTP and becomes aware of 637 an additional interface B2. 639 (4) Host B advertises the multiple interface addresses. 641 (5) Host A supports receiving media using MPRTP and becomes aware 642 of an additional interface A2. 644 Side note, even if an MPRTP-capable host has only one interface, 645 it MUST respond to the advertisement with its single interface. 647 (6) Each host receives information about the additional interfaces 648 and the appropriate endpoints starts to stream the multimedia 649 content using the additional paths. 651 If needed, each endpoint will need to independently perform 652 connectivity checks (not shown in figure) and ascertain 653 reachability before using the paths. 655 8.1.1. Gather or Discovering Candidates 657 The endpoint periodically polls the operating system or is notified 658 when an additional interface appears. If the endpoint wants to use 659 the additional interface for MPRTP it MUST advertise it to the other 660 peers. The endpoint may also use ICE [RFC5245] to gather additional 661 candidates. 663 8.1.2. NAT Traversal 665 After gathering their interface candidates, the endpoints decide 666 internally if they wish to perform connectivity checks. 668 [note-iceornot] 670 If the endpoint chooses to perform connectivity checks then it MUST 671 first advertise the gathered candidates as ICE candidates in SDP 672 during session setup and let ICE perform the connectivity checks. As 673 soon as a sufficient number of connectivity checks succeed, the 674 endpoint can use the successful candidates to advertise its MPRTP 675 interface candidates. 677 Alternatively, if the endpoint supports mobility extensions for ICE 678 [I-D.wing-mmusic-ice-mobility], it can let the ICE agent gather and 679 perform the connectivity checks. When the connectivity checks 680 succeed, the ICE agent should notify the MPRTP layer of these new 681 paths (5-tuples), these new paths are then used by MPRTP to send 682 media packets depending on the scheduling algorithm. 684 If an endpoint supports Interface selection via PCP Flow Extension 685 [I-D.reddy-mmusic-ice-best-interface-pcp], it will receive 686 notifications when new interfaces become available and additionally 687 when the link quality of a currently available interface changes. 688 The application can advertise and perform connectivity checks with 689 the new interface and in the case of changes in link quality pass the 690 information to the scheduling algorithm for better application 691 performance. 693 [Editors note: The interaction between the RTP agent and ICE agent is 694 needed for implementing a scheduling algorithm or congestion control. 695 See details of a scheduling algorithm in [ACM-MPRTP].] 697 8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP) 698 Interface Advertisement 700 If there is no media flowing at the moment and the application wants 701 to use the interfaces from the start of the session, it should 702 advertise them in SDP (See [I-D.singh-mmusic-mprtp-sdp-extension]). 703 Alternatively, the endpoint can setup the session as a single path 704 media session and upgrade the session to multipath by advertising the 705 session in-band (See Section 8.1.4 or 706 [I-D.wing-mmusic-ice-mobility]). Moreover, if an interface appears 707 and disappears, the endpoint SHOULD prefer to advertise it in-band 708 because the endpoint would not have to wait for a response from the 709 other endpoint before starting to use the interface. However, if 710 there is a conflict between an in-band and out-of-band advertisement, 711 i.e., the endpoint receives an in-band advertisement while it has a 712 pending out-of-band advertisement, or vice versa then the session is 713 setup using out-of-band mechanisms. 715 8.1.4. In-band Interface Advertisement 717 To advertise the multiple interfaces in RTCP, an MPRTP-capable 718 endpoint MUST add the MPRTP Interface Advertisement defined in 719 Figure 13 with the RTCP Sender Report (SR). Each unique address is 720 encapsulated in an Interface Advertisement block and contains the IP 721 address, RTP and RTCP port addresses. The Interface Advertisement 722 blocks are ordered based on a decreasing priority level. On 723 receiving the MPRTP Interface Advertisement, an MPRTP-capable 724 receiver MUST respond with the set of interfaces (subset or all 725 available) it wants to use. 727 If the sender and receiver have only one interface, then the 728 endpoints MUST indicate the negotiated single path IP, RTP port and 729 RTCP port addresses. 731 8.1.5. Subflow ID Assignment 733 After interface advertisements have been exchanged, the endpoint MUST 734 associate a Subflow ID to each unique subflow. Each combination of 735 sender and receiver IP addresses and port pairs (5-tuple) is a unique 736 subflow. If the connectivity checks have been performed then the 737 endpoint MUST only use the subflows for which the connectivity checks 738 have succeeded. 740 8.1.6. Active and Passive Subflows 742 To send and receive data an endpoint MAY use any number of subflows 743 from the set of available subflows. The subflows that carry media 744 data are called active subflows, while those subflows that don't send 745 any media packets (fallback paths) are called passive subflows. 747 An endpoint MUST multiplex the subflow specific RTP and RTCP packets 748 on the same port to keep the NAT bindings alive. This is inline with 749 the recommendation made in RFC6263[RFC6263]. Moreover, if an 750 endpoint uses ICE, multiplexing RTP and RTCP reduces the number of 751 components from 2 to 1 per media stream. If no MPRTP or MPRTCP 752 packets are received on a particular subflow at a receiver, the 753 receiver SHOULD remove the subflow from active and passive lists and 754 not send any MPRTCP reports for that subflow. It may keep the 755 bindings in a dead-pool, so that if the 5-tuple or subflow reappears, 756 it can quickly reallocate it based on past history. 758 8.2. RTP Transmission 760 If both endpoints are MPRTP-capable and if they want to use their 761 multiple interfaces for sending the media stream then they MUST use 762 the MPRTP header extensions. They MAY use normal RTP with legacy 763 endpoints (see Appendix A). 765 An MPRTP endpoint sends RTP packets with an MPRTP extension that maps 766 the media packet to a specific subflow (see Figure 8). The MPRTP 767 layer SHOULD associate an RTP packet with a subflow based on a 768 scheduling strategy. The scheduling strategy may either choose to 769 augment the paths to create higher throughput or use the alternate 770 paths for enhancing resilience or error-repair. Due to the changes 771 in path characteristics, the endpoint should be able change its 772 scheduling strategy during an ongoing session. The MPRTP sender MUST 773 also populate the subflow specific fields described in the MPRTP 774 extension header (see Section 9.1.1). 776 [ACM-MPRTP] describes and evaluates a scheduling algorithm for video 777 over multiple interfaces. The video is encoded at a single target 778 bit rate and is evaluated in various network scenarios, as discussed 779 in [I-D.ietf-rmcat-eval-criteria]. 781 8.3. Playout Considerations at the Receiver 783 A media receiver, irrespective of MPRTP support or not, should be 784 able to playback the media stream because the received RTP packets 785 are compliant to [RFC3550], i.e., a non-MPRTP receiver will ignore 786 the MPRTP header and still be able to playback the RTP packets. 787 However, the variation of jitter and loss per path may affect proper 788 playout. The receiver can compensate for the jitter by modifying the 789 playout delay (i.e., by calculating skew across all paths) of the 790 received RTP packets. For example, an adaptive playout algorithm is 791 discussed in [ACM-MPRTP]. 793 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 795 Aggregate RTCP provides the overall media statistics and follows the 796 normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific 797 RTCP provides the per path media statistics because the aggregate 798 RTCP report may not provide sufficient per path information to an 799 MPRTP scheduler. Specifically, the scheduler should be aware of each 800 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 802 The aggregate RTCP report (i.e., the regularly scheduled RTCP report) 803 MUST be sent compounded as described in [RFC5506], however, the 804 subflow-specific RTCP reports MAY be sent non-compounded. Further, 805 each subflow and the aggregate RTCP report MUST follow the timing 806 rules defined in [RFC4585]. 808 The RTCP reporting interval is locally implemented and the scheduling 809 of the RTCP reports may depend on the the behavior of each path. For 810 instance, the RTCP interval may be different for a passive path than 811 an active path to keep port bindings alive. Additionally, an 812 endpoint may decide to share the RTCP reporting bit rate equally 813 across all its paths or schedule based on the receiver rate on each 814 path. 816 8.5. RTCP Transmission 818 The sender sends an RTCP SR on each active path. For each SR the 819 receiver gets, it echoes one back to the same IP address-port pair 820 that sent the SR. The receiver tries to choose the symmetric path 821 and if the routing is symmetric then the per-path RTT calculations 822 will work out correctly. However, even if the paths are not 823 symmetric, the sender would at maximum, under-estimate the RTT of the 824 path by a factor of half of the actual path RTT. 826 9. Packet Formats 828 In this section we define the protocol structures described in the 829 previous sections. 831 9.1. RTP Header Extension for MPRTP 833 The MPRTP header extension is used to distribute a single RTP stream 834 over multiple subflows. 836 The header conforms to the one-byte RTP header extension defined in 837 [RFC5285]. The header extension contains a 16-bit length field that 838 counts the number of 32-bit words in the extension, excluding the 839 four-octet extension header (therefore zero is a valid length, see 840 Section 5.3.1 of [RFC3550] for details). 842 The RTP header for each subflow is defined below: 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |V=2|P|1| CC |M| PT | sequence number | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | timestamp | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | synchronization source (SSRC) identifier | 852 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 853 | 0xBE | 0xDE | length=N-1 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | ID | LEN | MPID |LENGTH | MPRTP header data | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 857 | .... | 858 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 859 | RTP payload | 860 | .... | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Figure 6: Generic MPRTP header extension 865 MPID: 867 The MPID field corresponds to the type of MPRTP packet. 868 Namely: 870 +---------------+--------------------------------------------------+ 871 | MPID ID | Use | 872 | Value | | 873 +---------------+--------------------------------------------------+ 874 | 0x0 | Subflow RTP Header. For this case the Length is | 875 | | set to 4 | 876 +---------------+--------------------------------------------------+ 878 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 880 length 882 The 4-bit length field is the length of extension data in bytes 883 not including the H-Ext ID and length fields. The value zero 884 indicates there is no data following. 886 MPRTP header data 888 Carries the MPID specific data as described in the following 889 sub-sections. 891 9.1.1. MPRTP RTP Extension for a Subflow 893 The RTP header for each subflow is defined below: 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 |V=2|P|1| CC |M| PT | sequence number | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | timestamp | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | synchronization source (SSRC) identifier | 903 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 904 | 0xBE | 0xDE | length=2 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | ID | LEN=4 | 0x0 | LEN=4 | Subflow ID | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 909 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 910 | RTP payload | 911 | .... | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 8: MPRTP header for subflow 916 MP ID = 0x0 918 Indicates that the MPRTP header extension carries subflow 919 specific information. 921 length = 4 923 Subflow ID: Identifier of the subflow. Every RTP packet belonging 924 to the same subflow carries the same unique subflow identifier. 926 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 927 the subflow. Each subflow has its own strictly monotonically 928 increasing sequence number space. 930 9.2. RTCP Extension for MPRTP (MPRTCP) 932 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 933 per subflow to determine the characteristics of each path, and 2) 934 advertise each interface. 936 0 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | SSRC of packet sender | 942 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 943 | SSRC_1 (SSRC of first source) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | MPRTCP_Type | block length | | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP Reports | 947 | ... | 948 | ... | 949 | ... | 950 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 952 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 953 normal SR/RR] 955 MPRTCP: 8 bits 957 Contains the constant 211 to identify this as an Multipath RTCP 958 packet. 960 encaps_length: 16 bits 962 As described for the RTCP packet (see Section 6.4.1 of the RTP 963 specification [RFC3550]), the length of this is in 32-bit words 964 minus one, including the header and any padding. 966 The encaps_length covers all MPRTCP_Type report blocks included 967 within this report. 969 MPRTCP_Type: 8-bits 971 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 972 packet. Namely: 974 +---------------+--------------------------------------------------+ 975 | MPRTCP_Type | Use | 976 | Value | | 977 +---------------+--------------------------------------------------+ 978 | 0 | Subflow Specific Report | 979 | 1 | Interface Advertisement (IPv4 Address) | 980 | 2 | Interface Advertisement (IPv4 Address) | 981 | 3 | Interface Advertisement (DNS Address) | 982 +---------------+--------------------------------------------------+ 984 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 986 block length: 8-bits 988 The 8-bit length field is the length of the encapsulated MPRTCP 989 reports in 32-bit word length (i.e., length * 4 bytes) 990 including the MPRTCP_Type and length fields. The value zero is 991 invalid and the report block MUST be ignored. 993 MPRTCP Reports: variable size 995 Defined later in 9.2.1 and 9.3. 997 9.2.1. MPRTCP Extension for Subflow Reporting 999 When sending a report for a specific subflow the sender or receiver 1000 MUST add only the reports associated with that 5-tuple. Each subflow 1001 is reported independently using the following MPRTCP Feedback header. 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | SSRC of packet sender | 1009 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1010 | SSRC_1 (SSRC of first source) | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Subflow-specific reports | 1015 | .... | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Subflow-specific reports | 1020 | .... | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 11: MPRTCP Subflow Reporting Header 1025 MPRTCP_Type: 0 1027 The value indicates that the encapsulated block is a subflow 1028 report. 1030 block length: 8-bits 1032 The 8-bit length field is the length of the encapsulated subflow- 1033 specific reports in 32-bit word length not including the 1034 MPRTCP_Type and length fields. 1036 Subflow ID: 16 bits 1038 Subflow identifier is the value associated with the subflow the 1039 endpoint is reporting about. If it is a sender it MUST use the 1040 Subflow ID associated with the 5-tuple. If it is a receiver it 1041 MUST use the Subflow ID received in the Subflow-specific Sender 1042 Report. 1044 Subflow-specific reports: variable 1046 Subflow-specific report contains all the reports associated with 1047 the Subflow ID. For a sender, it MUST include the Subflow- 1048 specific Sender Report (SSR). For a receiver, it MUST include 1049 Subflow-specific Receiver Report (SRR). Additionally, if the 1050 receiver supports subflow-specific extension reports then it MUST 1051 append them to the SRR. 1053 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 1055 [note-rtcp-reuse] 1057 Example: 1059 0 1 2 3 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | SSRC of packet sender | 1065 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1066 | SSRC_1 (SSRC of first source) | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1069 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1070 |V=2|P| RC | PT=SR=200 | length | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | SSRC of sender | 1073 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1074 | NTP timestamp, most significant word | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | NTP timestamp, least significant word | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | RTP timestamp | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | subflow's packet count | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | subflow's octet count | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1085 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1086 |V=2|P| RC | PT=RR=201 | length | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | SSRC of packet sender | 1089 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1090 | fraction lost | cumulative number of packets lost | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | extended highest sequence number received | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | inter-arrival jitter | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | last SR (LSR) | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | delay since last SR (DLSR) | 1099 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1100 | Subflow specific extension reports | 1101 | .... | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1105 (Bi-directional use-case, in case of uni-directional flow the subflow 1106 will only send an SR or RR). 1108 9.3. MPRTCP Extension for Interface advertisement 1110 This sub-section defines the RTCP header extension for in-band 1111 interface advertisement by the receiver. The interface advertisement 1112 block describes a method to represent IPv4, IPv6 and generic DNS-type 1113 addresses in a block format. It is based on the sub-reporting block 1114 in [RFC5760]. The interface advertisement SHOULD immediately follow 1115 the Receiver Report. If the Receiver Report is not present, then it 1116 MUST be appended to the Sender Report. 1118 The endpoint MUST advertise the interfaces it wants to use whenever 1119 an interface appears or disappears and also when it receives an 1120 Interface Advertisement. 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 |V=2|P|reserved | PT=MPRTCP=211 | encaps_length | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | SSRC of packet sender | 1128 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1129 | SSRC_1 (SSRC of first source) | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | MPRTCP_Type | block length | RTP Port | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Interface Address #1 | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | MPRTCP_Type | block length | RTP Port | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Interface Address #2 | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | MPRTCP_Type | block length | RTP Port | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Interface Address #.. | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | MPRTCP_Type | block length | RTP Port | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Interface Address #m | 1146 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1148 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1150 MPRTCP_Type: 8 bits 1152 The MPRTCP_Type corresponds to the type of interface address. 1153 Namely: 1155 1: IPv4 address 1156 2: IPv6 address 1158 3: DNS name 1160 block length: 8 bits 1162 The length of the Interface Advertisement block in 32-bit word 1163 lengths. 1165 For an IPv4 address, this should be 2 (8 octets including = 1166 2 + 2 + 4). 1168 For an IPv6 address, this should be 5 (20 octets = 2 +2 + 1169 16). 1171 For a DNS name, the length field indicates the number of 1172 word lengths making up the address string plus 1 (32-bit 1173 word for the 2 byte port number and 2 byte header). 1175 RTP Port: 2 octets 1177 The port number to which the sender sends RTP data. A port 1178 number of 0 is invalid and MUST NOT be used. 1180 Interface Address: 4 octets (IPv4), 16 octets (IPv6), or n octets 1181 (DNS name) 1183 The address to which receivers send feedback reports. For IPv4 1184 and IPv6, fixed-length address fields are used. A DNS name is 1185 an arbitrary-length string. The string MAY contain 1186 Internationalizing Domain Names in Applications (IDNA) domain 1187 names and MUST be UTF-8 [RFC3629] encoded. 1189 10. RTCP Timing reconsiderations for MPRTCP 1191 MPRTP endpoints MUST conform to the timing rule imposed in [RFC4585], 1192 i.e., the total RTCP rate between the participants MUST NOT exceed 5% 1193 of the media rate. For each endpoint, a subflow MUST send the 1194 aggregate and subflow-specific report. The endpoint SHOULD schedule 1195 the RTCP reports for the active subflows based on the share of the 1196 transmitted or received bit rate to the average media bit rate, this 1197 method ensures fair sharing of the RTCP bandwidth. Alternatively, 1198 the endpoint MAY schedule the reports in round-robin. 1200 11. SDP Considerations 1202 11.1. Signaling MPRTP Header Extension in SDP 1204 To indicate the use of the MPRTP header extensions (see Section 9) in 1205 SDP, the sender MUST use the following URI in extmap: urn:ietf:params 1206 :rtp-hdrext:mprtp. This is a media level parameter. Legacy RTP 1207 (non-MPRTP) clients will ignore this header extension, but can 1208 continue to parse and decode the packet (see Appendix A). 1210 Example: 1212 v=0 1213 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1214 s= 1215 c=IN IP4 192.0.2.1 1216 t=0 0 1217 m=video 49170 RTP/AVP 98 1218 a=rtpmap:98 H264/90000 1219 a=fmtp:98 profile-level-id=42A01E; 1220 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1222 11.2. Signaling MPRTP capability in SDP 1224 A participant of a media session MUST use SDP to indicate that it 1225 supports MPRTP. Not providing this information will make the other 1226 endpoint ignore the RTCP extensions. 1228 mprtp-attrib = "a=" "mprtp" [ 1229 SP mprtp-optional-parameter] 1230 CRLF ; flag to enable MPRTP 1232 The endpoint MUST use 'a=mprtp', if it is able to send and receive 1233 MPRTP packets. Generally, senders and receivers MUST indicate this 1234 capability if they support MPRTP and would like to use it in the 1235 specific media session being signaled. To exchange the additional 1236 interfaces, the endpoint SHOULD use the in-band signaling (See 1237 Section 9.3). Alternatively, advertise in SDP (See 1238 [I-D.singh-mmusic-mprtp-sdp-extension]). 1240 MPRTP endpoint multiplexes RTP and RTCP on a single port, sender MUST 1241 indicate support by adding "a=rtcp-mux" in SDP [RFC5761]. If an 1242 endpoint receives an SDP without "a=rtcp-mux" but contains "a=mprtp", 1243 then the endpoint MUST infer support for multiplexing. 1245 MPRTP endpoint uses Reduced-Size RTCP [RFC5506] for reporting path 1246 characterisitcs per subflow (MPRTCP). An MPRTP endpoint MUST 1247 indicate support by adding "a=rtcp-rsize" in SDP [RFC5761]. If an 1248 endpoint receives an "a=rtcp-rsize" but contains "a=mprtp", then the 1249 endpoint MUST infer support for Reduced-Size RTCP. 1251 [note-rtp-rtcp-mux] 1253 11.3. MPRTP with ICE 1255 If the endpoints intend to use ICE [RFC5245] for discovering 1256 interfaces and running connectivity checks then the endpoint MUST 1257 advertise its ICE candidates in the initial OFFER, as defined in ICE 1258 [RFC5245]. Thereafter the endpoints run connectivity checks. 1260 When an endpoint uses ICE's regular nomination [RFC5245] procedure, 1261 it chooses the best ICE candidate as the default path. In the case 1262 of an MPRTP endpoint, if more than one ICE candidate succeeded the 1263 connectivity checks then an MPRTP endpoint MAY advertise (some of) 1264 these in-band in RTCP as MPRTP interfaces. 1266 When an endpoint uses ICE's aggressive nomination [RFC5245] 1267 procedure, the selected candidate may change as more ICE checks 1268 complete. Instead of sending updated offers as additional ICE 1269 candidates appear (transience), the endpoint it MAY use in-band 1270 signaling to advertise its interfaces, as defined in Section 9.3. 1272 If the default interface disappears and the paths used for MPRTP are 1273 different from the one in the c= and m= lines then the an alternate 1274 interface for which the ICE checks were successful should be promoted 1275 to the c= and m= lines in the updated offer. 1277 When a new interface appears then the application/endpoint should 1278 internally decide if it wishes to use it and sends an updated offer 1279 with ICE candidates of the all its interfaces including the new 1280 interface. The receiving endpoint responds to the offer with all its 1281 ICE candidates in the answer and starts connectivity checks between 1282 all its candidates and the offerer's ICE candidates. Similarly, the 1283 initiating endpoint starts connectivity checks between the its 1284 interfaces (incl. the new interface) and all the received ICE 1285 candidates in the answer. If the connectivity checks succeed, the 1286 initiating endpoint MAY use in-band signaling (See Section 9.3) to 1287 advertise its new set of interfaces. 1289 11.4. Increased Throughput 1291 The MPRTP layer MAY choose to augment paths to increase throughput. 1292 If the desired media rate exceeds the current media rate, the 1293 endpoints MUST renegotiate the application specific ("b=AS:xxx") 1294 [RFC4566] bandwidth. 1296 11.5. Offer/Answer 1298 When SDP [RFC4566] is used to negotiate MPRTP sessions following the 1299 offer/answer model [RFC3264], the "a=mprtp" attribute (see 1300 Section 11.2) indicates the desire to use multiple interfaces to send 1301 or receive media data. The initial SDP offer MUST include this 1302 attribute at the media level. If the answerer wishes to also use 1303 MPRTP, it MUST include a media-level "a=mprtp" attribute in the 1304 answer. If the answer does not contain an "a=mprtp" attribute, the 1305 offerer MUST NOT stream media over multiple paths and the offerer 1306 MUST NOT advertise additional MPRTP interfaces in-band or out-of- 1307 band. 1309 When SDP is used in a declarative manner, the presence of an 1310 "a=mprtp" attribute signals that the sender can send or receive media 1311 data over multiple interfaces. The receiver SHOULD be capable to 1312 stream media to the multiple interfaces and be prepared to receive 1313 media from multiple interfaces. 1315 The following sections shows examples of SDP offer and answer for in- 1316 band and out-of-band signaling. 1318 11.5.1. In-band Signaling Example 1320 The following offer/answer shows that both the endpoints are MPRTP 1321 capable and SHOULD use in-band signaling for interfaces 1322 advertisements. 1324 Offer: 1325 v=0 1326 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1327 s= 1328 c=IN IP4 192.0.2.1 1329 t=0 0 1330 m=video 49170 RTP/AVP 98 1331 a=rtpmap:98 H264/90000 1332 a=fmtp:98 profile-level-id=42A01E; 1333 a=rtcp-mux 1334 a=mprtp 1336 Answer: 1337 v=0 1338 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1339 s= 1340 c=IN IP4 192.0.2.2 1341 t=0 0 1342 m=video 4000 RTP/AVP 98 1343 a=rtpmap:98 H264/90000 1344 a=fmtp:98 profile-level-id=42A01E; 1345 a=rtcp-mux 1346 a=mprtp 1348 The endpoint MAY now use in-band RTCP signaling to advertise its 1349 multiple interfaces. Alternatively, it MAY make another offer with 1350 the interfaces in SDP (out-of-band signaling) 1351 [I-D.singh-mmusic-mprtp-sdp-extension]. 1353 12. IANA Considerations 1355 The following contact information shall be used for all registrations 1356 in this document: 1358 Contact: Varun Singh 1359 mailto:varun.singh@iki.fi 1360 tel:+358-9-470-24785 1362 Note to the RFC-Editor: When publishing this document as an RFC, 1363 please replace "RFC XXXX" with the actual RFC number of this document 1364 and delete this sentence. 1366 12.1. MPRTP Header Extension 1368 This document defines a new extension URI to the RTP Compact Header 1369 Extensions sub-registry of the Real-Time Transport Protocol (RTP) 1370 Parameters registry, according to the following data: 1372 Extension URI: urn:ietf:params:rtp-hdrext:mprtp 1373 Description: Multipath RTP 1374 Reference: RFC XXXX 1376 12.2. MPRTCP Packet Type 1378 A new RTCP packet format has been registered with the RTCP Control 1379 Packet type (PT) Registry: 1381 Name: MPRTCP 1382 Long name: Multipath RTCP 1383 Value: 211 1384 Reference: RFC XXXX. 1386 This document defines a substructure for MPRTCP packets. A new sub- 1387 registry has been set up for the sub-report block type (MPRTCP_Type) 1388 values for the MPRTCP packet, with the following registrations 1389 created initially: 1391 Name: Subflow Specific Report 1392 Long name: Multipath RTP Subflow Specific Report 1393 Value: 0 1394 Reference: RFC XXXX. 1396 Name: IPv4 Address 1397 Long name: IPv4 Interface Address 1398 Value: 1 1399 Reference: RFC XXXX. 1401 Name: IPv6 Address 1402 Long name: IPv6 Interface Address 1403 Value: 2 1404 Reference: RFC XXXX. 1406 Name: DNS Name 1407 Long name: DNS Name indicating Interface Address 1408 Value: 3 1409 Reference: RFC XXXX. 1411 Further values may be registered on a first come, first served basis. 1412 For each new registration, it is mandatory that a permanent, stable, 1413 and publicly accessible document exists that specifies the semantics 1414 of the registered parameter as well as the syntax and semantics of 1415 the associated sub-report block. The general registration procedures 1416 of [RFC4566] apply. 1418 12.3. SDP Attributes 1420 This document defines a new SDP attribute, "mprtp", within the 1421 existing IANA registry of SDP Parameters. 1423 12.3.1. "mprtp" attribute 1425 o Attribute Name: MPRTP 1427 o Long Form: Multipath RTP 1428 o Type of Attribute: media-level 1430 o Charset Considerations: The attribute is not subject to the 1431 charset attribute. 1433 o Purpose: This attribute is used to indicate support for Multipath 1434 RTP. It can also provide one of many possible interfaces for 1435 communication. These interface addresses may have been validated 1436 using ICE procedures. 1438 o Appropriate Values: See Section 11.2 of RFC XXXX. 1440 13. Security Considerations 1442 TBD 1444 All drafts are required to have a security considerations section. 1445 See RFC 3552 [RFC3552] for a guide. 1447 14. Acknowledgements 1449 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1450 Trilogy (http://www.trilogy-project.org), a research project 1451 (ICT-216372) partially funded by the European Community under its 1452 Seventh Framework Program. The views expressed here are those of the 1453 author(s) only. The European Commission is not liable for any use 1454 that may be made of the information in this document. 1456 The work of Varun Singh and Joerg Ott from Aalto University has been 1457 partially supported by the European Institute of Innovation and 1458 Technology (EIT) ICT Labs activity RCLD 11882. 1460 Thanks to Roni Even , Miguel A. Garcia , Ralf Globisch , Christer 1461 Holmberg , and Frederic Maze for providing valuable feedback on 1462 earlier versions of this draft. 1464 15. References 1466 15.1. Normative References 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", BCP 14, RFC 2119, March 1997. 1471 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1472 10646", STD 63, RFC 3629, November 2003. 1474 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1475 Protocol (RTCP) Extensions for Single-Source Multicast 1476 Sessions with Unicast Feedback", RFC 5760, February 2010. 1478 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1479 (ICE): A Protocol for Network Address Translator (NAT) 1480 Traversal for Offer/Answer Protocols", RFC 5245, April 1481 2010. 1483 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1484 Header Extensions", RFC 5285, July 2008. 1486 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1487 Jacobson, "RTP: A Transport Protocol for Real-Time 1488 Applications", STD 64, RFC 3550, July 2003. 1490 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1491 Real-Time Transport Control Protocol (RTCP): Opportunities 1492 and Consequences", RFC 5506, April 2009. 1494 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1495 "Extended RTP Profile for Real-time Transport Control 1496 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1497 2006. 1499 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1500 Control Packets on a Single Port", RFC 5761, April 2010. 1502 15.2. Informative References 1504 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1505 Text on Security Considerations", BCP 72, RFC 3552, July 1506 2003. 1508 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1509 Iyengar, "Architectural Guidelines for Multipath TCP 1510 Development", RFC 6182, March 2011. 1512 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1513 4960, September 2007. 1515 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1516 Shim Protocol for IPv6", RFC 5533, June 2009. 1518 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1519 January 2008. 1521 [I-D.ietf-mmusic-rfc2326bis] 1522 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1523 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1524 (RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in 1525 progress), February 2014. 1527 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1528 A., Peterson, J., Sparks, R., Handley, M., and E. 1529 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1530 June 2002. 1532 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1533 with Session Description Protocol (SDP)", RFC 3264, June 1534 2002. 1536 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1537 Description Protocol", RFC 4566, July 2006. 1539 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1540 Keeping Alive the NAT Mappings Associated with RTP / RTP 1541 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1543 [I-D.singh-mmusic-mprtp-sdp-extension] 1544 Singh, V., Ott, J., Karkkainen, T., Globisch, R., and T. 1545 Schierl, "Multipath RTP (MPRTP) attribute in Session 1546 Description Protocol", draft-singh-mmusic-mprtp-sdp- 1547 extension-03 (work in progress), January 2014. 1549 [I-D.reddy-mmusic-ice-best-interface-pcp] 1550 Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun, 1551 "Improving ICE Interface Selection Using Port Control 1552 Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice- 1553 best-interface-pcp-00 (work in progress), October 2013. 1555 [I-D.wing-mmusic-ice-mobility] 1556 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 1557 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 1558 mobility-06 (work in progress), February 2014. 1560 [I-D.ietf-rmcat-eval-criteria] 1561 Singh, V. and J. Ott, "Evaluating Congestion Control for 1562 Interactive Real-time Media", draft-ietf-rmcat-eval- 1563 criteria-00 (work in progress), January 2014. 1565 [ACM-MPRTP] 1566 Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath 1567 considerations for real-time media", in Proc. of ACM 1568 Multimedia Systems, MMSys, 2013. 1570 Appendix A. Interoperating with Legacy Applications 1572 Some legacy endpoints may abort processing incoming packets, if they 1573 are received from different source address. This may occur due to 1574 the loop detection algorithm. Additionally, it is also possible for 1575 the receiver to reset processing of the stream if the jump in packet 1576 sequence numbers received over multiple interface is large. Both of 1577 these errors are based on implementation-specific details. 1579 An MPRTP sender can use its multiple interfaces to send media to a 1580 legacy RTP client. The legacy receiver will ignore the subflow RTP 1581 header extension and the receiver's de-jitter buffer will attempt to 1582 compensate for any mismatch in per-path latency. However, the 1583 receiver will only send the overall or aggregate RTCP report which 1584 may be insufficient for an MPRTP sender to adequately schedule 1585 packets over multiple paths or detect if a path disappeared. 1587 An MPRTP receiver can only use one of its interface when 1588 communicating with a legacy sender. 1590 Appendix B. Change Log 1592 Note to the RFC-Editor: please remove this section prior to 1593 publication as an RFC. 1595 B.1. Changes in draft-singh-avtcore-mprtp-10 1597 o Editorial updates based on review comments. 1599 o Renamed length to encaps_length. 1601 B.2. Changes in draft-singh-avtcore-mprtp-09 1603 o Editorial updates based on review comments. 1605 o Clarified use of a=rtcp-rsize. 1607 o Fixed bug in block length of interface advertisements. 1609 B.3. Changes in draft-singh-avtcore-mprtp-08 1611 o Added reference to use of PCP for discovering new interfaces. 1613 B.4. Changes in draft-singh-avtcore-mprtp-06 and -07 1615 o Added reference to Mobility ICE. 1617 B.5. Changes in draft-singh-avtcore-mprtp-05 1619 o SDP extensions moved to draft-singh-mmusic-mprtp-sdp-extension-00. 1620 Kept only the basic 'a=mprtp' attribute in this document. 1622 o Cleaned up ICE procedures for advertising only using in-band 1623 signaling. 1625 B.6. Changes in draft-singh-avtcore-mprtp-04 1627 o Fixed missing 0xBEDE header in MPRTP header format. 1629 o Removed connectivity checks and keep-alives from in-band 1630 signaling. 1632 o MPRTP and MPRTCP are multiplexed on a single port. 1634 o MPRTCP packet headers optimized. 1636 o Made ICE optional 1638 o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6. 1640 o Added how to use MPRTP in RTSP (Section 12). 1642 o Updated IANA Considerations section. 1644 B.7. Changes in draft-singh-avtcore-mprtp-03 1646 o Added this change log. 1648 o Updated section 6, 7 and 8 based on comments from MMUSIC. 1650 o Updated section 11 (SDP) based on comments of MMUSIC. 1652 o Updated SDP examples with ICE and non-ICE in out-of-band signaling 1653 scenario. 1655 o Added Appendix A on interop with legacy. 1657 o Updated IANA Considerations section. 1659 B.8. Changes in draft-singh-avtcore-mprtp-02 1661 o MPRTCP protocol extensions use only one PT=210, instead of 210 and 1662 211. 1664 o RTP header uses 1-byte extension instead of 2-byte. 1666 o Added section on RTCP Interval Calculations. 1668 o Added "mprtp-interface" attribute in SDP considerations. 1670 B.9. Changes in draft-singh-avtcore-mprtp-01 1672 o Added MPRTP and MPRTCP protocol extensions and examples. 1674 o WG changed from -avt to -avtcore. 1676 Editorial Comments 1678 [note-iceornot] Editor: Legacy applications do not require ICE for 1679 session establishment, therefore, MPRTP should not 1680 require it as well. 1682 [note-rtcp-reuse] Editor: inside the context of subflow specific reports 1683 can we reuse the payload type code for Sender Report 1684 (PT=200), Receiver Report (PT=201), Extension Report 1685 (PT=207). Transport and Payload specific RTCP 1686 messages are session specific and SHOULD be used as 1687 before. 1689 [note-rtp-rtcp-mux] Editor: If a=mprtp is indicated, does the endpoint 1690 need to indicate a=rtcp-mux and a=rtcp-rsize? 1691 because MPRTP mandates the use of RTP and RTCP 1692 multiplexing, and Reduced-Size RTCP. 1694 Authors' Addresses 1696 Varun Singh 1697 Aalto University 1698 School of Electrical Engineering 1699 Otakaari 5 A 1700 Espoo, FIN 02150 1701 Finland 1703 Email: varun@comnet.tkk.fi 1704 URI: http://www.netlab.tkk.fi/~varun/ 1705 Teemu Karkkainen 1706 Aalto University 1707 School of Electrical Engineering 1708 Otakaari 5 A 1709 Espoo, FIN 02150 1710 Finland 1712 Email: teemuk@comnet.tkk.fi 1714 Joerg Ott 1715 Aalto University 1716 School of Electrical Engineering 1717 Otakaari 5 A 1718 Espoo, FIN 02150 1719 Finland 1721 Email: jo@comnet.tkk.fi 1723 Saba Ahsan 1724 Aalto University 1725 School of Electrical Engineering 1726 Otakaari 5 A 1727 Espoo, FIN 02150 1728 Finland 1730 Email: saba.ahsan@aalto.fi 1732 Lars Eggert 1733 NetApp 1734 Sonnenallee 1 1735 Kirchheim 85551 1736 Germany 1738 Phone: +49 151 12055791 1739 Email: lars@netapp.com 1740 URI: http://eggert.org/