idnits 2.17.1 draft-singh-avtcore-mprtp-04.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 8 instances of lines with non-RFC2606-compliant FQDNs in the document. -- 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 (February 27, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (ref. '3') (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (ref. '7') (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '11') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5117 (ref. '14') (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. '19') (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-11 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Core Working Group V. Singh 3 Internet-Draft T. Karkkainen 4 Intended status: Experimental J. Ott 5 Expires: August 30, 2012 S. Ahsan 6 Aalto University 7 L. Eggert 8 NetApp 9 February 27, 2012 11 Multipath RTP (MPRTP) 12 draft-singh-avtcore-mprtp-04 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 August 30, 2012. 47 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Functional goals . . . . . . . . . . . . . . . . . . . . . 6 69 2.2. Compatibility goals . . . . . . . . . . . . . . . . . . . 7 70 3. RTP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. MPRTP Architecture . . . . . . . . . . . . . . . . . . . . . . 7 72 5. Example Media Flow Diagrams . . . . . . . . . . . . . . . . . 9 73 5.1. Streaming use-case . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Conversational use-case . . . . . . . . . . . . . . . . . 10 75 6. MPRTP Functional Blocks . . . . . . . . . . . . . . . . . . . 11 76 7. Available Mechanisms within the Functional Blocks . . . . . . 12 77 7.1. Session Setup . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1.1. Connectivity Checks . . . . . . . . . . . . . . . . . 12 79 7.1.2. Adding New or Updating Interfaces . . . . . . . . . . 12 80 7.1.3. In-band vs. Out-of-band Signaling . . . . . . . . . . 12 81 7.2. Expanding RTP . . . . . . . . . . . . . . . . . . . . . . 14 82 7.3. Expanding RTCP . . . . . . . . . . . . . . . . . . . . . . 14 83 7.4. Failure Handling and Teardown . . . . . . . . . . . . . . 14 84 8. MPRTP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 15 85 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8.1.1. Gather or Discovering Candidates . . . . . . . . . . . 16 87 8.1.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 16 88 8.1.3. Choosing between In-band (in RTCP) and Out-of-band 89 (in SDP) Interface Advertisement . . . . . . . . . . . 16 90 8.1.4. In-band Interface Advertisement . . . . . . . . . . . 17 91 8.1.5. Subflow ID Assignment . . . . . . . . . . . . . . . . 17 92 8.1.6. Active and Passive Subflows . . . . . . . . . . . . . 17 93 8.2. RTP Transmission . . . . . . . . . . . . . . . . . . . . . 18 94 8.3. Playout Considerations at the Receiver . . . . . . . . . . 18 95 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation . . 18 96 8.5. RTCP Transmission . . . . . . . . . . . . . . . . . . . . 19 97 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 19 98 9.1. RTP Header Extension for MPRTP . . . . . . . . . . . . . . 19 99 9.1.1. MPRTP RTP Extension for a Subflow . . . . . . . . . . 21 100 9.2. RTCP Extension for MPRTP (MPRTCP) . . . . . . . . . . . . 21 101 9.2.1. MPRTCP Extension for Subflow Reporting . . . . . . . . 23 102 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR . . . . 24 103 9.3. MPRTCP Extension for Interface advertisement . . . . . . . 26 104 10. RTCP Timing reconsiderations for MPRTCP . . . . . . . . . . . 27 105 11. SDP Considerations . . . . . . . . . . . . . . . . . . . . . . 27 106 11.1. Signaling MPRTP Header Extension in SDP . . . . . . . . . 28 107 11.2. Signaling MPRTP capability in SDP . . . . . . . . . . . . 28 108 11.3. MPRTP Interface Advertisement in SDP (out-of-band 109 signaling) . . . . . . . . . . . . . . . . . . . . . . . . 29 110 11.3.1. "interface" attribute . . . . . . . . . . . . . . . . 29 111 11.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 30 112 11.4. MPRTP with ICE . . . . . . . . . . . . . . . . . . . . . . 30 113 11.5. Increased Throughput . . . . . . . . . . . . . . . . . . . 31 114 11.6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . 31 115 11.6.1. In-band Signaling Example . . . . . . . . . . . . . . 32 116 11.6.2. Out-of-band Signaling Example . . . . . . . . . . . . 32 117 11.6.2.1. Without ICE . . . . . . . . . . . . . . . . . . . 32 118 11.6.2.2. With ICE . . . . . . . . . . . . . . . . . . . . . 33 119 12. MPRTP in RTSP . . . . . . . . . . . . . . . . . . . . . . . . 35 120 12.1. Solution Overview without ICE . . . . . . . . . . . . . . 35 121 12.2. Solution Overview with ICE . . . . . . . . . . . . . . . . 37 122 12.3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . 39 123 12.3.1. MPRTP Interface Transport Header Parameter . . . . . . 39 124 12.3.2. MPRTP Feature Tag . . . . . . . . . . . . . . . . . . 40 125 12.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 40 126 12.3.4. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . 40 127 12.3.5. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . 41 128 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 129 13.1. MPRTP Header Extension . . . . . . . . . . . . . . . . . . 42 130 13.2. MPRTCP Packet Type . . . . . . . . . . . . . . . . . . . . 42 131 13.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 43 132 13.3.1. "mprtp" attribute . . . . . . . . . . . . . . . . . . 43 133 13.4. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 134 13.4.1. RTSP Feature Tag . . . . . . . . . . . . . . . . . . . 44 135 13.4.2. RTSP Transport Parameters . . . . . . . . . . . . . . 44 136 13.4.3. Notify-Reason value . . . . . . . . . . . . . . . . . 44 137 14. Security Considerations . . . . . . . . . . . . . . . . . . . 44 138 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 139 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 140 16.1. Normative References . . . . . . . . . . . . . . . . . . . 45 141 16.2. Informative References . . . . . . . . . . . . . . . . . . 46 142 Appendix A. Interoperating with Legacy Applications . . . . . . . 46 143 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 144 B.1. changes in draft-singh-avtcore-mprtp-04 . . . . . . . . . 47 145 B.2. changes in draft-singh-avtcore-mprtp-03 . . . . . . . . . 47 146 B.3. changes in draft-singh-avtcore-mprtp-02 . . . . . . . . . 48 147 B.4. changes in draft-singh-avtcore-mprtp-01 . . . . . . . . . 48 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 150 1. Introduction 152 Multi-homed endpoints are becoming common in today's Internet, e.g., 153 devices that support multiple wireless access technologies such as 3G 154 and Wireless LAN. This means that there is often more than one 155 network path available between two endpoints. Transport protocols, 156 such as RTP, have not been designed to take advantage of the 157 availability of multiple concurrent paths and therefore cannot 158 benefit from the increased capacity and reliability that can be 159 achieved by pooling their respective capacities. 161 Multipath RTP (MPRTP) is an OPTIONAL extension to RTP [1] that allows 162 splitting a single RTP stream into multiple subflows that are 163 transmitted over different paths. In effect, this pools the resource 164 capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension 165 to RTCP, it is used along with MPRTP to report per-path sender and 166 receiver characteristics. 168 Other IETF transport protocols that are capable of using multiple 169 paths include SCTP [11], MPTCP [12] and SHIM6 [13]. However, these 170 protocols are not suitable for realtime communications. 172 1.1. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [2]. 178 1.2. Terminology 180 o Endpoint: host either initiating or terminating an RTP flow. 182 o Interface: logical or physical component that is capable of 183 acquiring a unique IP address. 185 o Path: sequence of links between a sender and a receiver. 186 Typically, defined by a set of source and destination addresses. 188 o Subflow: flow of RTP packets along a specific path, i.e., a subset 189 of the packets belonging to an RTP stream. The combination of all 190 RTP subflows forms the complete RTP stream. Typically, a subflow 191 would map to a unique path, i.e., each combination of IP addresses 192 and port pairs (5-tuple, including protocol) is a unique subflow. 194 1.3. Use-cases 196 The primary use-case for MPRTP is transporting high bit-rate 197 streaming multimedia content between endpoints, where at least one is 198 multi-homed. Such endpoints could be residential IPTV devices that 199 connect to the Internet through two different Internet service 200 providers (ISPs), or mobile devices that connect to the Internet 201 through 3G and WLAN interfaces. By allowing RTP to use multiple 202 paths for transmission, the following gains can be achieved: 204 o Higher quality: Pooling the resource capacity of multiple Internet 205 paths allows higher bit-rate and higher quality codecs to be used. 206 From the application perspective, the available bandwidth between 207 the two endpoints increases. 209 o Load balancing: Transmitting an RTP stream over multiple paths 210 reduces the bandwidth usage on a single path, which in turn 211 reduces the impact of the media stream on other traffic on that 212 path. 214 o Fault tolerance: When multiple paths are used in conjunction with 215 redundancy mechanisms (FEC, re-transmissions, etc.), outages on 216 one path have less impact on the overall perceived quality of the 217 stream. 219 A secondary use-case for MPRTP is transporting Voice over IP (VoIP) 220 calls to a device with multiple interfaces. Again, such an endpoint 221 could be a mobile device with multiple wireless interfaces. In this 222 case, little is to be gained from resource pooling, i.e., higher 223 capacity or load balancing, because a single path should be easily 224 capable of handling the required load. However, using multiple 225 concurrent subflows can improve fault tolerance, because traffic can 226 shift between the subflows when path outages occur. This results in 227 very fast transport-layer handovers that do not require support from 228 signaling. 230 2. Goals 232 This section outlines the basic goals that multipath RTP aims to 233 meet. These are broadly classified as Functional goals and 234 Compatibility goals. 236 2.1. Functional goals 238 Allow unicast RTP session to be split into multiple subflows in order 239 to be carried over multiple paths. This may prove beneficial in case 240 of video streaming. 242 o Increased Throughput: Cumulative capacity of the two paths may 243 meet the requirements of the multimedia session. Therefore, MPRTP 244 MUST support concurrent use of the multiple paths. 246 o Improved Reliability: MPRTP SHOULD be able to send redundant 247 packets or re-transmit packets along any available path to 248 increase reliability. 250 The protocol SHOULD be able to open new subflows for an existing 251 session when new paths appear and MUST be able to close subflows when 252 paths disappear. 254 2.2. Compatibility goals 256 MPRTP MUST be backwards compatible; an MPRTP stream needs to fall 257 back to be compatible with legacy RTP stacks if MPRTP support is not 258 successfully negotiated. 260 o Application Compatibility: MPRTP service model MUST be backwards 261 compatible with existing RTP applications, i.e., an MPRTP stack 262 MUST be able to work with legacy RTP applications and not require 263 changes to them. Therefore, the basic RTP APIs MUST remain 264 unchanged, but an MPRTP stack MAY provide extended APIs so that 265 the application can configure any additional features provided by 266 the MPRTP stack. 268 o Network Compatibility: individual RTP subflows MUST themselves be 269 well-formed RTP flows, so that they are able to traverse NATs and 270 firewalls. This MUST be the case even when interfaces appear 271 after session initiation. Interactive Connectivity Establishment 272 (ICE) [3] MAY be used for discovering new interfaces or performing 273 connectivity checks. 275 3. RTP Topologies 277 RFC 5117 [14] describes a number of scenarios using mixers and 278 translators in single-party (point-to-point), and multi-party (point- 279 to-multipoint) scenarios. RFC 3550 [1] (Section 2.3 and 7.x) discuss 280 in detail the impact of mixers and translators on RTP and RTCP 281 packets. MPRTP assumes that if a mixer or translator exists in the 282 network, then either all of the multiple paths or none of the 283 multiple paths go via this component. 285 4. MPRTP Architecture 287 In a typical scenario, an RTP session uses a single path. In an 288 MPRTP scenario, an RTP session uses multiple subflows that each use a 289 different path. Figure 1 shows the difference. 291 +--------------+ Signaling +--------------+ 292 | |------------------------------------>| | 293 | Client |<------------------------------------| Server | 294 | | Single RTP flow | | 295 +--------------+ +--------------+ 297 +--------------+ Signaling +--------------+ 298 | |------------------------------------>| | 299 | Client |<------------------------------------| Server | 300 | |<------------------------------------| | 301 +--------------+ MPRTP subflows +--------------+ 303 Figure 1: Comparison between traditional RTP streaming and MPRTP 305 +-----------------------+ +-------------------------------+ 306 | Application | | Application | 307 +-----------------------+ +-------------------------------+ 308 | | | MPRTP | 309 + RTP + +- - - - - - - -+- - - - - - - -+ 310 | | | RTP subflow | RTP subflow | 311 +-----------------------+ +---------------+---------------+ 312 | UDP | | UDP | UDP | 313 +-----------------------+ +---------------+---------------+ 314 | IP | | IP | IP | 315 +-----------------------+ +---------------+---------------+ 317 Figure 2: MPRTP Architecture 319 Figure 2 illustrates the differences between the standard RTP stack 320 and the MPRTP stack. MPRTP receives a normal RTP session from the 321 application and splits it into multiple RTP subflows. Each subflow 322 is then sent along a different path to the receiver. To the network, 323 each subflow appears as an independent, well-formed RTP flow. At the 324 receiver, the subflows are combined to recreate the original RTP 325 session. The MPRTP layer performs the following functions: 327 o Path Management: The layer is aware of alternate paths to the 328 other host, which may, for example, be the peer's multiple 329 interfaces. This enables the endpoint to transmit differently 330 marked packets along separate paths. MPRTP also selects 331 interfaces to send and receive data. Furthermore, it manages the 332 port and IP address pair bindings for each subflow. 334 o Packet Scheduling: the layer splits a single RTP flow into 335 multiple subflows and sends them across multiple interfaces 336 (paths). The splitting MAY BE done using different path 337 characteristics. 339 o Subflow recombination: the layer creates the original stream by 340 recombining the independent subflows. Therefore, the multipath 341 subflows appear as a single RTP stream to applications. 343 5. Example Media Flow Diagrams 345 There may be many complex technical scenarios for MPRTP, however, 346 this memo only considers the following two scenarios: 1) a 347 unidirectional media flow that represents the streaming use-case, and 348 2) a bidirectional media flow that represents a conversational use- 349 case. 351 5.1. Streaming use-case 353 In the unidirectional scenario, the receiver (client) initiates a 354 multimedia session with the sender (server). The receiver or the 355 sender may have multiple interfaces and both endpoints are MPRTP- 356 capable. Figure 3 shows this scenario. In this case, host A has 357 multiple interfaces. Host B performs connectivity checks on host A's 358 multiple interfaces. If the interfaces are reachable, then host B 359 streams multimedia data along multiple paths to host A. Moreover, 360 host B also sends RTCP Sender Reports (SR) for each subflow and host 361 A responds with a normal RTCP Receiver Report (RR) for the overall 362 session as well as the receiver statistics for each subflow. Host B 363 distributes the packets across the subflows based on the individually 364 measured path characteristics. 366 Alternatively, to reduce media startup time, host B may start 367 streaming multimedia data to host A's initiating interface and then 368 perform connectivity checks for the other interfaces. This method of 369 updating a single path session to a multipath session is called 370 "multipath session upgrade". 372 Host A Host B 373 ----------------------- ---------- 374 Interface A1 Interface A2 Interface B1 375 ----------------------- ---------- 376 | | 377 |------------------------------------->| Session setup with 378 |<-------------------------------------| multiple interfaces 379 | | | 380 | | | 381 | (RTP data B1->A1, B1->A2) | 382 |<=====================================| 383 | |<========================| 384 | | | 385 Note: there may be more scenarios. 387 Figure 3: Unidirectional media flow 389 5.2. Conversational use-case 391 In the bidirectional scenario, multimedia data flows in both 392 directions. The two hosts exchange their lists of interfaces with 393 each other and perform connectivity checks. Communication begins 394 after each host finds suitable address, port pairs. Interfaces that 395 receive data send back RTCP receiver statistics for that path (based 396 on the 5-tuple). The hosts balance their multimedia stream across 397 multiple paths based on the per path reception statistics and its own 398 volume of traffic. Figure 4 describes an example of a bidirectional 399 flow. 401 Host A Host B 402 --------------------------- --------------------------- 403 Interface A1 Interface A2 Interface B1 Interface B2 404 --------------------------- --------------------------- 405 | | | | 406 | | | |Session setup 407 |----------------------------------->| |with multiple 408 |<-----------------------------------| |interfaces 409 | | | | 410 | | | | 411 | (RTP data B1<->A1, B2<->A2) | | 412 |<===================================| | 413 | |<===================================| 414 |===================================>| | 415 | |===================================>| 416 | | | | 417 Note: the address pairs may have other permutations, 418 and they may be symmetric or asymmetric combinations. 420 Figure 4: Bidirectional flow 422 6. MPRTP Functional Blocks 424 This section describes some of the functional blocks needed for 425 MPRTP. We then investigate each block and consider available 426 mechanisms in the next section. 428 1. Session Setup: Interfaces may appear or disappear at anytime 429 during the session. To preserve backward compatibility with 430 legacy applications, a multipath session MUST look like a bundle 431 of individual RTP sessions. A multipath session may be upgraded 432 from a typical single path session, as and when new interfaces 433 appear or disappear. However, it is also possible to setup a 434 multipath session from the beginning, if the interfaces are 435 available at the start of the multimedia session. 437 2. Expanding RTP: For a multipath session, each subflow MUST look 438 like an independent RTP flow, so that individual RTCP messages 439 can be generated per subflow. Furthermore, MPRTP splits the 440 single multimedia stream into multiple subflows based on path 441 characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth- 442 delay product etc.) and dynamically adjusts the load on each 443 link. 445 3. Adding Interfaces: Interfaces on the host need to be regularly 446 discovered and advertised. This can be done at session setup 447 and/or during the session. Discovering interfaces is outside the 448 scope of this document. 450 4. Expanding RTCP: MPRTP MUST provide per path RTCP reports for 451 monitoring the quality of the path, for load balancing, or for 452 congestion control, etc. To maintain backward compatibility with 453 legacy applications, the receiver MUST also send aggregate RTCP 454 reports along with the per-path reports. 456 5. Maintenance and Failure Handling: In a multi-homed endpoint 457 interfaces may appear and disappear. If this occurs at the 458 sender, it has to re-adjust the load on the available links. On 459 the other hand, if this occurs at the receiver, then the 460 multimedia data transmitted by the sender to those interfaces is 461 lost. This data may be re-transmitted along a different path 462 i.e., to a different interface on the receiver. Furthermore, the 463 endpoint has to either explicitly signal the disappearance of an 464 interface, or the other endpoint has to detect it (by lack of 465 media packets, RTCP feedback, or keep-alive packets). 467 6. Teardown: The MPRTP layer releases the occupied ports on the 468 interfaces. 470 7. Available Mechanisms within the Functional Blocks 472 This section discusses some of the possible alternatives for each 473 functional block mentioned in the previous section. 475 7.1. Session Setup 477 MPRTP session can be set up in many possible ways e.g., during 478 handshake, or upgraded mid-session. The capability exchange may be 479 done using out-of-band signaling (e.g., Session Description Protocol 480 (SDP) [15] in Session Initiation Protocol (SIP) [16], Real-Time 481 Streaming Protocol (RTSP) [17]) or in-band signaling (e.g., RTP/RTCP 482 header extension, Session Traversal Utilities for NAT (STUN) 483 messages). 485 7.1.1. Connectivity Checks 487 The endpoint SHOULD be capable of performing connectivity checks 488 (e.g., using ICE [3]). If the IP addresses of the endpoints are 489 reachable (e.g., globally addressable, same network etc) then 490 connectivity checks are not needed. 492 7.1.2. Adding New or Updating Interfaces 494 Interfaces can appear and disappear during a session, the endpoint 495 MUST be capable of advertising the changes in its set of usable 496 interfaces. Additionally, the application or OS may define a policy 497 on when and/or what interfaces are usable. However, MPRTP requires a 498 method to advertise or notify the other endpoint about the updated 499 set of usable interfaces. 501 7.1.3. In-band vs. Out-of-band Signaling 503 MTRTP nodes will generally use a signaling protocol to establish 504 their MPRTP session. With the existence of such a signaling 505 relationship, two alternatives become available to exchange 506 information about the available interfaces on each side for extending 507 RTP sessions to MPRTP and for modifying MPRTP sessions: in-band and 508 out-of-band signaling. 510 In-band signaling refers to using mechanisms of RTP/RTCP itself to 511 communicate interface addresses, e.g., a dedicated RTCP extensions 512 along the lines of the one defined to communicate information about 513 the feedback target for RTP over SSM [4]. In-band signaling does not 514 rely on the availability of a separate signaling connection and the 515 information flows along the same path as the media streams, thus 516 minimizing dependencies. Moreover, if the media channel is secured 517 (e.g., by means of SRTP), the signaling is implicitly protected as 518 well if SRTCP encryption and authentication are chosen. In-band 519 signaling is also expected to take a direct path to the peer, 520 avoiding any signaling overlay-induced indirections and associated 521 processing overheads in signaling elements -- avoiding such may be 522 especially worthwhile if frequent updates may occur as in the case of 523 mobile users. Finally, RTCP is usually sent sufficiently frequently 524 (in point-to-point settings) to provide enough opportunities for 525 transmission and (in case of loss) retransmission of the 526 corresponding RTCP packets. 528 Examples for in-band signaling include RTCP extensions as noted above 529 or suitable extensions to STUN. 531 Out-of-band signaling refers to using a separate signaling connection 532 (via SIP, RTSP, or HTTP) to exchange interface information, e.g., 533 expressed in SDP. Clear benefits are that signaling occurs at setup 534 time anyway and that experience and SDP syntax (and procedures) are 535 available that can be re-used or easily adapted to provide the 536 necessary capabilities. In contrast to RTCP, SDP offers a reliable 537 communication channel so that no separate retransmissions logic is 538 necessary. In SDP, especially when combined with ICE, connectivity 539 check mechanisms including sophisticated rules are readily available. 540 While SDP is not inherently protected, suitable security may need to 541 be applied anyway to the basic session setup. 543 Examples for out-of-band signaling are dedicated extensions to SDP; 544 those may be combined with ICE. 546 Both types of mechanisms have their pros and cons for middleboxes. 547 With in-band signaling, control packets take the same path as the 548 media packets and they can be directly inspected by middleboxes so 549 that the elements operating on the signaling channel do not need to 550 understand new SDP. With out-of-band signaling, only the middleboxes 551 processing the signaling need to be modified and those on the data 552 forwarding path can remain untouched. 554 Overall, it may appear sensible to provide a combination of both 555 mechanisms: out-of-band signaling for session setup and initial 556 interface negotiation and in-band signaling to deal with frequent 557 changes in interface state (and for the potential case, albeit rather 558 theoretical case of MPRTP communication without a signaling channel). 560 In its present version, this document explores both options to 561 provide a broad understanding of how the corresponding mechanisms 562 would look like. 564 [[Comment.1: Some have suggested STUN may be suitable for doing in- 565 band interface advertisement. This is still under consideration, but 566 depends on implementation challenges as many legacy systems don't 567 implement STUN and many RTP systems ignore STUN messages. --Editor]] 569 7.2. Expanding RTP 571 RTCP [1] is generated per media session. However, with MPRTP, the 572 media sender spreads the RTP load across several interfaces. The 573 media sender SHOULD make the path selection, load balancing and fault 574 tolerance decisions based on the characteristics of each path. 575 Therefore, apart from normal RTP sequence numbers defined in [1], the 576 MPRTP sender MUST add subflow-specific sequence numbers to help 577 calculate fractional losses, jitter, RTT, playout time, etc., for 578 each path, and a subflow identifier to associate the characteristics 579 with a path. The RTP header extension for MPRTP is shown in 580 Section 9.1. 582 7.3. Expanding RTCP 584 To provide accurate per path information an MPRTP endpoint MUST send 585 (SR/RR) report for each unique subflow along with the overall session 586 RTCP report. Therefore, the additional subflow reporting affects the 587 RTCP bandwidth and the RTCP reporting interval. RTCP report 588 scheduling for each subflow may cause a problem for RTCP 589 recombination and reconstruction in cases when 1) RTCP for a subflow 590 is lost, and 2) RTCP for a subflow arrives later than the other 591 subflows. (There may be other cases as well.) 593 The sender distributes the media across different paths using the per 594 path RTCP reports. However, this document doesn't cover algorithms 595 for congestion control or load balancing. 597 7.4. Failure Handling and Teardown 599 An MPRTP endpoint MUST keep alive subflows that have been negotiated 600 but no media is sent on them. Moreover, using the information in the 601 subflow reports, a sender can monitor an active subflow for failure 602 (errors, unreachability, congestion) and decide not to use (make the 603 active subflow passive), or teardown the subflow. 605 If an interface disappears, the endpoint MUST send an updated 606 interface advertisement without the interface and release the the 607 associated subflows. 609 8. MPRTP Protocol 611 Host A Host B 612 ----------------------- ----------------------- 613 Interface A1 Interface A2 Interface B1 Interface B2 614 ----------------------- ----------------------- 615 | | | | 616 | | (1) | | 617 |--------------------------------------->| | 618 |<---------------------------------------| | 619 | | (2) | | 620 |<=======================================| | 621 |<=======================================| (3) | 622 | | (4) | | 623 |<- - - - - - - - - - - - - - - - - - - -| | 624 |<- - - - - - - - - - - - - - - - - - - -| | 625 |<- - - - - - - - - - - - - - - - - - - -| | 626 | | (5) | | 627 |- - - - - - - - - - - - - - - - - - - ->| | 628 |<=======================================| (6) | 629 |<=======================================| | 630 | |<========================================| 631 |<=======================================| | 632 | |<========================================| 634 Key: 635 | Interface 636 ---> Signaling Protocol 637 <=== RTP Packets 638 - -> RTCP Packet 640 Figure 5: MPRTP New Interface 642 8.1. Overview 644 The bullet points explain the different steps shown in Figure 5 for 645 upgrading a single path multimedia session to multipath session. 647 (1) The first two interactions between the hosts represents the 648 establishment of a normal RTP session. This may performed e.g. 649 using SIP or RTSP. 651 (2) When the RTP session has been established, host B streams 652 media using its interface B1 to host A at interface A1. 654 (3) Host B supports sending media using MPRTP and becomes aware of 655 an additional interface B2. 657 (4) Host B advertises the multiple interface addresses. 659 (5) Host A supports receiving media using MPRTP and becomes aware 660 of an additional interface A2. 662 Side note, even if an MPRTP-capable host has only one interface, 663 it MUST respond to the advertisement with its single interface. 665 (6) Each host receives information about the additional interfaces 666 and the appropriate endpoints starts to stream the multimedia 667 content using the additional paths. 669 If needed, each endpoint will need to independently perform 670 connectivity checks (not shown in figure) and ascertain 671 reachability before using the paths. 673 8.1.1. Gather or Discovering Candidates 675 The endpoint periodically polls the operating system or is notified 676 when an additional interface appears. If the endpoint wants to use 677 the additional interface for MPRTP it MUST advertise it to the other 678 peers. The endpoint may also use ICE [3] to gather additional 679 candidates. 681 8.1.2. NAT Traversal 683 After gathering their interface candidates, the endpoints decide 684 internally if they wish to perform connectivity checks. 686 [[Comment.2: Legacy applications do not require ICE for session 687 establishment, therefore, MPRTP should not require it as well. 688 --Editor]] 690 If the endpoint chooses to perform connectivity checks then it MUST 691 first advertise the gathered candidates as ICE candidates in SDP 692 during session setup and let ICE perform the connectivity checks. As 693 soon as a sufficient number of connectivity checks succeed, the 694 endpoint can use the successful candidates to advertise its MPRTP 695 interface candidates. 697 8.1.3. Choosing between In-band (in RTCP) and Out-of-band (in SDP) 698 Interface Advertisement 700 If there is no media flowing at the moment and the application wants 701 to use the interfaces from the start of the session, it should 702 advertise them in SDP (See Section 11.3). Alternatively, the 703 endpoint can setup the session as a single path media session and 704 upgrade the session to multipath by advertising the session in-band 705 (See Section 8.1.4). Moreover, if an interface appears and 706 disappears, the endpoint SHOULD prefer to advertise it in-band 707 because the endpoint would not have to wait for a response from the 708 other endpoint before starting to use the interface. However, if 709 there is a conflict between an in-band and out-of-band advertisement, 710 i.e., the endpoint receives an in-band advertisement while it has a 711 pending out-of-band advertisement, or vice versa then the session is 712 setup using out-of-band mechanisms. 714 8.1.4. In-band Interface Advertisement 716 To advertise the multiple interfaces in RTCP, an MPRTP-capable 717 endpoint MUST add the MPRTP Interface Advertisement defined in 718 Figure 13 with the RTCP Sender Report (SR). Each unique address is 719 encapsulated in an Interface Advertisement block and contains the IP 720 address, RTP and RTCP port addresses. The Interface Advertisement 721 blocks are ordered based on a decreasing priority level. On 722 receiving the MPRTP Interface Advertisement, an MPRTP-capable 723 receiver MUST respond with the set of interfaces (subset or all 724 available) it wants to use. 726 If the sender and receiver have only one interface, then the 727 endpoints MUST indicate the negotiated single path IP, RTP port and 728 RTCP port addresses. 730 8.1.5. Subflow ID Assignment 732 After interface advertisements have been exchanged, the endpoint MUST 733 associate a Subflow ID to each unique subflow. Each combination of 734 sender and receiver IP addresses and port pairs (5-tuple) is a unique 735 subflow. If the connectivity checks have been performed then the 736 endpoint MUST only use the subflows for which the connectivity checks 737 have succeeded. 739 8.1.6. Active and Passive Subflows 741 To send and receive data an endpoint MAY use any number of subflows 742 from the set of available subflows. The subflows that carry media 743 data are called active subflows, while those subflows that don't send 744 any media packets (fallback paths) are called passive subflows. 746 An endpoint MUST multiplex the subflow specific RTP and RTCP packets 747 on the same port to keep the NAT bindings alive. This is inline with 748 the recommendation made in RFC6263[18]. Moreover, if an endpoint 749 uses ICE, multiplexing RTP and RTCP reduces the number of components 750 from 2 to 1 per media stream. If no MPRTP or MPRTCP packets are 751 received on a particular subflow at a receiver, the receiver SHOULD 752 remove the subflow from active and passive lists and not send any 753 MPRTCP reports for that subflow. It may keep the bindings in a dead- 754 pool, so that if the 5-tuple or subflow reappears, it can quickly 755 reallocate it based on past history. 757 8.2. RTP Transmission 759 If both endpoints are MPRTP-capable and if they want to use their 760 multiple interfaces for sending the media stream then they MUST use 761 the MPRTP header extensions. They MAY use normal RTP with legacy 762 endpoints (see Appendix A). 764 An MPRTP endpoint sends RTP packets with an MPRTP extension that maps 765 the media packet to a specific subflow (see Figure 8). The MPRTP 766 layer SHOULD associate an RTP packet with a subflow based on a 767 scheduling strategy. The scheduling strategy may either choose to 768 augment the paths to create higher throughput or use the alternate 769 paths for enhancing resilience or error-repair. Due to the changes 770 in path characteristics, the endpoint should be able change its 771 scheduling strategy during an ongoing session. The MPRTP sender MUST 772 also populate the subflow specific fields described in the MPRTP 773 extension header (see Section 9.1.1). 775 8.3. Playout Considerations at the Receiver 777 A media receiver, irrespective of MPRTP support or not, should be 778 able to playback the media stream because the received RTP packets 779 are compliant to [1], i.e., a non-MPRTP receiver will ignore the 780 MPRTP header and still be able to playback the RTP packets. However, 781 the variation of jitter and loss per path may affect proper playout. 782 The receiver can compensate for the jitter by modifying the playout 783 delay (i.e., by calculating skew across all paths) of the received 784 RTP packets. 786 8.4. Subflow-specific RTCP Statistics and RTCP Aggregation 788 Aggregate RTCP provides the overall media statistics and follows the 789 normal RTCP defined in RFC3550 [1]. However, subflow specific RTCP 790 provides the per path media statistics because the aggregate RTCP 791 report may not provide sufficient per path information to an MPRTP 792 scheduler. Specifically, the scheduler should be aware of each 793 path's RTT and loss-rate, which an aggregate RTCP cannot provide. 794 The sender/receiver MUST use non-compound RTCP reports defined in 795 RFC5506 [5] to transmit the aggregate and subflow-specific RTCP 796 reports. Also, each subflow and the aggregate RTCP report MUST 797 follow the timing rules defined in [6]. 799 The RTCP reporting interval is locally implemented and the scheduling 800 of the RTCP reports may depend on the the behavior of each path. For 801 instance, the RTCP interval may be different for a passive path than 802 an active path to keep port bindings alive. Additionally, an 803 endpoint may decide to share the RTCP reporting bit rate equally 804 across all its paths or schedule based on the receiver rate on each 805 path. 807 8.5. RTCP Transmission 809 The sender sends an RTCP SR on each active path. For each SR the 810 receiver gets, it echoes one back to the same IP address-port pair 811 that sent the SR. The receiver tries to choose the symmetric path 812 and if the routing is symmetric then the per-path RTT calculations 813 will work out correctly. However, even if the paths are not 814 symmetric, the sender would at maximum, under-estimate the RTT of the 815 path by a factor of half of the actual path RTT. 817 9. Packet Formats 819 In this section we define the protocol structures described in the 820 previous sections. 822 9.1. RTP Header Extension for MPRTP 824 The MPRTP header extension is used to distribute a single RTP stream 825 over multiple subflows. 827 The header conforms to the one-byte RTP header extension defined in 828 [7]. The header extension contains a 16-bit length field that counts 829 the number of 32-bit words in the extension, excluding the four-octet 830 extension header (therefore zero is a valid length, see Section 5.3.1 831 of [1] for details). 833 The RTP header for each subflow is defined below: 835 0 1 2 3 836 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 |V=2|P|1| CC |M| PT | sequence number | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | timestamp | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | synchronization source (SSRC) identifier | 843 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 844 | 0xBE | 0xDE | length=N-1 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | ID | LEN | MPID |LENGTH | MPRTP header data | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 848 | .... | 849 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 850 | RTP payload | 851 | .... | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Figure 6: Generic MPRTP header extension 856 MPID: 858 The MPID field corresponds to the type of MPRTP packet. 859 Namely: 861 +---------------+--------------------------------------------------+ 862 | MPID ID | Use | 863 | Value | | 864 +---------------+--------------------------------------------------+ 865 | 0x0 | Subflow RTP Header. For this case the Length is | 866 | | set to 6 | 867 +---------------+--------------------------------------------------+ 869 Figure 7: RTP header extension values for MPRTP (H-Ext ID) 871 length 873 The 4-bit length field is the length of extension data in bytes 874 not including the H-Ext ID and length fields. The value zero 875 indicates there is no data following. 877 MPRTP header data 879 Carries the MPID specific data as described in the following 880 sub-sections. 882 9.1.1. MPRTP RTP Extension for a Subflow 884 The RTP header for each subflow is defined below: 886 0 1 2 3 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 |V=2|P|1| CC |M| PT | sequence number | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | timestamp | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | synchronization source (SSRC) identifier | 894 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 895 | 0xBE | 0xDE | length=3 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | ID | LEN=4 | 0x0 | LEN=4 | Subflow ID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Subflow-specific Seq Number | Pad (0) | Pad (0) | 900 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 901 | RTP payload | 902 | .... | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Figure 8: MPRTP header for subflow 907 MP ID = 0x0 909 Indicates that the MPRTP header extension carries subflow 910 specific information. 912 length = 4 914 Subflow ID: Identifier of the subflow. Every RTP packet belonging 915 to the same subflow carries the same unique subflow identifier. 917 Flow-Specific Sequence Number (FSSN): Sequence of the packet in 918 the subflow. Each subflow has its own strictly monotonically 919 increasing sequence number space. 921 9.2. RTCP Extension for MPRTP (MPRTCP) 923 The MPRTP RTCP header extension is used to 1) provide RTCP feedback 924 per subflow to determine the characteristics of each path, and 2) 925 advertise each interface. 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 |V=2|P|reserved | PT=MPRTCP=211 | length | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | SSRC of packet sender | 933 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 934 | SSRC_1 (SSRC of first source) | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | MPRTCP_Type | block length | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MPRTCP Reports | 938 | ... | 939 | ... | 940 | ... | 941 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 943 Figure 9: Generic RTCP Extension for MPRTP (MPRTCP) [appended to 944 normal SR/RR] 946 MPRTCP: 8 bits 948 Contains the constant 211 to identify this as an Multipath RTCP 949 packet. 951 length: 16 bits 953 As described for the RTCP packet (see Section 6.4.1 of the RTP 954 specification [1]), the length of this is in 32-bit words minus 955 one, including the header and any padding. 957 MPRTCP_Type: 8-bits 959 The MPRTCP_Type field corresponds to the type of MPRTP RTCP 960 packet. Namely: 962 +---------------+--------------------------------------------------+ 963 | MPRTCP_Type | Use | 964 | Value | | 965 +---------------+--------------------------------------------------+ 966 | 0 | Subflow Specific Report | 967 | 1 | Interface Advertisement (IPv4 Address) | 968 | 2 | Interface Advertisement (IPv4 Address) | 969 | 3 | Interface Advertisement (DNS Address) | 970 +---------------+--------------------------------------------------+ 972 Figure 10: RTP header extension values for MPRTP (MPRTCP_Type) 974 block length: 8-bits 976 The 8-bit length field is the length of the encapsulated MPRTCP 977 reports in 32-bit word length not including the MPRTCP_Type and 978 length fields. The value zero indicates there is no data 979 following. 981 MPRTCP Reports: variable size 983 Defined later in 9.2.1 and 9.3. 985 9.2.1. MPRTCP Extension for Subflow Reporting 987 When sending a report for a specific subflow the sender or receiver 988 MUST add only the reports associated with that 5-tuple. Each subflow 989 is reported independently using the following MPRTCP Feedback header. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |V=2|P|reserved | PT=MPRTCP=211 | length | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | SSRC of packet sender | 997 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 998 | SSRC_1 (SSRC of first source) | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Subflow-specific reports | 1003 | .... | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Subflow-specific reports | 1008 | .... | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 Figure 11: MPRTCP Subflow Reporting Header 1013 MPRTCP_Type: 0 1015 The value indicates that the encapsulated block is a subflow 1016 report. 1018 block length: 8-bits 1020 The 8-bit length field is the length of the encapsulated subflow- 1021 specific reports in 32-bit word length not including the 1022 MPRTCP_Type and length fields. 1024 Subflow ID: 16 bits 1026 Subflow identifier is the value associated with the subflow the 1027 endpoint is reporting about. If it is a sender it MUST use the 1028 Subflow ID associated with the 5-tuple. If it is a receiver it 1029 MUST use the Subflow ID received in the Subflow-specific Sender 1030 Report. 1032 Subflow-specific reports: variable 1034 Subflow-specific report contains all the reports associated with 1035 the Subflow ID. For a sender, it MUST include the Subflow- 1036 specific Sender Report (SSR). For a receiver, it MUST include 1037 Subflow-specific Receiver Report (SRR). Additionally, if the 1038 receiver supports subflow-specific extension reports then it MUST 1039 append them to the SRR. 1041 9.2.1.1. MPRTCP for Subflow-specific SR, RR and XR 1043 [[Comment.3: inside the context of subflow specific reports can we 1044 reuse the payload type code for Sender Report (PT=200), Receiver 1045 Report (PT=201), Extension Report (PT=207).Transport and Payload 1046 specific RTCP messages are session specific and SHOULD be used as 1047 before. --Editor]] 1049 Example: 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |V=2|P|reserved | PT=MPRTCP=211 | length | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | SSRC of packet sender | 1057 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1058 | SSRC_1 (SSRC of first source) | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | MPRTCP_Type=0 | block length | Subflow ID #1 | 1061 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1062 |V=2|P| RC | PT=SR=200 | length | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | SSRC of sender | 1065 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1066 | NTP timestamp, most significant word | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | NTP timestamp, least significant word | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | RTP timestamp | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | subflow's packet count | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | subflow's octet count | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | MPRTCP_Type=0 | block length | Subflow ID #2 | 1077 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1078 |V=2|P| RC | PT=RR=201 | length | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | SSRC of packet sender | 1081 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1082 | fraction lost | cumulative number of packets lost | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | extended highest sequence number received | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | inter-arrival jitter | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | last SR (LSR) | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | delay since last SR (DLSR) | 1091 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1092 | Subflow specific extension reports | 1093 | .... | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 Figure 12: Example of reusing RTCP SR and RR inside an MPRTCP header 1097 (Bi-directional use-case, in case of uni-directional flow the subflow 1098 will only send an SR or RR). 1100 9.3. MPRTCP Extension for Interface advertisement 1102 This sub-section defines the RTCP header extension for in-band 1103 interface advertisement by the receiver. The interface advertisement 1104 block describes a method to represent IPv4, IPv6 and generic DNS-type 1105 addresses in a block format. It is based on the sub-reporting block 1106 in [4]. The interface advertisement SHOULD immediately follow the 1107 Receiver Report. If the Receiver Report is not present, then it MUST 1108 be appended to the Sender Report. 1110 The endpoint MUST advertise the interfaces it wants to use whenever 1111 an interface appears or disappears and also when it receives an 1112 Interface Advertisement. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 |V=2|P|reserved | PT=MPRTCP=211 | length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | SSRC of packet sender | 1120 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1121 | SSRC_1 (SSRC of first source) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | MPRTCP_Type | block length | RTP Port | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Interface Address #1 | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | MPRTCP_Type | block length | RTP Port | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Interface Address #2 | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | MPRTCP_Type | block length | RTP Port | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Interface Address #.. | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | MPRTCP_Type | block length | RTP Port | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Interface Address #m | 1138 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1140 Figure 13: MPRTP Interface Advertisement. (appended to SR/RR) 1142 MPRTCP_Type: 8 bits 1144 The MPRTCP_Type corresponds to the type of interface address. 1145 Namely: 1147 1: IPv4 address 1149 2: IPv6 address 1151 3: DNS name 1153 block length: 8 bits 1155 The length of the Interface Advertisement block in bytes. 1157 For an IPv4 address, this should be 9 (i.e., 5 octets for 1158 the header and 4 octets for IPv4 address). 1160 For an IPv6 address, this should be 21. 1162 For a DNS name, the length field indicates the number of 1163 octets making up the string plus the 5 byte header. 1165 RTP Port: 2 octets 1167 The port number to which the sender sends RTP data. A port 1168 number of 0 is invalid and MUST NOT be used. 1170 Interface Address: 4 octets (IPv4), 16 octets (IPv6), or n octets 1171 (DNS name) 1173 The address to which receivers send feedback reports. For IPv4 1174 and IPv6, fixed-length address fields are used. A DNS name is 1175 an arbitrary-length string. The string MAY contain 1176 Internationalizing Domain Names in Applications (IDNA) domain 1177 names and MUST be UTF-8 [8] encoded. 1179 10. RTCP Timing reconsiderations for MPRTCP 1181 MPRTP endpoints MUST conform to the timing rule imposed in [6], i.e., 1182 the total RTCP rate between the participants MUST NOT exceed 5% of 1183 the media rate. For each endpoint, a subflow MUST send the aggregate 1184 and subflow-specific report. The endpoint SHOULD schedule the RTCP 1185 reports for the active subflows based on the share of the transmitted 1186 or received bit rate to the average media bit rate, this method 1187 ensures fair sharing of the RTCP bandwidth. Alternatively, the 1188 endpoint MAY schedule the reports in round-robin. 1190 11. SDP Considerations 1191 11.1. Signaling MPRTP Header Extension in SDP 1193 To indicate the use of the MPRTP header extensions (see Section 9) in 1194 SDP, the sender MUST use the following URI in extmap: 1195 urn:ietf:params:rtp-hdrext:mprtp. This is a media level parameter. 1196 Legacy RTP (non-MPRTP) clients will ignore this header extension, but 1197 can continue to parse and decode the packet (see Appendix A). 1199 Example: 1201 v=0 1202 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1203 s= 1204 c=IN IP4 192.0.2.1 1205 t=0 0 1206 m=video 49170 RTP/AVP 98 1207 a=rtpmap:98 H264/90000 1208 a=fmtp:98 profile-level-id=42A01E; 1209 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1211 11.2. Signaling MPRTP capability in SDP 1213 A participant of a media session MUST use SDP to indicate that it 1214 supports MPRTP. Not providing this information will make the other 1215 endpoint ignore the RTCP extensions. 1217 mprtp-attrib = "a=" "mprtp" [ 1218 SP mprtp-optional-parameter] 1219 CRLF ; flag to enable MPRTP 1221 The endpoint MUST use 'a=mprtp', if it is able to send and receive 1222 MPRTP packets. Generally, senders and receivers MUST indicate this 1223 capability if they support MPRTP and would like to use it in the 1224 specific media session being signaled. To exchange the additional 1225 interfaces, the endpoint SHOULD use the in-band signaling 1226 (Section 9.3). Alternatively, advertise in SDP (Section 11.3). 1228 MPRTP endpoint multiplexes RTP and RTCP on a single port, sender MUST 1229 indicate support by adding "a=rtcp-mux" in SDP. If an endpoint 1230 receives an SDP without "a=rtcp-mux" but contains "a=mprtp", then the 1231 endpoint MUST infer support for multiplexing. 1233 [[Comment.4: If a=mprtp is indicated, does the endpoint need to 1234 indicate a=rtcp-mux? because MPRTP mandates RTP RTCP multiplexing. 1235 --Editor]] 1237 11.3. MPRTP Interface Advertisement in SDP (out-of-band signaling) 1239 If the endpoint is aware of its multiple interfaces and wants to use 1240 them for MPRTP then it MAY use SDP to advertise these interfaces. 1241 Alternatively, it MAY use in-band signaling to advertise its 1242 interfaces, as defined in Section 9.3. The receiving endpoint MUST 1243 use the same mechanism to respond to an interface advertisement. In 1244 particular, if an endpoint receives an SDP offer, then it MUST 1245 respond to the offer in SDP. 1247 11.3.1. "interface" attribute 1249 The interface attribute is an optional media-level attribute and is 1250 used to advertise an endpoint's interface address. 1252 The syntax of the interface attribute is defined using the following 1253 Augmented BNF, as defined in [9]. The definitions of unicast- 1254 address, port, token, SP, and CRLF are according to RFC4566 [19]. 1256 mprtp-optional-parameter = mprtp-interface 1257 ; other optional parameters may be added later 1259 mprtp-interface = "interface" ":" counter SP unicast-address 1260 ":" rtp_port 1261 *(SP interface-description-extension) 1263 counter = 1*DIGIT 1264 rtp_port = port ;port from RFC4566 1266 : specifies one unicast IP address, the RTP and RTCP 1267 port number of the endpoint. The unicast address with lowest counter 1268 value MUST match the connection address ('c=' line). Similarly, the 1269 RTP and RTCP ports MUST match the RTP and RTCP ports in the 1270 associated 'm=' line. The counter should start at 1 and increment 1271 with each additional interface. Multiple interface lines MUST be 1272 ordered in a decreasing priority level as is the case with the 1273 Interface Advertisement blocks in in-band signaling (See Figure 13). 1275 : is taken from RFC4566 [19]. It is one of the IP 1276 addresses of the endpoint and allows the use of IPv4 addresses, IPv6 1277 addresses and Fully Qualified Domain Names (FQDN). An endpoint MUST 1278 only include the IP address for which the connectivity checks have 1279 succeeded. 1281 : is from RFC4566 [19]. It is the RTP port associated with the 1282 unicast address and note that the RTP and RTCP ports are multiplexed 1283 for MPRTP subflows. 1285 : is a monotonically increasing positive integer starting at 1286 1. The counter MUST reset for each media line. The counter value 1287 for an 'mprtp-interface' should remain the same for the session. 1289 The 'mprtp-interface' can be extended using the 'interface- 1290 description-extension' parameter. An endpoint MUST ignore any 1291 extensions it does not understand. 1293 11.3.2. Example 1295 The ABNF grammar is illustrated by means of an example: 1297 v=0 1298 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1299 s= 1300 c=IN IP4 192.0.2.1 1301 t=0 0 1302 m=video 49170 RTP/AVP 98 1303 a=rtpmap:98 H264/90000 1304 a=fmtp:98 profile-level-id=42A01E; 1305 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1306 a=rtcp-mux 1307 a=mprtp interface:1 192.0.2.1:49170 ;primary interface 1308 a=mprtp interface:2 198.51.100.1:51372 ;additional interface 1310 11.4. MPRTP with ICE 1312 If the endpoints intend to use ICE [3] for discovering interfaces and 1313 running connectivity checks then the following two step procedure 1314 MUST be followed: 1316 1. Advertise ICE candidates: in the initial OFFER the endpoints 1317 exchange candidates, as defined in ICE [3]. Thereafter the 1318 endpoints run connectivity checks. 1320 2. Advertise MPRTP interfaces: When a sufficient number of 1321 connectivity checks succeed the endpoint MUST send an updated 1322 offer containing the interfaces that they want to use for MPRTP. 1324 When an endpoint uses ICE's regular nomination [3] procedure, it 1325 chooses the best ICE candidate as the default path. In the case of 1326 an MPRTP endpoint, if more than one ICE candidate succeeded the 1327 connectivity checks then an MPRTP endpoint MAY advertise (some of) 1328 these as "mprtp-interfaces" in an updated offer. 1330 When an endpoint uses ICE's aggressive nomination [3] procedure, the 1331 selected candidate may change as more ICE checks complete. Instead 1332 of sending updated offers as additional ICE candidates appear 1333 (transience), the endpoint it MAY use in-band signaling to advertise 1334 its interfaces, as defined in Section 9.3. Additionally, it MAY send 1335 an updated offer when the transience stabilizes. 1337 If the default interface disappears and the paths used for MPRTP are 1338 different from the one in the c= and m= lines then the mprtp- 1339 intefaces with the lowest counter value should be promoted to the c= 1340 and m= lines in the updated offer. 1342 When a new interface appears then the application/endpoint should 1343 internally decide if it wishes to use it and sends an updated offer 1344 with ICE candidates of the new interface. The receiving endpoint 1345 responds to the offer with all its ICE candidates in the answer and 1346 starts connectivity checks between all its candidates and the 1347 offerer's new ICE candidate. Similarly, the initiating endpoint 1348 starts connectivity checks between the new interface and all the 1349 received ICE candidates in the answer. If the connectivity checks 1350 succeed, the initiating endpoint MAY send an updated offer with the 1351 new interface as an additional mprtp-interface. 1353 11.5. Increased Throughput 1355 The MPRTP layer MAY choose to augment paths to increase throughput. 1356 If the desired media rate exceeds the current media rate, the 1357 endpoints MUST renegotiate the application specific ("b=AS:xxx") [19] 1358 bandwidth. 1360 11.6. Offer/Answer 1362 When the SDP [19] is used to negotiate MPRTP sessions following the 1363 offer/answer model [15], the "a=mprtp" attribute (see Section 11.2) 1364 indicates the desire to use multiple interfaces to send or receive 1365 media data. The initial SDP offer MUST include this attribute at the 1366 media level. If the answerer wishes to also use MPRTP, it MUST 1367 include a media-level "a=mprtp" attribute in the answer. If the 1368 answer does not contain an "a=mprtp" attribute, the offerer MUST NOT 1369 stream media over multiple paths and the offerer MUST NOT advertise 1370 additional MPRTP interfaces in-band or out-of-band. 1372 When SDP is used in a declarative manner, the presence of an 1373 "a=mprtp" attribute signals that the sender can send or receive media 1374 data over multiple interfaces. The receiver SHOULD be capable to 1375 stream media to the multiple interfaces and be prepared to receive 1376 media from multiple interfaces. 1378 The following sections shows examples of SDP offer and answer for in- 1379 band and out-of-band signaling. 1381 11.6.1. In-band Signaling Example 1383 The following offer/answer shows that both the endpoints are MPRTP 1384 capable and SHOULD use in-band signaling for interfaces 1385 advertisements. 1387 Offer: 1388 v=0 1389 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1390 s= 1391 c=IN IP4 192.0.2.1 1392 t=0 0 1393 m=video 49170 RTP/AVP 98 1394 a=rtpmap:98 H264/90000 1395 a=fmtp:98 profile-level-id=42A01E; 1396 a=rtcp-mux 1397 a=mprtp 1399 Answer: 1400 v=0 1401 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1402 s= 1403 c=IN IP4 192.0.2.2 1404 t=0 0 1405 m=video 4000 RTP/AVP 98 1406 a=rtpmap:98 H264/90000 1407 a=fmtp:98 profile-level-id=42A01E; 1408 a=rtcp-mux 1409 a=mprtp 1411 The endpoint MAY now use in-band RTCP signaling to advertise its 1412 multiple interfaces. Alternatively, it MAY make another offer with 1413 the interfaces in SDP (out-of-band signaling). 1415 11.6.2. Out-of-band Signaling Example 1417 If the multiple interfaces are included in an SDP offer then the 1418 receiver MUST respond to the request with an SDP answer. 1420 11.6.2.1. Without ICE 1422 In this example, the offerer advertises two interfaces and the 1423 answerer responds with a single interface description. The endpoint 1424 MAY use one or both paths depending on the end-to-end characteristics 1425 of each path. 1427 Offer: 1428 v=0 1429 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1430 s= 1431 c=IN IP4 192.0.2.1 1432 t=0 0 1433 m=video 49170 RTP/AVP 98 1434 a=rtpmap:98 H264/90000 1435 a=fmtp:98 profile-level-id=42A01E; 1436 a=rtcp-mux 1437 a=mprtp interface:1 192.0.2.1:49170 1438 a=mprtp interface:2 198.51.100.1:51372 1440 Answer: 1441 v=0 1442 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1443 s= 1444 c=IN IP4 192.0.2.2 1445 t=0 0 1446 m=video 4000 RTP/AVP 98 1447 a=rtpmap:98 H264/90000 1448 a=fmtp:98 profile-level-id=42A01E; 1449 a=rtcp-mux 1450 a=mprtp interface:1 192.0.2.2:4000 1452 11.6.2.2. With ICE 1454 In this example, the endpoint first sends its ICE candidates in the 1455 initial offer and the other endpoint answers with its ICE candidates. 1457 Initial offer (with ICE candidates): 1459 Offer: 1460 v=0 1461 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1462 s= 1463 c=IN IP4 192.0.2.1 1464 t=0 0 1465 a=ice-pwd:asd88fgpdd777uzjYhagZg 1466 a=ice-ufrag:8hhY 1467 a=mprtp 1468 m=video 49170 RTP/AVP 98 1469 a=rtpmap:98 H264/90000 1470 a=fmtp:98 profile-level-id=42A01E; 1471 a=rtcp-mux 1472 a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host 1473 a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host 1475 Answer: 1476 v=0 1477 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1478 s= 1479 c=IN IP4 192.0.2.2 1480 t=0 0 1481 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1482 a=ice-ufrag:9uB6 1483 a=mprtp 1484 m=video 4000 RTP/AVP 98 1485 a=rtpmap:98 H264/90000 1486 a=fmtp:98 profile-level-id=42A01E; 1487 a=rtcp-mux 1488 a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host 1490 Thereafter, each endpoint conducts ICE connectivity checks and when 1491 sufficient number of connectivity checks succeed, the endpoint sends 1492 an updated offer. In the updated offer, the endpoint advertises its 1493 multiple interfaces for MPRTP. 1495 Updated offer (with MPRTP interfaces): 1497 Offer: 1498 v=0 1499 o=alice 2890844526 2890844527 IN IP4 192.0.2.1 1500 s= 1501 c=IN IP4 192.0.2.1 1502 t=0 0 1503 m=video 49170 RTP/AVP 98 1504 a=rtpmap:98 H264/90000 1505 a=fmtp:98 profile-level-id=42A01E; 1506 a=rtcp-mux 1507 a=mprtp interface:1 192.0.2.1:49170 1508 a=mprtp interface:2 198.51.100.1:51372 1510 Answer: 1511 v=0 1512 o=bob 2890844528 2890844529 IN IP4 192.0.2.2 1513 s= 1514 c=IN IP4 192.0.2.2 1515 t=0 0 1516 m=video 4000 RTP/AVP 98 1517 a=rtpmap:98 H264/90000 1518 a=fmtp:98 profile-level-id=42A01E; 1519 a=rtcp-mux 1520 a=mprtp interface:1 192.0.2.2:4000 1522 12. MPRTP in RTSP 1524 Endpoints MUST use RTSP 2.0 [17] for session setup. Endpoints MUST 1525 multiplex RTP and RTCP on a single port [10] and follow the 1526 recommendations made in Appendix C of [17]. 1528 12.1. Solution Overview without ICE 1530 1. The RTSP Server should include all of its multiple interfaces via 1531 the SDP attribute ("a=mprtp interface") in the RTSP DESCRIBE 1532 message. 1534 2. The RTSP Client should include all its multiple interface in the 1535 RTSP SETUP message using the new attribute ("dest_mprtp_addr=") 1536 in the Transport header. [[Comment.5: Do we need a new lower 1537 layer transport MPRTP?. --Editor]] 1539 3. The RTSP Server responds to the RTSP SETUP message with a 200 OK 1540 containing its MPRTP interfaces (using the "src_mprtp_header=") 1541 in the Transport header. After this the RTSP Client can issue a 1542 PLAY request. 1544 4. If a new interface appears or an old one disappear at the RTSP 1545 Client during playback, it should send a new RTSP SETUP message 1546 containing the updated interfaces ("dest_mprtp_addr") in the 1547 Transport header. [[Comment.6: Sending a re-SETUP to update the 1548 interfaces during PLAY state would require a change in behavior 1549 of the server. Similar to Section 5.12 of 1550 [draft-ietf-mmusic-rtsp-nat]. --Editor]] 1552 5. If a new interface appear or an old one disappear at the RTSP 1553 Server during playback, the RTSP Server should send a PLAY_NOTIFY 1554 message with a new Notify-Reason: "src-mprtp-interface-update". 1555 The request must contain the updated interfaces 1556 ("dest_mprtp_addr") in the "MPRTP-Interfaces" header. 1558 6. Alternatively, the RTSP Server or Client may use the RTCP (in- 1559 band) mechanism to advertise their interfaces. 1561 [[Comment.7: Does it make sense to advertise out-of-band (in RTSP 1562 SETUP) when advertising in-band in RTCP is less complex? --Editor]] 1564 The overview is illustrated by means of an example: 1566 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 1567 CSeq: 111 1568 User-Agent: PhonyClient 1.3 1569 Accept: application/sdp, application/example 1570 Supported: setup.mprtp, setup.rtp.rtcp.mux 1572 S->C: RTSP/2.0 200 OK 1573 CSeq: 111 1574 Date: 23 Jan 2011 15:35:06 GMT 1575 Server: PhonyServer 1.3 1576 Content-Type: application/sdp 1577 Content-Length: 367 1578 Supported: setup.mprtp, setup.rtp.rtcp.mux 1580 v=0 1581 o=mprtp-rtsp-server 2890844526 2890844527 IN IP4 192.0.2.1 1582 s= 1583 c=IN IP4 192.0.2.1 1584 t=0 0 1585 m=video 49170 RTP/AVP 98 1586 a=rtpmap:98 H264/90000 1587 a=fmtp:98 profile-level-id=42A01E; 1588 a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp 1589 a=rtcp-mux 1590 a=mprtp interface:1 192.0.2.1:49170 1591 a=mprtp interface:2 198.51.100.1:51372 1593 On receiving the response to the RTSP DESCRIBE message, the RTSP 1594 Client sends a RTSP SETUP message containing its MPRTP interfaces in 1595 the Transport header using the "dest_mprtp_addr=" attribute. The 1596 RTSP Server responds with a 200 OK containing both the RTSP client's 1597 and the RTSP Server's MPRTP interfaces. 1599 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 1600 CSeq: 112 1601 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 1602 1 192.0.2.2 4000"; RTCP-mux, 1603 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 1604 RTP/AVP/TCP;unicast;interleaved=0-1 1605 Accept-Ranges: NPT, UTC 1606 User-Agent: PhonyClient 1.3 1607 Supported: setup.mprtp, setup.rtp.rtcp.mux 1609 S->C: RTSP/2.0 200 OK 1610 CSeq: 112 1611 Session: 12345678 1612 Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr=" 1613 1 192.0.2.2 4000"; 1614 src_mprtp_addr="1 192.0.2.1 49170; 1615 2 198.51.100.1 51372"; RTCP-mux 1616 Accept-Ranges: NPT 1617 Date: 23 Jan 2012 15:35:06 GMT 1618 Server: PhonyServer 1.3 1619 Supported: setup.mprtp, setup.rtp.rtcp.mux 1621 The RTSP Client can issue a PLAY request on receiving the 200 OK and 1622 media can start to stream once the RTSP server receives the PLAY 1623 request. 1625 12.2. Solution Overview with ICE 1627 This overview uses the ICE mechanisms [20] defined for RTSP 2.0 [17]. 1629 1. The RTSP Server should include the "a=rtsp-ice-d-m" attribute and 1630 also indicate that it supports MPRTP by including the "a=mprtp" 1631 attribute in the SDP of the RTSP DESCRIBE message. 1633 2. The client sends a RTSP SETUP message containing the D-ICE in 1634 lower level transport and ICE candidates in the transport header. 1635 The RTSP Server and client then follow the procedures (Steps 2 to 1636 8) described in [20]. 1638 3. When the connectivity checks conclude the RTSP Client can send an 1639 updated RTSP SETUP message with its MPRTP interfaces (ICE 1640 candidates that were successful) in the Transport header 1641 ("dest_mprtp_addr="). The RTSP Server responds to the RTSP SETUP 1642 message with a 200 OK containing its MPRTP interfaces (ICE 1643 candidates that were successful) in the Transport header 1644 ("src_mprtp_header="). After receiving the 200 OK, the RTSP 1645 client can issue the PLAY request. 1647 4. Alternatively after the connectivity checks conclude, the RTSP 1648 Client can issue the PLAY request (Step 9 and 10 of [20]) and the 1649 endpoints can use the RTCP (in-band) mechanism to advertise their 1650 interfaces. 1652 5. If a new interface appears or an old one disappears, the RTSP 1653 Client should issue an updated SETUP message with the new 1654 candidates (See Section 5.12 of [20]) or the RTSP Server should 1655 send a PLAY_NOTIFY message (See Section 5.13 of [20]). After 1656 connectivity checks succeed for the new interfaces, the RTSP 1657 Client can proceed with the instructions in Step 3 or 4. 1659 The overview is illustrated by means of an example: 1661 C->S: DESCRIBE rtsp://server.example.com/foo RTSP/2.0 1662 CSeq: 312 1663 User-Agent: PhonyClient 1.3 1664 Accept: application/sdp, application/example 1665 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 1667 S->C: RTSP/2.0 200 OK 1668 CSeq: 312 1669 Date: 23 Jan 2012 15:35:06 GMT 1670 Server: PhonyServer 1.3 1671 Content-Type: application/sdp 1672 Content-Length: 367 1673 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 1675 v=0 1676 o=mprtp-rtsp-server 2890844526 2890842807 IN IP4 192.0.2.1 1677 s=SDP Seminar 1678 i=A Seminar on the session description protocol 1679 u=http://www.example.com/lectures/sdp.ps 1680 e=seminar@example.com (Seminar Management) 1681 t=2873397496 2873404696 1682 a=recvonly 1683 a=rtsp-ice-d-m 1684 a=control: * 1685 m=video 49170 RTP/AVP 98 1686 a=rtpmap:98 H264/90000 1687 a=fmtp:98 profile-level-id=42A01E; 1688 a=rtcp-mux 1689 a=mprtp 1690 a=control: /video 1692 C->S: SETUP rtsp://server.example.com/foo/video RTSP/2.0 1693 CSeq: 302 1694 Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=9uB6; 1695 ICE-Password=YH75Fviy6338Vbrhrlp8Yh; 1696 candidates="1 1 UDP 2130706431 192.0.2.2 1697 4000 typ host"; RTCP-mux, 1698 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", 1699 RTP/AVP/TCP;unicast;interleaved=0-1 1700 Accept-Ranges: NPT, UTC 1701 User-Agent: PhonyClient 1.3 1702 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 1704 S->C: RTSP/2.0 200 OK 1705 CSeq: 302 1706 Session: 12345678 1707 Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; 1708 ICE-ufrag=8hhY; ICE-Password= 1709 asd88fgpdd777uzjYhagZg; candidates=" 1710 1 1 UDP 2130706431 192.0.2.1 49170 typ host; 1711 2 1 UDP 1694498815 198.51.100.1 51372 typ host" 1712 Accept-Ranges: NPT 1713 Date: 23 Jan 2012 15:35:06 GMT 1714 Server: PhonyServer 1.3 1715 Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux 1717 After the connectivity checks complete, the RTSP Client can send an 1718 updated RTSP SETUP message containing the MPRTP interfaces for which 1719 the connectivity checks were successful. These steps are the same as 1720 the ones in the previous example. 1722 12.3. RTSP Extensions 1724 12.3.1. MPRTP Interface Transport Header Parameter 1726 This section defines a new RTSP transport parameter for carrying 1727 MPRTP interfaces. The transport parameters may only occur once in 1728 each transport specification. The parameter can contain one or more 1729 MPRTP interfaces. In the SETUP response if the RTSP server support 1730 MPRTP it MUST be include one or more MPRTP interfaces. 1732 trns-parameter = 1734 trns-parameter =/ SEMI dest-mprtp-interface-par 1735 trns-parameter =/ SEMI src-mprtp-interface-par 1736 dest-mprtp-interface-par = "dest_mprtp_addr" EQUAL DQ SWS 1737 interface *(SEMI interface) SWS DQ 1738 src-mprtp-interface-par = "src_mprtp_addr" EQUAL DQ SWS 1739 interface *(SEMI interface) SWS DQ 1741 interface = counter SP 1742 unicast-address SP 1743 rtp_port SP 1744 *(SP interface-description-extension) 1746 counter = See section 11.3.1 1747 unicast-address = See section 11.3.1 1748 rtp_port = See section 11.3.1 1749 interface-description-extension = See section 11.3.1 1751 12.3.2. MPRTP Feature Tag 1753 A feature tag is defined for indicating MPRTP support in the RTSP 1754 capabilities mechanism: "setup.mprtp". This feature tag indicates 1755 that the endpoint supports all the mandatory extensions defined in 1756 this specification and is applicable to all types of RTSP agents; 1757 clients, servers and proxies. 1759 The MPRTP compliant RTSP Client MUST send the feature tag 1760 "setup.mprtp" in the "Supported" header of all DESCRIBE and SETUP 1761 requests. 1763 12.3.3. Status Codes 1765 TBD 1767 12.3.4. New Reason for PLAY_NOTIFY 1769 A new value used in the PLAY_NOTIFY methods Notify-Reason header is 1770 defined: "src-mprtp-interface-update". This reason indicates that 1771 the RTSP Server has updated set of MPRTP interfaces. 1773 Notify-Reas-val =/ "src-mprtp-interface-update" 1775 PLAY_NOTIFY requests with Notify-Reason header set to src-mprtp- 1776 interface-update MUST include a mprtp-interfaces header. 1778 mprtp-interfaces = "mprtp-interfaces" HCOLON interface 1779 *(COMMA interface) 1780 interface = counter SP 1781 unicast-address SP 1782 rtp_port SP 1783 *(SP interface-description-extension) 1785 counter = See section 11.3.1 1786 unicast-address = See section 11.3.1 1787 rtp_port = See section 11.3.1 1788 interface-description-extension = See section 11.3.1 1790 [[Comment.8: Do we need to add a new header attribute?. 1791 Alternatively, the RTSP Server could just send the PLAY_NOTIFY and 1792 let the RTSP client initiate a new RTSP SETUP message with its 1793 current interfaces and the RTSP Server can then respond with its 1794 updated set of interfaces. This will make it a 3-way exchange as 1795 opposed to a 1-way notification. Alternatively, using SET_PARAMETER 1796 reduces it to a 2-way exchange and can be initiated by both the RTSP 1797 Server and the RTSP Client. However, SET_PARAMETER can only be used 1798 when the endpoints are in SETUP state. --Editor]] 1800 Example: 1802 S->C: PLAY_NOTIFY rtsp://server.example.com/foo RTSP/2.0 1803 CSeq: 305 1804 Notify-Reason: src-mprtp-interface-update 1805 Session: 12345678 1806 mprtp-interfaces: 2 192.0.2.10 48211, 3 198.51.100.11 38703 1807 Server: PhonyServer 1.3 1809 C->S: RTSP/2.0 200 OK 1810 CSeq: 305 1811 User-Agent: PhonyClient 1.3 1813 12.3.5. re-SETUP 1815 The server SHALL support SETUP requests in PLAYING state if it is 1816 only updating the transport parameter (dest_mprtp_addr). If the 1817 session is established using ICE then the RTSP Server and Client MUST 1818 also follow the procedures described for re-SETUP in [20]. 1820 13. IANA Considerations 1822 The following contact information shall be used for all registrations 1823 in this document: 1825 Contact: Varun Singh 1826 mailto:varun.singh@iki.fi 1827 tel:+358-9-470-24785 1829 Note to the RFC-Editor: When publishing this document as an RFC, 1830 please replace "RFC XXXX" with the actual RFC number of this document 1831 and delete this sentence. 1833 13.1. MPRTP Header Extension 1835 This document defines a new extension URI to the RTP Compact Header 1836 Extensions sub-registry of the Real-Time Transport Protocol (RTP) 1837 Parameters registry, according to the following data: 1839 Extension URI: urn:ietf:params:rtp-hdrext:mprtp 1840 Description: Multipath RTP 1841 Reference: RFC XXXX 1843 13.2. MPRTCP Packet Type 1845 A new RTCP packet format has been registered with the RTCP Control 1846 Packet type (PT) Registry: 1848 Name: MPRTCP 1849 Long name: Multipath RTCP 1850 Value: 211 1851 Reference: RFC XXXX. 1853 This document defines a substructure for MPRTCP packets. A new sub- 1854 registry has been set up for the sub-report block type (MPRTCP_Type) 1855 values for the MPRTCP packet, with the following registrations 1856 created initially: 1858 Name: Subflow Specific Report 1859 Long name: Multipath RTP Subflow Specific Report 1860 Value: 0 1861 Reference: RFC XXXX. 1863 Name: IPv4 Address 1864 Long name: IPv4 Interface Address 1865 Value: 1 1866 Reference: RFC XXXX. 1868 Name: IPv6 Address 1869 Long name: IPv6 Interface Address 1870 Value: 2 1871 Reference: RFC XXXX. 1873 Name: DNS Name 1874 Long name: DNS Name indicating Interface Address 1875 Value: 3 1876 Reference: RFC XXXX. 1878 Further values may be registered on a first come, first served basis. 1879 For each new registration, it is mandatory that a permanent, stable, 1880 and publicly accessible document exists that specifies the semantics 1881 of the registered parameter as well as the syntax and semantics of 1882 the associated sub-report block. The general registration procedures 1883 of [19] apply. 1885 13.3. SDP Attributes 1887 This document defines a new SDP attribute, "mprtp", within the 1888 existing IANA registry of SDP Parameters. 1890 13.3.1. "mprtp" attribute 1892 o Attribute Name: MPRTP 1894 o Long Form: Multipath RTP 1896 o Type of Attribute: media-level 1898 o Charset Considerations: The attribute is not subject to the 1899 charset attribute. 1901 o Purpose: This attribute is used to indicate support for Multipath 1902 RTP. It can also provide one of many possible interfaces for 1903 communication. These interface addresses may have been validated 1904 using ICE procedures. 1906 o Appropriate Values: See Section 11.2 and Section 11.3.1 of RFC 1907 XXXX. 1909 13.4. RTSP 1911 This document requests registration in a number of registries for 1912 RTSP. 1914 13.4.1. RTSP Feature Tag 1916 This document request that one RTSP 2.0 feature tag be registered in 1917 the "RTSP 2.0 feature tag" registry: 1919 setup.mprtp See Section 12.3.2. 1921 13.4.2. RTSP Transport Parameters 1923 This document requests that 2 transport parameters be registered in 1924 RTSP 2.0's "Transport Parameters": 1926 "dest_mprtp_addr": See Section 12.3.1. 1928 "src_mprtp_addr": See Section 12.3.1. 1930 13.4.3. Notify-Reason value 1932 This document requests that one assignment be done in the RTSP 2.0 1933 Notify-Reason header value registry. The defined value is: 1935 "src-mprtp-interface-update": See Section 12.3.4. 1937 14. Security Considerations 1939 TBD 1941 All drafts are required to have a security considerations section. 1942 See RFC 3552 [21] for a guide. 1944 15. Acknowledgements 1946 Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by 1947 Trilogy (http://www.trilogy-project.org), a research project (ICT- 1948 216372) partially funded by the European Community under its Seventh 1949 Framework Program. The views expressed here are those of the 1950 author(s) only. The European Commission is not liable for any use 1951 that may be made of the information in this document. 1953 The authors would also like acknowledge the contribution of Ralf 1954 Globisch and Thomas Schierl for providing the input and text for the 1955 MPRTP interface advertisement in SDP. 1957 Thanks to Miguel A. Garcia, Ralf Globisch, Christer Holmberg, and 1958 Roni Even for providing valuable feedback on earlier versions of this 1959 draft 1961 16. References 1963 16.1. Normative References 1965 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1966 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 1967 RFC 3550, July 2003. 1969 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1970 Levels", BCP 14, RFC 2119, March 1997. 1972 [3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1973 Protocol for Network Address Translator (NAT) Traversal for 1974 Offer/Answer Protocols", RFC 5245, April 2010. 1976 [4] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1977 Protocol (RTCP) Extensions for Single-Source Multicast Sessions 1978 with Unicast Feedback", RFC 5760, February 2010. 1980 [5] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1981 Real-Time Transport Control Protocol (RTCP): Opportunities and 1982 Consequences", RFC 5506, April 2009. 1984 [6] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1985 "Extended RTP Profile for Real-time Transport Control Protocol 1986 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 1988 [7] Singer, D. and H. Desineni, "A General Mechanism for RTP Header 1989 Extensions", RFC 5285, July 2008. 1991 [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1992 STD 63, RFC 3629, November 2003. 1994 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1995 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1997 [10] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1998 Control Packets on a Single Port", RFC 5761, April 2010. 2000 16.2. Informative References 2002 [11] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 2003 September 2007. 2005 [12] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, 2006 "Architectural Guidelines for Multipath TCP Development", 2007 RFC 6182, March 2011. 2009 [13] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 2010 Protocol for IPv6", RFC 5533, June 2009. 2012 [14] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 2013 January 2008. 2015 [15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2016 Session Description Protocol (SDP)", RFC 3264, June 2002. 2018 [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2019 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2020 Session Initiation Protocol", RFC 3261, June 2002. 2022 [17] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. 2023 Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", 2024 draft-ietf-mmusic-rfc2326bis-28 (work in progress), 2025 October 2011. 2027 [18] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping 2028 Alive the NAT Mappings Associated with RTP / RTP Control 2029 Protocol (RTCP) Flows", RFC 6263, June 2011. 2031 [19] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2032 Description Protocol", RFC 4566, July 2006. 2034 [20] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address 2035 Translator (NAT) Traversal mechanism for media controlled by 2036 Real-Time Streaming Protocol (RTSP)", 2037 draft-ietf-mmusic-rtsp-nat-11 (work in progress), October 2011. 2039 [21] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 2040 Security Considerations", BCP 72, RFC 3552, July 2003. 2042 Appendix A. Interoperating with Legacy Applications 2044 An MPRTP sender can use its multiple interfaces to send media to a 2045 legacy RTP client. The legacy receiver will ignore the subflow RTP 2046 header and the receiver's de-jitter buffer will try to compensate for 2047 the mismatch in per-path delay. However, the receiver can only send 2048 the overall or aggregate RTCP report which may be insufficient for an 2049 MPRTP sender to adequately schedule packets or detect if a path 2050 disappeared. 2052 An MPRTP receiver can only use one of its interface when 2053 communicating with a legacy sender. 2055 Appendix B. Change Log 2057 Note to the RFC-Editor: please remove this section prior to 2058 publication as an RFC. 2060 B.1. changes in draft-singh-avtcore-mprtp-04 2062 o Fixed missing 0xBEDE header in MPRTP header format. 2064 o Removed connectivity checks and keep-alives from in-band 2065 signaling. 2067 o MPRTP and MPRTCP are multiplexed on a single port. 2069 o MPRTCP packet headers optimized. 2071 o Made ICE optional 2073 o Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6. 2075 o Added how to use MPRTP in RTSP (Section 12). 2077 o Updated IANA Considerations section. 2079 B.2. changes in draft-singh-avtcore-mprtp-03 2081 o Added this change log. 2083 o Updated section 6, 7 and 8 based on comments from MMUSIC. 2085 o Updated section 11 (SDP) based on comments of MMUSIC. 2087 o Updated SDP examples with ICE and non-ICE in out-of-band signaling 2088 scenario. 2090 o Added Appendix A on interop with legacy. 2092 o Updated IANA Considerations section. 2094 B.3. changes in draft-singh-avtcore-mprtp-02 2096 o MPRTCP protocol extensions use only one PT=210, instead of 210 and 2097 211. 2099 o RTP header uses 1-byte extension instead of 2-byte. 2101 o Added section on RTCP Interval Calculations. 2103 o Added "mprtp-interface" attribute in SDP considerations. 2105 B.4. changes in draft-singh-avtcore-mprtp-01 2107 o Added MPRTP and MPRTCP protocol extensions and examples. 2109 o WG changed from -avt to -avtcore. 2111 Authors' Addresses 2113 Varun Singh 2114 Aalto University 2115 School of Science and Technology 2116 Otakaari 5 A 2117 Espoo, FIN 02150 2118 Finland 2120 Email: varun@comnet.tkk.fi 2121 URI: http://www.netlab.tkk.fi/~varun/ 2123 Teemu Karkkainen 2124 Aalto University 2125 School of Science and Technology 2126 Otakaari 5 A 2127 Espoo, FIN 02150 2128 Finland 2130 Email: teemuk@comnet.tkk.fi 2131 Joerg Ott 2132 Aalto University 2133 School of Science and Technology 2134 Otakaari 5 A 2135 Espoo, FIN 02150 2136 Finland 2138 Email: jo@comnet.tkk.fi 2140 Saba Ahsan 2141 Aalto University 2142 School of Science and Technology 2143 Otakaari 5 A 2144 Espoo, FIN 02150 2145 Finland 2147 Email: sahsan@cc.hut.fi 2149 Lars Eggert 2150 NetApp 2151 Sonnenallee 1 2152 Kirchheim 85551 2153 Germany 2155 Phone: +49 151 12055791 2156 Email: lars@netapp.com 2157 URI: http://eggert.org/