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