idnits 2.17.1 draft-singh-avtcore-mprtp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (October 31, 2011) is 4533 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC5760' on line 500 -- Looks like a reference, but probably isn't: 'RFC5245' on line 726 -- Looks like a reference, but probably isn't: 'RFC6263' on line 906 == Unused Reference: '19' is defined on line 1607, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5245 (ref. '3') (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (ref. '6') (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '10') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5117 (ref. '13') (Obsoleted by RFC 7667) == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-28 -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '17') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Core Working Group V. Singh 3 Internet-Draft T. Karkkainen 4 Intended status: Experimental J. Ott 5 Expires: May 3, 2012 S. Ahsan 6 Aalto University 7 L. Eggert 8 Nokia 9 October 31, 2011 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-03 14 Abstract 16 The Real-time Transport Protocol (RTP) is used to deliver real-time 17 content and, along with the RTP Control Protocol (RTCP), forms the 18 control channel between the sender and receiver. However, RTP and 19 RTCP assume a single delivery path between the sender and receiver 20 and make decisions based on the measured characteristics of this 21 single path. Increasingly, endpoints are becoming multi-homed, which 22 means that they are connected via multiple Internet paths. Network 23 utilization can be improved when endpoints use multiple parallel 24 paths for communication. The resulting increase in reliability and 25 throughput can also enhance the user experience. This document 26 extends the Real-time Transport Protocol (RTP) so that a single 27 session can take advantage of the availability of multiple paths 28 between two endpoints. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2012. 47 Copyright Notice 48 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 6 70 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 8 73 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 9 75 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 10 76 7. Available Mechanisms within the Functional Blocks . . . . . . 11 77 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 11 79 7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 11 80 7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 11 81 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 13 82 7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . . 13 83 7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 13 84 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 14 85 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1.1. Gather or Discovering Candidates . . . . . . . . . . . 15 87 8.1.2. RTCP Subflow or Interface advertisement . . . . . . . 15 88 8.1.3. Connectivity Checks . . . . . . . . . . . . . . . . . 15 89 8.1.4. Active and Passive Subflows . . . . . . . . . . . . . 16 90 8.1.5. Middlebox Considerations . . . . . . . . . . . . . . . 16 91 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . . 16 92 8.3. Playout Considerations at the Receiver . . . . . . . . . . 17 93 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 17 94 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 17 96 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 18 97 9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . . 18 98 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 19 99 9.1.2. MPRTP RTP Extension for Connectivity Checks . . . . . 20 100 9.1.3. MPRTP RTP Extension for Keep-alive Packets . . . . . . 20 101 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 20 102 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . . 22 103 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 23 104 9.3. MPRTCP Extension for Interface advertisement . . . . . . . 25 105 9.3.1. Interface Advertisement block . . . . . . . . . . . . 26 106 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 27 107 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 27 108 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . . 27 109 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . . 28 110 11.3. MPRTP Interface Advertisement in SDP (out-of-band 111 signaling) . . . . . . . . . . . . . . . . . . . . . . . . 28 112 11.3.1. "interface" attribute . . . . . . . . . . . . . . . . 28 113 11.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 29 114 11.4. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . . 29 115 11.5. Increased Throughput . . . . . . . . . . . . . . . . . . . 30 116 11.6. Offer/Answer Examples . . . . . . . . . . . . . . . . . . 30 117 11.6.1. In-band signaling . . . . . . . . . . . . . . . . . . 30 118 11.6.2. Out-of-band signaling . . . . . . . . . . . . . . . . 31 119 11.6.2.1. Without ICE . . . . . . . . . . . . . . . . . . . 31 120 11.6.2.2. With ICE . . . . . . . . . . . . . . . . . . . . . 32 121 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 122 12.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . . 33 123 12.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . . 34 124 12.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 34 125 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 126 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 127 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 128 15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 129 15.2. Informative References . . . . . . . . . . . . . . . . . . 35 130 Appendix A. Interoperating with Legacy Applications . . . . . . . 36 131 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 132 B.1. changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 36 133 B.2. changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 37 134 B.3. changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 37 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 137 1. Introduction 139 Multi-homed endpoints are becoming common in today's Internet, e.g., 140 devices that support multiple wireless access technologies such as 3G 141 and Wireless LAN. This means that there is often more than one 142 network path available between two endpoints. Transport protocols, 143 such as RTP, have not been designed to take advantage of the 144 availability of multiple concurrent paths and therefore cannot 145 benefit from the increased capacity and reliability that can be 146 achieved by pooling their respective capacities. 148 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [1] that allows 149 splitting a single RTP stream into multiple subflows that are 150 transmitted over different paths. In effect, this pools the resource 151 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 152 to RTCP, it is used along with MPRTP to report per-path sender and 153 receiver characteristics. 155 Other IETF transport protocols that are capable of using multiple 156 paths include SCTP [10], MPTCP [11] and SHIM6 [12]. However, these 157 protocols are not suitable for realtime communications. 159 1.1. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [2]. 165 1.2. Terminology 167 o Endpoint: host either initiating or terminating an RTP flow. 169 o Interface: logical or physical component that is capable of 170 acquiring a unique IP address. 172 o Path: sequence of links between a sender and a receiver. 173 Typically, defined by a set of source and destination addresses. 175 o Subflow: flow of RTP packets along a specific path, i.e., a subset 176 of the packets belonging to an RTP stream. The combination of all 177 RTP subflows forms the complete RTP stream. Typically, a subflow 178 would map to a unique path, i.e., each combination of IP addresses 179 and port pairs (5-tuple, including protocol) is a unique subflow. 181 1.3. Use-cases 183 The primary use-case for MPRTP is transporting high bit-rate 184 streaming multimedia content between endpoints, where at least one is 185 multi-homed. Such endpoints could be residential IPTV devices that 186 connect to the Internet through two different Internet service 187 providers (ISPs), or mobile devices that connect to the Internet 188 through 3G and WLAN interfaces. By allowing RTP to use multiple 189 paths for transmission, the following gains can be achieved: 191 o Higher quality: Pooling the resource capacity of multiple Internet 192 paths allows higher bit-rate and higher quality codecs to be used. 193 From the application perspective, the available bandwidth between 194 the two endpoints increases. 196 o Load balancing: Transmitting an RTP stream over multiple paths 197 reduces the bandwidth usage on a single path, which in turn 198 reduces the impact of the media stream on other traffic on that 199 path. 201 o Fault tolerance: When multiple paths are used in conjunction with 202 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 203 one path have less impact on the overall perceived quality of the 204 stream. 206 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 207 calls to a device with multiple interfaces. Again, such an endpoint 208 could be a mobile device with multiple wireless interfaces. In this 209 case, little is to be gained from resource pooling, i.e., higher 210 capacity or load balancing, because a single path should be easily 211 capable of handling the required load. However, using multiple 212 concurrent subflows can improve fault tolerance, because traffic can 213 shift between the subflows when path outages occur. This results in 214 very fast transport-layer handovers that do not require support from 215 signaling. 217 2. Goals 219 This section outlines the basic goals that multipath RTP aims to 220 meet. These are broadly classified as Functional goals and 221 Compatibility goals. 223 2.1. Functional goals 225 Allow unicast RTP session to be split into multiple subflows in order 226 to be carried over multiple paths. This may prove beneficial in case 227 of video streaming. 229 o Increased Throughput: Cumulative capacity of the two paths may 230 meet the requirements of the multimedia session. Therefore, MPRTP 231 MUST support concurrent use of the multiple paths. 233 o Improved Reliability: MPRTP SHOULD be able to send redundant 234 packets or re-transmit packets along any available path to 235 increase reliability. 237 The protocol SHOULD be able to open new subflows for an existing 238 session when new paths appear and MUST be able to close subflows when 239 paths disappear. 241 2.2. Compatibility goals 243 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 244 back to be compatible with legacy RTP stacks if MPRTP support is not 245 successfully negotiated. 247 o Application Compatibility: MPRTP service model MUST be backwards 248 compatible with existing RTP applications, i.e., an MPRTP stack 249 MUST be able to work with legacy RTP applications and not require 250 changes to them. Therefore, the basic RTP APIs MUST remain 251 unchanged, but an MPRTP stack MAY provide extended APIs so that 252 the application can configure any additional features provided by 253 the MPRTP stack. 255 o Network Compatibility: individual RTP subflows MUST themselves be 256 well-formed RTP flows, so that they are able to traverse NATs and 257 firewalls. This MUST be the case even when interfaces appear 258 after session initiation. Interactive Connectivity Establishment 259 (ICE) [3] MAY be used for discovering new interfaces or performing 260 connectivity checks. 262 3. RTP Topologies 264 RFC 5117 [13] describes a number of scenarios using mixers and 265 translators in single-party (point-to-point), and multi-party (point- 266 to-multipoint) scenarios. RFC 3550 [1] (Section 2.3 and 7.x) discuss 267 in detail the impact of mixers and translators on RTP and RTCP 268 packets. MPRTP assumes that if a mixer or translator exists in the 269 network, then either all of the multiple paths or none of the 270 multiple paths go via this component. 272 4. MPRTP Architecture 274 In a typical scenario, an RTP session uses a single path. In an 275 MPRTP scenario, an RTP session uses multiple subflows that each use a 276 different path. Figure 1 shows the difference. 278 +--------------+ Signaling +--------------+ 279 | |------------------------------------>| | 280 | Client |<------------------------------------| Server | 281 | | Single RTP flow | | 282 +--------------+ +--------------+ 284 +--------------+ Signaling +--------------+ 285 | |------------------------------------>| | 286 | Client |<------------------------------------| Server | 287 | |<------------------------------------| | 288 +--------------+ MPRTP subflows +--------------+ 290 Figure 1: Comparison between traditional RTP streaming and MPRTP 292 +-----------------------+ +-------------------------------+ 293 | Application | | Application | 294 +-----------------------+ +-------------------------------+ 295 | | | MPRTP | 296 + RTP + +- - - - - - - -+- - - - - - - -+ 297 | | | RTP subflow | RTP subflow | 298 +-----------------------+ +---------------+---------------+ 299 | UDP | | UDP | UDP | 300 +-----------------------+ +---------------+---------------+ 301 | IP | | IP | IP | 302 +-----------------------+ +---------------+---------------+ 304 Figure 2: MPRTP Architecture 306 Figure 2 illustrates the differences between the standard RTP stack 307 and the MPRTP stack. MPRTP receives a normal RTP session from the 308 application and splits it into multiple RTP subflows. Each subflow 309 is then sent along a different path to the receiver. To the network, 310 each subflow appears as an independent, well-formed RTP flow. At the 311 receiver, the subflows are combined to recreate the original RTP 312 session. The MPRTP layer performs the following functions: 314 o Path Management: The layer is aware of alternate paths to the 315 other host, which may, for example, be the peer's multiple 316 interfaces. So that it is able to send differently marked packets 317 along separate paths. MPRTP also selects interfaces to send and 318 receive data. Furthermore, it manages the port and IP address 319 pair bindings for each subflow. 321 o Packet Scheduling: the layer splits a single RTP flow into 322 multiple subflows and sends them across multiple interfaces 323 (paths). The splitting MAY BE done using different path 324 characteristics. 326 o Subflow recombination: the layer creates the original stream by 327 recombining the independent subflows. Therefore, the multipath 328 subflows appear as a single RTP stream to applications. 330 5. Example Media Flow Diagrams 332 There may be many complex technical scenarios for MPRTP, however, 333 this memo only considers the following two scenarios: 1) a 334 unidirectional media flow that represents the streaming use-case, and 335 2) a bidirectional media flow that represents a conversational use- 336 case. 338 5.1. Streaming use-case 340 In the unidirectional scenario, the receiver (client) initiates a 341 multimedia session with the sender (server). The receiver or the 342 sender may have multiple interfaces and both endpoints are MPRTP- 343 capable. Figure 3 shows this scenario. In this case, host A has 344 multiple interfaces. Host B performs connectivity checks on host A's 345 multiple interfaces. If the interfaces are reachable, then host B 346 streams multimedia data along multiple paths to host A. Moreover, 347 host B also sends RTCP Sender Reports (SR) for each subflow and host 348 A responds with a normal RTCP Receiver Report (RR) for the overall 349 session and receiver statistics for each subflow. Host B distributes 350 the packets across the subflows based on the individually measured 351 path characteristics. 353 Alternatively, to reduce media startup time, host B may start 354 streaming multimedia data to host A's initiating interface and then 355 perform connectivity checks for the other interfaces. This method of 356 updating a single path session to a multipath session is called 357 "multipath session upgrade". 359 Host A Host B 360 ----------------------- ---------- 361 Interface A1 Interface A2 Interface B1 362 ----------------------- ---------- 363 | | 364 |------------------------------------->| Session setup with 365 |<-------------------------------------| multiple interfaces 366 | | | 367 | | | 368 | (RTP data B1->A1, B1->A2) | 369 |<=====================================| 370 | |<========================| 371 | | | 372 Note: there may be more scenarios. 374 Figure 3: Unidirectional media flow 376 5.2. Conversational use-case 378 In the bidirectional scenario, multimedia data flows in both 379 directions. The two hosts exchange their lists of interfaces with 380 each other and perform connectivity checks. Communication begins 381 after each host finds suitable address, port pairs. Interfaces that 382 receive data send back RTCP receiver statistics for that path (based 383 on the 5-tuple). The hosts balance their multimedia stream across 384 multiple paths based on the per path reception statistics and its own 385 volume of traffic. Figure 4 describes an example of a bidirectional 386 flow. 388 Host A Host B 389 --------------------------- --------------------------- 390 Interface A1 Interface A2 Interface B1 Interface B2 391 --------------------------- --------------------------- 392 | | | | 393 | | | | 394 |----------------------------------->| |Session setup with 395 |<-----------------------------------| |multiple interfaces 396 | | | | 397 | | | | 398 | (RTP data B1<->A1, B2<->A2) | | 399 |<===================================| | 400 | |<===================================| 401 |===================================>| | 402 | |===================================>| 403 | | | | 404 Note: the address pairs may have other permutations, 405 and they may be symmetric or asymmetric combinations. 407 Figure 4: Bidirectional flow 409 6. MPRTP Functional Blocks 411 This section describes some of the functional blocks needed for 412 MPRTP. We then investigate each block and consider available 413 mechanisms in the next section. 415 1. Session Setup: Interfaces may appear or disappear at anytime 416 during the session. To preserve backward compatibility with 417 legacy applications, a multipath session MUST look like a bundle 418 of individual RTP sessions. Multipath session may be upgraded 419 from a typical single path session, as and when new interfaces 420 appear or disappear. However, it should be possible to setup a 421 multipath session from the beginning if the interfaces are 422 available at the start of the multimedia session. 424 2. Expanding RTP: For a multipath session, each subflow MUST look 425 like an independent RTP flow, so that individual RTCP messages 426 can be generated per subflow. Furthermore, MPRTP splits the 427 single multimedia stream into multiple subflows based on path 428 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 429 delay product etc.) and dynamically adjusts the load on each 430 link. 432 3. Adding Interfaces: Interfaces on the host need to be regularly 433 discovered and advertised. This can be done at session setup 434 and/or during the session. Discovering interfaces is outside the 435 scope of this document. 437 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 438 monitoring the quality of the path, for load balancing, or for 439 congestion control, etc. To maintain backward compatibility with 440 legacy applications, the receiver MUST also send aggregate RTCP 441 reports along with the per-path reports. 443 5. Maintenance and Failure Handling: In a multi-homed endpoint 444 interfaces may appear and disappear. If this occurs at the 445 sender, it has to re-adjust the load on the available links. On 446 the other hand, if this occurs at the receiver, then the 447 multimedia data transmitted by the sender to those interfaces is 448 lost. This data may be re-transmitted along a different path 449 i.e., to a different interface on the receiver. Furthermore, the 450 endpoint has to either explicitly signal the disappearance of an 451 interface, or the other endpoint has to detect it (by lack of 452 media packets, RTCP feedback, or keep-alive packets). 454 6. Teardown: The MPRTP layer releases the occupied ports on the 455 interfaces. 457 7. Available Mechanisms within the Functional Blocks 459 This section discusses some of the possible alternatives for each 460 functional block mentioned in the previous section. 462 7.1. Session Setup 464 MPRTP session can be set up in many possible ways e.g., during 465 handshake, or upgraded mid-session. The capability exchange may be 466 done using out-of-band signaling (e.g., SDP [14] in SIP [15], RTSP 467 [16]) or in-band signaling (e.g., RTP/RTCP header extension, STUN 468 messages). 470 [[Comment.1: Using SIP over SCTP, MPTCP instead of UDP/TCP are out of 471 scope of the document. --MMUSIC Review]] 473 7.1.1. Connectivity Checks 475 The endpoint SHOULD be capable of performing connectivity checks 476 (e.g., using ICE [3]). If the IP addresses of the endpoints are 477 reachable (e.g., globally addressable, same network etc) then 478 connectivity checks are not needed. 480 7.1.2. Adding New or Updating Interfaces 482 Interfaces can appear and disappear during a session, the endpoint 483 MUST be capable of advertising the changes in its set of usable 484 interfaces. Additionally, the application or OS may define a policy 485 on when and/or what interfaces are usable. However, MPRTP requires a 486 method to advertise the updated set of usable interfaces. 488 7.1.3. In-band vs. Out-of-band Signaling 490 MTRTP nodes will generally use a signaling protocol to establish 491 their MPRTP session. With the existence of such a signaling 492 relationship, two alternatives become available to exchange 493 information about the available interfaces on each side for extending 494 RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and 495 out-of-band signaling. 497 In-band signaling refers to using mechanisms of RTP/RTCP itself to 498 communicate interface addresses, e.g., a dedicated RTCP extensions 499 along the lines of the one defined to communicate information about 500 the feedback target for RTP over SSM [RFC5760]. In-band signaling 501 does not rely on the availability of a separate signaling connection 502 and the information flows along the same path as the media streams, 503 thus minimizing dependencies. Moreover, if the media channel is 504 secured (e.g., by means of SRTP), the signaling is implicitly 505 protected as well if SRTCP encryption and authentication are chosen. 506 In-band signaling is also expected to take a direct path to the peer, 507 avoiding any signaling overlay-induced indirections and associated 508 processing overheads in signaling elements -- avoiding such may be 509 especially worthwhile if frequent updates may occur as in the case of 510 mobile users. Finally, RTCP is usually sent sufficiently frequently 511 (in point-to-point settings) to provide enough opportunities for 512 transmission and (in case of loss) retransmission of the 513 corresponding RTCP packets. 515 Examples for in-band signaling include RTCP extensions as noted above 516 or suitable extensions to STUN. 518 Out-of-band signaling refers to using a separate signaling connection 519 (via SIP, RTSP, or HTTP) to exchange interface information, e.g., 520 expressed in SDP. Clear benefits are that signaling occurs at setup 521 time anyway and that experience and SDP syntax (and procedures) are 522 available that can be re-used or easily adapted to provide the 523 necessary capabilities. In contrast to RTCP, SDP offers a reliable 524 communication channel so that no separate retransmissions logic is 525 necessary. In SDP, especially when combined with ICE, connectivity 526 check mechanisms including sophisticated rules are readily available. 527 While SDP is not inherently protected, suitable security may need to 528 be applied anyway to the basic session setup. 530 Examples for out-of-band signaling are dedicated extensions to SDP; 531 those may be combined with ICE. 533 Both types of mechanisms have their pros and cons for middleboxes. 534 With in-band signaling, control packets take the same path as the 535 media packets and they can be directly inspected by middleboxes so 536 that the elements operating on the signaling channel do not need to 537 understand new SDP. With out-of-band signaling, only the middleboxes 538 processing the signaling need to be modified and those on the data 539 forwarding path can remain untouched. 541 Overall, it may appear sensible to provide a combination of both 542 mechanisms: out-of-band signaling for session setup and initial 543 interface negotiation and in-band signaling to deal with frequent 544 changes in interface state (and for the potential case, albeit rather 545 theoretical case of MPRTP communication without a signaling channel). 547 In its present version, this document explores both options to 548 provide a broad understanding of how the corresponding mechanisms 549 would look like. 551 [[Comment.2: Some have suggested STUN may be suitable for doing in- 552 band interface advertisement. This is still under consideration, but 553 depends on implementation challenges as many legacy systems don't 554 implement STUN and many RTP systems ignore STUN messages. --Editor]] 556 7.2. Expanding RTP 558 RTCP [1] is generated per media session. However, with MPRTP, the 559 media sender spreads the RTP load across several interfaces. The 560 media sender SHOULD make the path selection, load balancing and fault 561 tolerance decisions based on the characteristics of each path. 562 Therefore, apart from normal RTP sequence numbers defined in [1], the 563 MPRTP sender MUST add subflow-specific sequence numbers to help 564 calculate fractional losses, jitter, RTT, playout time, etc., for 565 each path and a subflow identifier to associate the characteristics 566 with a path. The RTP header extension for MPRTP is shown in 567 Section 9.1. 569 7.3. Expanding RTCP 571 To provide accurate per path information an MPRTP endpoint MUST send 572 (SR/RR) report for each unique subflow along with the overall session 573 RTCP report. Therefore, the additional subflow reporting affects the 574 RTCP bandwidth and the RTCP reporting interval. RTCP report 575 scheduling for each subflow may cause a problem for RTCP 576 recombination and reconstruction in cases when 1) RTCP for a subflow 577 is lost, and 2) RTCP for a subflow arrives later than the other 578 subflows. (There may be other cases as well.) 580 The sender distributes the media across different paths using the per 581 path RTCP reports. However, this document doesn't cover algorithms 582 for congestion control or load balancing. 584 7.4. Failure Handling and Teardown 586 An MPRTP endpoint MUST keep alive subflows that have been negotiated 587 but no media is sent on them. Moreover, using the information in the 588 subflow reports, a sender can monitor the subflows for failure 589 (errors, unreachability, congestion) and decide not to use the under- 590 performing subflows. 592 If an interface disappears, the endpoint MUST send an updated 593 interface advertisement without the interface and release the the 594 associated subflows. 596 8. MPRTP Protocol 598 Host A Host B 599 ----------------------- ----------------------- 600 Interface A1 Interface A2 Interface B1 Interface B2 601 ----------------------- ----------------------- 602 | | | | 603 | | (1) | | 604 |--------------------------------------->| | 605 |<---------------------------------------| | 606 | | (2) | | 607 |<=======================================| | 608 |<=======================================| (3) | 609 | | (4) | | 610 |<- - - - - - - - - - - - - - - - - - - -| | 611 |<- - - - - - - - - - - - - - - - - - - -| | 612 |<- - - - - - - - - - - - - - - - - - - -| | 613 | | (5) | | 614 |- - - - - - - - - - - - - - - - - - - ->| | 615 |<=======================================| (6) | 616 |<=======================================| | 617 | |<========================================| 618 |<=======================================| | 619 | |<========================================| 621 Key: 622 | Interface 623 ---> Signaling Protocol 624 <=== RTP Packets 625 - -> RTCP Packet 627 Figure 5: MPRTP New Interface 629 8.1. Overview 631 The bullet points explain the different steps shown in Figure 5 for 632 upgrading a single path multimedia session to multipath session. 634 (1) The first two interactions between the hosts represents the 635 establishment of a normal RTP session. This may performed e.g. 636 using SIP or RTSP. 638 (2) When the RTP session has been established, host B streams 639 media using its interface B1 to host A at interface A1. 641 (3) Host B supports sending media using MPRTP and becomes aware of 642 an additional interface B2. 644 (4) Host B advertises the multiple interface addresses. 646 (5) Host A supports receiving media using MPRTP and becomes aware 647 of an additional interface A2. 649 Side note, even if an MPRTP-capable host has only one interface, 650 it MUST respond to the advertisement with its single interface. 652 (6) Each host receives information about the additional interfaces 653 and the appropriate endpoints starts to stream the multimedia 654 content using the additional paths. 656 If needed, each endpoint will need to independently perform 657 connectivity checks (not shown in figure) and ascertain 658 reachability before using the paths. 660 8.1.1. Gather or Discovering Candidates 662 The endpoint periodically polls the operating system or is notified 663 when an additional interface appears. If the endpoint wants to use 664 the additional interface it MUST advertise it to the other peers. 665 The endpoint may also use ICE [3] to gather additional candidates. 667 8.1.2. RTCP Subflow or Interface advertisement 669 To advertise the multiple interfaces, an MPRTP-capable endpoint MUST 670 add the MPRTP Interface Advertisement defined in Figure 13 with the 671 RTCP Sender Report (SR). Each unique address is encapsulated in an 672 Interface Advertisement block and contains the IP address, RTP and 673 RTCP port addresses. The Interface Advertisement blocks are ordered 674 based on a decreasing priority level. On receiving the MPRTP 675 Interface Advertisement, an MPRTP-capable receiver MUST respond with 676 the set of interfaces (subset or all available) it wants to use. 678 If the sender and receiver have only one interface, then the 679 endpoints MUST indicate the negotiated single path IP, RTP port and 680 RTCP port addresses. 682 8.1.3. Connectivity Checks 684 After MPRTP support has been negotiated and interface advertisements 685 have been exchanged, the endpoint MAY initiate connectivity checks to 686 determine which pairs of interfaces offer valid paths between the 687 sender and the receiver. Each combination of sender and receiver IP 688 addresses and port pairs (5-tuple) is a unique subflow. An endpoint 689 MUST associate a Subflow ID to each unique subflow. 691 To initiate a connectivity check, the endpoints send an RTP packet 692 using the appropriate MPRTP extension header (See Figure 7), 693 associated Subflow ID and no RTP payload. The receiving endpoint 694 replies to the connectivity check with an RTCP packet with the 695 appropriate packet type (See Figure 10) and Subflow ID. After the 696 endpoint receives the reply, the path is considered a valid candidate 697 for sending data. An endpoint MAY choose to do any number of 698 connectivity checks for any interface pairs at any point in a 699 session. 701 [[Comment.3: Open Issue: How should the endpoint adjust the RTCP 702 Reporting interval/schedule the RTCP packet on receiving a 703 connectivity check containing a new Subflow ID? One option is send 704 immediately as defined in RFC4585. Another option is the RTCP timing 705 defined in RFC6263. --Editor]] 707 8.1.4. Active and Passive Subflows 709 To send and receive data an endpoint MAY use any number of subflows 710 from the set of available subflows. The subflows that carry media 711 data are called active subflows, while those subflows that don't send 712 any media packet are called passive subflows. 714 An endpoint should send MPRTP keep alive packets (see Section 9.1.3) 715 on the subflows where no media is sent to keep the NAT bindings 716 alive. 718 [[Comment.4: Open Issue: How to differentiate between Passive and 719 Active connections? Editor: Active paths get "regular flow" of media 720 packets while passive paths are for failover of active paths. 721 --Editor]] 723 [[Comment.5: Open Issue: How to keep a passive connection alive, if 724 not actively used? Alternatively, what is the maximum timeout? keep- 725 alive for ICE/NAT bindings should not be less than 15 seconds 726 [RFC5245]. --Editor]] 728 8.1.5. Middlebox Considerations 730 TBD. 732 8.2. RTP Transmission 734 If both endpoints are MPRTP-capable and if they want to use their 735 multiple interfaces for sending the media stream then they MUST use 736 the MPRTP header extensions. They MAY use normal RTP with legacy 737 endpoints (see Appendix A). 739 An MPRTP endpoint sends RTP packets with an MPRTP extension that maps 740 the media packet to a specific subflow (see Figure 8). The MPRTP 741 layer SHOULD associate an RTP packet with a subflow based on a 742 scheduling strategy. The scheduling strategy may either choose to 743 augment the paths to create higher throughput or use the alternate 744 paths for enhancing resilience or error-repair. Due to the changes 745 in path characteristics, the endpoint should be able change its 746 scheduling strategy during an ongoing session. The MPRTP sender MUST 747 also populate the subflow specific fields described in the MPRTP 748 extension header (see Section 9.1.1). 750 8.3. Playout Considerations at the Receiver 752 A media receiver, irrespective of MPRTP support or not, should be 753 able to playback the media stream because the received RTP packets 754 are compliant to [1], i.e., a non-MPRTP receiver will ignore the 755 MPRTP header and still be able to playback the RTP packets. However, 756 the variation of jitter and loss per path may affect proper playout. 757 The receiver can compensate for the jitter by modifying the playout 758 delay (i.e., by calculating skew across all paths) of the received 759 RTP packets. 761 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 763 Aggregate RTCP provides the overall media statistics and follows the 764 normal RTCP defined in RFC3550 [1]. However, subflow specific RTCP 765 provides the per path media statistics because the aggregate RTCP 766 report may not provide sufficient per path information to an MPRTP 767 scheduler. Specifically, the scheduler should be aware of each 768 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 769 The sender/receiver MUST use non-compound RTCP reports defined in 770 RFC5506 [4] to transmit the aggregate and subflow-specific RTCP 771 reports. Also, each subflow and the aggregate RTCP report MUST 772 follow the timing rules defined in [5]. 774 The RTCP reporting interval is locally implemented and the scheduling 775 of the RTCP reports may depend on the the behavior of each path. For 776 instance, the RTCP interval may be different for a passive path than 777 an active path to keep port bindings alive. Additionally, an 778 endpoint may decide to share the RTCP reporting bit rate equally 779 across all its paths or schedule based on the receiver rate on each 780 path. 782 8.5. RTCP Transmission 784 The sender sends an RTCP SR on each active path. For each SR the 785 receiver gets, it echoes one back to the same IP address-port pair 786 that sent the SR. The receiver tries to choose the symmetric path 787 and if the routing is symmetric then the per-path RTT calculations 788 will work out correctly. However, even if the paths are not 789 symmetric, the sender would at maximum, under-estimate the RTT of the 790 path by a factor of half of the actual path RTT. 792 9. Packet Formats 794 In this section we define the protocol structures described in the 795 previous sections. 797 9.1. RTP Header Extension for MPRTP 799 The MPRTP header extension is used to 1) distribute a single RTP 800 stream over multiple subflows, 2) perform connectivity checks on the 801 advertised interfaces, and 3) keep-alive passive interfaces (paths). 803 The header conforms to the one-byte RTP header extension defined in 804 [6]. The header extension contains a 16-bit length field that counts 805 the number of 32-bit words in the extension, excluding the four-octet 806 extension header (therefore zero is a valid length, see Section 5.3.1 807 of [1] for details). 809 The RTP header for each subflow is defined below: 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 |V=2|P|1| CC |M| PT | sequence number | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | timestamp | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | synchronization source (SSRC) identifier | 819 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 820 | ID | LEN | MPID |LENGTH | MPRTP header data | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 822 | .... | 823 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 824 | RTP payload | 825 | .... | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 6: Generic MPRTP header extension 830 MPID: 832 The MPID field corresponds to the type of MPRTP packet. 833 Namely: 835 +---------------+--------------------------------------------------+ 836 | MPID ID | Use | 837 | Value | | 838 +---------------+--------------------------------------------------+ 839 | 0x00 | Subflow RTP Header. For this case the Length is | 840 | | set to 6 | 841 | 0x01 | Connectivity Check. For this case the length is | 842 | | set to 0 | 843 | TBD | Keep Alive Packet. | 844 +---------------+--------------------------------------------------+ 846 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 848 length 850 The 4-bit length field is the length of extension data in bytes 851 not including the H-Ext ID and length fields. The value zero 852 indicates there is no data following. 854 MPRTP header data 856 Carries the MPID specific data as described in the following 857 sub-sections. 859 9.1.1. MPRTP RTP Extension for a Subflow 861 The RTP header for each subflow is defined below: 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 |V=2|P|1| CC |M| PT | sequence number | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | timestamp | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | synchronization source (SSRC) identifier | 871 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 872 | ID | LEN=4 | 0x00 | LEN=4 | Subflow ID | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 875 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 876 | RTP payload | 877 | .... | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 8: MPRTP header for subflow 882 MP ID = 0x00 884 Indicates that the MPRTP header extension carries subflow 885 specific information. 887 length = 4 889 Subflow ID: Identifier of the subflow. Every RTP packet belonging 890 to the same subflow carries the same unique subflow identifier. 892 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 893 the subflow. Each subflow has its own strictly monotonically 894 increasing sequence number space. 896 9.1.2. MPRTP RTP Extension for Connectivity Checks 898 [[Comment.6: Open Issue: What sequence number to use for the RTP 899 session? Alternative 1: An MPRTP receiver MUST NOT give the packet 900 with MPID=0x01 to the decoder and ignore these packets from RTCP 901 calculation. Alternative 2: Instead of sending an RTP packet the 902 sender transmits a modified STUN packet. --Editor]] 904 9.1.3. MPRTP RTP Extension for Keep-alive Packets 906 [[Comment.7: RTCP guidelines for keep alive packet [RFC6263] 907 recommends multiplexing RTP and RTCP. If so, we can do the same and 908 remove the keep alive from the list. Alternatively, the endpoint can 909 send zero payload RTP packet with the correct RTP sequence number, 910 RTP timestamp and monotonically increasing the subflow specific 911 sequence number each time [RFC6263 Sec 4.6].] --Editor]] 913 9.2. RTCP Extension for MPRTP (MPRTCP) 915 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 916 per subflow to determine the characteristics of each path, 2) 917 advertise each interface and perform connectivity check on the other 918 endpoint's interfaces, and 3) to keep alive a passive connection. 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |V=2|P|reserved | PT=MPRTCP=211 | length | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | SSRC of packet sender | 926 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 927 | SSRC_1 (SSRC of first source) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | MPRTCP_Type | block length | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | MPRTCP Reports | 932 | ... | 933 | ... | 934 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 936 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 937 normal SR/RR] 939 MPRTCP: 8 bits 941 Contains the constant 211 to identify this as an Multipath RTCP 942 packet. 944 length: 16 bits 946 As described for the RTCP packet (see Section 6.4.1 of the RTP 947 specification [1]), the length of this is in 32-bit words minus 948 one, including the header and any padding. 950 MPRTCP_Type: 16-bits 952 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 953 packet. Namely: 955 +---------------+--------------------------------------------------+ 956 | MPRTCP_Type | Use | 957 | Value | | 958 +---------------+--------------------------------------------------+ 959 | 0x00 | Subflow Specific Report | 960 | 0x01 | Connectivity Check. For this case the length is | 961 | | set to 0 | 962 | 0x02 | Interface Advertisement | 963 | TBD | Keep Alive Packet. | 964 +---------------+--------------------------------------------------+ 966 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 968 block length: 16-bits 970 The 16-bit length field is the length of the encapsulated 971 MPRTCP reports in 32-bit word length not including the 972 MPRTCP_Type and length fields. The value zero indicates there 973 is no data following. 975 MPRTCP Reports: variable size 977 Defined later in 9.2.1 and 9.3.1. 979 9.2.1. MPRTCP Extension for Subflow Reporting 981 When sending a report for a specific subflow the sender or receiver 982 MUST add only the reports associated with that 5-tuple. Each subflow 983 is reported independently using the following MPRTCP Feedback header. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |V=2|P|reserved | PT=MPRTCP=211 | length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | SSRC of packet sender | 991 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 992 | SSRC_1 (SSRC of first source) | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | MPRTCP_Type=0x02 | block length | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Subflow ID #1 | reserved | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Subflow-specific reports | 999 | .... | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | MPRTCP_Type=0x02 | block length | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Subflow ID #2 | reserved | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Subflow-specific reports | 1006 | .... | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Figure 11: MPRTCP Subflow Reporting Header 1011 MPRTCP_Type: 0x02 1013 block length: 16-bits 1014 The 16-bit length field is the length of the encapsulated subflow- 1015 specific reports in 32-bit word length not including the 1016 MPRTCP_Type and length fields. 1018 Subflow ID: 16 bits 1020 Subflow identifier is the value associated with the subflow the 1021 endpoint is reporting about. If it is a sender it MUST use the 1022 Subflow ID associated with the 5-tuple. If it is a receiver it 1023 MUST use the Subflow ID received in the Subflow-specific Sender 1024 Report. 1026 Subflow-specific reports: variable 1028 Subflow-specific report contains all the reports associated with 1029 the Subflow ID. For a sender, it MUST include the Subflow- 1030 specific Sender Report (SSR). For a receiver, it MUST include 1031 Subflow-specific Receiver Report (SRR). Additionally, if the 1032 receiver supports subflow-specific extension reports then it MUST 1033 append them to the SRR. 1035 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 1037 [[Comment.8: inside the context of subflow specific reports can we 1038 reuse the payload type code for Sender Report (PT=200), Receiver 1039 Report (PT=201), Extension Report (PT=207).Transport and Payload 1040 specific RTCP messages are session specific and SHOULD be used as 1041 before. --Editor]] 1043 Example: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |V=2|P|reserved | PT=MPRTCP=211 | length | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | SSRC of packet sender | 1051 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1052 | SSRC_1 (SSRC of first source) | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | MPRTCP_Type=0x02 | block length | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Subflow ID #1 | reserved | 1057 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1058 |V=2|P| RC | PT=SR=200 | length | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | SSRC of sender | 1061 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1062 | NTP timestamp, most significant word | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | NTP timestamp, least significant word | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | RTP timestamp | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | subflow's packet count | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | subflow's octet count | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | MPRTCP_Type=0x02 | block length | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Subflow ID #2 | reserved | 1075 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1076 |V=2|P| RC | PT=RR=201 | length | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | SSRC of packet sender | 1079 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1080 | fraction lost | cumulative number of packets lost | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | extended highest sequence number received | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | inter-arrival jitter | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | last SR (LSR) | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | delay since last SR (DLSR) | 1089 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1090 | Subflow specific extension reports | 1091 | .... | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1094 (Bi-directional use-case, in case of uni-directional flow the subflow 1095 will only send an SR or RR). 1097 9.3. MPRTCP Extension for Interface advertisement 1099 This sub-section defines the RTCP header extension for in-band 1100 interface advertisement by the receiver. The interface advertisement 1101 SHOULD immediately follow the Receiver Report. If the Receiver 1102 Report is not present, then it MUST be appended to the Sender Report. 1104 The endpoint MUST advertise the interfaces it wants to use whenever 1105 an interface appears or disappears and also when it receives an 1106 Interface Advertisement. 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 |V=2|P|reserved | PT=MPRTCP=211 | length | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | SSRC of packet sender | 1114 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1115 | SSRC_1 (SSRC of first source) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | MPRTCP_Type=0x02 | block length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Interface #1 Advertisement block | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Interface #2 Advertisement block | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Interface #... Advertisement block | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Interface #m Advertisement block | 1126 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1128 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1130 MPRTCP_Type: 0x00 1132 block length: 16-bits 1134 The 16-bit length field is the length of the encapsulated 1135 interface advertisement blocks in 32-bit word length not 1136 including the MPRTCP_Type and length fields. 1138 Interface Advertisement block: variable size 1139 Defined later in 9.3.1. 1141 9.3.1. Interface Advertisement block 1143 This block describes a method to represent IPv4, IPv6 and generic 1144 DNS-type addresses in a block format. It is based on the sub- 1145 reporting block in [7]. 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type={0,1,2} | Length | Subflow ID | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | RTCP Port | RTCP Port | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Address | 1155 + + 1156 : : 1157 | | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 Figure 14: Interface Advertisement block during path discovery 1162 Type: 8 bits 1164 The Type corresponds to the type of address. Namely: 1166 0: IPv4 address 1168 1: IPv6 address 1170 2: DNS name 1172 Length: 8 bits 1174 The length of the Interface Advertisement block in bytes. 1176 For an IPv4 address, this should be 9 (i.e., 5 octets for 1177 the header and 4 octets for IPv4 address). 1179 For an IPv6 address, this should be 21. 1181 For a DNS name, the length field indicates the number of 1182 octets making up the string plus the 5 byte header. 1184 RTP Port: 2 octets 1185 The port number to which the sender sends RTP data. A port 1186 number of 0 is invalid and MUST NOT be used. 1188 RTCP Port: 2 octets 1190 The port number to which receivers send feedback reports. A 1191 port number of 0 is invalid and MUST NOT be used. 1193 Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 1195 The address to which receivers send feedback reports. For IPv4 1196 and IPv6, fixed-length address fields are used. A DNS name is 1197 an arbitrary-length string. The string MAY contain 1198 Internationalizing Domain Names in Applications (IDNA) domain 1199 names and MUST be UTF-8 [8] encoded. 1201 10. RTCP Timing reconsiderations for MPRTCP 1203 MPRTP endpoints MUST conform to the timing rule imposed in [5], i.e., 1204 the total RTCP rate between the participants MUST NOT exceed 5% of 1205 the media rate. For each endpoint, a subflow MUST send the aggregate 1206 and subflow-specific report. The endpoint SHOULD schedule the RTCP 1207 reports for the active subflows based on the share of the transmitted 1208 or received bit rate to the average media bit rate, this method 1209 ensures fair sharing of the RTCP bandwidth. Alternatively, the 1210 endpoint MAY schedule the reports in round-robin. 1212 11. SDP Considerations 1214 11.1. Signaling MPRTP Header Extension in SDP 1216 To indicate the use of the MPRTP header extensions (see Section 9) in 1217 SDP, the sender MUST use the following URI: 1218 urn:ietf:params:rtp-hdrext:mprtp. This is a media level parameter. 1219 Legacy RTP (non-MPRTP) clients will ignore this header extension, but 1220 can continue to parse and decode the packet (see Appendix A). 1222 Example: 1224 m=video 49170 RTP/AVP 98 1225 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1227 11.2. Signaling MPRTP capability in SDP 1229 A participant of a media session MUST use SDP to indicate that it 1230 supports MPRTP. Not providing this information will make the other 1231 endpoint ignore the RTCP extensions. 1233 mprtp-attrib = "a=" "mprtp" [ 1234 SP mprtp-optional-parameter] 1235 CRLF ; flag to enable MPRTP 1237 The endpoint MUST use 'a=mprtp', if it is able to send and receive 1238 MPRTP packets. Generally, senders and receivers MUST indicate this 1239 capability if they support MPRTP and would like to use it in the 1240 specific media session being signaled. To exchange the additional 1241 interfaces, the endpoint SHOULD use the in-band signaling 1242 (Section 9.3). Alternatively, advertise in SDP (Section 11.3). 1244 11.3. MPRTP Interface Advertisement in SDP (out-of-band signaling) 1246 If the endpoint is aware of its multiple interfaces and wants to use 1247 them for MPRTP then it MAY use SDP to advertise these interfaces. 1248 Alternatively, it MAY use in-band signaling to advertise its 1249 interfaces, as defined in Section 9.3 (MPRTCP_Type=0x02). The 1250 receiving endpoint MUST use the same mechanism to respond to an 1251 interface advertisement. In particular, if an endpoint receives an 1252 SDP offer, then it MUST respond to the offer in SDP. 1254 11.3.1. "interface" attribute 1256 The interface attribute is an optional media-level attribute and is 1257 used to advertise an endpoint's interface address. 1259 The syntax of the interface attribute is defined using the following 1260 Augmented BNF, as defined in [9]. The definitions of unicast- 1261 address, port, token, SP, and CRLF are according to RFC4566 [17]. 1263 mprtp-optional-parameter = mprtp-interface 1264 ; other optional parameters may be added later 1266 mprtp-interface = "interface" ":" counter SP unicast-address 1267 ":" rtp_port "/" rtcp_port 1268 *(SP interface-description-extension) 1270 counter = 1*DIGIT 1271 rtp_port = port ;port from RFC4566 1272 rtcp_port = port ;port from RFC4566 1274 : specifies one of the unicast IP address, the RTP 1275 and RTCP port numbers of the endpoint. The unicast address with 1276 lowest counter value MUST match the connection address ('c=' line). 1277 Similarly, the RTP and RTCP ports MUST match with the RTP and RTCP 1278 ports in the associated 'm=' line. The counter should start at 1 and 1279 increment with each additional interface. Multiple interface lines 1280 MUST be ordered in a decreasing priority level as is the case with 1281 the Interface Advertisement blocks in in-band signaling (See 1282 Figure 13). 1284 : is taken from RFC4566 [17]. It is one of the IP 1285 addresses of the endpoint allows the use of IPv4 addresses, IPv6 1286 addresses and Fully Qualified Domain Names (FQDN). An endpoint MUST 1287 only include the IP address for which the connectivity checks have 1288 succeeded. 1290 : is from RFC4566 [17]. It is the RTP or RTCP port associated 1291 the unicast address. 1293 : is a monotonically increasing positive integer starting at 1294 1. The counter MUST reset for each media line. The counter value 1295 for an interface, port should remain the same for the session. 1297 The 'mprtp-interface' can be extended using the 'interface- 1298 description-extension' parameter. An endpoint MUST ignore any 1299 extensions it does not understand. 1301 11.3.2. Example 1303 The ABNF grammar is illustrated by means of an example: 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=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1314 a=mprtp interface:1 192.0.2.1:49170/49171 ;primary interface 1315 a=mprtp interface:2 192.1.2.1:51372/51373 ;additional interface 1317 11.4. MPRTP with ICE 1319 If the endpoints intend to use ICE [3] for discovering interfaces and 1320 running connectivity checks then the following two step procedure 1321 MUST be followed: 1323 1. Advertise ICE candidates: in the initial OFFER the endpoints 1324 exchange candidates, as defined in ICE [3]. Thereafter the 1325 endpoints run connectivity checks 1327 2. Advertise MPRTP interfaces: When a sufficient number of 1328 connectivity checks succeed the endpoint MUST send an updated 1329 offer containing the interfaces that they want to use for MPRTP. 1331 Typically when a sufficient number of connectivity checks succeed the 1332 endpoint choose the best ICE candidate as the default path. Since 1333 more than one candidate may have succeeded the connectivity checks, 1334 an MPRTP endpoint MAY advertise (some of) these as "mprtp- 1335 interfaces". 1337 11.5. Increased Throughput 1339 The MPRTP layer MAY choose to augment paths to increase throughput. 1340 If the desired media rate exceeds the current media rate, the 1341 endpoints MUST renegotiate the application specific ("b=AS:xxx") [17] 1342 bandwidth. 1344 11.6. Offer/Answer Examples 1346 This section shows examples of SDP offer and answer for in-band and 1347 out-of-band signaling. 1349 11.6.1. In-band signaling 1351 The following offer/answer shows that both the endpoints are MPRTP 1352 capable and SHOULD use in-band signaling for interfaces 1353 advertisements. 1355 Offer: 1356 v=0 1357 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1358 s= 1359 c=IN IP4 192.0.2.1 1360 t=0 0 1361 m=video 49170 RTP/AVP 98 1362 a=rtpmap:98 H264/90000 1363 a=fmtp:98 profile-level-id=42A01E; 1364 a=mprtp 1366 Answer: 1367 v=0 1368 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1369 s= 1370 c=IN IP4 192.0.2.2 1371 t=0 0 1372 m=video 4000 RTP/AVP 98 1373 a=rtpmap:98 H264/90000 1374 a=fmtp:98 profile-level-id=42A01E; 1375 a=mprtp 1377 The endpoint MAY now use in-band RTCP signaling to advertise its 1378 multiple interfaces. Alternatively, it MAY make another offer with 1379 the interfaces in SDP (out-of-band signaling). 1381 11.6.2. Out-of-band signaling 1383 If the multiple interfaces are included in an SDP offer then the 1384 receiver MUST respond to the request with an SDP answer. 1386 11.6.2.1. Without ICE 1388 In this example, the offerer advertises two interfaces and the 1389 answerer responds with a single interface description. The endpoint 1390 MAY use one or both paths depending on the end-to-end characteristics 1391 of each path. 1393 Offer: 1394 v=0 1395 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1396 s= 1397 c=IN IP4 192.0.2.1 1398 t=0 0 1399 m=video 49170 RTP/AVP 98 1400 a=rtpmap:98 H264/90000 1401 a=fmtp:98 profile-level-id=42A01E; 1402 a=mprtp interface:1 192.0.2.1:49170/49171 1403 a=mprtp interface:2 192.1.2.1:51372/51373 1405 Answer: 1406 v=0 1407 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1408 s= 1409 c=IN IP4 192.0.2.2 1410 t=0 0 1411 m=video 4000 RTP/AVP 98 1412 a=rtpmap:98 H264/90000 1413 a=fmtp:98 profile-level-id=42A01E; 1414 a=mprtp interface:1 192.0.2.2:4000/4001 1416 11.6.2.2. With ICE 1418 In this example, the endpoint first sends its ICE candidates in the 1419 initial offer and the other endpoint answers with its ICE candidates. 1421 Initial offer (with ICE candidates): 1423 Offer: 1424 v=0 1425 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1426 s= 1427 c=IN IP4 192.0.2.1 1428 t=0 0 1429 a=ice-pwd:asd88fgpdd777uzjYhagZg 1430 a=ice-ufrag:8hhY 1431 m=video 49170 RTP/AVP 98 1432 a=rtpmap:98 H264/90000 1433 a=fmtp:98 profile-level-id=42A01E; 1434 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 1435 a=candidate:2 1 UDP 1694498815 192.1.2.1 51372 typ host 1437 Answer: 1438 v=0 1439 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1440 s= 1441 c=IN IP4 192.0.2.2 1442 t=0 0 1443 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1444 a=ice-ufrag:9uB6 1445 m=video 4000 RTP/AVP 98 1446 a=rtpmap:98 H264/90000 1447 a=fmtp:98 profile-level-id=42A01E; 1448 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 1450 Thereafter, each endpoint conducts ICE connectivity checks and when 1451 sufficient number of connectivity checks succeed, the endpoint sends 1452 an updated offer. In the updated offer, the endpoint advertises its 1453 multiple interfaces for MPRTP. 1455 Updated offer (with MPRTP interfaces): 1457 Offer: 1458 v=0 1459 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1460 s= 1461 c=IN IP4 192.0.2.1 1462 t=0 0 1463 m=video 49170 RTP/AVP 98 1464 a=rtpmap:98 H264/90000 1465 a=fmtp:98 profile-level-id=42A01E; 1466 a=mprtp interface:1 192.0.2.1:49170/49171 1467 a=mprtp interface:2 192.1.2.1:51372/51373 1469 Answer: 1470 v=0 1471 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1472 s= 1473 c=IN IP4 192.0.2.2 1474 t=0 0 1475 m=video 4000 RTP/AVP 98 1476 a=rtpmap:98 H264/90000 1477 a=fmtp:98 profile-level-id=42A01E; 1478 a=mprtp interface:1 192.0.2.2:4000/4001 1480 12. IANA Considerations 1482 The following contact information shall be used for all registrations 1483 in this document: 1485 Contact: Varun Singh 1486 mailto:varun.singh@iki.fi 1487 tel:+358-9-470-24785 1489 12.1. MPRTP Header Extension 1491 This document defines a new extension URI to the RTP Compact Header 1492 Extensions sub-registry of the Real-Time Transport Protocol (RTP) 1493 Parameters registry, according to the following data: 1495 Extension URI: urn:ietf:params:rtp-hdrext:mprtp 1496 Description: Multipath RTP 1497 Reference: RFC XXXX 1499 12.2. MPRTCP Packet Type 1501 A new RTCP packet format has been registered with the RTCP Control 1502 Packet type (PT) Registry: 1504 Name: MPRTCP 1505 Long name: Multipath RTCP 1506 Value: 211 1507 Reference: RFC XXXX. 1509 12.3. SDP Attributes 1511 This document defines a new SDP attribute, "mprtp", within the 1512 existing IANA registry of SDP Parameters. 1514 TBD. 1516 13. Security Considerations 1518 TBD 1520 All drafts are required to have a security considerations section. 1521 See RFC 3552 [18] for a guide. 1523 14. Acknowledgements 1525 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1526 Trilogy (http://www.trilogy-project.org), a research project (ICT- 1527 216372) partially funded by the European Community under its Seventh 1528 Framework Program. The views expressed here are those of the 1529 author(s) only. The European Commission is not liable for any use 1530 that may be made of the information in this document. 1532 The authors would also like acknowledge the contribution of Ralf 1533 Globisch and Thomas Schierl for providing the input and text for the 1534 MPRTP interface advertisement in SDP. 1536 Thanks to Christer Holmberg, Miguel A. Garcia, and Roni Even for 1537 providing valuable feedback on earlier versions of this draft 1539 15. References 1540 15.1. Normative References 1542 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1543 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1544 RFC 3550, July 2003. 1546 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1547 Levels", BCP 14, RFC 2119, March 1997. 1549 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1550 Protocol for Network Address Translator (NAT) Traversal for 1551 Offer/Answer Protocols", RFC 5245, April 2010. 1553 [4] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1554 Real-Time Transport Control Protocol (RTCP): Opportunities and 1555 Consequences", RFC 5506, April 2009. 1557 [5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1558 "Extended RTP Profile for Real-time Transport Control Protocol 1559 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 1561 [6] Singer, D. and H. Desineni, "A General Mechanism for RTP Header 1562 Extensions", RFC 5285, July 2008. 1564 [7] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1565 Protocol (RTCP) Extensions for Single-Source Multicast Sessions 1566 with Unicast Feedback", RFC 5760, February 2010. 1568 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1569 STD 63, RFC 3629, November 2003. 1571 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1572 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1574 15.2. Informative References 1576 [10] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 1577 September 2007. 1579 [11] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, 1580 "Architectural Guidelines for Multipath TCP Development", 1581 RFC 6182, March 2011. 1583 [12] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 1584 Protocol for IPv6", RFC 5533, June 2009. 1586 [13] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1587 January 2008. 1589 [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1590 Session Description Protocol (SDP)", RFC 3264, June 2002. 1592 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1593 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1594 Session Initiation Protocol", RFC 3261, June 2002. 1596 [16] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. 1597 Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", 1598 draft-ietf-mmusic-rfc2326bis-28 (work in progress), 1599 October 2011. 1601 [17] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1602 Description Protocol", RFC 4566, July 2006. 1604 [18] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 1605 Security Considerations", BCP 72, RFC 3552, July 2003. 1607 [19] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping 1608 Alive the NAT Mappings Associated with RTP / RTP Control 1609 Protocol (RTCP) Flows", RFC 6263, June 2011. 1611 Appendix A. Interoperating with Legacy Applications 1613 An MPRTP sender can use its multiple interfaces to send media to a 1614 legacy RTP client. The legacy receiver will ignore the subflow RTP 1615 header and the receiver's de-jitter buffer will try to compensate for 1616 the mismatch in per-path delay. However, the receiver can only send 1617 the overall or aggregate RTCP report which may be insufficient for an 1618 MPRTP sender to adequately schedule packets or detect if a path 1619 disappeared. 1621 An MPRTP receiver can only use one of its interface when 1622 communicating with a legacy sender. 1624 Appendix B. Change Log 1626 Note to the RFC-Editor: please remove this section prior to 1627 publication as an RFC. 1629 B.1. changes in draft-singh-avtcore-mprtp-03 1631 o Added this change log. 1633 o Updated section 6, 7 and 8 based on comments from MMUSIC. 1635 o Updated section 11 (SDP) based on comments of MMUSIC. 1637 o Updated SDP examples with ICE and non-ICE in out-of-band signaling 1638 scenario. 1640 o Added Appendix A on interop with legacy. 1642 o Updated IANA considerations section 1644 B.2. changes in draft-singh-avtcore-mprtp-02 1646 o MPRTCP protocol extensions use only one PT=210, instead of 210 and 1647 211. 1649 o RTP header uses 1-byte extension instead of 2-byte. 1651 o Added section on RTCP Interval Calculations. 1653 o Added "mprtp-interface" attribute in SDP considerations. 1655 B.3. changes in draft-singh-avtcore-mprtp-01 1657 o Added MPRTP and MPRTCP protocol extensions and examples. 1659 o WG changed from -avt to -avtcore. 1661 Authors' Addresses 1663 Varun Singh 1664 Aalto University 1665 School of Science and Technology 1666 Otakaari 5 A 1667 Espoo, FIN 02150 1668 Finland 1670 Email: varun@comnet.tkk.fi 1671 URI: http://www.netlab.tkk.fi/~varun/ 1672 Teemu Karkkainen 1673 Aalto University 1674 School of Science and Technology 1675 Otakaari 5 A 1676 Espoo, FIN 02150 1677 Finland 1679 Email: teemuk@comnet.tkk.fi 1681 Joerg Ott 1682 Aalto University 1683 School of Science and Technology 1684 Otakaari 5 A 1685 Espoo, FIN 02150 1686 Finland 1688 Email: jo@comnet.tkk.fi 1690 Saba Ahsan 1691 Aalto University 1692 School of Science and Technology 1693 Otakaari 5 A 1694 Espoo, FIN 02150 1695 Finland 1697 Email: sahsan@cc.hut.fi 1699 Lars Eggert 1700 Nokia Research Center 1701 P.O. Box 407 1702 Nokia Group 00045 1703 Finland 1705 Phone: +358 50 48 24461 1706 Email: lars.eggert@nokia.com 1707 URI: http://research.nokia.com/people/lars_eggert