idnits 2.17.1 draft-singh-avtcore-mprtp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC3550' on line 939 -- Looks like a reference, but probably isn't: 'RFC4960' on line 151 -- Looks like a reference, but probably isn't: 'RFC6182' on line 151 -- Looks like a reference, but probably isn't: 'RFC5533' on line 151 -- Looks like a reference, but probably isn't: 'RFC2119' on line 160 -- Looks like a reference, but probably isn't: 'RFC5245' on line 1237 -- Looks like a reference, but probably isn't: 'RFC5117' on line 259 -- Looks like a reference, but probably isn't: 'RFC3264' on line 1270 -- Looks like a reference, but probably isn't: 'RFC3261' on line 461 -- Looks like a reference, but probably isn't: 'I-D.ietf-mmusic-rfc2326bis' on line 462 -- Looks like a reference, but probably isn't: 'RFC5760' on line 1091 -- Looks like a reference, but probably isn't: 'I-D.wing-mmusic-ice-mobility' on line 690 -- Looks like a reference, but probably isn't: 'I-D.singh-mmusic-mprtp-sdp-extension' on line 1322 -- Looks like a reference, but probably isn't: 'RFC6263' on line 733 -- Looks like a reference, but probably isn't: 'RFC5506' on line 780 -- Looks like a reference, but probably isn't: 'RFC4585' on line 1166 -- Looks like a reference, but probably isn't: 'RFC5285' on line 813 -- Looks like a reference, but probably isn't: 'RFC3629' on line 1162 -- Looks like a reference, but probably isn't: 'RFC5761' on line 1216 -- Looks like a reference, but probably isn't: 'RFC4566' on line 1387 -- Looks like a reference, but probably isn't: 'RFC3552' on line 1417 == Unused Reference: '10' is defined on line 1480, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 1484, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1501, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1511, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1515, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-04 ** Obsolete normative reference: RFC 4960 (ref. '3') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5117 (ref. '5') (Obsoleted by RFC 7667) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-34 ** Obsolete normative reference: RFC 4566 (ref. '9') (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 23 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: January 15, 2014 S. Ahsan 6 Aalto University 7 L. Eggert 8 NetApp 9 July 14, 2013 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-07 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 January 15, 2014. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . 17 97 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . 23 104 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 25 105 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 25 106 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . 25 107 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . 26 108 11.3. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . 26 109 11.4. Increased Throughput . . . . . . . . . . . . . . . . . . 27 110 11.5. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 27 111 11.5.1. In-band Signaling Example . . . . . . . . . . . . . 28 112 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . 30 118 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 119 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 120 15.1. Normative References . . . . . . . . . . . . . . . . . . 31 121 15.2. Informative References . . . . . . . . . . . . . . . . . 32 122 Appendix A. Interoperating with Legacy Applications . . . . . . 33 123 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 124 B.1. Changes in draft-singh-avtcore-mprtp-06 and -07 . . . . . 33 125 B.2. Changes in draft-singh-avtcore-mprtp-05 . . . . . . . . . 33 126 B.3. Changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 33 127 B.4. Changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 34 128 B.5. Changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 34 129 B.6. Changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 34 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 132 1. Introduction 134 Multi-homed endpoints are becoming common in today's Internet, e.g., 135 devices that support multiple wireless access technologies such as 3G 136 and Wireless LAN. This means that there is often more than one 137 network path available between two endpoints. Transport protocols, 138 such as RTP, have not been designed to take advantage of the 139 availability of multiple concurrent paths and therefore cannot 140 benefit from the increased capacity and reliability that can be 141 achieved by pooling their respective capacities. 143 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [RFC3550] that 144 allows splitting a single RTP stream into multiple subflows that are 145 transmitted over different paths. In effect, this pools the resource 146 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 147 to RTCP, it is used along with MPRTP to report per-path sender and 148 receiver characteristics. 150 Other IETF transport protocols that are capable of using multiple 151 paths include SCTP [RFC4960], MPTCP [RFC6182] and SHIM6 [RFC5533]. 152 However, these protocols are not suitable for real-time 153 communications. 155 1.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 1.2. Terminology 163 o Endpoint: host either initiating or terminating an RTP flow. 165 o Interface: logical or physical component that is capable of 166 acquiring a unique IP address. 168 o Path: sequence of links between a sender and a receiver. 169 Typically, defined by a set of source and destination addresses. 171 o Subflow: flow of RTP packets along a specific path, i.e., a subset 172 of the packets belonging to an RTP stream. The combination of all 173 RTP subflows forms the complete RTP stream. Typically, a subflow 174 would map to a unique path, i.e., each combination of IP addresses 175 and port pairs (5-tuple, including protocol) is a unique subflow. 177 1.3. Use-cases 179 The primary use-case for MPRTP is transporting high bit-rate 180 streaming multimedia content between endpoints, where at least one is 181 multi-homed. Such endpoints could be residential IPTV devices that 182 connect to the Internet through two different Internet service 183 providers (ISPs), or mobile devices that connect to the Internet 184 through 3G and WLAN interfaces. By allowing RTP to use multiple 185 paths for transmission, the following gains can be achieved: 187 o Higher quality: Pooling the resource capacity of multiple Internet 188 paths allows higher bit-rate and higher quality codecs to be used. 189 From the application perspective, the available bandwidth between 190 the two endpoints increases. 192 o Load balancing: Transmitting an RTP stream over multiple paths 193 reduces the bandwidth usage on a single path, which in turn 194 reduces the impact of the media stream on other traffic on that 195 path. 197 o Fault tolerance: When multiple paths are used in conjunction with 198 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 199 one path have less impact on the overall perceived quality of the 200 stream. 202 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 203 calls to a device with multiple interfaces. Again, such an endpoint 204 could be a mobile device with multiple wireless interfaces. In this 205 case, little is to be gained from resource pooling, i.e., higher 206 capacity or load balancing, because a single path should be easily 207 capable of handling the required load. However, using multiple 208 concurrent subflows can improve fault tolerance, because traffic can 209 shift between the subflows when path outages occur. This results in 210 very fast transport-layer handovers that do not require support from 211 signaling. 213 2. Goals 215 This section outlines the basic goals that multipath RTP aims to 216 meet. These are broadly classified as Functional goals and 217 Compatibility goals. 219 2.1. Functional goals 221 Allow unicast RTP session to be split into multiple subflows in order 222 to be carried over multiple paths. This may prove beneficial in case 223 of video streaming. 225 o Increased Throughput: Cumulative capacity of the two paths may 226 meet the requirements of the multimedia session. Therefore, MPRTP 227 MUST support concurrent use of the multiple paths. 229 o Improved Reliability: MPRTP SHOULD be able to send redundant 230 packets or re-transmit packets along any available path to 231 increase reliability. 233 The protocol SHOULD be able to open new subflows for an existing 234 session when new paths appear and MUST be able to close subflows when 235 paths disappear. 237 2.2. Compatibility goals 238 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 239 back to be compatible with legacy RTP stacks if MPRTP support is not 240 successfully negotiated. 242 o Application Compatibility: MPRTP service model MUST be backwards 243 compatible with existing RTP applications, i.e., an MPRTP stack 244 MUST be able to work with legacy RTP applications and not require 245 changes to them. Therefore, the basic RTP APIs MUST remain 246 unchanged, but an MPRTP stack MAY provide extended APIs so that 247 the application can configure any additional features provided by 248 the MPRTP stack. 250 o Network Compatibility: individual RTP subflows MUST themselves be 251 well-formed RTP flows, so that they are able to traverse NATs and 252 firewalls. This MUST be the case even when interfaces appear 253 after session initiation. Interactive Connectivity Establishment 254 (ICE) [RFC5245] MAY be used for discovering new interfaces or 255 performing connectivity checks. 257 3. RTP Topologies 259 RFC 5117 [RFC5117] describes a number of scenarios using mixers and 260 translators in single-party (point-to-point), and multi-party (point- 261 to-multipoint) scenarios. RFC 3550 [RFC3550] (Section 2.3 and 7.x) 262 discuss in detail the impact of mixers and translators on RTP and 263 RTCP packets. MPRTP assumes that if a mixer or translator exists in 264 the network, then either all of the multiple paths or none of the 265 multiple paths go via this component. 267 4. MPRTP Architecture 269 In a typical scenario, an RTP session uses a single path. In an 270 MPRTP scenario, an RTP session uses multiple subflows that each use a 271 different path. Figure 1 shows the difference. 273 +--------------+ Signaling +--------------+ 274 | |------------------------------------>| | 275 | Client |<------------------------------------| Server | 276 | | Single RTP flow | | 277 +--------------+ +--------------+ 279 +--------------+ Signaling +--------------+ 280 | |------------------------------------>| | 281 | Client |<------------------------------------| Server | 282 | |<------------------------------------| | 283 +--------------+ MPRTP subflows +--------------+ 285 Figure 1: Comparison between traditional RTP streaming and MPRTP 287 +-----------------------+ +-------------------------------+ 288 | Application | | Application | 289 +-----------------------+ +-------------------------------+ 290 | | | MPRTP | 291 + RTP + +- - - - - - - -+- - - - - - - -+ 292 | | | RTP subflow | RTP subflow | 293 +-----------------------+ +---------------+---------------+ 294 | UDP | | UDP | UDP | 295 +-----------------------+ +---------------+---------------+ 296 | IP | | IP | IP | 297 +-----------------------+ +---------------+---------------+ 299 Figure 2: MPRTP Architecture 301 Figure 2 illustrates the differences between the standard RTP stack 302 and the MPRTP stack. MPRTP receives a normal RTP session from the 303 application and splits it into multiple RTP subflows. Each subflow 304 is then sent along a different path to the receiver. To the network, 305 each subflow appears as an independent, well-formed RTP flow. At the 306 receiver, the subflows are combined to recreate the original RTP 307 session. The MPRTP layer performs the following functions: 309 o Path Management: The layer is aware of alternate paths to the 310 other host, which may, for example, be the peer's multiple 311 interfaces. This enables the endpoint to transmit differently 312 marked packets along separate paths. MPRTP also selects 313 interfaces to send and receive data. Furthermore, it manages the 314 port and IP address pair bindings for each subflow. 316 o Packet Scheduling: the layer splits a single RTP flow into 317 multiple subflows and sends them across multiple interfaces 318 (paths). The splitting MAY BE done using different path 319 characteristics. 321 o Subflow recombination: the layer creates the original stream by 322 recombining the independent subflows. Therefore, the multipath 323 subflows appear as a single RTP stream to applications. 325 5. Example Media Flow Diagrams 327 There may be many complex technical scenarios for MPRTP, however, 328 this memo only considers the following two scenarios: 1) a 329 unidirectional media flow that represents the streaming use-case, and 330 2) a bidirectional media flow that represents a conversational use- 331 case. 333 5.1. Streaming use-case 334 In the unidirectional scenario, the receiver (client) initiates a 335 multimedia session with the sender (server). The receiver or the 336 sender may have multiple interfaces and both endpoints are MPRTP- 337 capable. Figure 3 shows this scenario. In this case, host A has 338 multiple interfaces. Host B performs connectivity checks on host A's 339 multiple interfaces. If the interfaces are reachable, then host B 340 streams multimedia data along multiple paths to host A. Moreover, 341 host B also sends RTCP Sender Reports (SR) for each subflow and host 342 A responds with a normal RTCP Receiver Report (RR) for the overall 343 session as well as the receiver statistics for each subflow. Host B 344 distributes the packets across the subflows based on the individually 345 measured path characteristics. 347 Alternatively, to reduce media startup time, host B may start 348 streaming multimedia data to host A's initiating interface and then 349 perform connectivity checks for the other interfaces. This method of 350 updating a single path session to a multipath session is called 351 "multipath session upgrade". 353 Host A Host B 354 ----------------------- ---------- 355 Interface A1 Interface A2 Interface B1 356 ----------------------- ---------- 357 | | 358 |------------------------------------->| Session setup with 359 |<-------------------------------------| multiple interfaces 360 | | | 361 | | | 362 | (RTP data B1->A1, B1->A2) | 363 |<=====================================| 364 | |<========================| 365 | | | 366 Note: there may be more scenarios. 368 Figure 3: Unidirectional media flow 370 5.2. Conversational use-case 372 In the bidirectional scenario, multimedia data flows in both 373 directions. The two hosts exchange their lists of interfaces with 374 each other and perform connectivity checks. Communication begins 375 after each host finds suitable address, port pairs. Interfaces that 376 receive data send back RTCP receiver statistics for that path (based 377 on the 5-tuple). The hosts balance their multimedia stream across 378 multiple paths based on the per path reception statistics and its own 379 volume of traffic. Figure 4 describes an example of a bidirectional 380 flow. 382 Host A Host B 383 --------------------------- --------------------------- 384 Interface A1 Interface A2 Interface B1 Interface B2 385 --------------------------- --------------------------- 386 | | | | 387 | | | |Session setup 388 |----------------------------------->| |with multiple 389 |<-----------------------------------| |interfaces 390 | | | | 391 | | | | 392 | (RTP data B1<->A1, B2<->A2) | | 393 |<===================================| | 394 | |<===================================| 395 |===================================>| | 396 | |===================================>| 397 | | | | 398 Note: the address pairs may have other permutations, 399 and they may be symmetric or asymmetric combinations. 401 Figure 4: Bidirectional flow 403 6. MPRTP Functional Blocks 405 This section describes some of the functional blocks needed for 406 MPRTP. We then investigate each block and consider available 407 mechanisms in the next section. 409 1. Session Setup: Interfaces may appear or disappear at anytime 410 during the session. To preserve backward compatibility with 411 legacy applications, a multipath session MUST look like a bundle 412 of individual RTP sessions. A multipath session may be upgraded 413 from a typical single path session, as and when new interfaces 414 appear or disappear. However, it is also possible to setup a 415 multipath session from the beginning, if the interfaces are 416 available at the start of the multimedia session. 418 2. Expanding RTP: For a multipath session, each subflow MUST look 419 like an independent RTP flow, so that individual RTCP messages 420 can be generated per subflow. Furthermore, MPRTP splits the 421 single multimedia stream into multiple subflows based on path 422 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 423 delay product etc.) and dynamically adjusts the load on each 424 link. 426 3. Adding Interfaces: Interfaces on the host need to be regularly 427 discovered and advertised. This can be done at session setup and 428 /or during the session. Discovering interfaces is outside the 429 scope of this document. 431 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 432 monitoring the quality of the path, for load balancing, or for 433 congestion control, etc. To maintain backward compatibility with 434 legacy applications, the receiver MUST also send aggregate RTCP 435 reports along with the per-path reports. 437 5. Maintenance and Failure Handling: In a multi-homed endpoint 438 interfaces may appear and disappear. If this occurs at the 439 sender, it has to re-adjust the load on the available links. On 440 the other hand, if this occurs at the receiver, then the 441 multimedia data transmitted by the sender to those interfaces is 442 lost. This data may be re-transmitted along a different path 443 i.e., to a different interface on the receiver. Furthermore, the 444 endpoint has to either explicitly signal the disappearance of an 445 interface, or the other endpoint has to detect it (by lack of 446 media packets, RTCP feedback, or keep-alive packets). 448 6. Teardown: The MPRTP layer releases the occupied ports on the 449 interfaces. 451 7. Available Mechanisms within the Functional Blocks 453 This section discusses some of the possible alternatives for each 454 functional block mentioned in the previous section. 456 7.1. Session Setup 458 MPRTP session can be set up in many possible ways e.g., during 459 handshake, or upgraded mid-session. The capability exchange may be 460 done using out-of-band signaling (e.g., Session Description Protocol 461 (SDP) [RFC3264] in Session Initiation Protocol (SIP) [RFC3261], Real- 462 Time Streaming Protocol (RTSP) [I-D.ietf-mmusic-rfc2326bis]) or in- 463 band signaling (e.g., RTP/RTCP header extension, Session Traversal 464 Utilities for NAT (STUN) messages). 466 7.1.1. Connectivity Checks 468 The endpoint SHOULD be capable of performing connectivity checks 469 (e.g., using ICE [RFC5245]). If the IP addresses of the endpoints 470 are reachable (e.g., globally addressable, same network etc) then 471 connectivity checks are not needed. 473 7.1.2. Adding New or Updating Interfaces 475 Interfaces can appear and disappear during a session, the endpoint 476 MUST be capable of advertising the changes in its set of usable 477 interfaces. Additionally, the application or OS may define a policy 478 on when and/or what interfaces are usable. However, MPRTP requires a 479 method to advertise or notify the other endpoint about the updated 480 set of usable interfaces. 482 7.1.3. In-band vs. Out-of-band Signaling 484 MTRTP nodes will generally use a signaling protocol to establish 485 their MPRTP session. With the existence of such a signaling 486 relationship, two alternatives become available to exchange 487 information about the available interfaces on each side for extending 488 RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and 489 out-of-band signaling. 491 In-band signaling refers to using mechanisms of RTP/RTCP itself to 492 communicate interface addresses, e.g., a dedicated RTCP extensions 493 along the lines of the one defined to communicate information about 494 the feedback target for RTP over SSM [RFC5760]. In-band signaling 495 does not rely on the availability of a separate signaling connection 496 and the information flows along the same path as the media streams, 497 thus minimizing dependencies. Moreover, if the media channel is 498 secured (e.g., by means of SRTP), the signaling is implicitly 499 protected as well if SRTCP encryption and authentication are chosen. 500 In-band signaling is also expected to take a direct path to the peer, 501 avoiding any signaling overlay-induced indirections and associated 502 processing overheads in signaling elements -- avoiding such may be 503 especially worthwhile if frequent updates may occur as in the case of 504 mobile users. Finally, RTCP is usually sent sufficiently frequently 505 (in point-to-point settings) to provide enough opportunities for 506 transmission and (in case of loss) retransmission of the 507 corresponding RTCP packets. 509 Examples for in-band signaling include RTCP extensions as noted above 510 or suitable extensions to STUN [I-D.wing-mmusic-ice-mobility]. 512 Out-of-band signaling refers to using a separate signaling connection 513 (via SIP, RTSP, or HTTP) to exchange interface information, e.g., 514 expressed in SDP. Clear benefits are that signaling occurs at setup 515 time anyway and that experience and SDP syntax (and procedures) are 516 available that can be re-used or easily adapted to provide the 517 necessary capabilities. In contrast to RTCP, SDP offers a reliable 518 communication channel so that no separate retransmissions logic is 519 necessary. In SDP, especially when combined with ICE, connectivity 520 check mechanisms including sophisticated rules are readily available. 521 While SDP is not inherently protected, suitable security may need to 522 be applied anyway to the basic session setup. 524 Examples for out-of-band signaling are dedicated extensions to SDP; 525 those may be combined with ICE. 527 Both types of mechanisms have their pros and cons for middleboxes. 528 With in-band signaling, control packets take the same path as the 529 media packets and they can be directly inspected by middleboxes so 530 that the elements operating on the signaling channel do not need to 531 understand new SDP. With out-of-band signaling, only the middleboxes 532 processing the signaling need to be modified and those on the data 533 forwarding path can remain untouched. 535 Overall, it may appear sensible to provide a combination of both 536 mechanisms: out-of-band signaling for session setup and initial 537 interface negotiation and in-band signaling to deal with frequent 538 changes in interface state (and for the potential case, albeit rather 539 theoretical case of MPRTP communication without a signaling channel). 541 In its present version, this document explores both options to 542 provide a broad understanding of how the corresponding mechanisms 543 would look like. 545 7.2. Expanding RTP 547 RTCP [RFC3550] is generated per media session. However, with MPRTP, 548 the media sender spreads the RTP load across several interfaces. The 549 media sender SHOULD make the path selection, load balancing and fault 550 tolerance decisions based on the characteristics of each path. 551 Therefore, apart from normal RTP sequence numbers defined in 552 [RFC3550], the MPRTP sender MUST add subflow-specific sequence 553 numbers to help calculate fractional losses, jitter, RTT, playout 554 time, etc., for each path, and a subflow identifier to associate the 555 characteristics with a path. The RTP header extension for MPRTP is 556 shown in Section 9.1. 558 7.3. Expanding RTCP 560 To provide accurate per path information an MPRTP endpoint MUST send 561 (SR/RR) report for each unique subflow along with the overall session 562 RTCP report. Therefore, the additional subflow reporting affects the 563 RTCP bandwidth and the RTCP reporting interval. RTCP report 564 scheduling for each subflow may cause a problem for RTCP 565 recombination and reconstruction in cases when 1) RTCP for a subflow 566 is lost, and 2) RTCP for a subflow arrives later than the other 567 subflows. (There may be other cases as well.) 569 The sender distributes the media across different paths using the per 570 path RTCP reports. However, this document doesn't cover algorithms 571 for congestion control or load balancing. 573 7.4. Failure Handling and Teardown 574 An MPRTP endpoint MUST keep alive subflows that have been negotiated 575 but no media is sent on them. Moreover, using the information in the 576 subflow reports, a sender can monitor an active subflow for failure 577 (errors, unreachability, congestion) and decide not to use (make the 578 active subflow passive), or teardown the subflow. 580 If an interface disappears, the endpoint MUST send an updated 581 interface advertisement without the interface and release the the 582 associated subflows. 584 8. MPRTP Protocol 586 Host A Host B 587 ----------------------- ----------------------- 588 Interface A1 Interface A2 Interface B1 Interface B2 589 ----------------------- ----------------------- 590 | | | | 591 | | (1) | | 592 |--------------------------------------->| | 593 |<---------------------------------------| | 594 | | (2) | | 595 |<=======================================| | 596 |<=======================================| (3) | 597 | | (4) | | 598 |<- - - - - - - - - - - - - - - - - - - -| | 599 |<- - - - - - - - - - - - - - - - - - - -| | 600 |<- - - - - - - - - - - - - - - - - - - -| | 601 | | (5) | | 602 |- - - - - - - - - - - - - - - - - - - ->| | 603 |<=======================================| (6) | 604 |<=======================================| | 605 | |<========================================| 606 |<=======================================| | 607 | |<========================================| 609 Key: 610 | Interface 611 ---> Signaling Protocol 612 <=== RTP Packets 613 - -> RTCP Packet 615 Figure 5: MPRTP New Interface 617 8.1. Overview 619 The bullet points explain the different steps shown in Figure 5 for 620 upgrading a single path multimedia session to multipath session. 622 (1) The first two interactions between the hosts represents the 623 establishment of a normal RTP session. This may performed e.g. 624 using SIP or RTSP. 626 (2) When the RTP session has been established, host B streams 627 media using its interface B1 to host A at interface A1. 629 (3) Host B supports sending media using MPRTP and becomes aware of 630 an additional interface B2. 632 (4) Host B advertises the multiple interface addresses. 634 (5) Host A supports receiving media using MPRTP and becomes aware 635 of an additional interface A2. 637 Side note, even if an MPRTP-capable host has only one interface, 638 it MUST respond to the advertisement with its single interface. 640 (6) Each host receives information about the additional interfaces 641 and the appropriate endpoints starts to stream the multimedia 642 content using the additional paths. 644 If needed, each endpoint will need to independently perform 645 connectivity checks (not shown in figure) and ascertain 646 reachability before using the paths. 648 8.1.1. Gather or Discovering Candidates 650 The endpoint periodically polls the operating system or is notified 651 when an additional interface appears. If the endpoint wants to use 652 the additional interface for MPRTP it MUST advertise it to the other 653 peers. The endpoint may also use ICE [RFC5245] to gather additional 654 candidates. 656 8.1.2. NAT Traversal 658 After gathering their interface candidates, the endpoints decide 659 internally if they wish to perform connectivity checks. 661 [[: note-iceornotLegacy applications do not require ICE for session 662 establishment, therefore, MPRTP should not require it as well.]] 663 If the endpoint chooses to perform connectivity checks then it MUST 664 first advertise the gathered candidates as ICE candidates in SDP 665 during session setup and let ICE perform the connectivity checks. As 666 soon as a sufficient number of connectivity checks succeed, the 667 endpoint can use the successful candidates to advertise its MPRTP 668 interface candidates. 670 Alternatively, if the endpoint supports mobility extensions for ICE 671 [I-D.wing-mmusic-ice-mobility], it can let the ICE agent gather and 672 perform the connectivity checks. When the connectivity checks 673 succeed, the ICE agent should notify the MPRTP layer of these new 674 paths (5-tuples) so that these new paths can be used by MPRTP to send 675 media packets. 677 [Editors note: The interaction between the RTP agent and ICE agent is 678 needed for implementing a scheduling algorithm or congestion 679 control.] 681 8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP) 682 Interface Advertisement 684 If there is no media flowing at the moment and the application wants 685 to use the interfaces from the start of the session, it should 686 advertise them in SDP (See [I-D.singh-mmusic-mprtp-sdp-extension]). 687 Alternatively, the endpoint can setup the session as a single path 688 media session and upgrade the session to multipath by advertising the 689 session in-band (See Section 8.1.4 or 690 [I-D.wing-mmusic-ice-mobility]). Moreover, if an interface appears 691 and disappears, the endpoint SHOULD prefer to advertise it in-band 692 because the endpoint would not have to wait for a response from the 693 other endpoint before starting to use the interface. However, if 694 there is a conflict between an in-band and out-of-band advertisement, 695 i.e., the endpoint receives an in-band advertisement while it has a 696 pending out-of-band advertisement, or vice versa then the session is 697 setup using out-of-band mechanisms. 699 8.1.4. In-band Interface Advertisement 701 To advertise the multiple interfaces in RTCP, an MPRTP-capable 702 endpoint MUST add the MPRTP Interface Advertisement defined in Figure 703 13 with the RTCP Sender Report (SR). Each unique address is 704 encapsulated in an Interface Advertisement block and contains the IP 705 address, RTP and RTCP port addresses. The Interface Advertisement 706 blocks are ordered based on a decreasing priority level. On 707 receiving the MPRTP Interface Advertisement, an MPRTP-capable 708 receiver MUST respond with the set of interfaces (subset or all 709 available) it wants to use. 711 If the sender and receiver have only one interface, then the 712 endpoints MUST indicate the negotiated single path IP, RTP port and 713 RTCP port addresses. 715 8.1.5. Subflow ID Assignment 717 After interface advertisements have been exchanged, the endpoint MUST 718 associate a Subflow ID to each unique subflow. Each combination of 719 sender and receiver IP addresses and port pairs (5-tuple) is a unique 720 subflow. If the connectivity checks have been performed then the 721 endpoint MUST only use the subflows for which the connectivity checks 722 have succeeded. 724 8.1.6. Active and Passive Subflows 726 To send and receive data an endpoint MAY use any number of subflows 727 from the set of available subflows. The subflows that carry media 728 data are called active subflows, while those subflows that don't send 729 any media packets (fallback paths) are called passive subflows. 731 An endpoint MUST multiplex the subflow specific RTP and RTCP packets 732 on the same port to keep the NAT bindings alive. This is inline with 733 the recommendation made in RFC6263[RFC6263]. Moreover, if an 734 endpoint uses ICE, multiplexing RTP and RTCP reduces the number of 735 components from 2 to 1 per media stream. If no MPRTP or MPRTCP 736 packets are received on a particular subflow at a receiver, the 737 receiver SHOULD remove the subflow from active and passive lists and 738 not send any MPRTCP reports for that subflow. It may keep the 739 bindings in a dead-pool, so that if the 5-tuple or subflow reappears, 740 it can quickly reallocate it based on past history. 742 8.2. RTP Transmission 744 If both endpoints are MPRTP-capable and if they want to use their 745 multiple interfaces for sending the media stream then they MUST use 746 the MPRTP header extensions. They MAY use normal RTP with legacy 747 endpoints (see Appendix A). 749 An MPRTP endpoint sends RTP packets with an MPRTP extension that maps 750 the media packet to a specific subflow (see Figure 8). The MPRTP 751 layer SHOULD associate an RTP packet with a subflow based on a 752 scheduling strategy. The scheduling strategy may either choose to 753 augment the paths to create higher throughput or use the alternate 754 paths for enhancing resilience or error-repair. Due to the changes 755 in path characteristics, the endpoint should be able change its 756 scheduling strategy during an ongoing session. The MPRTP sender MUST 757 also populate the subflow specific fields described in the MPRTP 758 extension header (see Section 9.1.1). 760 8.3. Playout Considerations at the Receiver 762 A media receiver, irrespective of MPRTP support or not, should be 763 able to playback the media stream because the received RTP packets 764 are compliant to [RFC3550], i.e., a non-MPRTP receiver will ignore 765 the MPRTP header and still be able to playback the RTP packets. 766 However, the variation of jitter and loss per path may affect proper 767 playout. The receiver can compensate for the jitter by modifying the 768 playout delay (i.e., by calculating skew across all paths) of the 769 received RTP packets. 771 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 773 Aggregate RTCP provides the overall media statistics and follows the 774 normal RTCP defined in RFC3550 [RFC3550]. However, subflow specific 775 RTCP provides the per path media statistics because the aggregate 776 RTCP report may not provide sufficient per path information to an 777 MPRTP scheduler. Specifically, the scheduler should be aware of each 778 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 779 The sender/receiver MUST use non-compound RTCP reports defined in 780 RFC5506 [RFC5506] to transmit the aggregate and subflow-specific RTCP 781 reports. Also, each subflow and the aggregate RTCP report MUST 782 follow the timing rules defined in [RFC4585]. 784 The RTCP reporting interval is locally implemented and the scheduling 785 of the RTCP reports may depend on the the behavior of each path. For 786 instance, the RTCP interval may be different for a passive path than 787 an active path to keep port bindings alive. Additionally, an 788 endpoint may decide to share the RTCP reporting bit rate equally 789 across all its paths or schedule based on the receiver rate on each 790 path. 792 8.5. RTCP Transmission 794 The sender sends an RTCP SR on each active path. For each SR the 795 receiver gets, it echoes one back to the same IP address-port pair 796 that sent the SR. The receiver tries to choose the symmetric path 797 and if the routing is symmetric then the per-path RTT calculations 798 will work out correctly. However, even if the paths are not 799 symmetric, the sender would at maximum, under-estimate the RTT of the 800 path by a factor of half of the actual path RTT. 802 9. Packet Formats 804 In this section we define the protocol structures described in the 805 previous sections. 807 9.1. RTP Header Extension for MPRTP 809 The MPRTP header extension is used to distribute a single RTP stream 810 over multiple subflows. 812 The header conforms to the one-byte RTP header extension defined in 813 [RFC5285]. The header extension contains a 16-bit length field that 814 counts the number of 32-bit words in the extension, excluding the 815 four-octet extension header (therefore zero is a valid length, see 816 Section 5.3.1 of [RFC3550] for details). 818 The RTP header for each subflow is defined below: 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 |V=2|P|1| CC |M| PT | sequence number | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | timestamp | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | synchronization source (SSRC) identifier | 828 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 829 | 0xBE | 0xDE | length=N-1 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | ID | LEN | MPID |LENGTH | MPRTP header data | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 833 | .... | 834 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 835 | RTP payload | 836 | .... | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 6: Generic MPRTP header extension 841 MPID: 843 The MPID field corresponds to the type of MPRTP packet. 844 Namely: 846 +---------------+--------------------------------------------------+ 847 | MPID ID | Use | 848 | Value | | 849 +---------------+--------------------------------------------------+ 850 | 0x0 | Subflow RTP Header. For this case the Length is | 851 | | set to 4 | 852 +---------------+--------------------------------------------------+ 854 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 856 length 858 The 4-bit length field is the length of extension data in bytes 859 not including the H-Ext ID and length fields. The value zero 860 indicates there is no data following. 862 MPRTP header data 864 Carries the MPID specific data as described in the following 865 sub-sections. 867 9.1.1. MPRTP RTP Extension for a Subflow 869 The RTP header for each subflow is defined below: 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 |V=2|P|1| CC |M| PT | sequence number | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | timestamp | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | synchronization source (SSRC) identifier | 879 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 880 | 0xBE | 0xDE | length=2 | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | ID | LEN=4 | 0x0 | LEN=4 | Subflow ID | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 885 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 886 | RTP payload | 887 | .... | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 8: MPRTP header for subflow 892 MP ID = 0x0 894 Indicates that the MPRTP header extension carries subflow 895 specific information. 897 length = 4 899 Subflow ID: Identifier of the subflow. Every RTP packet belonging 900 to the same subflow carries the same unique subflow identifier. 902 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 903 the subflow. Each subflow has its own strictly monotonically 904 increasing sequence number space. 906 9.2. RTCP Extension for MPRTP (MPRTCP) 908 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 909 per subflow to determine the characteristics of each path, and 2) 910 advertise each interface. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |V=2|P|reserved | PT=MPRTCP=211 | length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | SSRC of packet sender | 918 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 919 | SSRC_1 (SSRC of first source) | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | MPRTCP_Type | block length | | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP Reports | 923 | ... | 924 | ... | 925 | ... | 926 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 928 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 929 normal SR/RR] 931 MPRTCP: 8 bits 933 Contains the constant 211 to identify this as an Multipath RTCP 934 packet. 936 length: 16 bits 938 As described for the RTCP packet (see Section 6.4.1 of the RTP 939 specification [RFC3550]), the length of this is in 32-bit words 940 minus one, including the header and any padding. 942 MPRTCP_Type: 8-bits 944 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 945 packet. Namely: 947 +---------------+--------------------------------------------------+ 948 | MPRTCP_Type | Use | 949 | Value | | 950 +---------------+--------------------------------------------------+ 951 | 0 | Subflow Specific Report | 952 | 1 | Interface Advertisement (IPv4 Address) | 953 | 2 | Interface Advertisement (IPv4 Address) | 954 | 3 | Interface Advertisement (DNS Address) | 955 +---------------+--------------------------------------------------+ 957 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 959 block length: 8-bits 961 The 8-bit length field is the length of the encapsulated MPRTCP 962 reports in 32-bit word length not including the MPRTCP_Type and 963 length fields. The value zero indicates there is no data 964 following. 966 MPRTCP Reports: variable size 968 Defined later in 9.2.1 and 9.3. 970 9.2.1. MPRTCP Extension for Subflow Reporting 972 When sending a report for a specific subflow the sender or receiver 973 MUST add only the reports associated with that 5-tuple. Each subflow 974 is reported independently using the following MPRTCP Feedback header. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |V=2|P|reserved | PT=MPRTCP=211 | length | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | SSRC of packet sender | 982 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 983 | SSRC_1 (SSRC of first source) | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | MPRTCP_Type=0 | block length | Subflow ID #1 | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Subflow-specific reports | 988 | .... | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | MPRTCP_Type=0 | block length | Subflow ID #2 | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Subflow-specific reports | 993 | .... | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Figure 11: MPRTCP Subflow Reporting Header 998 MPRTCP_Type: 0 1000 The value indicates that the encapsulated block is a subflow 1001 report. 1003 block length: 8-bits 1005 The 8-bit length field is the length of the encapsulated subflow- 1006 specific reports in 32-bit word length not including the 1007 MPRTCP_Type and length fields. 1009 Subflow ID: 16 bits 1011 Subflow identifier is the value associated with the subflow the 1012 endpoint is reporting about. If it is a sender it MUST use the 1013 Subflow ID associated with the 5-tuple. If it is a receiver it 1014 MUST use the Subflow ID received in the Subflow-specific Sender 1015 Report. 1017 Subflow-specific reports: variable 1019 Subflow-specific report contains all the reports associated with 1020 the Subflow ID. For a sender, it MUST include the Subflow- 1021 specific Sender Report (SSR). For a receiver, it MUST include 1022 Subflow-specific Receiver Report (SRR). Additionally, if the 1023 receiver supports subflow-specific extension reports then it MUST 1024 append them to the SRR. 1026 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 1028 [[: note-rtcp-reuseinside the context of subflow specific reports can 1029 we reuse the payload type code for Sender Report (PT=200), Receiver 1030 Report (PT=201), Extension Report (PT=207). Transport and Payload 1031 specific RTCP messages are session specific and SHOULD be used as 1032 before.]] 1034 Example: 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 |V=2|P|reserved | PT=MPRTCP=211 | length | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | SSRC of packet sender | 1042 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1043 | SSRC_1 (SSRC of first source) | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1046 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1047 |V=2|P| RC | PT=SR=200 | length | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | SSRC of sender | 1050 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1051 | NTP timestamp, most significant word | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | NTP timestamp, least significant word | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | RTP timestamp | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | subflow's packet count | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | subflow's octet count | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1062 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1063 |V=2|P| RC | PT=RR=201 | length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | SSRC of packet sender | 1066 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1067 | fraction lost | cumulative number of packets lost | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | extended highest sequence number received | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | inter-arrival jitter | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | last SR (LSR) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | delay since last SR (DLSR) | 1076 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1077 | Subflow specific extension reports | 1078 | .... | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1082 (Bi-directional use-case, in case of uni-directional flow the subflow 1083 will only send an SR or RR). 1085 9.3. MPRTCP Extension for Interface advertisement 1087 This sub-section defines the RTCP header extension for in-band 1088 interface advertisement by the receiver. The interface advertisement 1089 block describes a method to represent IPv4, IPv6 and generic DNS-type 1090 addresses in a block format. It is based on the sub-reporting block 1091 in [RFC5760]. The interface advertisement SHOULD immediately follow 1092 the Receiver Report. If the Receiver Report is not present, then it 1093 MUST be appended to the Sender Report. 1095 The endpoint MUST advertise the interfaces it wants to use whenever 1096 an interface appears or disappears and also when it receives an 1097 Interface Advertisement. 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 |V=2|P|reserved | PT=MPRTCP=211 | length | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | SSRC of packet sender | 1105 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1106 | SSRC_1 (SSRC of first source) | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | MPRTCP_Type | block length | RTP Port | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Interface Address #1 | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | MPRTCP_Type | block length | RTP Port | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Interface Address #2 | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | MPRTCP_Type | block length | RTP Port | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Interface Address #.. | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | MPRTCP_Type | block length | RTP Port | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Interface Address #m | 1123 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1125 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1127 MPRTCP_Type: 8 bits 1129 The MPRTCP_Type corresponds to the type of interface address. 1130 Namely: 1132 1: IPv4 address 1134 2: IPv6 address 1136 3: DNS name 1138 block length: 8 bits 1140 The length of the Interface Advertisement block in bytes. 1142 For an IPv4 address, this should be 9 (i.e., 5 octets for 1143 the header and 4 octets for IPv4 address). 1145 For an IPv6 address, this should be 21. 1147 For a DNS name, the length field indicates the number of 1148 octets making up the string plus the 5 byte header. 1150 RTP Port: 2 octets 1152 The port number to which the sender sends RTP data. A port 1153 number of 0 is invalid and MUST NOT be used. 1155 Interface Address: 4 octets (IPv4), 16 octets (IPv6), or n octets 1156 (DNS name) 1158 The address to which receivers send feedback reports. For IPv4 1159 and IPv6, fixed-length address fields are used. A DNS name is 1160 an arbitrary-length string. The string MAY contain 1161 Internationalizing Domain Names in Applications (IDNA) domain 1162 names and MUST be UTF-8 [RFC3629] encoded. 1164 10. RTCP Timing reconsiderations for MPRTCP 1166 MPRTP endpoints MUST conform to the timing rule imposed in [RFC4585], 1167 i.e., the total RTCP rate between the participants MUST NOT exceed 5% 1168 of the media rate. For each endpoint, a subflow MUST send the 1169 aggregate and subflow-specific report. The endpoint SHOULD schedule 1170 the RTCP reports for the active subflows based on the share of the 1171 transmitted or received bit rate to the average media bit rate, this 1172 method ensures fair sharing of the RTCP bandwidth. Alternatively, 1173 the endpoint MAY schedule the reports in round-robin. 1175 11. SDP Considerations 1177 11.1. Signaling MPRTP Header Extension in SDP 1179 To indicate the use of the MPRTP header extensions (see Section 9) in 1180 SDP, the sender MUST use the following URI in extmap: urn:ietf:params 1181 :rtp-hdrext:mprtp. This is a media level parameter. Legacy RTP 1182 (non-MPRTP) clients will ignore this header extension, but can 1183 continue to parse and decode the packet (see Appendix A). 1185 Example: 1187 v=0 1188 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1189 s= 1190 c=IN IP4 192.0.2.1 1191 t=0 0 1192 m=video 49170 RTP/AVP 98 1193 a=rtpmap:98 H264/90000 1194 a=fmtp:98 profile-level-id=42A01E; 1195 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1197 11.2. Signaling MPRTP capability in SDP 1199 A participant of a media session MUST use SDP to indicate that it 1200 supports MPRTP. Not providing this information will make the other 1201 endpoint ignore the RTCP extensions. 1203 mprtp-attrib = "a=" "mprtp" [ 1204 SP mprtp-optional-parameter] 1205 CRLF ; flag to enable MPRTP 1207 The endpoint MUST use 'a=mprtp', if it is able to send and receive 1208 MPRTP packets. Generally, senders and receivers MUST indicate this 1209 capability if they support MPRTP and would like to use it in the 1210 specific media session being signaled. To exchange the additional 1211 interfaces, the endpoint SHOULD use the in-band signaling (See 1212 Section 9.3). Alternatively, advertise in SDP (See 1213 [I-D.singh-mmusic-mprtp-sdp-extension]). 1215 MPRTP endpoint multiplexes RTP and RTCP on a single port, sender MUST 1216 indicate support by adding "a=rtcp-mux" in SDP [RFC5761]. If an 1217 endpoint receives an SDP without "a=rtcp-mux" but contains "a=mprtp", 1218 then the endpoint MUST infer support for multiplexing. 1220 [[: note-rtp-rtcp-muxIf a=mprtp is indicated, does the endpoint need 1221 to indicate a=rtcp-mux? because MPRTP mandates RTP and RTCP 1222 multiplexing.]] 1224 11.3. MPRTP with ICE 1226 If the endpoints intend to use ICE [RFC5245] for discovering 1227 interfaces and running connectivity checks then the endpoint MUST 1228 advertise its ICE candidates in the initial OFFER, as defined in ICE 1229 [RFC5245]. Thereafter the endpoints run connectivity checks. 1231 When an endpoint uses ICE's regular nomination [RFC5245] procedure, 1232 it chooses the best ICE candidate as the default path. In the case 1233 of an MPRTP endpoint, if more than one ICE candidate succeeded the 1234 connectivity checks then an MPRTP endpoint MAY advertise (some of) 1235 these in-band in RTCP as MPRTP interfaces. 1237 When an endpoint uses ICE's aggressive nomination [RFC5245] 1238 procedure, the selected candidate may change as more ICE checks 1239 complete. Instead of sending updated offers as additional ICE 1240 candidates appear (transience), the endpoint it MAY use in-band 1241 signaling to advertise its interfaces, as defined in Section 9.3. 1243 If the default interface disappears and the paths used for MPRTP are 1244 different from the one in the c= and m= lines then the an alternate 1245 interface for which the ICE checks were successful should be promoted 1246 to the c= and m= lines in the updated offer. 1248 When a new interface appears then the application/endpoint should 1249 internally decide if it wishes to use it and sends an updated offer 1250 with ICE candidates of the all its interfaces including the new 1251 interface. The receiving endpoint responds to the offer with all its 1252 ICE candidates in the answer and starts connectivity checks between 1253 all its candidates and the offerer's ICE candidates. Similarly, the 1254 initiating endpoint starts connectivity checks between the its 1255 interfaces (incl. the new interface) and all the received ICE 1256 candidates in the answer. If the connectivity checks succeed, the 1257 initiating endpoint MAY use in-band signaling (See Section 9.3) to 1258 advertise its new set of interfaces. 1260 11.4. Increased Throughput 1262 The MPRTP layer MAY choose to augment paths to increase throughput. 1263 If the desired media rate exceeds the current media rate, the 1264 endpoints MUST renegotiate the application specific ("b=AS:xxx") 1265 [RFC4566] bandwidth. 1267 11.5. Offer/Answer 1269 When SDP [RFC4566] is used to negotiate MPRTP sessions following the 1270 offer/answer model [RFC3264], the "a=mprtp" attribute (see 1271 Section 11.2) indicates the desire to use multiple interfaces to send 1272 or receive media data. The initial SDP offer MUST include this 1273 attribute at the media level. If the answerer wishes to also use 1274 MPRTP, it MUST include a media-level "a=mprtp" attribute in the 1275 answer. If the answer does not contain an "a=mprtp" attribute, the 1276 offerer MUST NOT stream media over multiple paths and the offerer 1277 MUST NOT advertise additional MPRTP interfaces in-band or out-of- 1278 band. 1280 When SDP is used in a declarative manner, the presence of an 1281 "a=mprtp" attribute signals that the sender can send or receive media 1282 data over multiple interfaces. The receiver SHOULD be capable to 1283 stream media to the multiple interfaces and be prepared to receive 1284 media from multiple interfaces. 1286 The following sections shows examples of SDP offer and answer for in- 1287 band and out-of-band signaling. 1289 11.5.1. In-band Signaling Example 1291 The following offer/answer shows that both the endpoints are MPRTP 1292 capable and SHOULD use in-band signaling for interfaces 1293 advertisements. 1295 Offer: 1296 v=0 1297 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1298 s= 1299 c=IN IP4 192.0.2.1 1300 t=0 0 1301 m=video 49170 RTP/AVP 98 1302 a=rtpmap:98 H264/90000 1303 a=fmtp:98 profile-level-id=42A01E; 1304 a=rtcp-mux 1305 a=mprtp 1307 Answer: 1308 v=0 1309 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1310 s= 1311 c=IN IP4 192.0.2.2 1312 t=0 0 1313 m=video 4000 RTP/AVP 98 1314 a=rtpmap:98 H264/90000 1315 a=fmtp:98 profile-level-id=42A01E; 1316 a=rtcp-mux 1317 a=mprtp 1319 The endpoint MAY now use in-band RTCP signaling to advertise its 1320 multiple interfaces. Alternatively, it MAY make another offer with 1321 the interfaces in SDP (out-of-band signaling) 1322 [I-D.singh-mmusic-mprtp-sdp-extension]. 1324 12. IANA Considerations 1326 The following contact information shall be used for all registrations 1327 in this document: 1329 Contact: Varun Singh 1330 mailto:varun.singh@iki.fi 1331 tel:+358-9-470-24785 1333 Note to the RFC-Editor: When publishing this document as an RFC, 1334 please replace "RFC XXXX" with the actual RFC number of this document 1335 and delete this sentence. 1337 12.1. MPRTP Header Extension 1339 This document defines a new extension URI to the RTP Compact Header 1340 Extensions sub-registry of the Real-Time Transport Protocol (RTP) 1341 Parameters registry, according to the following data: 1343 Extension URI: urn:ietf:params:rtp-hdrext:mprtp 1344 Description: Multipath RTP 1345 Reference: RFC XXXX 1347 12.2. MPRTCP Packet Type 1349 A new RTCP packet format has been registered with the RTCP Control 1350 Packet type (PT) Registry: 1352 Name: MPRTCP 1353 Long name: Multipath RTCP 1354 Value: 211 1355 Reference: RFC XXXX. 1357 This document defines a substructure for MPRTCP packets. A new sub- 1358 registry has been set up for the sub-report block type (MPRTCP_Type) 1359 values for the MPRTCP packet, with the following registrations 1360 created initially: 1362 Name: Subflow Specific Report 1363 Long name: Multipath RTP Subflow Specific Report 1364 Value: 0 1365 Reference: RFC XXXX. 1367 Name: IPv4 Address 1368 Long name: IPv4 Interface Address 1369 Value: 1 1370 Reference: RFC XXXX. 1372 Name: IPv6 Address 1373 Long name: IPv6 Interface Address 1374 Value: 2 1375 Reference: RFC XXXX. 1377 Name: DNS Name 1378 Long name: DNS Name indicating Interface Address 1379 Value: 3 1380 Reference: RFC XXXX. 1382 Further values may be registered on a first come, first served basis. 1383 For each new registration, it is mandatory that a permanent, stable, 1384 and publicly accessible document exists that specifies the semantics 1385 of the registered parameter as well as the syntax and semantics of 1386 the associated sub-report block. The general registration procedures 1387 of [RFC4566] apply. 1389 12.3. SDP Attributes 1391 This document defines a new SDP attribute, "mprtp", within the 1392 existing IANA registry of SDP Parameters. 1394 12.3.1. "mprtp" attribute 1396 o Attribute Name: MPRTP 1398 o Long Form: Multipath RTP 1400 o Type of Attribute: media-level 1402 o Charset Considerations: The attribute is not subject to the 1403 charset attribute. 1405 o Purpose: This attribute is used to indicate support for Multipath 1406 RTP. It can also provide one of many possible interfaces for 1407 communication. These interface addresses may have been validated 1408 using ICE procedures. 1410 o Appropriate Values: See Section 11.2 of RFC XXXX. 1412 13. Security Considerations 1414 TBD 1416 All drafts are required to have a security considerations section. 1417 See RFC 3552 [RFC3552] for a guide. 1419 14. Acknowledgements 1420 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1421 Trilogy (http://www.trilogy-project.org), a research project 1422 (ICT-216372) partially funded by the European Community under its 1423 Seventh Framework Program. The views expressed here are those of the 1424 author(s) only. The European Commission is not liable for any use 1425 that may be made of the information in this document. 1427 Thanks to Miguel A. Garcia, Ralf Globisch, Christer Holmberg, and 1428 Roni Even for providing valuable feedback on earlier versions of this 1429 draft 1431 15. References 1433 15.1. Normative References 1435 [10] Singh, V., Ott, J., Karkkainen, T., Globisch, R., and T. 1436 Schierl, "Multipath RTP (MPRTP) attribute in Session 1437 Description Protocol", draft-singh-mmusic-mprtp-sdp- 1438 extension-01 (work in progress), January 2013. 1440 [11] Wing, D., Reddy, T., Patil, P., and P. Martinsen, 1441 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 1442 mobility-04 (work in progress), June 2013. 1444 [1] Bradner, S., "Key words for use in RFCs to Indicate 1445 Requirement Levels", BCP 14, RFC 2119, March 1997. 1447 [2] Yergeau, F., "UTF-8, a transformation format of ISO 1448 10646", STD 63, RFC 3629, November 2003. 1450 [3] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1451 Protocol (RTCP) Extensions for Single-Source Multicast 1452 Sessions with Unicast Feedback", RFC 5760, February 2010. 1454 [4] Rosenberg, J., "Interactive Connectivity Establishment 1455 (ICE): A Protocol for Network Address Translator (NAT) 1456 Traversal for Offer/Answer Protocols", RFC 5245, April 1457 2010. 1459 [5] Singer, D. and H. Desineni, "A General Mechanism for RTP 1460 Header Extensions", RFC 5285, July 2008. 1462 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. 1463 Jacobson, "RTP: A Transport Protocol for Real-Time 1464 Applications", STD 64, RFC 3550, July 2003. 1466 [7] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1467 Real-Time Transport Control Protocol (RTCP): Opportunities 1468 and Consequences", RFC 5506, April 2009. 1470 [8] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1471 "Extended RTP Profile for Real-time Transport Control 1472 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1473 2006. 1475 [9] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1476 Control Packets on a Single Port", RFC 5761, April 2010. 1478 15.2. Informative References 1480 [10] Marjou, X. and A. Sollaud, "Application Mechanism for 1481 Keeping Alive the NAT Mappings Associated with RTP / RTP 1482 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 1484 [1] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1485 Text on Security Considerations", BCP 72, RFC 3552, July 1486 2003. 1488 [2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1489 Iyengar, "Architectural Guidelines for Multipath TCP 1490 Development", RFC 6182, March 2011. 1492 [3] Stewart, R., "Stream Control Transmission Protocol", RFC 1493 4960, September 2007. 1495 [4] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1496 Shim Protocol for IPv6", RFC 5533, June 2009. 1498 [5] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1499 January 2008. 1501 [6] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1502 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1503 (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in 1504 progress), April 2013. 1506 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1507 A., Peterson, J., Sparks, R., Handley, M., and E. 1508 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1509 June 2002. 1511 [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1512 with Session Description Protocol (SDP)", RFC 3264, June 1513 2002. 1515 [9] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1516 Description Protocol", RFC 4566, July 2006. 1518 Appendix A. Interoperating with Legacy Applications 1520 An MPRTP sender can use its multiple interfaces to send media to a 1521 legacy RTP client. The legacy receiver will ignore the subflow RTP 1522 header and the receiver's de-jitter buffer will try to compensate for 1523 the mismatch in per-path delay. However, the receiver can only send 1524 the overall or aggregate RTCP report which may be insufficient for an 1525 MPRTP sender to adequately schedule packets or detect if a path 1526 disappeared. 1528 An MPRTP receiver can only use one of its interface when 1529 communicating with a legacy sender. 1531 Appendix B. Change Log 1533 Note to the RFC-Editor: please remove this section prior to 1534 publication as an RFC. 1536 B.1. Changes in draft-singh-avtcore-mprtp-06 and -07 1538 o Added reference to Mobility ICE. 1540 B.2. Changes in draft-singh-avtcore-mprtp-05 1542 o SDP extensions moved to draft-singh-mmusic-mprtp-sdp-extension-00. 1543 Kept only the basic 'a=mprtp' attribute in this document. 1545 o Cleaned up ICE procedures for advertising only using in-band 1546 signaling. 1548 B.3. Changes in draft-singh-avtcore-mprtp-04 1550 o Fixed missing 0xBEDE header in MPRTP header format. 1552 o Removed connectivity checks and keep-alives from in-band 1553 signaling. 1555 o MPRTP and MPRTCP are multiplexed on a single port. 1557 o MPRTCP packet headers optimized. 1559 o Made ICE optional 1561 o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6. 1563 o Added how to use MPRTP in RTSP (Section 12). 1565 o Updated IANA Considerations section. 1567 B.4. Changes in draft-singh-avtcore-mprtp-03 1569 o Added this change log. 1571 o Updated section 6, 7 and 8 based on comments from MMUSIC. 1573 o Updated section 11 (SDP) based on comments of MMUSIC. 1575 o Updated SDP examples with ICE and non-ICE in out-of-band signaling 1576 scenario. 1578 o Added Appendix A on interop with legacy. 1580 o Updated IANA Considerations section. 1582 B.5. Changes in draft-singh-avtcore-mprtp-02 1584 o MPRTCP protocol extensions use only one PT=210, instead of 210 and 1585 211. 1587 o RTP header uses 1-byte extension instead of 2-byte. 1589 o Added section on RTCP Interval Calculations. 1591 o Added "mprtp-interface" attribute in SDP considerations. 1593 B.6. Changes in draft-singh-avtcore-mprtp-01 1595 o Added MPRTP and MPRTCP protocol extensions and examples. 1597 o WG changed from -avt to -avtcore. 1599 Authors' Addresses 1601 Varun Singh 1602 Aalto University 1603 School of Electrical Engineering 1604 Otakaari 5 A 1605 Espoo, FIN 02150 1606 Finland 1608 Email: varun@comnet.tkk.fi 1609 URI: http://www.netlab.tkk.fi/~varun/ 1610 Teemu Karkkainen 1611 Aalto University 1612 School of Electrical Engineering 1613 Otakaari 5 A 1614 Espoo, FIN 02150 1615 Finland 1617 Email: teemuk@comnet.tkk.fi 1619 Joerg Ott 1620 Aalto University 1621 School of Electrical Engineering 1622 Otakaari 5 A 1623 Espoo, FIN 02150 1624 Finland 1626 Email: jo@comnet.tkk.fi 1628 Saba Ahsan 1629 Aalto University 1630 School of Electrical Engineering 1631 Otakaari 5 A 1632 Espoo, FIN 02150 1633 Finland 1635 Email: saba.ahsan@aalto.fi 1637 Lars Eggert 1638 NetApp 1639 Sonnenallee 1 1640 Kirchheim 85551 1641 Germany 1643 Phone: +49 151 12055791 1644 Email: lars@netapp.com 1645 URI: http://eggert.org/