One document matched: draft-singh-avtcore-mprtp-08.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 I-D.ietf-mmusic-rtsp-nat PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-rtsp-nat.xml">
<!ENTITY I-D.singh-mmusic-mprtp-sdp-extension PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-mmusic-mprtp-sdp-extension.xml">
<!ENTITY I-D.wing-mmusic-ice-mobility PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-mmusic-ice-mobility.xml">
<!ENTITY I-D.reddy-mmusic-ice-best-interface-pcp PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.reddy-mmusic-ice-best-interface-pcp.xml">
<!ENTITY I-D.singh-rmcat-cc-eval PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-rmcat-cc-eval.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">
<!ENTITY rfc5761 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- 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-08" 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 Electrical Engineering</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 Electrical Engineering</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 Electrical Engineering</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 Electrical Engineering</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>saba.ahsan@aalto.fi</email>
</address>
</author>
<author initials="L." surname="Eggert" fullname="Lars Eggert">
<organization abbrev="NetApp"> NetApp </organization>
<address>
<postal>
<street>Sonnenallee 1</street>
<code>85551</code> <city>Kirchheim</city>
<country>Germany</country>
</postal>
<phone>+49 151 12055791</phone>
<email>lars@netapp.com</email>
<uri> http://eggert.org/ </uri>
</address>
</author>
<date year="2014" />
<!-- <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 real-time
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><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>
</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>-->
</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. This
enables the endpoint to transmit 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 as well as the
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>
<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. A multipath session may be upgraded from a
typical single path session, as and when new interfaces appear or
disappear. However, it is also 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>
<!--Ralf -03: An endpoint must be capable of advertising changes in its set of
usable interfaces, which may be the result of an interface appearing or
disappearing. -->
<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"
>Session Description Protocol (SDP)</xref> in <xref
target="RFC3261">Session Initiation Protocol (SIP)</xref>, <xref
target="I-D.ietf-mmusic-rfc2326bis">Real-Time Streaming Protocol
(RTSP)</xref>) or in-band signaling (e.g., RTP/RTCP header extension,
Session Traversal Utilities for NAT (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 or notify the other endpoint about
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 <xref target="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 <xref
target="I-D.wing-mmusic-ice-mobility">STUN</xref>. </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>
</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 an active
subflow for failure (errors, unreachability, congestion) and decide
not to use (make the active subflow passive), or teardown the
subflow.</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 for MPRTP 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="NAT Traversal" anchor="sec-mprtp-nat-traversal">
<t>After gathering their interface candidates, the endpoints decide
internally if they wish to perform connectivity checks.</t>
<t><cref anchor="note-iceornot" source="Editor">Legacy applications
do not require ICE for session establishment, therefore, MPRTP
should not require it as well.</cref></t>
<t>If the endpoint chooses to perform connectivity checks then it
MUST first advertise the gathered candidates as ICE candidates in
SDP during session setup and let ICE perform the connectivity
checks. As soon as a sufficient number of connectivity checks
succeed, the endpoint can use the successful candidates to advertise
its MPRTP interface candidates.</t>
<t>Alternatively, if the endpoint supports <xref
target="I-D.wing-mmusic-ice-mobility">mobility extensions for
ICE</xref>, it can let the ICE agent gather and perform the
connectivity checks. When the connectivity checks succeed, the ICE
agent should notify the MPRTP layer of these new paths (5-tuples),
these new paths are then used by MPRTP to send media packets
depending on the scheduling algorithm.
</t>
<t>
If an endpoint supports <xref
target="I-D.reddy-mmusic-ice-best-interface-pcp">Interface selection
via PCP Flow Extension</xref>, it will receive notifications when new
interfaces become available and additionally when the link quality of a
currently available interface changes. The application can advertise
and perform connectivity checks with the new interface and in the
case of changes in link quality pass the information to the scheduling
algorithm for better application performance.
</t>
<t>[Editors note: The interaction between the RTP agent and ICE
agent is needed for implementing a scheduling algorithm or
congestion control. See details of a scheduling algorithm in
<xref target="ACM-MPRTP" />.]</t>
</section>
<section title="Choosing between In-band (in RTCP) and Out-of-band
(in SDP) Interface Advertisement" anchor="sec-mprtp-subflow-advert">
<t>If there is no media flowing at the moment and the application
wants to use the interfaces from the start of the session, it
should advertise them in SDP (See <xref
target="I-D.singh-mmusic-mprtp-sdp-extension" />). Alternatively,
the endpoint can setup the session as a single path media session
and upgrade the session to multipath by advertising the session
in-band (See <xref target="sec-mprtp-rtcp-subflow-advert" /> or <xref
target="I-D.wing-mmusic-ice-mobility" />).
Moreover, if an interface appears and disappears, the endpoint
SHOULD prefer to advertise it in-band because the endpoint would
not have to wait for a response from the other endpoint before
starting to use the interface. However, if there is a conflict
between an in-band and out-of-band advertisement, i.e., the
endpoint receives an in-band advertisement while it has a pending
out-of-band advertisement, or vice versa then the session is setup
using out-of-band mechanisms.</t>
</section>
<section title="In-band Interface Advertisement"
anchor="sec-mprtp-rtcp-subflow-advert">
<t>To advertise the multiple interfaces in RTCP, 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.</t>
</section>
<section title="Subflow ID Assignment"
anchor="sec-mprtp-subflow-id">
<t>After interface advertisements have been exchanged, the endpoint
MUST associate a Subflow ID to each unique subflow. Each combination
of sender and receiver IP addresses and port pairs (5-tuple) is a
unique subflow. If the connectivity checks have been performed then
the endpoint MUST only use the subflows for which the connectivity
checks have succeeded.</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>
Commented in -03
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 packets (fallback paths) are called passive subflows.</t>
<t>An endpoint MUST multiplex the subflow specific RTP and RTCP
packets on the same port to keep the NAT bindings alive. This is
inline with the recommendation made in RFC6263<xref target="RFC6263"
/>. Moreover, if an endpoint uses ICE, multiplexing RTP and RTCP
reduces the number of components from 2 to 1 per media stream. If no
MPRTP or MPRTCP packets are received on a particular subflow at a
receiver, the receiver SHOULD remove the subflow from active and
passive lists and not send any MPRTCP reports for that subflow. It may
keep the bindings in a dead-pool, so that if the 5-tuple or subflow
reappears, it can quickly reallocate it based on past history.</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>
<t><xref target="ACM-MPRTP" /> describes and evaluates a scheduling
algorithm for video over multiple interfaces. The video is encoded at
a single target bit rate and is evaluated in various network scenarios,
as discussed in <xref target="I-D.singh-rmcat-cc-eval" />.
</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. For example, an adaptive playout
algorithm is discussed in <xref target="ACM-MPRTP" />.</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>
</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 distribute a single RTP
stream over multiple subflows.</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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | |
+---------------+--------------------------------------------------+
| 0x0 | Subflow RTP Header. For this case the Length is |
| | set to 4 |
+---------------+--------------------------------------------------+
]]></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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xBE | 0xDE | length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | LEN=4 | 0x0 | LEN=4 | Subflow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific Seq Number | Pad (0) | Pad (0) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t>MP ID = 0x0
<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>
commented in -03
1. (see <xref target="RFC6263" x:fmt="of" x:sec="4.6"/>)
2. 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, and 2) advertise each
interface.</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: 8-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 | |
+---------------+--------------------------------------------------+
| 0 | Subflow Specific Report |
| 1 | Interface Advertisement (IPv4 Address) |
| 2 | Interface Advertisement (IPv4 Address) |
| 3 | Interface Advertisement (DNS Address) |
+---------------+--------------------------------------------------+
]]></artwork>
</figure></t></list>
</t>
<t>block length: 8-bits
<list style="empty"><t>The 8-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-rtcp-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=0 | block length | Subflow ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type=0 | block length | Subflow ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>MPRTCP_Type: 0
<list style="empty"><t>The value indicates that the encapsulated
block is a subflow report.</t></list>
</t>
<t>block length: 8-bits
<list style="empty"><t>The 8-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=0 | block length | Subflow ID #1 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|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=0 | block length | Subflow ID #2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|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 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" />. 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 | block length | RTP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type | block length | RTP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type | block length | RTP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address #.. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPRTCP_Type | block length | RTP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address #m |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
]]></artwork>
</figure>
<t><list style="empty">
<t>MPRTCP_Type: 8 bits
<list style="empty"><t>The MPRTCP_Type corresponds to the type of
interface address. Namely:
<list>
<t>1: IPv4 address</t>
<t>2: IPv6 address</t>
<t>3: DNS name</t>
</list>
</t></list>
</t>
<t>block 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>Interface 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 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 in extmap: 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[
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
]]></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 (See <xref target="sec-mprtp-pkt-format-rtcp-ia" />).
Alternatively, advertise in SDP (See <xref
target="I-D.singh-mmusic-mprtp-sdp-extension" />).</t>
<!-- However, it is possible for an MPRTP sender to stream data using
multiple paths to a non-MPRTP client.-->
<t>MPRTP endpoint multiplexes RTP and RTCP on a single port, sender
MUST indicate support by adding "a=rtcp-mux" in SDP <xref
target="RFC5761" />. If an endpoint receives an SDP without
"a=rtcp-mux" but contains "a=mprtp", then the endpoint MUST infer
support for multiplexing.</t>
<t><cref anchor="note-rtp-rtcp-mux" source="Editor">If a=mprtp is
indicated, does the endpoint need to indicate a=rtcp-mux? because
MPRTP mandates RTP and RTCP multiplexing.</cref></t>
<!-- <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 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
endpoint MUST advertise its ICE candidates in the initial OFFER, as
defined in <xref target="RFC5245">ICE</xref>. Thereafter the endpoints
run connectivity checks.</t>
<t>When an endpoint uses ICE's regular nomination <xref target="RFC5245"/>
procedure, it chooses the best ICE candidate as the default path. In the
case of an MPRTP endpoint, if more than one ICE candidate succeeded the
connectivity checks then an MPRTP endpoint MAY advertise (some of) these
in-band in RTCP as MPRTP interfaces.</t>
<t>When an endpoint uses ICE's aggressive nomination <xref
target="RFC5245" /> procedure, the selected candidate may change as more
ICE checks complete. Instead of sending updated offers as additional ICE
candidates appear (transience), the endpoint it MAY use in-band signaling
to advertise its interfaces, as defined in <xref
target="sec-mprtp-pkt-format-rtcp-ia" />.</t>
<t>If the default interface disappears and the paths used for MPRTP
are different from the one in the c= and m= lines then the an
alternate interface for which the ICE checks were successful should be
promoted to the c= and m= lines in the updated offer.</t>
<t>When a new interface appears then the application/endpoint should
internally decide if it wishes to use it and sends an updated offer
with ICE candidates of the all its interfaces including the new
interface. The receiving endpoint responds to the offer with all its
ICE candidates in the answer and starts connectivity checks between
all its candidates and the offerer's ICE candidates. Similarly, the
initiating endpoint starts connectivity checks between the its
interfaces (incl. the new interface) and all the received ICE
candidates in the answer. If the connectivity checks succeed, the
initiating endpoint MAY use in-band signaling (See <xref
target="sec-mprtp-pkt-format-rtcp-ia" />) to advertise its new set of
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="Offer/Answer">
<t>When SDP <xref target="RFC4566" /> is used to negotiate MPRTP
sessions following the offer/answer model <xref target="RFC3264" />, the
"a=mprtp" attribute (see <xref target="mprtp-sdp-ice-mprtp" />) indicates
the desire to use multiple interfaces to send or receive media data. The
initial SDP offer MUST include this attribute at the media level. If the
answerer wishes to also use MPRTP, it MUST include a media-level "a=mprtp"
attribute in the answer. If the answer does not contain an "a=mprtp"
attribute, the offerer MUST NOT stream media over multiple paths and the
offerer MUST NOT advertise additional MPRTP interfaces in-band or
out-of-band.</t>
<t>When SDP is used in a declarative manner, the presence of an "a=mprtp"
attribute signals that the sender can send or receive media data over
multiple interfaces. The receiver SHOULD be capable to stream media to the
multiple interfaces and be prepared to receive media from multiple
interfaces.</t>
<t>The following sections shows examples of SDP offer and answer for
in-band and out-of-band signaling.</t>
<section title="In-band Signaling Example">
<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=rtcp-mux
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=rtcp-mux
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) <xref
target="I-D.singh-mmusic-mprtp-sdp-extension" />.</t>
</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>
<t>Note to the RFC-Editor: When publishing this document as an RFC, please
replace "RFC XXXX" with the actual RFC number of this document and delete
this sentence.</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>
<t>This document defines a substructure for MPRTCP packets. A new
sub-registry has been set up for the sub-report block type (MPRTCP_Type)
values for the MPRTCP packet, with the following registrations created
initially: </t>
<t><figure>
<artwork><![CDATA[
Name: Subflow Specific Report
Long name: Multipath RTP Subflow Specific Report
Value: 0
Reference: RFC XXXX.
Name: IPv4 Address
Long name: IPv4 Interface Address
Value: 1
Reference: RFC XXXX.
Name: IPv6 Address
Long name: IPv6 Interface Address
Value: 2
Reference: RFC XXXX.
Name: DNS Name
Long name: DNS Name indicating Interface Address
Value: 3
Reference: RFC XXXX.
]]></artwork>
</figure></t>
<t> Further values may be registered on a first come, first served basis.
For each new registration, it is mandatory that a permanent, stable, and
publicly accessible document exists that specifies the semantics of the
registered parameter as well as the syntax and semantics of the
associated sub-report block. The general registration procedures of <xref
target="RFC4566" /> apply.</t>
</section>
<section title="SDP Attributes">
<t>This document defines a new SDP attribute, "mprtp", within the
existing IANA registry of SDP Parameters.</t>
<section title=""mprtp" attribute">
<t><list style="symbols">
<t>Attribute Name: MPRTP</t>
<t>Long Form: Multipath RTP</t>
<t>Type of Attribute: media-level</t>
<t>Charset Considerations: The attribute is not subject to the
charset attribute.</t>
<t>Purpose: This attribute is used to indicate support for
Multipath RTP. It can also provide one of many possible interfaces
for communication. These interface addresses may have been
validated using ICE procedures.</t>
<t>Appropriate Values: See <xref target="mprtp-sdp-ice-mprtp"/>
of RFC XXXX.</t>
</list></t>
</section>
</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>
<!-- DDos Attack, advertising victim's IP address -->
<!-- Privacy -->
<!-- Hijacking a session -->
</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 work of Varun Singh and Joerg Ott from Aalto University has been
partially supported by the European Institute of Innovation and Technology
(EIT) ICT Labs activity RCLD 11882.</t>
<t>Thanks to Miguel A. Garcia, Ralf Globisch, Christer Holmberg, 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 -->
&rfc5761; <!-- multiplexing -->
</references>
<references title="Informative References">
&rfc3552; <!-- guideline for sec considerations -->
<!-- &rfc3611; rtcp xr -->
&rfc6182; <!-- mptcp -->
&rfc4960; <!-- sctp -->
&rfc5533; <!-- shim6 -->
&rfc5117; <!-- rtp topologies -->
&I-D.ietf-mmusic-rfc2326bis; <!--rtsp 2.0-->
&rfc3261; <!-- SIP -->
&rfc3264; <!-- o/a with SDP -->
&rfc4566; <!-- sdp -->
&rfc6263; <!-- keepalive -->
<!-- ICE and related specs for interface discovery -->
&I-D.singh-mmusic-mprtp-sdp-extension;
&I-D.reddy-mmusic-ice-best-interface-pcp;
&I-D.wing-mmusic-ice-mobility;
<!-- Eval -->
&I-D.singh-rmcat-cc-eval;
<reference anchor="ACM-MPRTP">
<front><title>MPRTP: multipath considerations for real-time media</title>
<author fullname="Varun Singh" initials="V." surname="Singh" />
<author fullname="Saba Ahsan" initials="S." surname="Ahsan" />
<author fullname="Joerg Ott" initials="J." surname="Ott" />
<date year="2013" /></front>
<seriesInfo name="in Proc. of ACM Multimedia Systems," value="MMSys" />
</reference>
</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 title="Changes in draft-singh-avtcore-mprtp-08">
<t><list style="symbols">
<t>Added reference to use of PCP for discovering new interfaces.</t>
</list></t>
</section>
<section title="Changes in draft-singh-avtcore-mprtp-06 and -07">
<t><list style="symbols">
<t>Added reference to Mobility ICE.</t>
</list></t>
</section>
<section title="Changes in draft-singh-avtcore-mprtp-05">
<t><list style="symbols">
<t>SDP extensions moved to
draft-singh-mmusic-mprtp-sdp-extension-00. Kept only the
basic 'a=mprtp' attribute in this document.</t>
<t>Cleaned up ICE procedures for advertising only using
in-band signaling.</t>
</list></t>
</section>
<section title="Changes in draft-singh-avtcore-mprtp-04">
<t><list style="symbols">
<t>Fixed missing 0xBEDE header in MPRTP header format.</t>
<t>Removed connectivity checks and keep-alives from in-band
signaling.</t>
<t>MPRTP and MPRTCP are multiplexed on a single port.</t>
<t>MPRTCP packet headers optimized.</t>
<t>Made ICE optional</t>
<t>Updated Sections: 7.1.2, 8.1.x, 11.2, 11.4, 11.6.</t>
<t>Added how to use MPRTP in RTSP (Section 12).</t>
<t>Updated IANA Considerations section.</t>
</list></t>
</section>
<section 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 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 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:26 |