One document matched: draft-singh-avtcore-mprtp-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an
Internet Draft using xml2rfc, which is available here: http://xml.resource.org.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from
the online citation libraries. There has to be one entity for each item to be
referenced. An alternate method (rfc include) is described in the references.
-->
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc3550 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3552 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY rfc3611 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc3629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY rfc5245 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc5285 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5285.xml">
<!ENTITY rfc5760 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5760.xml">
<!ENTITY rfc4960 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY rfc5533 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml">
<!ENTITY rfc3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3264 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc5117 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5117.xml">
<!ENTITY rfc4566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc5506 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY rfc6182 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6182.xml">
<!ENTITY I-D.ietf-mmusic-rfc2326bis PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rfc2326bis.xml">
<!ENTITY rfc6263 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6263.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline=yes ?>
<?rfc comments="yes"?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-singh-avtcore-mprtp-03" ipr='trust200902'>
<!-- category values: std, bcp, info, exp, and historic ipr
values: full3667, noModification3667, noDerivatives3667 you can add the
attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output
with "(if approved)" -->
<front>
<title abbrev="Multipath RTP">Multipath RTP (MPRTP)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Varun Singh" initials="V" surname="Singh">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>varun@comnet.tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~varun/</uri>
</address>
</author>
<author fullname="Teemu Karkkainen" initials="T" surname="Karkkainen">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>teemuk@comnet.tkk.fi</email>
</address>
</author>
<author fullname="Joerg Ott" initials="J" surname="Ott">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>jo@comnet.tkk.fi</email>
</address>
</author>
<author fullname="Saba Ahsan" initials="S" surname="Ahsan">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>sahsan@cc.hut.fi</email>
</address>
</author>
<author initials="L." surname="Eggert" fullname="Lars Eggert">
<organization abbrev="Nokia"> Nokia Research Center </organization>
<address>
<postal>
<street>P.O. Box 407</street>
<code>00045</code> <city>Nokia Group</city>
<country>Finland</country>
</postal>
<phone>+358 50 48 24461</phone>
<email>lars.eggert@nokia.com</email>
<uri>http://research.nokia.com/people/lars_eggert</uri>
</address>
</author>
<date year="2011" />
<!-- <area>RAI</area> <workgroup>AVT Working
Group</workgroup> -->
<area>Internet Engineering Task Force</area>
<workgroup>AVT Core Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>RTCP</keyword>
<keyword>multipath</keyword>
<keyword>streaming</keyword>
<abstract>
<t>The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multi-homed endpoints are becoming common in today's Internet, e.g., devices that support multiple wireless access technologies such as 3G and Wireless LAN. This means that there is often more than one network path available between two endpoints. Transport protocols, such as RTP, have not been designed to take advantage of the availability of multiple concurrent paths and therefore cannot benefit from the increased capacity and reliability that can be achieved by pooling their respective capacities.</t>
<t>Multipath RTP (MPRTP) is an OPTIONAL extension to <xref target="RFC3550">RTP</xref> that allows splitting a single RTP stream into multiple subflows that are transmitted over different paths. In effect, this pools the resource capacity of multiple paths. Multipath RTCP (MPRTCP) is an extension to RTCP, it is used along with MPRTP to report per-path sender and receiver characteristics.</t>
<t>Other IETF transport protocols that are capable of using multiple paths include <xref target="RFC4960">SCTP</xref>, <xref target="RFC6182">MPTCP</xref> and <xref target="RFC5533">SHIM6</xref>. However, these protocols are not suitable for realtime communications.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />.</t>
</section>
<section title="Terminology">
<!-- <t> .</t> -->
<t><list style="symbols">
<t>Endpoint: host either initiating or terminating an RTP flow.</t>
<t>Interface: logical or physical component that is capable of acquiring a unique IP address.</t>
<t>Path: sequence of links between a sender and a receiver. Typically, defined by a set of source and destination addresses.</t>
<t>Subflow: flow of RTP packets along a specific path, i.e., a subset of the packets belonging to an RTP stream. The combination of all RTP subflows forms the complete RTP stream. Typically, a subflow would map to a unique path, i.e., each combination of IP addresses and port pairs (5-tuple, including protocol) is a unique subflow.</t>
<!-- <t>
Connection: is s
</t>-->
</list></t>
</section>
<section title="Use-cases">
<t>
The primary use-case for MPRTP is transporting high bit-rate streaming multimedia content between endpoints, where at least one is multi-homed. Such endpoints could be residential IPTV devices that connect to the Internet through two different Internet service providers (ISPs), or mobile devices that connect to the Internet through 3G and WLAN interfaces. By allowing RTP to use multiple paths for transmission, the following gains can be achieved:
<list style="symbols">
<t>Higher quality: Pooling the resource capacity of multiple Internet paths allows higher bit-rate and higher quality codecs to be used. From the application perspective, the available bandwidth between the two endpoints increases.</t>
<t>Load balancing: Transmitting an RTP stream over multiple paths reduces the bandwidth usage on a single path, which in turn reduces the impact of the media stream on other traffic on that path.</t>
<t>Fault tolerance: When multiple paths are used in conjunction with redundancy mechanisms (FEC, re-transmissions, etc.), outages on one path have less impact on the overall perceived quality of the stream.</t>
</list>
</t>
<t>
A secondary use-case for MPRTP is transporting Voice over IP (VoIP) calls to a device with multiple interfaces. Again, such an endpoint could be a mobile device with multiple wireless interfaces. In this case, little is to be gained from resource pooling, i.e., higher capacity or load balancing, because a single path should be easily capable of handling the required load. However, using multiple concurrent subflows can improve fault tolerance, because traffic can shift between the subflows when path outages occur. This results in very fast transport-layer handovers that do not require support from signaling.
</t>
<!--<t>JO: There may be other scenarios such as, High Quality Audio </t>-->
<!--
<t>A typical use-case for MPRTP is to maximize throughput, i.e., all available paths are used to stream data simultaneously. <xref target="fig-mp-use-case1"></xref> shows this basic use-case where-in Host A establishes a connection with Host B using RTSP, SIP or some other similar protocol, during the handshake, the two end-points exchange their multiple addresses. Depending on the bandwidth delay product and loss characteristics of each path the host MAY send data concurrently along the two paths or send redundant data (FEC, re-transmissions etc) along one path and normal streaming data along the other.
</t>
<figure anchor="fig-mp-use-case1"
title="Example MPRTP Scenario">
<artwork><![CDATA[
Host A Host B
//----------------------- -----------------------
Address A1 Address A2 Address B1 Address
//----------------------- -----------------------
| | | |
| (initial connection setup) | |
| (A advertises interfaces A1, A2) | |
|-----------------------------------\>| |
| (B advertises interfaces B1, B2) | |
|<-----------------------------------| |
| | | |
| (RTP data B1->A1, B2->A2) | |
|<===================================| |
| |<===================================|
| | | |
]]></artwork>
</figure>
<t><xref target="fig-mp-use-case2"></xref> describes a
simpler scenario where-in only one host has multiple interfaces.</t>
<figure anchor="fig-mp-use-case2" title="Simplified MPRTP Scenario">
<artwork><![CDATA[
Host A Host B
//----------------------- ----------
Address A1 Address A2 Address B1
//----------------------- ----------
| | |
| (initial connection setup) |
| (A advertises interfaces A1, A2) |
|-------------------------------------\>|
| (B only advertises interfaces B1) |
|<-------------------------------------|
| | |
| (RTP data B1->A1, B2->A2) |
|<=====================================|
| |<========================|
| | |
]]></artwork>
</figure>
<t>Furthermore, the above figures for simplicity only show simplex data flow but the protocol MAY also be used for duplex communication. There may be more complex scenarios involving middle-boxes, NATs and firewalls. We discuss them in more detail in later sections.</t>
-->
</section>
</section>
<section title="Goals">
<t>This section outlines the basic goals that multipath RTP aims to meet. These are broadly classified as Functional goals and Compatibility goals.</t>
<section title="Functional goals">
<t>Allow unicast RTP session to be split into multiple subflows in order to be carried over multiple paths. This may prove beneficial in case of video streaming.
<list style="symbols">
<t>Increased Throughput: Cumulative capacity of the two paths may meet the requirements of the multimedia session. Therefore, MPRTP MUST support concurrent use of the multiple paths. <!-- (Note: should this be a function of bandwidth-delay product)
possibility of streaming future data, i.e. send current data along a low delay path while future data along a high delay, such that data along the two paths arrive relatively at the time of playback. -->
</t>
<t>Improved Reliability: MPRTP SHOULD be able to send redundant packets or re-transmit packets along any available path to increase reliability.</t>
</list>
The protocol SHOULD be able to open new subflows for an existing session when new paths appear and MUST be able to close subflows when paths disappear.</t>
</section>
<section title="Compatibility goals">
<t>MPRTP MUST be backwards compatible; an MPRTP stream needs to fall back to be compatible with legacy RTP stacks if MPRTP support is not successfully negotiated.<list style="symbols">
<t>Application Compatibility: MPRTP service model MUST be backwards compatible with existing RTP applications, i.e., an MPRTP stack MUST be able to work with legacy RTP applications and not require changes to them. Therefore, the basic RTP APIs MUST remain unchanged, but an MPRTP stack MAY provide extended APIs so that the application can configure any additional features provided by the MPRTP stack.</t>
<t>Network Compatibility: individual RTP subflows MUST themselves be well-formed RTP flows, so that they are able to traverse NATs and firewalls. This MUST be the case even when interfaces appear after session initiation. <xref target="RFC5245">Interactive Connectivity Establishment (ICE)</xref> MAY be used for discovering new interfaces or performing connectivity checks.</t>
</list>
</t>
</section>
</section>
<!--
<section title="Comparison to TCP, SCTP, and MPTCP">
Teemu: Can we get rid of this? Especially the TCP stuff seems irrelevant.
<t>TCP is a transport protocol and runs over IP, TCP has a strong feedback loop provides services such as reliability and congestion control. RTP is an application layer protocols and runs on top of UDP. RTP is capable of running over multicast network and has a loose feedback loop using RTCP. Due to this loose binding RTP/RTCP provides limited services for Congestion Control, Reliability etc <xref target="RFC4585"></xref> <xref target="RFC3611"></xref>.</t>
<t>While SCTP supports multihoming and multipath functions, it is typically used as a failover mechanism and cannot be used to make concurrent data transfer over multiple interfaces. However, <xref target="I-D.ietf-mptcp-architecture">MPTCP</xref> describes an extension to TCP for multipath concurrent data transfer.</t>
<t>(...)</t>
<t>However, MPRTP provides aggregate path information for each subflow that may be used to adapt to the link characteristics.</t>
</section>
-->
<section title="RTP Topologies">
<t><xref target="RFC5117">RFC 5117</xref> describes a number of scenarios using mixers and translators in single-party (point-to-point), and multi-party (point-to-multipoint) scenarios.
<xref target="RFC3550">RFC 3550</xref> (Section 2.3 and 7.x) discuss in detail the impact of mixers and translators on RTP and RTCP packets. MPRTP assumes that if a mixer or translator exists in the network, then either all of the multiple paths or none of the multiple paths go via this component.
</t>
</section>
<section title="MPRTP Architecture">
<t>In a typical scenario, an RTP session uses a single path. In an MPRTP scenario, an RTP session uses multiple subflows that each use a different path. <xref target="fig-mprtp-streaming" /> shows the difference. </t>
<!-- <section title="Operation overview"> -->
<figure anchor="fig-mprtp-streaming" title="Comparison between traditional RTP streaming and MPRTP">
<artwork><![CDATA[
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| | Single RTP flow | |
+--------------+ +--------------+
+--------------+ Signaling +--------------+
| |------------------------------------>| |
| Client |<------------------------------------| Server |
| |<------------------------------------| |
+--------------+ MPRTP subflows +--------------+
]]></artwork>
</figure>
<!-- </section> -->
<figure anchor="fig-mprtp-archit" title="MPRTP Architecture">
<artwork><![CDATA[
+-----------------------+ +-------------------------------+
| Application | | Application |
+-----------------------+ +-------------------------------+
| | | MPRTP |
+ RTP + +- - - - - - - -+- - - - - - - -+
| | | RTP subflow | RTP subflow |
+-----------------------+ +---------------+---------------+
| UDP | | UDP | UDP |
+-----------------------+ +---------------+---------------+
| IP | | IP | IP |
+-----------------------+ +---------------+---------------+
]]></artwork>
</figure>
<t><xref target="fig-mprtp-archit" /> illustrates the differences between the standard RTP stack and the MPRTP stack. MPRTP receives a normal RTP session from the application and splits it into multiple RTP subflows. Each subflow is then sent along a different path to the receiver. To the network, each subflow appears as an independent, well-formed RTP flow. At the receiver, the subflows are combined to recreate the original RTP session. The MPRTP layer performs the following functions:
<list style="symbols">
<t>Path Management: The layer is aware of alternate paths to the other host, which may, for example, be the peer's multiple interfaces. So that it is able to send differently marked packets along separate paths.
<!-- detects the host's multiple interfaces and advertises them as they appear and disappear.--> MPRTP also selects interfaces to send and receive data. Furthermore, it manages the port and IP address pair bindings for each subflow.
<!--
Path Management: The layer is aware of alternate paths to the peer, which may, for example, be the peer's multiple interfaces or routing labels for an intermediate router to send differently marked packets along separate paths.
(The entire draft so far talked about identifying paths by IP address/interface. This route label stuff is unclear even for MPTCP. Suggest to remove it. -- Lars)
MPRTP also selects interfaces or marks packets with different routing labels to send and receive data. Furthermore, it manages the port and IP address pair bindings for each interface.
(Does it? Isn't the IP stack doing that? -- Lars)
-->
</t>
<t>Packet Scheduling: the layer splits a single RTP flow into multiple subflows and sends them across multiple interfaces (paths). The splitting MAY BE done using different path characteristics.</t>
<t>Subflow recombination: the layer creates the original stream by recombining the independent subflows. Therefore, the multipath subflows appear as a single RTP stream to applications.</t>
</list>
</t>
<!--change from ind-02-draft [Christer/MMUSIC]:The text says that, for SIP, one SHOULD use SCTP or MPTCP instead of UDP or TCP, but there is no justification.
Also, isn't such statement is outside the scope of the document?
<section title="Relationship of MPRTP with Session Signaling">
<t>
Session signaling (e.g., <xref target="RFC3261">SIP</xref>, <xref target="I-D.ietf-mmusic-rfc2326bis">RTSP</xref>) SHOULD be done over a failover-capable or multipath-capable transport for e.g., <xref target="RFC4960">SCTP</xref> or <xref target="RFC6182">MPTCP</xref> instead of TCP or UDP.
</t>
</section>
-->
</section>
<!-- NOTE: find the drawback/pain of using ICE!! -->
<section title="Example Media Flow Diagrams">
<t>There may be many complex technical scenarios for MPRTP, however, this memo only considers the following two scenarios: 1) a unidirectional media flow that represents the streaming use-case, and 2) a bidirectional media flow that represents a conversational use-case.</t>
<section title="Streaming use-case">
<t>In the unidirectional scenario, the receiver (client) initiates a multimedia session with the sender (server). The receiver or the sender may have multiple interfaces and both endpoints are MPRTP-capable. <xref target="fig-mprtp-unidir" /> shows this scenario. In this case, host A has multiple interfaces. Host B performs connectivity checks on host A's multiple interfaces. If the interfaces are reachable, then host B streams multimedia data along multiple paths to host A. Moreover, host B also sends RTCP Sender Reports (SR) for each subflow and host A responds with a normal RTCP Receiver Report (RR) for the overall session and receiver statistics for each subflow. Host B distributes the packets across the subflows based on the individually measured path characteristics.</t>
<t>Alternatively, to reduce media startup time, host B may start streaming multimedia data to host A's initiating interface and then perform connectivity checks for the other interfaces. This method of updating a single path session to a multipath session is called "multipath session upgrade".
</t>
<figure anchor="fig-mprtp-unidir" title="Unidirectional media flow">
<artwork><![CDATA[
Host A Host B
----------------------- ----------
Interface A1 Interface A2 Interface B1
----------------------- ----------
| |
|------------------------------------->| Session setup with
|<-------------------------------------| multiple interfaces
| | |
| | |
| (RTP data B1->A1, B1->A2) |
|<=====================================|
| |<========================|
| | |
Note: there may be more scenarios.
]]></artwork>
</figure>
</section>
<!-- or
Host A Host B
---------- -----------------------
Address A1 Address B1 Address B2
---------- -----------------------
| | |
| (initial connection setup) | |
| (A only advertises interfaces A1) | |
|----------------------------------->| |
| (B advertises interfaces B1, B2) | |
|<-----------------------------------| |
| | |
| (RTP data B1->A1, B2->A1) | |
|<===================================| |
|<================================================|
or
Host A Host B
----------------------- -----------------------
Address A1 Address A2 Address B1 Address B2
----------------------- -----------------------
| | | |
| (initial connection setup) | |
| (A advertises interfaces A1, A2) | |
|----------------------------------->| |
| (B advertises interfaces B1, B2) | |
|<-----------------------------------| |
| | | |
| (RTP data B1->A1, B2->A2) | |
|<===================================| |
| |<===================================|
-->
<section title="Conversational use-case">
<t>In the bidirectional scenario, multimedia data flows in both directions. The two hosts exchange their lists of interfaces with each other and perform connectivity checks. Communication begins after each host finds suitable address, port pairs. Interfaces that receive data send back RTCP receiver statistics for that path (based on the 5-tuple). The hosts balance their multimedia stream across multiple paths based on the per path reception statistics and its own volume of traffic. <xref target="fig-mprtp-bidir" /> describes an example of a bidirectional flow.</t>
<figure anchor="fig-mprtp-bidir" title="Bidirectional flow">
<artwork>
<![CDATA[
Host A Host B
--------------------------- ---------------------------
Interface A1 Interface A2 Interface B1 Interface B2
--------------------------- ---------------------------
| | | |
| | | |
|----------------------------------->| |Session setup with
|<-----------------------------------| |multiple interfaces
| | | |
| | | |
| (RTP data B1<->A1, B2<->A2) | |
|<===================================| |
| |<===================================|
|===================================>| |
| |===================================>|
| | | |
Note: the address pairs may have other permutations,
and they may be symmetric or asymmetric combinations.
]]></artwork>
</figure>
</section>
</section>
<!--
[Christer/MMUSIC]:
ED_5_3-1: I don't think this section belongs to the example call flows.
ED_5_3-2: The text talks about "ahead of time". Ahead of what time?
<section title="Challenges with Multipath Interface Discovery">
<t>For some applications, where the user expects immediate playback, e.g., High Definition Media Streaming or IPTV, it may not be possible to perform connectivity checks within the given time bound. In these cases, connectivity checks MAY need to be done ahead of time.</t>
<t>[Open Issue: ICE or any other system would have to be aware of the endpoint's interfaces ahead of time].</t>
</section>
-->
<section title="MPRTP Functional Blocks">
<t>This section describes some of the functional blocks needed for MPRTP. We then investigate each block and consider available mechanisms in the next section.
<list style="numbers">
<t>Session Setup: Interfaces may appear or disappear at anytime during the session. To preserve backward compatibility with legacy applications, a multipath session MUST look like a bundle of individual RTP sessions. Multipath session may be upgraded from a typical single path session, as and when new interfaces appear or disappear. However, it should be possible to setup a multipath session from the beginning if the interfaces are available at the start of the multimedia session.</t>
<t>Expanding RTP: For a multipath session, each subflow MUST look like an independent RTP flow, so that individual RTCP messages can be generated per subflow. Furthermore, MPRTP splits the single multimedia stream into multiple subflows based on path characteristics (e.g. RTT, loss-rate, receiver rate, bandwidth-delay product etc.) and dynamically adjusts the load on each link.</t>
<t>Adding Interfaces: Interfaces on the host need to be regularly discovered and advertised. This can be done at session setup and/or during the session. Discovering interfaces is outside the scope of this document.<!--When discovering and receiving new interfaces, the MPRTP layer needs to select address and port pairs.--></t>
<t>Expanding RTCP: MPRTP MUST provide per path RTCP reports for monitoring the quality of the path, for load balancing, or for congestion control, etc. To maintain backward compatibility with legacy applications, the receiver MUST also send aggregate RTCP reports along with the per-path reports.</t>
<t>Maintenance and Failure Handling: In a multi-homed endpoint interfaces may appear and disappear. If this occurs at the sender, it has to re-adjust the load on the available links. On the other hand, if this occurs at the receiver, then the multimedia data transmitted by the sender to those interfaces is lost. This data may be re-transmitted along a different path i.e., to a different interface on the receiver. Furthermore, the endpoint has to either explicitly signal the disappearance of an interface, or the other endpoint has to detect it (by lack of media packets, RTCP feedback, or keep-alive packets).</t>
<t>Teardown: The MPRTP layer releases the occupied ports on the interfaces.</t>
</list>
</t>
</section>
<section title="Available Mechanisms within the Functional Blocks">
<t>This section discusses some of the possible alternatives for each functional block mentioned in the previous section.</t>
<section title="Session Setup">
<t>MPRTP session can be set up in many possible ways e.g., during handshake, or upgraded mid-session. The capability exchange may be done using out-of-band signaling (e.g., <xref target="RFC3264" >SDP</xref> in <xref target="RFC3261">SIP</xref>, <xref target="I-D.ietf-mmusic-rfc2326bis">RTSP</xref>) or in-band signaling (e.g., RTP/RTCP header extension, STUN messages).</t>
<t><cref anchor="note-sip-mp" source="MMUSIC Review">Using SIP over SCTP, MPTCP instead of UDP/TCP are out of scope of the document.</cref></t>
<section title="Connectivity Checks">
<t>The endpoint SHOULD be capable of performing connectivity checks (e.g., using <xref target="RFC5245">ICE</xref>). If the IP addresses of the endpoints are reachable (e.g., globally addressable, same network etc) then connectivity checks are not needed. <!--If the connectivity checks are successful, then multimedia data can flow between the new address, port pairs.--></t>
</section>
<section title="Adding New or Updating Interfaces">
<!-- <t> When interfaces appear and disappear mid-session, ICE <xref target="RFC5245" /> may be used for discovering interfaces and performing connectivity checks. However, MPRTP may require a capability re-negotiation (e.g. using SDP) to include all these new interfaces. This method is referred to as out-of-band multipath advertisement.</t>
<t>Alternatively, when new interfaces appear, the interface advertisements may be done in-band using RTP/RTCP extensions. The endpoints perform connectivity checks (see <xref target="fig-mprtp-new-subflow" /> for more details).</t> -->
<t> Interfaces can appear and disappear during a session, the endpoint MUST be capable of advertising the changes in its set of usable interfaces. Additionally, the application or OS may define a policy on when and/or what interfaces are usable. However, MPRTP requires a method to advertise the updated set of usable interfaces.</t>
<!--<t>Interface Advertisements can be done by sending an updated offer using SDP (see <xref target="mprtp-sdp-ice-mprtp-interface-attribute" />) or in-band using RTP/RTCP extensions (see <xref target="sec-mprtp-pkt-format-rtcp-ia" />).</t>
-->
</section>
<section title="In-band vs. Out-of-band Signaling">
<t>
MTRTP nodes will generally use a signaling protocol to establish their
MPRTP session. With the existence of such a signaling relationship,
two alternatives become available to exchange information about the
available interfaces on each side for extending RTP sessions to MPRTP
and for modifying MPRTP sessions: in-band and out-of-band signaling.
</t>
<t>
In-band signaling refers to using mechanisms of RTP/RTCP itself to
communicate interface addresses, e.g., a dedicated RTCP extensions
along the lines of the one defined to communicate information about
the feedback target for RTP over SSM [RFC5760]. In-band signaling
does not rely on the availability of a separate signaling connection
and the information flows along the same path as the media streams,
thus minimizing dependencies. Moreover, if the media channel is
secured (e.g., by means of SRTP), the signaling is implicitly
protected as well if SRTCP encryption and authentication are chosen.
In-band signaling is also expected to take a direct path to the
peer, avoiding any signaling overlay-induced indirections and
associated processing overheads in signaling elements -- avoiding
such may be especially worthwhile if frequent updates may occur
as in the case of mobile users. Finally, RTCP is usually sent
sufficiently frequently (in point-to-point settings) to provide
enough opportunities for transmission and (in case of loss)
retransmission of the corresponding RTCP packets.
</t>
<t>
Examples for in-band signaling include RTCP extensions as noted above
or suitable extensions to STUN.
</t>
<t>
Out-of-band signaling refers to using a separate signaling connection
(via SIP, RTSP, or HTTP) to exchange interface information, e.g.,
expressed in SDP. Clear benefits are that signaling occurs at setup
time anyway and that experience and SDP syntax (and procedures) are
available that can be re-used or easily adapted to provide the
necessary capabilities. In contrast to RTCP, SDP offers a reliable
communication channel so that no separate retransmissions logic is
necessary. In SDP, especially when combined with ICE, connectivity
check mechanisms including sophisticated rules are readily available.
While SDP is not inherently protected, suitable security may need to
be applied anyway to the basic session setup.
</t>
<t>
Examples for out-of-band signaling are dedicated extensions to SDP;
those may be combined with ICE.
</t>
<t>
Both types of mechanisms have their pros and cons for middleboxes.
With in-band signaling, control packets take the same path as the
media packets and they can be directly inspected by middleboxes so
that the elements operating on the signaling channel do not need to
understand new SDP. With out-of-band signaling, only the middleboxes
processing the signaling need to be modified and those on the data
forwarding path can remain untouched.
</t>
<t>
Overall, it may appear sensible to provide a combination of both
mechanisms: out-of-band signaling for session setup and initial
interface negotiation and in-band signaling to deal with frequent
changes in interface state (and for the potential case, albeit rather
theoretical case of MPRTP communication without a signaling channel).
</t>
<t>
In its present version, this document explores both options to provide
a broad understanding of how the corresponding mechanisms would look
like.
</t>
<t><cref anchor="note-stun-use" source="Editor">Some have suggested STUN may be suitable for doing in-band interface advertisement. This is still under consideration, but depends on implementation challenges as many legacy systems don't implement STUN and many RTP systems ignore STUN messages<!-- (see <xref target="RFC6263" x:fmt="of" x:sec="4.4"/>) -->.</cref></t>
</section>
</section>
<section title="Expanding RTP">
<t><xref target="RFC3550">RTCP</xref> is generated per media session. However, with MPRTP, the media sender spreads the RTP load across several interfaces. The media sender SHOULD make the path selection, load balancing and fault tolerance decisions based on the characteristics of each path. Therefore, apart from normal RTP sequence numbers defined in <xref target="RFC3550" / >, the MPRTP sender MUST add subflow-specific sequence numbers to help calculate fractional losses, jitter, RTT, playout time, etc., for each path and a subflow identifier to associate the characteristics with a path. The RTP header extension for MPRTP is shown in <xref target="sec-mprtp-pkt-format-hdrext" />. </t>
</section>
<section title="Expanding RTCP">
<t> To provide accurate per path information an MPRTP endpoint MUST send (SR/RR) report for each unique subflow along with the overall session RTCP report. Therefore, the additional subflow reporting affects the RTCP bandwidth and the RTCP reporting interval. RTCP report scheduling for each subflow may cause a problem for RTCP recombination and reconstruction in cases when 1) RTCP for a subflow is lost, and 2) RTCP for a subflow arrives later than the other subflows. (There may be other cases as well.)</t>
<t>The sender distributes the media across different paths using the per path RTCP reports. However, this document doesn't cover algorithms for congestion control or load balancing.</t>
</section>
<!--
[Christer/MMUSIC]:
I don't think it's within the scope of this draft to make any recommendations regarding SIP/SDP transport.
<section title="Checking and Failure Handling">
<cref anchor="Note 1" source="Editor">If the original interface that setup the session disappears then does the session signaling failover to another interface? Can we recommend that SIP/RTSP be run over MPTCP, SCTP].</cref>
</section>-->
<section title="Failure Handling and Teardown">
<t>An MPRTP endpoint MUST keep alive subflows that have been negotiated but no media is sent on them. Moreover, using the information in the subflow reports, a sender can monitor the subflows for failure (errors, unreachability, congestion) and decide not to use the under-performing subflows.</t>
<t>If an interface disappears, the endpoint MUST send an updated interface advertisement without the interface and release the the associated subflows.</t>
</section>
</section>
<section title="MPRTP Protocol" anchor="sec-mprtp-proto">
<!-- [Comment MMUSIC/Christer: keep generic].
<t>To enable a quick start of a multimedia session, a multipath session MUST be upgraded from a single path session. Therefore, no explicit changes are needed in multimedia session setup and the session can be setup as before.</t> -->
<!-- <section title="Connection Initiation">
<t>The multipath discovery and transmission begins after establishing a single path RTP session.</t>
</section> -->
<figure anchor="fig-mprtp-new-subflow" title="MPRTP New Interface">
<artwork><![CDATA[
Host A Host B
----------------------- -----------------------
Interface A1 Interface A2 Interface B1 Interface B2
----------------------- -----------------------
| | | |
| | (1) | |
|--------------------------------------->| |
|<---------------------------------------| |
| | (2) | |
|<=======================================| |
|<=======================================| (3) |
| | (4) | |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
|<- - - - - - - - - - - - - - - - - - - -| |
| | (5) | |
|- - - - - - - - - - - - - - - - - - - ->| |
|<=======================================| (6) |
|<=======================================| |
| |<========================================|
|<=======================================| |
| |<========================================|
Key:
| Interface
---> Signaling Protocol
<=== RTP Packets
- -> RTCP Packet
]]></artwork>
</figure>
<section title="Overview" anchor="sec-mprtp-proto-overview">
<!--due to changes in connections. new interfaces can appear, old ones can disappear.-->
<t>
The bullet points explain the different steps shown in <xref target="fig-mprtp-new-subflow" /> for upgrading a single path multimedia session to multipath session.
<list style="empty">
<t>(1) The first two interactions between the hosts represents the establishment of a normal RTP session. This may performed e.g. using SIP or RTSP.</t>
<t>(2) When the RTP session has been established, host B streams media using its interface B1 to host A at interface A1.</t>
<t>(3) Host B supports sending media using MPRTP and becomes aware of an additional interface B2.</t>
<t>(4) Host B advertises the multiple interface addresses.</t>
<t>(5) Host A supports receiving media using MPRTP and becomes aware of an additional interface A2.</t>
<t>Side note, even if an MPRTP-capable host has only one interface, it MUST respond to the advertisement with its single interface.</t>
<t>(6) Each host receives information about the additional interfaces and the appropriate endpoints starts to stream the multimedia content using the additional paths.</t>
<t>If needed, each endpoint will need to independently perform connectivity checks (not shown in figure) and ascertain reachability before using the paths.</t>
</list>
</t>
<section title="Gather or Discovering Candidates" anchor="sec-mprtp-gather-candidates">
<t>The endpoint periodically polls the operating system or is notified when an additional interface appears. If the endpoint wants to use the additional interface it MUST advertise it to the other peers. The endpoint may also use <xref target="RFC5245">ICE</xref> to gather additional candidates.</t>
</section>
<section title="RTCP Subflow or Interface advertisement" anchor="sec-mprtp-rtcp-subflow-advert">
<t> To advertise the multiple interfaces, an MPRTP-capable endpoint MUST add the MPRTP Interface Advertisement defined in <xref target="fig-mp-rtcp-header-ia" /> with the RTCP Sender Report (SR). Each unique address is encapsulated in an Interface Advertisement block and contains the IP address, RTP and RTCP port addresses. The Interface Advertisement blocks are ordered based on a decreasing priority level. On receiving the MPRTP Interface Advertisement, an MPRTP-capable receiver MUST respond with the set of interfaces (subset or all available) it wants to use.
</t>
<t> If the sender and receiver have only one interface, then the endpoints MUST indicate the negotiated single path IP, RTP port and RTCP port addresses. <!--If an endpoint receives an RTCP report without the MPRTP Interface Advertisement, then the endpoint must assume that the other endpoint is not MPRTP capable.-->
</t>
</section>
<section title="Connectivity Checks" anchor="sec-mprtp-proto-addr-select" >
<t>After MPRTP support has been negotiated and interface advertisements have been exchanged, the endpoint MAY initiate connectivity checks to determine which pairs of interfaces offer valid paths between the sender and the receiver. Each combination of sender and receiver IP addresses and port pairs (5-tuple) is a unique subflow. An endpoint MUST associate a Subflow ID to each unique subflow.</t>
<t>To initiate a connectivity check, the endpoints send an RTP packet using the appropriate MPRTP extension header (See <xref target="table-mprtp-rtp-extn" />), associated Subflow ID and no RTP payload. The receiving endpoint replies to the connectivity check with an RTCP packet with the appropriate packet type (See <xref target="table-mprtp-rtcp-extn" />) and Subflow ID. After the endpoint receives the reply, the path is considered a valid candidate for sending data. An endpoint MAY choose to do any number of connectivity checks for any interface pairs at any point in a session.</t>
<!-- Editor: Each combination of sender/receiver port pair is a unique subflow -->
<t><cref anchor="note-cc-rtcp-int-imp" source="Editor">Open Issue: How should the endpoint adjust the RTCP Reporting interval/schedule the RTCP packet on receiving a connectivity check containing a new Subflow ID? One option is send immediately as defined in RFC4585. Another option is the RTCP timing defined in RFC6263.</cref></t>
</section>
<section title="Active and Passive Subflows" anchor="sec-mprtp-proto-subflow-desc" >
<t>To send and receive data an endpoint MAY use any number of subflows from the set of available subflows. The subflows that carry media data are called active subflows, while those subflows that don't send any media packet are called passive subflows.</t>
<t>An endpoint should send MPRTP keep alive packets (see <xref target="sec-mprtp-pkt-format-hdrext-kalive" />) on the subflows where no media is sent to keep the NAT bindings alive.</t>
<t><cref anchor="note-active-passive" source="Editor">Open Issue: How to differentiate between Passive and Active connections? Editor: Active paths get "regular flow" of media packets while passive paths are for failover of active paths.</cref></t>
<t><cref anchor="note-keep-alive-timer" source="Editor">Open Issue: How to keep a passive connection alive, if not actively used? Alternatively, what is the maximum timeout? keep-alive for ICE/NAT bindings should not be less than 15 seconds [RFC5245].</cref></t>
</section>
<section title="Middlebox Considerations" anchor="sec-mprtp-proto-mbox-cons" >
<t>TBD.</t>
</section>
</section>
<section title="RTP Transmission" anchor="sec-mprtp-pkt-trans">
<t>If both endpoints are MPRTP-capable and if they want to use their multiple interfaces for sending the media stream then they MUST use the MPRTP header extensions. They MAY use normal RTP with legacy endpoints (see <xref target="sec-mprtp-back-legacy" />).</t>
<t>An MPRTP endpoint sends RTP packets with an MPRTP extension that maps the media packet to a specific subflow (see <xref target="fig-mprtp-header-subflow" />). The MPRTP layer SHOULD associate an RTP packet with a subflow based on a scheduling strategy. The scheduling strategy may either choose to augment the paths to create higher throughput or use the alternate paths for enhancing resilience or error-repair. Due to the changes in path characteristics, the endpoint should be able change its scheduling strategy during an ongoing session. The MPRTP sender MUST also populate the subflow specific fields described in the MPRTP extension header (see <xref target="sec-mprtp-pkt-format-hdrext-rtp" />).</t>
</section>
<section title="Playout Considerations at the Receiver" anchor="sec-mprtp-playout">
<t>A media receiver, irrespective of MPRTP support or not, should be able to playback the media stream because the received RTP packets are compliant to <xref target="RFC3550" />, i.e., a non-MPRTP receiver will ignore the MPRTP header and still be able to playback the RTP packets. However, the variation of jitter and loss per path may affect proper playout. The receiver can compensate for the jitter by modifying the playout delay (i.e., by calculating skew across all paths) of the received RTP packets.</t>
</section>
<section title="Subflow-specific RTCP Statistics and RTCP Aggregation" anchor="sec-mprtp-rtcp-agg">
<t>Aggregate RTCP provides the overall media statistics and follows the normal RTCP defined in RFC3550 <xref target="RFC3550" />. However, subflow specific RTCP provides the per path media statistics because the aggregate RTCP report may not provide sufficient per path information to an MPRTP scheduler. Specifically, the scheduler should be aware of each path's RTT and loss-rate, which an aggregate RTCP cannot provide. The sender/receiver MUST use non-compound RTCP reports defined in RFC5506 <xref target="RFC5506" /> to transmit the aggregate and subflow-specific RTCP reports. Also, each subflow and the aggregate RTCP report MUST follow the timing rules defined in <xref target="RFC4585" />.</t>
<!-- A simple MPRTP scheduler makes its decisions based on the per path jitter, loss and RTT and the aggregate RTCP Receiver Report. -->
<!-- <t>[Editor: 1) Should the RTCP RRs sent per path carry a) the aggregate and the path's RR or b) the aggregate and RR of each path.
2) Should the per path RTCP Interval be dependent on the overall session bit rate or per path interval receiver rate?]</t> -->
<t>The RTCP reporting interval is locally implemented and the scheduling of the RTCP reports may depend on the the behavior of each path. For instance, the RTCP interval may be different for a passive path than an active path to keep port bindings alive. Additionally, an endpoint may decide to share the RTCP reporting bit rate equally across all its paths or schedule based on the receiver rate on each path.</t>
<!-- <t>For calculating the RTCP reporting interval, each path is considered as a unique peer. For example, if there are two paths between sender and receiver then n=4. Similarly, for 3 paths, n=6. </t>-->
</section>
<section title="RTCP Transmission" anchor="sec-mp-rtcp-pkt-trans">
<t> The sender sends an RTCP SR on each active path. For each SR the receiver gets, it echoes one back to the same IP address-port pair that sent the SR. The receiver tries to choose the symmetric path and if the routing is symmetric then the per-path RTT calculations will work out correctly. However, even if the paths are not symmetric, the sender would at maximum, under-estimate the RTT of the path by a factor of half of the actual path RTT.</t>
<t></t>
</section>
</section>
<section title="Packet Formats" anchor="sec-mprtp-pkt-format">
<t>In this section we define the protocol structures described in the previous sections.</t>
<section title="RTP Header Extension for MPRTP" anchor="sec-mprtp-pkt-format-hdrext">
<t>The MPRTP header extension is used to 1) distribute a single RTP stream over multiple subflows, 2) perform connectivity checks on the advertised interfaces, and 3) keep-alive passive interfaces (paths).</t>
<t>The header conforms to the one-byte RTP header extension defined in <xref target="RFC5285" />. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length, see Section 5.3.1 of <xref target="RFC3550" /> for details).</t>
<t>The RTP header for each subflow is defined below:</t>
<figure anchor="fig-mprtp-header-gen" title="Generic MPRTP header extension">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ID | LEN | MPID |LENGTH | MPRTP header data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t>MPID:
<list style="empty"><t>The MPID field corresponds to the type of MPRTP packet. Namely:
<figure anchor="table-mprtp-rtp-extn" title="RTP header extension values for MPRTP (H-Ext ID)">
<artwork><![CDATA[
+---------------+--------------------------------------------------+
| MPID ID | Use |
| Value | |
+---------------+--------------------------------------------------+
| 0x00 | Subflow RTP Header. For this case the Length is |
| | set to 6 |
| 0x01 | Connectivity Check. For this case the length is |
| | set to 0 |
| TBD | Keep Alive Packet. |
+---------------+--------------------------------------------------+
]]></artwork>
</figure></t></list>
</t>
<t> length
<list style="empty"><t>The 4-bit length field is the length of extension data in bytes not including the H-Ext ID and length fields. The value zero indicates there is no data following.</t></list>
</t>
<t>MPRTP header data
<list style="empty"><t>Carries the MPID specific data as described in the following sub-sections.</t></list>
</t>
</list></t>
<section title="MPRTP RTP Extension for a Subflow" anchor="sec-mprtp-pkt-format-hdrext-rtp">
<t>The RTP header for each subflow is defined below:</t>
<figure anchor="fig-mprtp-header-subflow" title="MPRTP header for subflow">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ID | LEN=4 | 0x00 | LEN=4 | Subflow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific Seq Number | Pad (0) | Pad (0) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t>MP ID = 0x00
<list style="empty"><t>Indicates that the MPRTP header extension carries subflow specific information.</t></list>
</t>
<t> length = 4</t>
<t>Subflow ID: Identifier of the subflow. Every RTP packet belonging to the same subflow carries the same unique subflow identifier.</t>
<!-- Choose the Subflow ID randomly? -->
<t>Flow-Specific Sequence Number (FSSN): Sequence of the packet in the subflow. Each subflow has its own strictly monotonically increasing sequence number space.</t>
<!-- Choose the FSSN randomly? -->
<!--This corresponds to the sequence number of the packet in the associated subflow. -->
</list></t>
</section>
<section title="MPRTP RTP Extension for Connectivity Checks" anchor="sec-mprtp-pkt-format-hdrext-cc">
<t><cref anchor="note-cc-mprtp" source="Editor">Open Issue: What sequence number to use for the RTP session? Alternative 1: An MPRTP receiver MUST NOT give the packet with MPID=0x01 to the decoder and ignore these packets from RTCP calculation. Alternative 2: Instead of sending an RTP packet the sender transmits a modified STUN packet.</cref></t>
</section>
<section title="MPRTP RTP Extension for Keep-alive Packets" anchor="sec-mprtp-pkt-format-hdrext-kalive">
<t><cref anchor="note-ka-rtcp" source="Editor">RTCP guidelines for keep alive packet [RFC6263] recommends multiplexing RTP and RTCP. If so, we can do the same and remove the keep alive from the list. Alternatively, the endpoint can send zero payload RTP packet with the correct RTP sequence number, RTP timestamp and monotonically increasing the subflow specific sequence number each time [RFC6263 Sec 4.6].]</cref></t><!-- (see <xref target="RFC6263" x:fmt="of" x:sec="4.6"/>) -->
<!-- 15 seconds timeout Tr for ICE/NAT bindings -->
</section>
</section>
<section title="RTCP Extension for MPRTP (MPRTCP)" anchor="sec-pkt-format-mprtcp-gen">
<t> The MPRTP RTCP header extension is used to 1) provide RTCP feedback per subflow to determine the characteristics of each path, 2) advertise each interface and perform connectivity check on the other endpoint's interfaces, and 3) to keep alive a passive connection.</t>
<figure anchor="fig-mp-rtcp-header" title="Generic RTCP Extension for MPRTP (MPRTCP) [appended to normal SR/RR]">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP Reports |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
]]></artwork>
</figure>
<t>
<list style="empty">
<t>MPRTCP: 8 bits
<list style="empty"> <t>Contains the constant 211 to identify this as an Multipath RTCP packet.</t></list>
</t>
<t>length: 16 bits
<list style="empty"><t> As described for the RTCP packet (see Section 6.4.1 of the RTP specification <xref target="RFC3550" />), the length of this is in 32-bit words minus one, including the header and any padding.</t></list>
</t>
<t>MPRTCP_Type: 16-bits
<list style="empty"><t>The MPRTCP_Type field corresponds to the type of MPRTP RTCP packet. Namely:
<figure anchor="table-mprtp-rtcp-extn" title="RTP header extension values for MPRTP (MPRTCP_Type)">
<artwork><![CDATA[
+---------------+--------------------------------------------------+
| MPRTCP_Type | Use |
| Value | |
+---------------+--------------------------------------------------+
| 0x00 | Subflow Specific Report |
| 0x01 | Connectivity Check. For this case the length is |
| | set to 0 |
| 0x02 | Interface Advertisement |
| TBD | Keep Alive Packet. |
+---------------+--------------------------------------------------+
]]></artwork>
</figure></t></list>
</t>
<t>block length: 16-bits
<list style="empty"><t>The 16-bit length field is the length of the encapsulated MPRTCP reports in 32-bit word length not including the MPRTCP_Type and length fields. The value zero indicates there is no data following.</t></list>
</t>
<t>MPRTCP Reports: variable size
<list style="empty"><t>Defined later in
<xref target="sec-mprtp-pkt-format-subflow-rtcp" format="counter" /> and
<xref target="sec-mprtp-pkt-format-ia" format="counter" />.</t></list>
</t>
</list></t>
<section title="MPRTCP Extension for Subflow Reporting" anchor="sec-mprtp-pkt-format-subflow-rtcp">
<t> When sending a report for a specific subflow the sender or receiver MUST add only the reports associated with that 5-tuple. <!-- If sending a compound RTCP report, the subflow-specific report MAY be appended to the session specific reports, i.e., Sender Report (SR) and/or Receiver Report (RR) MUST precede the subflow-specific report.</t>
<t> --> Each subflow is reported independently using the following MPRTCP Feedback header.</t>
<figure anchor="fig-mp-rtcp-header-generic" title="MPRTCP Subflow Reporting Header">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0x02 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow ID #1 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0x02 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow ID #2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>MPRTCP_Type: 0x02</t>
<t>block length: 16-bits
<list style="empty"><t>The 16-bit length field is the length of the encapsulated subflow-specific reports in 32-bit word length not including the MPRTCP_Type and length fields.</t></list>
</t>
<t>Subflow ID: 16 bits
<list style="empty"><t>Subflow identifier is the value associated with the subflow the endpoint is reporting about. If it is a sender it MUST use the Subflow ID associated with the 5-tuple. If it is a receiver it MUST use the Subflow ID received in the Subflow-specific Sender Report.</t></list>
</t>
<t>Subflow-specific reports: variable
<list style="empty"><t>Subflow-specific report contains all the reports associated with the Subflow ID. For a sender, it MUST include the Subflow-specific Sender Report (SSR). For a receiver, it MUST include Subflow-specific Receiver Report (SRR). Additionally, if the receiver supports subflow-specific extension reports then it MUST append them to the SRR.</t></list>
</t>
<section title="MPRTCP for Subflow-specific SR, RR and XR" anchor="sec-mprtp-pkt-format-rtcp-sr-report">
<t><cref anchor="note-rtcp-reuse" source="Editor"> inside the context of subflow specific reports can we reuse the payload type code for Sender Report (PT=200), Receiver Report (PT=201), Extension Report (PT=207).<!-- BYE (PT=203) can be used for explicitly tearing down the subflow.--> Transport and Payload specific RTCP messages are session specific and SHOULD be used as before.</cref></t>
<t>Example:</t>
<figure anchor="fig-mp-rtcp-header-ssr" title="Example of reusing RTCP SR and RR inside an MPRTCP header (Bi-directional use-case, in case of uni-directional flow the subflow will only send an SR or RR).">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0x02 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow ID #1 | reserved |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subflow's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subflow's octet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0x02 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow ID #2 | reserved |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Subflow specific extension reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="MPRTCP Extension for Interface advertisement" anchor="sec-mprtp-pkt-format-rtcp-ia">
<t>This sub-section defines the RTCP header extension for in-band interface advertisement by the receiver. The interface advertisement SHOULD immediately follow the Receiver Report. If the Receiver Report is not present, then it MUST be appended to the Sender Report.</t>
<t>The endpoint MUST advertise the interfaces it wants to use whenever an interface appears or disappears and also when it receives an Interface Advertisement.</t>
<figure anchor="fig-mp-rtcp-header-ia" title="MPRTP Interface Advertisement. (appended to SR/RR)">
<artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=MPRTCP=211 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0x02 | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface #1 Advertisement block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface #2 Advertisement block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface #... Advertisement block |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface #m Advertisement block |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
]]></artwork>
</figure>
<t>
<list style="empty">
<t>MPRTCP_Type: 0x00</t>
<t>block length: 16-bits
<list style="empty"><t>The 16-bit length field is the length of the encapsulated interface advertisement blocks in 32-bit word length not including the MPRTCP_Type and length fields.</t></list>
</t>
<t>Interface Advertisement block: variable size
<list style="empty"><t>Defined later in <xref
target="sec-mprtp-pkt-format-ia" format="counter" />.</t></list>
</t>
</list></t>
<section title="Interface Advertisement block" anchor="sec-mprtp-pkt-format-ia">
<t>This block describes a method to represent IPv4, IPv6 and generic DNS-type addresses in a block format. It is based on the sub-reporting block in <xref target="RFC5760" />.</t>
<figure anchor="fig-mprtp-address-header" title="Interface Advertisement block during path discovery"><artwork><![CDATA[
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type={0,1,2} | Length | Subflow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Port | RTCP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+ +
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t><list style="empty">
<t>Type: 8 bits
<list style="empty"><t>The Type corresponds to the type of address. Namely:
<list><t>0: IPv4 address</t>
<t>1: IPv6 address</t>
<t>2: DNS name</t></list>
</t></list>
</t>
<t>Length: 8 bits
<list style="empty"><t>The length of the Interface Advertisement block in bytes.
<list>
<t>For an IPv4 address, this should be 9 (i.e., 5 octets for the header and 4 octets for IPv4 address).</t>
<t>For an IPv6 address, this should be 21.</t>
<t>For a DNS name, the length field indicates the number of octets making up the string plus the 5 byte header.</t>
</list>
</t></list>
</t>
<t>RTP Port: 2 octets
<list style="empty"><t>The port number to which the sender sends RTP data. A port number of 0 is invalid and MUST NOT be used.</t></list>
</t>
<t>RTCP Port: 2 octets
<list style="empty"><t>The port number to which receivers send feedback reports. A port number of 0 is invalid and MUST NOT be used. </t></list>
</t>
<t>Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
<list style="empty"><t>The address to which receivers send feedback reports. For IPv4 and IPv6, fixed-length address fields are used. A DNS name is an arbitrary-length string. The string MAY contain Internationalizing Domain Names in Applications (IDNA) domain names and MUST be <xref target="RFC3629">UTF-8</xref> encoded.</t></list>
</t>
</list></t>
</section>
</section>
</section>
<section title="RTCP Timing reconsiderations for MPRTCP" anchor="sec-mprtcp-timer">
<!--
<t>Based on the timing rules defined in <xref target="RFC4585">, a sender or receiver MUST use only 5% of the average media rate. In a peer-to-peer scenario, each end-point uses 2.5% of the media rate for its RTCP.</t>
-->
<t>MPRTP endpoints MUST conform to the timing rule imposed in <xref target="RFC4585" />, i.e., the total RTCP rate between the participants MUST NOT exceed 5% of the media rate. For each endpoint, a subflow MUST send the aggregate and subflow-specific report. The endpoint SHOULD schedule the RTCP reports for the active subflows based on the share of the transmitted or received bit rate to the average media bit rate, this method ensures fair sharing of the RTCP bandwidth. Alternatively, the endpoint MAY schedule the reports in round-robin.</t>
</section>
<section anchor="sec-mprtp-sdp" title="SDP Considerations">
<!--<t>The packet formats specified in this document define extensions for RTP and RTCP. The use of MPRTP is left to the discretion of the sender and receiver.</t> -->
<!-- The MPRTP MAY be used without prior signaling. This is consistent with the rules governing of parsing RTP Header Extensions, as described in <xref target="RFC3550" />. -->
<section title="Signaling MPRTP Header Extension in SDP" anchor="mprtp-sdp-mprtp-hdrext">
<t>To indicate the use of the MPRTP header extensions (see <xref target="sec-mprtp-pkt-format" />) in SDP, the sender MUST use the following URI: urn:ietf:params:rtp-hdrext:mprtp. This is a media level parameter. Legacy RTP (non-MPRTP) clients will ignore this header extension, but can continue to parse and decode the packet (see <xref target="sec-mprtp-back-legacy" />).</t>
<!-- urn:ietf:params:rtp-hdrext:mprtp-subflow -->
<t>Example:</t>
<figure>
<artwork><![CDATA[
m=video 49170 RTP/AVP 98
a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp
]]></artwork>
</figure>
</section>
<section title="Signaling MPRTP capability in SDP" anchor="mprtp-sdp-ice-mprtp">
<t>A participant of a media session MUST use SDP to indicate that it supports MPRTP. Not providing this information will make the other endpoint ignore the RTCP extensions. <!--However, MPRTP MAY be used by either sender or receiver without prior signaling.--></t>
<figure>
<artwork><![CDATA[
mprtp-attrib = "a=" "mprtp" [
SP mprtp-optional-parameter]
CRLF ; flag to enable MPRTP
]]></artwork>
</figure>
<t>The endpoint MUST use 'a=mprtp', if it is able to send and receive MPRTP packets. Generally, senders and receivers MUST indicate this capability if they support MPRTP and would like to use it in the specific media session being signaled. To exchange the additional interfaces, the endpoint SHOULD use the in-band signaling (<xref target="sec-mprtp-pkt-format-rtcp-ia" />). Alternatively, advertise in SDP (<xref target="mprtp-sdp-ia-sdp" />).</t>
<!-- However, it is possible for an MPRTP sender to stream data using multiple paths to a non-MPRTP client.-->
<!-- <section title="Offer/Answer Considerations">
</section>
-->
</section>
<!-->
<t>In this case, the non-MPRTP client will ignore the extension header and the de-jitter buffer will try to re-order incoming packets. </t>
<t>Currently, there are no extensions defined for the literal 'mprtp' but we provide the opportunity to extend it using the mprtp-optional-parameter.</t> -->
<section title="MPRTP Interface Advertisement in SDP (out-of-band signaling)" anchor="mprtp-sdp-ia-sdp">
<t>If the endpoint is aware of its multiple interfaces and wants to use them for MPRTP then it MAY use SDP to advertise these interfaces. Alternatively, it MAY use in-band signaling to advertise its interfaces, as defined in <xref target="sec-mprtp-pkt-format-rtcp-ia" /> (MPRTCP_Type=0x02). The receiving endpoint MUST use the same mechanism to respond to an interface advertisement. In particular, if an endpoint receives an SDP offer, then it MUST respond to the offer in SDP.</t>
<section title=""interface" attribute" anchor="mprtp-sdp-ice-mprtp-interface-attribute">
<t>The interface attribute is an optional media-level attribute and is used to advertise an endpoint's interface address.</t>
<t>The syntax of the interface attribute is defined using the following Augmented BNF, as defined in <xref target="RFC5234" />. The definitions of unicast-address, port, token, SP, and CRLF are according to <xref target="RFC4566">RFC4566</xref>. </t>
<figure>
<artwork><![CDATA[
mprtp-optional-parameter = mprtp-interface
; other optional parameters may be added later
mprtp-interface = "interface" ":" counter SP unicast-address
":" rtp_port "/" rtcp_port
*(SP interface-description-extension)
counter = 1*DIGIT
rtp_port = port ;port from RFC4566
rtcp_port = port ;port from RFC4566
]]></artwork>
</figure>
<t><mprtp-interface>: specifies one of the unicast IP address, the RTP and RTCP port numbers of the endpoint. The unicast address with lowest counter value MUST match the connection address ('c=' line). Similarly, the RTP and RTCP ports MUST match with the RTP and RTCP ports in the associated 'm=' line. The counter should start at 1 and increment with each additional interface. Multiple interface lines MUST be ordered in a decreasing priority level as is the case with the Interface Advertisement blocks in in-band signaling (See <xref target="fig-mp-rtcp-header-ia" />). </t>
<t><unicast-address>: is taken from <xref target="RFC4566">RFC4566</xref>. It is one of the IP addresses of the endpoint allows the use of IPv4 addresses, IPv6 addresses and Fully Qualified Domain Names (FQDN). An endpoint MUST only include the IP address for which the connectivity checks have succeeded.</t>
<t><port>: is from <xref target="RFC4566">RFC4566</xref>. It is the RTP or RTCP port associated the unicast address.</t>
<t><counter>: is a monotonically increasing positive integer starting at 1. The counter MUST reset for each media line. The counter value for an interface, port should remain the same for the session.</t>
<!-- counter... why did we need it? -->
<t>The 'mprtp-interface' can be extended using the 'interface-description-extension' parameter. An endpoint MUST ignore any extensions it does not understand.</t>
</section>
<section title="Example">
<t>The ABNF grammar is illustrated by means of an example:</t>
<figure>
<artwork><![CDATA[
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp
a=mprtp interface:1 192.0.2.1:49170/49171 ;primary interface
a=mprtp interface:2 192.1.2.1:51372/51373 ;additional interface
]]></artwork>
</figure>
</section>
</section>
<section title="MPRTP with ICE" anchor="mprtp-sdp-ia-ice-sdp">
<t>If the endpoints intend to use <xref target="RFC5245">ICE</xref> for discovering interfaces and running connectivity checks then the following two step procedure MUST be followed: </t>
<!--changed from -02 draft: [Christer/MMUSIC]:these endpoints MUST NOT use in-band interface advertisement and the associated connectivity checks, as described in <xref target="sec-mprtp-pkt-format-hdrext-cc" /> (MPID=0x01). -->
<t><list style="numbers">
<t>Advertise ICE candidates: in the initial OFFER the endpoints exchange candidates, as defined in <xref target="RFC5245">ICE</xref>. Thereafter the endpoints run connectivity checks</t>
<t>Advertise MPRTP interfaces: When a sufficient number of connectivity checks succeed the endpoint MUST send an updated offer containing the interfaces that they want to use for MPRTP.</t>
</list>
Typically when a sufficient number of connectivity checks succeed the endpoint choose the best ICE candidate as the default path. Since more than one candidate may have succeeded the connectivity checks, an MPRTP endpoint MAY advertise (some of) these as "mprtp-interfaces".</t>
<!--This process enables the participants to use MPRTP capabilities from the start of a media session-->
</section>
<section anchor="mprtp-sdp-inc-througput" title="Increased Throughput">
<t>The MPRTP layer MAY choose to augment paths to increase throughput. If the desired media rate exceeds the current media rate, the endpoints MUST renegotiate the application specific ("b=AS:xxx") <xref target="RFC4566" /> bandwidth.</t>
</section>
<!-- <section title="Increased Reliability" anchor="mprtp-sdp-reliability">
<t>TBD</t>
</section>
<section title="Decoding dependency" anchor="mprtp-sdp-decdep">
<t>TBD</t>
</section>
-->
<section title="Offer/Answer Examples">
<t>This section shows examples of SDP offer and answer for in-band and out-of-band signaling.</t>
<section title="In-band signaling">
<t>The following offer/answer shows that both the endpoints are MPRTP capable and SHOULD use in-band signaling for interfaces advertisements.</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Answer:
v=0
o=bob 2890844528 2890844529 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=video 4000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp
]]></artwork>
</figure>
<t>The endpoint MAY now use in-band RTCP signaling to advertise its multiple interfaces. Alternatively, it MAY make another offer with the interfaces in SDP (out-of-band signaling).</t>
</section>
<section title="Out-of-band signaling">
<t>If the multiple interfaces are included in an SDP offer then the receiver MUST respond to the request with an SDP answer.</t>
<section title="Without ICE">
<t> In this example, the offerer advertises two interfaces and the answerer responds with a single interface description. The endpoint MAY use one or both paths depending on the end-to-end characteristics of each path.</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp interface:1 192.0.2.1:49170/49171
a=mprtp interface:2 192.1.2.1:51372/51373
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Answer:
v=0
o=bob 2890844528 2890844529 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=video 4000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp interface:1 192.0.2.2:4000/4001
]]></artwork>
</figure>
</section>
<section title="With ICE">
<t>In this example, the endpoint first sends its ICE candidates in the initial offer and the other endpoint answers with its ICE candidates.</t>
<t>Initial offer (with ICE candidates):</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host
a=candidate:2 1 UDP 1694498815 192.1.2.1 51372 typ host
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Answer:
v=0
o=bob 2890844528 2890844529 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=video 4000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host
]]></artwork>
</figure>
<t>Thereafter, each endpoint conducts ICE connectivity checks and when sufficient number of connectivity checks succeed, the endpoint sends an updated offer. In the updated offer, the endpoint advertises its multiple interfaces for MPRTP.</t>
<t>Updated offer (with MPRTP interfaces):</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp interface:1 192.0.2.1:49170/49171
a=mprtp interface:2 192.1.2.1:51372/51373
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Answer:
v=0
o=bob 2890844528 2890844529 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
m=video 4000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=mprtp interface:1 192.0.2.2:4000/4001
]]></artwork>
</figure>
</section>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The following contact information shall be used for all registrations in this document:
<figure>
<artwork><![CDATA[
Contact: Varun Singh
mailto:varun.singh@iki.fi
tel:+358-9-470-24785
]]></artwork>
</figure>
</t>
<section title="MPRTP Header Extension">
<t>This document defines a new extension URI to the RTP Compact Header
Extensions sub-registry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data:
<figure>
<artwork><![CDATA[
Extension URI: urn:ietf:params:rtp-hdrext:mprtp
Description: Multipath RTP
Reference: RFC XXXX
]]></artwork>
</figure>
</t>
</section>
<section title="MPRTCP Packet Type">
<t>A new RTCP packet format has been registered with the RTCP Control Packet type (PT) Registry:
<figure>
<artwork><![CDATA[
Name: MPRTCP
Long name: Multipath RTCP
Value: 211
Reference: RFC XXXX.
]]></artwork>
</figure>
</t>
</section>
<section title="SDP Attributes">
<t>This document defines a new SDP attribute, "mprtp", within the existing IANA registry of SDP Parameters.</t>
<t>TBD.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
<t>All drafts are required to have a security considerations section. See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by Trilogy
(http://www.trilogy-project.org), a research project (ICT-216372)
partially funded by the European Community under its Seventh
Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use
that may be made of the information in this document.</t>
<t>The authors would also like acknowledge the contribution of Ralf
Globisch and Thomas Schierl for providing the input and text for the
MPRTP interface advertisement in SDP.</t>
<!-- Roni, Christer etc for reviews-->
<t>Thanks to Christer Holmberg, Miguel A. Garcia, and Roni Even for providing valuable feedback on earlier versions of this draft</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<!--<section anchor="Contributors" title="Contributors"> <t>...</t> </section>
-->
</middle>
<back>
<references title="Normative References">
&rfc2119; <!-- keywords -->
&rfc3629; <!-- UTF-8 -->
&rfc5760; <!-- rtcp ssm -->
&rfc5245; <!-- ice -->
&rfc5285; <!-- gen header ext -->
&rfc3550; <!-- rtp -->
&rfc5506; <!-- non-compound -->
&rfc4585; <!-- avpf -->
&rfc5234; <!-- abnf -->
</references>
<references title="Informative References">
&rfc3552; <!-- guideline for sec considerations -->
<!-- &rfc3611; rtcp xr -->
&rfc4566; <!-- sdp -->
&rfc4960; <!-- sctp -->
&rfc5533; <!-- shim6 -->
&rfc5117; <!-- rtp topologies -->
&rfc3261; <!-- SIP -->
&rfc3264; <!-- o/a with SDP -->
&rfc6182; <!-- mptcp -->
&I-D.ietf-mmusic-rfc2326bis;
&rfc6263; <!-- keepalive -->
</references>
<section title="Interoperating with Legacy Applications" anchor="sec-mprtp-back-legacy">
<t>An MPRTP sender can use its multiple interfaces to send media to a legacy RTP client. The legacy receiver will ignore the subflow RTP header and the receiver's de-jitter buffer will try to compensate for the mismatch in per-path delay. However, the receiver can only send the overall or aggregate RTCP report which may be insufficient for an MPRTP sender to adequately schedule packets or detect if a path disappeared.</t>
<t>An MPRTP receiver can only use one of its interface when communicating with a legacy sender.</t>
</section>
<section anchor="App-a" title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section anchor="App-ind-03" title="changes in draft-singh-avtcore-mprtp-03">
<t><list style="symbols">
<t>Added this change log.</t>
<t>Updated section 6, 7 and 8 based on comments from MMUSIC.</t>
<t>Updated section 11 (SDP) based on comments of MMUSIC.</t>
<t>Updated SDP examples with ICE and non-ICE in out-of-band signaling scenario.</t>
<t>Added <xref target="sec-mprtp-back-legacy" /> on interop with legacy.</t>
<t>Updated IANA considerations section</t>
</list></t>
</section>
<section anchor="App-ind-02" title="changes in draft-singh-avtcore-mprtp-02">
<t><list style="symbols">
<t>MPRTCP protocol extensions use only one PT=210, instead of 210 and 211.</t>
<t>RTP header uses 1-byte extension instead of 2-byte.</t>
<t>Added section on RTCP Interval Calculations.</t>
<t>Added "mprtp-interface" attribute in SDP considerations.</t>
</list></t>
</section>
<section anchor="App-ind-01" title="changes in draft-singh-avtcore-mprtp-01">
<t><list style="symbols">
<t>Added MPRTP and MPRTCP protocol extensions and examples.</t>
<t>WG changed from -avt to -avtcore.</t>
</list></t>
</section>
</section>
<!-- Change Log
v00 2010-02-18 Varun Initial version, 9 sections -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:17:22 |