Internet DRAFT - draft-leiwm-avtcore-mprtp-ra
draft-leiwm-avtcore-mprtp-ra
AVT Core Working Group W. Lei
Internet-Draft W. Zhang
Intended status: Experimental S. Liu
Expires: September 12, 2013 Northeastern University
March 12, 2013
Multipath RTP based on RTP Relay Application (MPRTP-RA)
draft-leiwm-avtcore-mprtp-ra-00
Abstract
This document defines the framework of multipath transmission of real-time
media based on relay. The framework allows participants to use multiple
paths,including the default IP path and relay paths, to transport media in a
RTP session. A relay path may via one or more RTP relay nodes which provide
relay services for media data. This framework describes function blocks and
behaviors of MPRTP-RA-capable RTP agent and RTP relay. The framework also
defines multipath transport protocol by extending RTP, and relay control
protocol named OpenPath.
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of
BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute working documents as
Internet-Drafts. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress."
This Internet-Draft will expire on September 12, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect
on the date of publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect to
this document. Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the
Simplified BSD License.
Leiwm, et al. Expires September 12, 2013 [Page 1]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Table of Contents
1 Introduction................................................. 3
2 Terminology.................................................. 4
3 Definitions.................................................. 4
4 Goals........................................................ 5
4.1 Functional goals............................................. 5
4.2 Compatibility goals.......................................... 5
5 MPRTP-RA Topologies.......................................... 6
6 MPRTP-RA Use Scenarios....................................... 7
7 Overview of operation........................................ 9
7.1 Usage Scenario in SIP system................................. 10
8 MPRTP-RA Agent Behavior...................................... 12
8.1 MPRTP-RA session management.................................. 12
8.2 Path management.............................................. 12
8.3 Flow partitioning and scheduling............................. 15
8.4 Subflow recombination........................................ 15
8.5 Subflow RTP transmission..................................... 15
8.6 Subflow RTCP transmission.................................... 15
9 RTP Relay Behavior........................................... 16
9.1 Path-Table................................................... 16
9.2 Connection Management........................................ 18
9.3 Relay Service Management..................................... 18
9.4 Path Validity Management..................................... 19
9.5 Query Messages Processing.................................... 19
9.6 Path-Table Modification Messages Processing.................. 19
9.7 RTP/RTCP Packet Processing................................... 20
10 OpenPath Protocol............................................ 20
10.1 Protocol Overview............................................ 21
10.1.1 Relay-to-Controller.......................................... 21
10.1.2 Controller-to-Relay.......................................... 22
10.1.3 Symmetric.................................................... 23
10.2 Common Structures............................................ 23
10.2.1 OpenPath Common Header....................................... 23
10.2.2 Common Body of OpenPath Failure Responses.................... 24
10.2.3 Transport Address Structure.................................. 25
10.3 OpenPath Request and Success Response Message Format......... 26
10.3.1 HELLO........................................................ 26
10.3.2 START/STOP/BYE............................................... 26
10.3.3 ECHO......................................................... 26
10.3.4 NOTIFY/DELETE_PATH........................................... 27
10.3.5 FEATURES..................................................... 27
10.3.6 STATISTICS................................................... 28
10.3.7 ADD-PATH/ UPDATE_PATH........................................ 28
11 MPRTP-RA Packet Formats...................................... 28
11.1 RTP Header Extension for MPRTP-RA............................ 29
11.1.1 MPRTP-RA RTP Extensions for a Subflow........................ 30
11.2 RTCP Extension for MPRTP-RA (MPRTCP-RA)...................... 30
Leiwm, et al. Expires September 12, 2013 [Page 2]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
11.2.1 MPRTCP-RA Extensions for Subflow Reporting (SR/RR)........... 31
11.2.2 MPRTCP-RA Extensions for Subflow Path Probe.................. 33
11.2.3 MPRTCP-RA Extensions for Subflow Keepalive................... 34
12 SDP Considerations........................................... 34
12.1 Signaling MPRTP-RA Header Extension in SDP................... 34
12.2 Signaling MPRTP-RA Capability in SDP......................... 35
12.3 Relay Path Advertisement in SDP.............................. 35
12.4 Offer/Answer................................................. 36
12.4.1 An Example................................................... 37
13 IANA Considerations.......................................... 38
13.1 MPRTP-RA Header Extension.................................... 38
13.2 MPRTCP-RA Packet Type........................................ 39
13.3 SDP Attributes............................................... 39
14 Security Considerations...................................... 40
15 References................................................... 40
15.1 Normative References......................................... 40
15.2 Informative References....................................... 4E
1. Introduction
Media transmission in traditional networks mainly depends on a single path,
such as the default IP path determined by routing protocols. However, the
default IP path usually is not optimal and sometimes even worse when the
path via different Internet Service Provider (ISP) networks.
IP communication applications usually adopt a relay-based way to transfer
media. Relay-based media transmission is used to be a general solution for
NAT and firewall traversal which usually makes direct media transmission
between the sender and the receiver unfeasible. And this can provide
communication applications with opportunities to autonomously select media
transmission path by replacing the default IP path with a relay path.
Whether the default IP path or the relay path, the end-to-end media session
mainly uses transport protocols dedicated to single-path media transmission,
such as RTP. However, the single path may not be capable of handling load
requirements of media transmission, especially when transporting high bit-
rate multimedia content.
Using multiple paths between source and destination for media transmission
has been shown to be an effective method to increase throughput and
reliability. This document defines the framework of multipath transmission
of real-time media based on relay. The framework allows participants to use
multiple paths, including the default IP path and relay paths, to transport
media in a RTP session.
This framework describes the function blocks and behaviors of the MPRTP-RA-
capable RTP agent and RTP relay. The framework also defines the application-
level multipath transport protocol by extending RTP, and the relay control
Leiwm, et al. Expires September 12, 2013 [Page 3]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
protocol named OpenPath.
2. Terminology
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 RFC2119 [2].
3. Definitions
1) Endpoint: host either initiating or terminating a RTP flow.
2) 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 should map to a unique
path.
3) Path: sequence of logical links between a sender and a receiver. We
define it by a set of addresses. All available paths for a MPRTP-RA session
include a default path and one or more relay paths.
4) Default path: a path between a sender and a receiver, which is same as
the path negotiated and established by a normal RTP session. It is
determined by the c= and m= lines in Session Description Protocol (SDP)
during session setup. If either the sender or the receiver is not behind a
symmetric NAT, the default path may be the direct network path between the
sender and the receiver. Otherwise, it may traverse a third-party node, such
as a TURN server or a media server which is responsible for relaying RTP
packets.
5) Relay path: a path via one or multiple RTP relay nodes between a sender
and a receiver. A relay path is defined by a sequence of (S, R1, ..., Rm, D),
where Ri denotes the address of the i-th relay node and m denotes the number
of relay nodes in this path.
6) Candidate path: a path that is either a default path or a relay path.
7) Active path: a path that carries media data.
8) RTP Relay: an intermediary entity that primarily plays the role of
forwarding RTP subflow according to a Path-Table. RTP Relay receives RTP
packets from its upstream entity of the subflow that the received RTP
packets belong to, obtains the next-hop transport address based on the
matching results in the Path-Table, and forwards the RTP packets to the
corresponding next-hop transport address. All RTP fields produced by initial
RTP protocol remain intact.
9) Path-Table: a table consisting of a set of path entries.
10) MPRTP-RA Session: a special type of RTP session in which the original
Leiwm, et al. Expires September 12, 2013 [Page 4]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
single media stream is split into multiple subflows and each subflow is
mapped to a unique path.
4. Goals
This section outlines the basic goals that multipath RTP based on RTP relay
aims to meet. These are broadly classified as Functional goals and
Compatibility goals.
4.1 Functional goals
In multipath RTP based on RTP relay, the original media flow in a RTP
session is split into multiple subflows which are carried over multiple
paths. This may prove beneficial in case of video streaming.
1) Increased Throughput: In some cases, the relay path, which is assigned to
a media session according to the location of participants and the current
network status, has better transport capacity than the default path between
the participants. And cumulative transport capacity of multiple paths may
better meet the requirements of the high bit-rate media session.
2) Improved Reliability: when multiple paths are available, MPRTP-RA agent
can use some of them to send redundant packets or re-transmit packets to
increase reliability. When one active path occurs failure such as errors,
unreachability or congestion, MPRTP-RA agent can tear down the corresponding
subflow or switch the subflow load to other candidate paths based on a
scheduling strategy.
3) Load balancing: transmitting a 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 and then avoids congestion in
network hot-spots. From the perspective of the whole network, the network
load balancing and network utilization can be significantly improved.
4.2 Compatibility goals
MPRTP-RA MUST be backwards compatible. In other words, if multiple paths are
not available, the endpoints supporting the extension in this document
should fall back to be compatible with legacy RTP stacks.
1) Application Compatibility: MPRTP-RA-capable RTP applications MUST be
backwards compatible with existing RTP applications and not require any
change to them. Moreover, regardless of whether the receiver is MPRTP-RA-
capable, the MPRTP-RA-capable sender is allowed to use multiple paths for
transmission. The media receiver with legacy RTP stack is still able to
reconstruct and playback the media stream because the received RTP packets
are compliant to [RFC3550].
Leiwm, et al. Expires September 12, 2013 [Page 5]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
2) Network Compatibility: individual RTP subflows MUST themselves be well-
formed RTP flows, so that they are able to traverse NATs and firewalls.
5. MPRTP-RA Topologies
For a multimedia session, the media transmission path from the source to its
receiver is usually the default IP path determined by routing protocols,
such as OSPF. However, the default IP path usually is not optimal and
sometimes even when the path goes through different ISP networks. If the
media transmission path is switched to another path, referred to as a relay
path, which goes through one or more relay nodes, and if network bandwidth
and other performance metrics between the endpoints and its neighboring
relay nodes and between two successive relay nodes if they exist can be
ensured, the quality of the received media can be improved.
In addition, when transporting high bit-rate multimedia content, the single
path may not be capable of handling the load requirements of media
transmission. It is an increasingly common practice for the endpoints with
high access bandwidth through well-connected access networks. The bandwidth
constraints of an end-to-end multimedia session are gradually migrating from
user access network to inside the network. In this case, using multiple
paths, including the default IP path and the relay paths, between the source
and the destination for media transmission has been shown to be a more
effective method than using a single path. The media sender balances their
multimedia stream across multiple paths based on the path reception
statistics (e.g. RTT, loss-rate, delay etc.). The resource capacity of
multiple paths can well meet the throughput requirements, better packet
losses and delays within a predictable range, such that enhance user
experience.
The relay nodes mentioned above may be deployed in a variety of ways.
Combined with application requirements, application service providers can
deploy a large number of proprietary media servers with high network
bandwidth and computing performance in their system. The participating nodes
that access the same application may also self-organize to form a dynamic
overlay network among which the nodes with higher performance can provide
media relay service to others.
This specification presents the notion of "RTP relay", which could be
considered as intermediate systems at the RTP level. The deployment of RTP
relay nodes provides more options of media transport paths different from
the default path.
RFC3550 supports the use of RTP-level translators and mixers, and discusses
the impact on RTP and RTCP packets in detail. RFC5117 describes a number of
scenarios using mixers and translators in point-to-point and point-to-
multipoint topologies. MPRTP-RA presented in this document assumes that if a
mixer or translator exists in the network, then either all of the multiple
Leiwm, et al. Expires September 12, 2013 [Page 6]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
paths or none of the multiple paths go via this component.
6. MPRTP-RA Usage Scenarios
MPRTP-RA can be applied in many multimedia application scenarios for
multipath multimedia transport, including point-to-point real-time
communication, many-to-one parallel streaming and one-to-many multicast
streaming. In these scenarios, higher bit-rate and higher quality codecs are
allowed to be used.
Figure 1 illustrates a point-to-point MPRTP-RA session. There are three
paths between the sender and the receiver, including the default path, one
relay path via one RTP relay node and one relay path via two RTP relay
nodes. Applications running at the sender side can choose a data
partitioning method according to its particular requirements. Then, each
flow is assigned to a path. The receiver reassembles the received flows
using a resequencing buffer to retrieve the reconstructed flow which is
decoded and displayed.
RTP data(A, Relay-1,B)
+------------+
+------------------->| RTP Relay-1|------------------------+
| +------------+ |
| V
+--------+ RTP data(A,B) +--------+
| User A |----------------------------------------------->| User B |
+--------+ +--------+
| ^
| RTP data(A, Relay-2,Relay-3,B) |
| +------------+ +------------+ |
+--->| RTP Relay-2|-------------------->| RTP Relay-3|-----+
+------------+ +------------+
Figure 1. A point-to-point multipath RTP session
A wide range of applications require data transmission from geographically
distributed sources to one destination. For instance, large volume data of
high definition movies are stored at multiple geographically distributed
locations. The audiences need to retrieve and integrate data from several
locations. This usage scenario can be completed by a many-to-one MPRTP
session, which is depicted in Figure 2. A MPRTP-RA agent streams different
portions of a video from three servers concurrently. The path between the
server and the MPRTP-RA agent may go through one or more RTP relay nodes.
Leiwm, et al. Expires September 12, 2013 [Page 7]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
+---+
| A |----------------------------------------------------+
+---+ |
|
V
+---+ +---------+ +---+
| B |------------------|RTP Relay|-------------------->| D |
+---+ +---------+ +---+
^
|
+---+ +---------+ |
| C |------------------|RTP Relay|-----------------------+
+---+ +---------+
Figure 2. A many-to-one multipath RTP session
Many video applications are typically characterized by a wide range of
connection qualities and receiving devices which are with different
capabilities ranging from cell phones with small screens and restricted
processing power to high-end PC with high-definition display. These systems
are usually adopting layered coding. Layered coding enables the encoding of
a high-quality video bit stream containing one or more subset bit streams
that can themselves be decoded independently. This usage scenario can be
completed by a one-to-many MPRTP-RA session, which is depicted in figure 3.
A video source is encoded into multiple streams, each of which is
transported by a source tree for video multicast.
+---+
+------------------------->| A |
| +--->+---+
| |
+---------+ |
+------------------->|RTP Relay|----------------|------+
| +---------+ | |
| | | |
| | | V
+---+ +------------------+ | +---+
| S | | | | B |
+---+ +------------------|--+ +---+
| | | ^
| | | |
| +---------+ | |
+------------------->|RTP Relay|-------------|---------+
+---------+ |
| |
| +------>+---+
+------------------------->| C |
+---+
Figure 3. A one-to-many multipath RTP session
Leiwm, et al. Expires September 12, 2013 [Page 8]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
7. Overview of operation
As intermediate entities, RTP relay nodes provide data relay service to the
communicating endpoints. Then multiple relay paths may be generated between
a sender and a receiver.
If the RTP relay nodes are deployed by application service provider, the
relay paths may be assigned by the server system. If the RTP relay nodes are
those participating nodes with higher performance, MPRTP-RA-capable
endpoints can query the third-party component to obtain relay paths when
they want to establish MPRTP-RA session. Whether it is the server system or
the third party component, for simplicity sake, we call it controller below.
The controller is responsible for selecting one or multiple relay paths for
a media flow.
Considering the execution efficiency, the relay path is designed to be
unidirectional. A bidirectional media flow in a conversational use-case is
regarded as two independent unidirectional flows in opposite directions.
Relay paths are assigned for each unidirectional flow.
The sender and the RTP relay nodes need to know the relay path information
so they can correctly forward subflow data along a particular relay path. An
alternative approach, similar to source routing, is that the sender can
store the entire route in packet headers. Each intermediate node will simply
examine the headers of a received packet and forward it to the next node as
indicated in the source route. The advantage of the method is to simplify
the implementation of RTP relay nodes. They need not store any path
information and can perform routing of RTP packets only based on RTP
extension headers. But this method introduces traffic overhead considerably,
especially when the payload traffic is relatively small.
In practice, the sender and the RTP relay nodes need not to know the
complete information of the associated path. They just need to know the
next-hop transport address for each path associated with them. A pair of
transport address comprises one network address plus one port. During
assigning the relay paths for a media flow, the controller associates a
unique path identifier to each relay path and communicates with RTP relay
nodes to set the corresponding path information. When the controller is
located in server system, the next-hop transport addresses of the sender for
each relay paths and the associated path identifiers should be advertised to
the sender using a kind of out-of-band signaling (e.g., Session Description
Protocol (SDP) in Session Initiation Protocol (SIP), Real-Time Streaming
Protocol (RTSP)).
A RTP relay node performs packet lookups and forwarding based on Path-Table
which stores path information. The Path-Table contains a set of path entries
which can be added, updated and deleted by the controller via OpenPath
protocol. The controller is free to be implemented in any way, provided that
Leiwm, et al. Expires September 12, 2013 [Page 9]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
correct semantics of OpenPath protocol are preserved. For example, the
controller can be implemented as a function module of SIP server or a
standalone component.
The sender performs connectivity checks on multiple relay paths to ascertain
reachability before using them. If the path is reachable, then it is
referred to available path. According to the transmission requirements of
the current RTP session, the sender selects the default path and one or
multiple available relay paths as active paths among all the available paths
to transmit multimedia data to the receiver. The sender distributes the
packets across the active paths based on a scheduling strategy and
dynamically adjusts the load on each path. The receiver combines the
received subflows to recreate the original RTP session.
A multipath RTP session should be established before using multiple paths to
transport media flow. It can be set up in many possible ways e.g., during
session establishment, or at anytime during the session. To reduce media
startup time, endpoints can start transporting multimedia data via the
default path and then perform path connectivity checks for relay paths. If
there are one or multiple available relay paths, the endpoints update the
single path session to a multipath session.
For a multipath RTP session, each subflow appears as an independent RTP
flow. To monitor the transport quality of the path, the participants MUST
generate individual RTCP messages for per subflow. To maintain backward
compatibility with legacy applications, the participants MUST also send
aggregate RTCP packets along with the subflow specific RTCP packets.
Specifically, the participants generate aggregate RTCP following the normal
RTCP defined in RFC3550, and send them along the default path. Meanwhile,
the sender generates RTCP Sender Reports (SR) for each subflow and sends
them along the same path as the subflow RTP packets. The receiver responds
with a RTCP Receiver Report (RR) for each subflow, which is sent along the
default path.
7.1 Usage Scenario in SIP system
Figure 4 depicts a kind of usage scenario in which SIP is used as a separate
signaling to advertise relay paths information. In this case, two
participants are MPRTP-RA-capable.
Leiwm, et al. Expires September 12, 2013 [Page 10]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
+-----------------+
(1)INVITE | SIP Server | (3)INVITE
+---------------------->| --------------|------------------------+
| +-------------------| | Controller |<-------------------+ |
| | (6)200OK +-----------------+ (4)200OK | |
| | ^ ^ ^ | |
| | (2)(5) | |(2)(5) | (2)(5) | |
| V +-------+ V +------+ | V
+--------+ P-1/P-3 | +------------+ | P-1/P-3 +--------+
| User A |<---------|----->| RTP Relay-1|<-------|----------->| User B |
+--------+ | +------------+ | +--------+
^ | | ^
| V V |
| +------------+ +------------+ |
+--->| RTP Relay-2|<------------------->| RTP Relay-3|<-------+
P-2/P-4 +------------+ +------------+ P-2/P-4
Figure 4. Usage Scenario for Relay-based Multipath Transmission in SIP System
(1) User A sends the INVITE to the SIP server that serves her domain. SIP
server extracts the current addressable locations of the caller and the
callee, and the media information including media types and listed media
codecs. SIP server assigns the appropriate relay paths for the media flow
from user B to user A with the aid of a dedicated component named
controller.
(2) In this example, two relay paths assigned to the media flow from user B
to user A are (B, Relay-1, A) and (B, Relay-3, Relay-2, A), named P-1 and
P-2. And each relay path is associated with a globally unique path
identifier, separately named PID-1 and PID-2. The controller component sends
an AddPath request of OpenPath protocol to each of the three selected RTP
relay nodes. AddPath request includes the corresponding path identifier and
next-hop transport address of the receiving RTP relay node. For Relay-1, the
path identifier is PID-1 and the next-hop transport address is the current
addressable location of user A. For Relay-2, the path identifier is PID-2
and the next-hop transport address is the current addressable location of
user A.For Relay-3, the path identifier is PID-2 and the next-hop transport
address is Relay-2's IP address and relay service port.
(3) SIP server inserts the path identifiers and the next-hop transport
addresses of user B into SDP body of INVITE and forward the modified INVITE
to user B. The next-hop transport addresses of user B for P-1 and P-2 are
separately the rely address of Relay-1 and Relay-3.
(4) User B answers the call and sends back a 200 OK response. In the same
way, SIP server assigns the appropriate relay paths for the media flow from
user A to user B with the aid of the controller.
(5) In this example, the controller assigns the same relay paths with
Leiwm, et al. Expires September 12, 2013 [Page 11]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
opposite direction for the media flow from user A to user B based on
symmetry principle.They are separately (A, Relay-1, B) and (A, Relay-2,
Relay-3, B), named P-3 and P-4, associated with the path identifiers of
PID-3 and PID-4. The controller component sends an AddPath request of
OpenPath protocol to each of the three selected RTP relay nodes. For Relay-
1, the path identifier is PID-3 and the next-hop transport address is the
current addressable location of user B. For Relay-2, the path identifier is
PID-4 and the next-hop transport address is Relay-3's IP address and relay
service port. For Relay-3, the path identifier is PID-4 and the next-hop
transport address is the current addressable location of user B.
(6) SIP server inserts the path identifiers and the next-hop transport
addresses of user A into SDP body of 200 OK response and forwards it to user
A. The next-hop transport addresses of user A for P-3 and P-4 are separately
the rely address of Relay-1 and Relay-2.
(7) Through the signaling process above, user A and user B separately obtain
the information of candidate relay paths as the sending peer of the
corresponding media flow. After connectivity check, user A and user B take
advantage of multiple paths to transport the media flow.
8. MRTP Agent Behavior
Given multiple paths, MPRTP-RA and its companion control protocol, multipath
RTCP (MRTCP-RA), need to provide essential support for multipath media
transport, including session and path management, flow partitioning and
scheduling, subflow recombination, QoS feedback for each subflow as well as
payload type identification, sequence numbering, timestamping and delivery
monitoring.
8.1 MPRTP-RA session management
RTP is a session-oriented protocol. At the same way, a multipath RTP session
needs to be established before transporting data on multiple paths. The
multipath RTP session setup uses a way of out-of-band signaling (e.g., SDP
in SIP or RTSP). The capability exchange and relay path advertisement should
be done during the signaling process. A multipath RTP session may be setup
from the beginning, or may be upgraded from a typical single path RTP
session.
To be backward compatibility with legacy applications, a multipath RTP
session must look like a bundle of individual RTP sessions.
8.2 Path management
The sender gathers candidate paths from the out-of-band signaling for the
multipath RTP session setup. The default path is determined by the c= and m=
lines in SDP. It may be the direct network path between the sender and the
Leiwm, et al. Expires September 12, 2013 [Page 12]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
receiver, or may traverse a third-party node, such as a TURN server or a
dedicated relay server. For the latter, IP address and port of the third-
party node is in the c= and m= lines in SDP.
Candidate relay paths may change during a session. For example, a relay node
on the relay path fails during the session, or additional relay paths are
assigned for the session. The changes should be advertised to the sender by
the same way of out-of-band signaling.
The sender needs to perform path probes to determine if the path is
available and if so, obtains the transmission quality of the path at the
same time. After obtaining a new candidate path, the sender first performs
path probe process, if the path is available, marks it available and puts it
into the available path list ordered based on a decreasing priority level;
if the path is not available, marks it unavailable and puts it into the
unavailable path list. The sender will periodically perform path probes for
all the paths in available path list to actively detect path failure and
perceive the dynamic changes to the path. If the probe process for a
particular path fails, the path will be marked unavailable and removed from
the available path list to the unavailable path list. The sender should also
perform path probes for the paths in unavailable path list in a longer
cycle. If the probe process for a particular path successes, the path will
be marked available and removed from the unavailable path list to the
available path list.
If no media is received on a relay path within a given time, RTP relay nodes
will withdraw the corresponding resources allocated for this path.Therefore,
all the relay paths should be kept alive periodically. To meet this
requirement, the sender MUST multiplex the subflow specific RTP and RTCP
packets on the same port. On the one hand, the multiplexed RTCP packets can
be used to keep alive the relay path. This is in line with the
recommendation made in RFC6263. On the other hand, multiplexing RTP and RTCP
reduces the number of ports used by per multipath RTP session. For non-
active paths, the sender only needs to periodically send RTCP keepalive
packets.
When RTP and RTCP packets are multiplexed onto a single port, the RTCP
packet type field occupies the same position in the packet as the
combination of the RTP marker (M) bit and the RTP payload type (PT). This
field is used to distinguish RTP and RTCP packets. It is RECOMMENDED to
follow the guidelines in the RTP/AVP profile [RFC3551] for the choice of RTP
payload type values, with the additional restriction in RFC5761.
Using the information in the subflow reports, a sender can monitor active
paths for failure (e.g., errors, unreachability, and congestion). If failure
happens in an active path, the sender may perform flow repartitioning and
spread the RTP load across other active paths, or may select a new path from
the available path list to replace the failure path.
Leiwm, et al. Expires September 12, 2013 [Page 13]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
8.3 Flow partitioning and scheduling
This document does not limit the usage of multiple paths. The sender may
concurrently use multiple paths to obtain higher throughput, or may send all
traffic on a specified path while all other available paths are used only
rarely to enhance resilience (e.g., for retransmission, for error-repair, or
for redundancy packets). The sender MUST only use the default path and the
relay paths in available path list as the active path. How to select
multiple paths among all available paths and how many paths to use
concurrently are outside the scope of this document.
If multiple paths are used concurrently, the original multimedia stream
should be divided into several substreams. The partition may be done based
on media type, encoding scheme and path characteristics. Flow partitioning
methods are outside the scope of this document. An application should make
appropriate choices according to its own needs. Payload format
specifications for particular payload types should be developed to adapt
them to multipath transport. Here, we introduce several options for
reference only.
A simple flow partitioning scheme is to assign packets to multiple subflows
using the round-robin algorithm. Specifically, the original media stream is
first divided into blocks of equal-sized temporal length. Then, a subflow is
assembled by picking blocks periodically from the original blocks in an
increasing order. This method can be applied to both audio and video
formats. However, all the data are treated equally and not distinguished
based on their different importance in terms of decoded media quality.And
great correlations exist among subflows which are sent along paths with
different transport capacity.
Furthermore, a multistream coder using layered coding, multiple description
coding or object-oriented coding can produce multiple compressed media
flows. In layered coding, a flow is either the base layer or one of the
enhancement layers; in multiple description coding, a flow typically
consists of packets from a description; in object-oriented coding, various
objects are coded individually and placed in so-called elementary steams.
Each coding flow corresponds to a separate subflow, or several coding flows
are multiplexed into one subflow. Data participant in this way can
effectively reduce the correlations among subflows.
The sender should associate a subflow with an active path based on a
scheduling strategy. A scheduling policy should jointly consider various
factors including the estimated path bandwidth information, the path
reception statistics (e.g. RTT, loss-rate, delay etc.), the relative
importance of subflow data and so on. Due to the changes in path
characteristics, the sender should be able to change its scheduling strategy
during an ongoing session to fully explore the potential of multipath
transport.
Leiwm, et al. Expires September 12, 2013 [Page 14]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
8.4 Subflow recombination
A media receiver, irrespective of MPRTP-RA support or not, should be able to
process the media stream received from multiple paths correctly. A legacy
receiver just ignores the MPRTP-RA extension headers and follows the normal
process defined in RTP. A MPRTP-RA-capable receiver first restores the order
of each subflow using path identifier and subflow sequence numbers. It then
examines the head-of-line packets of the subflows and orders them according
to their timestamps and original flow sequence numbers. Therefore, the
multipath subflows appear as a single RTP stream to the existing up-level
applications which do not require changes.
8.5 Subflow RTP transmission
In a multipath RTP session, if multiple paths are used to send the media
stream, RTP packets MUST follow the subflow specific fields described in the
MPRTP-RA extension headers. Specifically, the subflow specific fields
include path identifier and subflow-specific sequence number. The
corresponding RTP header extension is shown in section 10.
A Path identifier, which is globally unique, is used to identify a specific
path by the sender and RTP relay nodes. Meanwhile, the path identifier in
RTP packets is also used to identify a subflow by the receiver. Apart from
normal RTP sequence numbers defined in RTP, the multipath sender MUST add
subflow-specific sequence numbers to help calculate fractional losses,
jitter, RTT, playout time, etc, for each path. The initial subflow sequence
number is randomly generated when the subflow is first established in the
MPRTP-RA session.
8.6 Subflow RTCP transmission
The participants generate aggregate RTCP reports to provide the overall
media statistics and follow the normal RTCP defined in [RFC3550]. Aggregate
RTCP reports are transmitted along the default path.
Meanwhile, the participants also generate individual RTCP reports for per
subflow to provide the per path media statistics. The sender generates RTCP
Sender Reports for each unique subflow and sends them along the same path as
the subflow RTP packets. The subflow specific RTP and RTCP packets are
multiplexed on a single port. As the relay path is unidirectional, the
receiver generates RTCP Receiver Reports for each unique subflow and sends
them along the default path. The aggregate and subflow-specific RTCP reports
MUST NOT be compounded as defined in RFC 5506.
Although subflow RTCP SRs and RRs are not sent along the same path, they
still can be used to measure round-trip propagation to the receiver along
different paths as defined in RFC3550. Since all subflow RTCP RRs are sent
along the default path, the calculated round-trip propagation delays can
Leiwm, et al. Expires September 12, 2013 [Page 15]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
correctly represent relative size of transmission delays of different paths.
In RTP, RTCP reports are transmitted at a low rate. This algorithm
effectively keeps the bandwidth used by RTCP to a relatively constant ratio
of the total session bandwidth. However, such a feedback rate may not be
frequent enough for the sender to quickly adapt to path fluctuation and
transmission errors. Timely RTCP reports are necessary for multipath
transport environments. The additional subflow RTCP reports MUST follow the
timing rules defined in RFC 4585 [5]. For point-to-point applications, since
the number of the participants is relatively small, subflow RTCP reports are
usually sent sufficiently frequently.
The RTCP reporting interval may be locally implemented and may depend on the
behavior of each path. For instance, the RTCP interval may be different for
an active path, an alternate path, and an unavailable path. Additionally, an
endpoint may decide to share the RTCP reporting bandwidth equally across all
its paths or schedule based on the rate on each path.
9. RTP Relay Behavior
A RTP relay node performs RTP/RTCP packet lookups and forwarding based on a
Path-Table. All the RTP Relay nodes are managed by a controller over
connections using a protocol referred to as OpenPath protocol.
9.1 Path-Table
The Path-Table contains a set of path entries each of which corresponds to
an associated relay path. Each path entry consists of match fields, result
fields and counters (see table 1).
Leiwm, et al. Expires September 12, 2013 [Page 16]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Table 1: Fields in a path entry.
+-------------------------------------+---------------------------+
| Fields | Bits |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Match fields |
+-----------------------------------------------------------------+
| Path Identifier | 32 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Result fields |
+-----------------------------------------------------------------+
| Next-hop transport address type | 8 |
+-------------------------------------+---------------------------+
| | For an IPv6 address, this |
|Next-hop transport IP address | is 128;for an IPv4 address|
| | , this is 32. |
+-------------------------------------+---------------------------+
| Next-hop transport port | 16 |
+-------------------------------------+---------------------------+
| Idle timeout | 16 |
+-------------------------------------+---------------------------+
| Hard timeout | 16 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Counters |
+-----------------------------------------------------------------+
| Received packets | 64 |
+-------------------------------------+---------------------------+
| Received bytes | 64 |
+-------------------------------------+---------------------------+
| Duration (seconds) | 32 |
+-------------------------------------+---------------------------+
| Duration (nanoseconds | 32 |
+-----------------------------------------------------------------+
Match fields are used to match against RTP/RTCP packets. Match fields only
consist of Path ID in this document.
Path ID: a 32 bit unsigned integer uniquely identifying the associated path.
Result fields include next-hop transport address and idle timeout. Next-hop
transport address is to determine where the matched packets are forwarded.
Type: corresponds to the type of the next-hop transport address. Namely:
1: IPv4 address
2: IPv6 address
IP Address: the address to which the relay node forwards the matched
packets.
Leiwm, et al. Expires September 12, 2013 [Page 17]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Port: the port number to which the relay node forwards the matched packets.
It is multiplexed by RTP and RTCP packets.
Counters are maintained for each path entry and updated for matching RTP
packets.
Received packets: the amount of packets the path has matched.
Received bytes: the amount of bytes the path has matched.
Duration: the amount of time the path has been installed in the RTP relay
node.
9.2 Connection Management
A RTP relay node communicates with the controller over a connection which
may be encrypted using TLS or run directly over TCP.
The RTP relay node initiates a standard TLS or TCP connection to the
controller. The RTP relay node can get the IP address of the controller in a
number of ways, such as manual configuration, DNS domain name queries and so
on.
When a connection is established, the RTP relay node immediately sends a
HELLO message to the controller. The relay ID field is set to the unique
identifier of the RTP relay node. The version field is set to the highest
OpenPath protocol version supported by the RTP relay node. The HELLO message
contains the IP address and port of the RTP relay node for the relay
service. Upon receipt of this message, the controller checks the included
OpenPath protocol version. If the version is not supported, the controller
responds to the HELLO with a failure response; otherwise, the controller
replies with a success response. The RTP relay node completes the
registration process by exchanging HELLO messages.
If a failure response to the HELLO message is received, the RTP relay node
then terminate the connection. Otherwise, the connection proceeds and the
RTP relay node may start relay service.
During the lifetime of the connection, Echo requests should be sent
periodically from either the RTP relay node or the controller, and the
request receiver must return an ECHO reply.
9.3 Relay Service Management
After receiving a success response to the HELLO message, the RTP relay node
may send a START message to the controller to indicate that it has enough
capacity to provide relay service.
In the case that the RTP relay node is overloaded, or under other some
situations, the RTP relay node may send a STOP message to the controller to
Leiwm, et al. Expires September 12, 2013 [Page 18]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
indicate that it will no longer receive new relay service requests (i.e.
ADD_PATH messages) for a while. During this period, the RTP relay node still
provides relay service for those existing relay paths. And ECHO messages
still need to be sent periodically between the RTP relay node and the
controller.When the RTP relay node recovers from an overloaded state, it may
send a START message to the controller to indicate that it has additional
capacities to provide new relay services.
When the RTP relay node wants to stop relay service permanently, it should
actively send a BYE message to the controller before terminating the
connection. In this way, the controller can be ready in time to do some
remedial measures. For instance, the controller may assign new relay paths
for the affected media flow.
9.4 Path Validity Management
Each path entry has an idle timeout and a hard timeout associated with it.
These two fields control how quickly a path entry expires. When a path entry
is inserted by an ADD_PATH request or modified by a UPDATE_PATH request, its
idle timeout and hard timeout are set with the values from the message.
If either value is non-zero, the RTP relay node must note the arrival time
of RTP/RTCP packet on the associated path, as it may need to evict the path
entry later. A non-zero hard timeout field causes the path entry to be
removed after the given number of seconds, regardless of how many packets it
has matched. A non-zero idle timeout field causes the path entry to be
removed when it has matched no packets in the given number of seconds. Using
these two fields, the RTP relay node can actively clear those expired path
entries. In addition, the controller may actively remove path entries by
sending DELETE_PATH messages.If the RTP relay node actively removes a path
entry, it must send a NOTIFY message to the controller. The NOTIFY message
contains a complete description of the path entry including the reason for
removal, the path entry duration and statistics at the time of removal.
9.5 Query Messages Processing
After connection establishment, the RTP relay node may receive Feature
requests from the controller to provide capabilities information. The RTP
relay node must respond with a Feature reply that specifies its
capabilities.
During the lifetime of the connection, the controller may periodically
collect statistics from a RTP relay node by sending STATISTICS requests. The
RTP relay node must respond with a Statistics reply that specifies its
current statistics.
9.6 Path-Table Modification Messages Processing
Leiwm, et al. Expires September 12, 2013 [Page 19]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Path-Table in the RTP relay node is managed by the controller through Path-
Table modification messages. This document defines three Path-Table
modification message types: ADD_PATH for inserting a new path entry,
DELETE_PATH for removing an existing path entry, and UPDATE_PATH for
modifying an existing path entry.
For ADD_PATH requests, the RTP relay node must first check if any path entry
with the same path identifier has existed in the Path-Table. If an overlap
conflict exists between an existing path entry and the ADD_PATH request, the
RTP relay node must refuse the addition and respond with a failure response.
For valid ADD_PATH requests, the RTP relay node must insert a new path entry
in the Path-Table and respond to the controller with a success response. The
counters of received packets and received bytes in the new inserted entry
are set to zero.
For DELETE_PATH requests, if a matching entry exists in the Path-Table, it
must be removed, and a success response is returned to the controller. For
DELETE_PATH requests, if no path entry matches, no path entry modification
occurs, and a failure response is returned to the controller.
For UPDATE_PATH requests, if a matching entry exists in the Path-Table, the
result fields of this entry is updated with the value from the request, and
counter fields are left unchanged. For UPDATE_PATH requests, if no path
entry matches, no path entry modification occurs, and a failure response is
returned to the controller.
9.7 RTP/RTCP Packet Processing
The main function of RTP relay node is to provide media relay service to the
associated subflows. All subflows associated with a RTP relay node share a
common relay port of the RTP relay node.
On receiving a data packet, RTP relay node first distinguishes whether it is
a RTP packet or a RTCP packet. Then RTP relay node extracts the path ID from
the appropriate position in the packet and does matching in the Path-Table.
If the received packet does not match a path entry in the Path-Table, RTP
relay node should drop the packet. If the received packet matches a path
entry in the Path-Table, RTP relay node forwards it to the associated next-
hop transport address in the matched path entry. Meanwhile, RTP relay node
updates the associated statistical counters in the matched path entry.
If the received packet is a RTCP probe packet, RTP relay node needs to do
some special handling before forwarding it to the associated next-hop
transport address. In this case, RTP relay node generates a Relay Node block
and appends it to the received RTCP probe packet.
10. OpenPath Protocol
Leiwm, et al. Expires September 12, 2013 [Page 20]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
The controller is implementation-specific. However, between the controller
and the RTP relay node, all messages MUST be formatted according to the
OpenPath protocol.
10.1 Protocol Overview
OpenPath is based on a request/response transaction model. Each transaction
consists of a request and a response. A response uses the same transaction
id as is in the associated request to facilitate pairing. The transaction id
is a 32-bit identifier generated by the request sender.
All OpenPath messages begin with a common OpenPath header. OpenPath messages
MAY contain a body. The structure and interpretation of a body depends on
the message type.
OpenPath messages are guaranteed delivery over a connection-oriented
channel. All integer fields are carried in network octet order, that is,
most significant byte first. Octets designated as padding have the value
zero.
OpenPath message types fall into three classes: relay-to-controller,
controller-to-relay and symmetric. Relay-to-controller messages are
initiated by the RTP relay node and used to manage the channel connection
and update the controller of changes to the RTP relay node. Controller-to-
relay messages are initiated by the controller and used to manage the Path-
Table or inspect the state of the RTP relay node. Symmetric messages are
initiated by either the controller or the RTP relay node. The message types
used by OpenPath are described below.
10.1.1 Relay-to-Controller
Relay-to-Controller messages are initiated by the controller and require a
response from the controller.
HELLO: The RTP relay node registers with the controller by sending a HELLO
request. The HELLO request contain the unique identifier of the RTP relay
node, the highest OpenPath protocol version supported by the RTP relay node,
and the IP address and port of the RTP relay node for the relay service. The
controller must respond with a HELLO response that indicates the outcome of
registration. This is commonly performed upon establishment of the OpenPath
connection channel.
START: The RTP relay node starts relay service by sending a START request.
The controller must respond with a START response that indicates the
outcome of relay service startup.
STOP: The RTP relay node may stop relay service temporarily by sending a
STOP request. For instance, when the RTP relay node is overloaded, it may
Leiwm, et al. Expires September 12, 2013 [Page 21]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
want to refuse accepting any new relay service requests for a while. The
controller must respond with a STOP response that indicates the outcome of
relay service pause. During relay service pause, the RTP relay node still
provides relay service for those existing relay paths. The RTP relay node
may restart relay service by sending a START request after a while.
BYE: The RTP relay node may terminate the relay service permanently by
sending a BYE request, such as before terminating the OpenPath connection
channel or exiting. Meanwhile, the RTP relay node ceases relay service for
all existing relay paths. If the RTP relay node wants to start relay service
again, it must first perform registration with the controller.
NOTIFY: When the RTP relay node actively removes a path entry, it may notify
the controller by sending a NOTIFY request. For instance, in order to save
the resource, the RTP relay node actively removes those path entries which
lack activity.
10.1.2 Controller-to-Relay
Controller-to-Relay messages are initiated by the controller and require a
response from the RTP relay node.
FEATURES: The controller may request the capabilities of a RTP relay node by
sending a FEATURES request. The RTP relay node must respond with a FEATURES
response that specifies the capabilities of the RTP relay node. This is
commonly performed after successful registration of the RTP relay node.
STATISTICS: The controller may periodically collect statistics from the RTP
relay node by sending STATISTICS requests. The RTP relay node must respond
with a STATISTICS response that specifies current statistics of the RTP
relay node.
ADD_PATH: When the controller needs to assign relay paths for a media flow,
the controller must send an ADD_PATH request to each RTP relay node on the
assigned relay path. The RTP relay node must respond with an ADD_PATH
response that specifies the outcome of adding a new path entry. A relay path
is assigned successfully only when each RTP relay node replies with an
ADD_PATH success response.
UPDATE_PATH: The controller may want to modify an existing path entry in the
Path-Table of a RTP relay node by sending a UPDATE_PATH request. For
instance, a media stream may be "put on hold" and transmission of media
may be ceased for a while. In this case, the controller may update the idle
timeout and hard timeout of the corresponding path entries of all the RTP
relay nodes on the affected relay paths to a longer time. The RTP relay node
must respond with an UPDATE_PATH response that specifies the outcome of
updating an existing path entry.
Leiwm, et al. Expires September 12, 2013 [Page 22]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
DELETE_PATH: The controller may delete an existing path entry in the Path-
Table of a RTP relay node by sending a DELETE_PATH request, such as when a
media stream ends normally. The RTP relay node must respond with a
DELETE_PATH response that specifies the outcome of deleting an existing path
entry.
10.1.3 Symmetric
Symmetric messages are sent in either direction.
ECHO: Echo requests MUST be sent periodically from either the controller or
the RTP relay node. And the receiver must return an ECHO response. ECHO
messages can be used to measure the latency of a controller-relay
connection, as well as verify the peer's liveness. The receiver of an ECHO
request must respond with an ECHO response, which consists of an OpenPath
header plus the unmodified body of an ECHO request message.
10.2 Common Structures
This section describes structures used by multiple messages.
10.2.1 OpenPath Common Header
Common OpenPath header is defined below:
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 |R|S| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (V): 6 bits
This field identifies the version of OpenPath protocol version being
used.The version defined by this document is one (1).
R: 1 bit
If the R bit is set, the message is an OpenPath request; otherwise, the
message is an OpenPath response.
S: 1 bit
When the message is a request, this bit is reserved. When the message is
a response, if the S bit is set, the message is a success response;
otherwise, the message is a failure response.
Leiwm, et al. Expires September 12, 2013 [Page 23]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Type: 8 bits
This field identifies the type of the OpenPath messages. This document
defines 11 OpenPath message types:
+----------------------------------------------------------------+
| Type Value | Type Name | Sending Direction |
+--------------+---------------+---------------------------------+
| 1 | HELLO | RTP relay -> Controller |
+--------------+---------------+---------------------------------+
| 2 | BYTE | RTP relay -> Controller |
+--------------+---------------+---------------------------------+
| 3 | ECHO | RTP relay -> Controller or |
| | | Controller -> RTP relay |
+--------------+---------------+---------------------------------+
| 4 | START | RTP relay -> Controller |
+--------------+---------------+---------------------------------+
| 5 | STOP | RTP relay -> Controller |
+--------------+---------------+---------------------------------+
| 6 | NOTIFY | RTP relay -> Controller |
+--------------+---------------+---------------------------------+
| 7 | FEATURES | Controller -> RTP relay |
+--------------+---------------+---------------------------------+
| 8 | STATISTICS | Controller -> RTP relay |
+--------------+---------------+---------------------------------+
| 9 | ADD-PATH | Controller -> RTP relay |
+--------------+---------------+---------------------------------+
| 10 | DETELE-PATH | Controller -> RTP relay |
+--------------+---------------+---------------------------------+
| 11 | UPDATE-PATH | Controller -> RTP relay |
+----------------------------------------------------------------+
Length: 16 bits
The length field indicates the total length of the message in 32-bit
words including the header and any padding.
Relay ID: 32 bits
This field is a 32-bit identifier that corresponds to a globally unique
RTP relay node. It is generated by the RTP relay node when it startups,
and remains unchanged during the entire lifecycle of the RTP relay node.
Transaction ID: 32 bits
This field identifies the transaction id associated with this message. It
is randomly generated by the request sender and discarded when the
associated response message is received. The transaction ids of responses
must always match the request that prompted them.
10.2.2 Common Body of OpenPath Failure Responses
Leiwm, et al. Expires September 12, 2013 [Page 24]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
OpenPath failure responses of all message types MAY contain an optional body
after the common OpenPath header. If the body is present, it conforms to a
common structure defined below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status code | Rlength | reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status code: 8 bits
This field is a numeric result code that indicates the outcome of a
request processing.
Rlength: 8 bits
This field is the length of the reason phrase in 16-bit word length.
Reason: variable size
This field is a short textual description of the status code.
10.2.3 Transport Address Structure
A RTP relay node needs to advertise the controller about its transport
address for relay service. The controller also needs to tell the RTP relay
node about the transport address of its next-hop node for each associated
path. A transport address is defined as follow.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Pad(0) | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 8 bits
This field is the type of transport address. Namely:
1: IPv4 address
2: IPv6 address
Port: 16 bits
This field is the port number part of transport address.
Address: 4 octets (IPv4), 16 octets (IPv6)
Leiwm, et al. Expires September 12, 2013 [Page 25]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
The IP address part of transport address.
10.3 OpenPath Request and Success Response Message Format
10.3.1 HELLO
The HELLO request contains a body beyond a common OpenPath header. The body
contains the transport address of the RTP relay node to provide relay
service.
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 |R|S| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Pad(0) | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HELLO success response only contains a common OpenPath header.
10.3.2 START/STOP/BYE
The START/STOP/BYE requests and their success responses have no body; that
is, they only contain a common OpenPath header.
10.3.3 ECHO
An ECHO request consists of a common OpenPath header and an optional body.
If the body is absent, the ECHO request/response messages are used to simply
verify liveness between the controller and the RTP relay node. The body may
contain a timestamp to check latency between the controller and the RTP
relay node. Example:
Leiwm, et al. Expires September 12, 2013 [Page 26]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
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 |R|S| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp,least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP timestamp: Using the timestamp format of the Network Time Protocol
(NTP), which is in seconds relative to 0h UTC on 1 January 1900 [RFC1305].
The full resolution NTP timestamp is a 64-bit unsigned fixed-point number
with the integer part in the first 32 bits and the fractional part in the
last 32 bits.
10.3.4 NOTIFY/DELETE_PATH
The NOTIFY/DELETE_PATH requests contain a body beyond a common OpenPath
header. The body only contains a Path ID field.
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 |R|S| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path ID: 32 bits
This field is a 32-bit identifier that corresponds to a globally unique
path. It is generated by the controller when assigning relay paths for a
media flow.
The NOTIFY/DELETE_PATH success responses only contain a common OpenPath
header.
10.3.5 FEATURES
Leiwm, et al. Expires September 12, 2013 [Page 27]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
The FEATURES request only contains a common OpenPath header.
The FEATURES success response contains a body beyond the common OpenPath
header.
(to be continued)
10.3.6 STATISTICS
The STATISTICS request only contains a common OpenPath header.
The STATISTICS success response contains a body beyond the common OpenPath
header.
(to be continued)
10.3.7 ADD-PATH/ UPDATE_PATH
The ADD-PATH/ UPDATE_PATH requests contain a body beyond a common OpenPath
header. The body contains match fields and result fields of a path entry.
The result fields contain next-hop transport address and idle/hard timeout.
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 |R|S| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Pad(0) | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Idle timeout | Hard timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Idle timeout: 16 bits
This field is the number of seconds after which the path will timeout if
no traffic.
Hard timeout: 16 bits
This field is the number of seconds after which the path must expire
regardless of whether or not packets go through the path.
The ADD-PATH/ UPDATE_PATH success responses only contain a common OpenPath
header.
11. MPRTP-RA Packet Formats
Leiwm, et al. Expires September 12, 2013 [Page 28]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
In this section we define the RTP/RTCP protocol structures to meet the
requirements described in the previous sections.
11.1 RTP Header Extension for MPRTP-RA
The MPRTP-RA header extension is used to distribute a single RTP stream over
multiple subflows which are transmitted along different paths.
The header conforms to the one-byte RTP header extension defined in [9]. 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 [1] for details).
The RTP header for each subflow is defined below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPID | LEN | reserved | MPRTP-RA header data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPID:This field corresponds to the type of MPRTP-RA packet.Namely:
+----------------------------------------------------------------+
| MPID value | Use |
+--------------+-------------------------------------------------+
| 0x01 | Subflow RTP header. For this case the LEN |
| | is set to 6. |
+--------------+-------------------------------------------------+
LEN:
This field is the number that minus one of extension data bytes following
the one-byte header.
MPRTP-RA header data:
This field carries the MPID specific data as described in the following
sub-sections.
Leiwm, et al. Expires September 12, 2013 [Page 29]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
11.1.1 MPRTP-RA RTP Extensions for a Subflow
The RTP header for each subflow is defined below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 | LEN=6 | reserved | Subflow-specific Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPID=0x1:
This field indicates that the MPRTP-RA header extension carries subflow
specific information.
Subflow-Specific Sequence Number (SSSN):
This field is sequence of the packet in the subflow. Each subflow has its
own strictly monotonically increasing sequence number space.
Path ID:
This field is identifier of the path as well as the subflow. Every RTP
along the same path carries the same unique path identifier.
11.2 RTCP Extension for MPRTP-RA (MPRTCP-RA)
The RTCP header extension for MPRTP-RA is used to 1) provide RTCP feedback
of per subflow to determine the characteristics of each path, 2) probe the
transport capability of each path, and 3) keep alive each path.
Leiwm, et al. Expires September 12, 2013 [Page 30]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
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-RA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of the first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MPRTCP-RA Type | block length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MPRTCP-RA data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PT=MPRTCP-RA=211:
This field identifies that it is a Multipath RTCP packets.
MPRTCP-RA Type: 8 bits
This field corresponds to the type of MPRTP-RA RTCP packet. Namely:
+---------------------------------------------------------------+
|MPRTCP-RA Type value | Use |
+---------------------+-----------------------------------------+
| 0 | Subflow Specific Report |
+---------------------+-----------------------------------------+
| 1 | Path Probe |
+---------------------+-----------------------------------------+
| 2 | Keep Alive |
+---------------------+-----------------------------------------+
block length: 8 bits
This field is the length of the encapsulated MPRTCP-RA data in 16-bit word
length following block length field. The value zero indicates there is no
data following.
MPRTCP-RA data: variable size
This field will be defined later in the following sub-sections.
11.2.1 MPRTCP-RA Extensions for Subflow Reporting (SR/RR)
When sending a report for a specific subflow the sender or receiver MUST add
only the reports associated with that path. Each subflow is reported
independently using the following MPRTCP-RA Feedback header.
Leiwm, et al. Expires September 12, 2013 [Page 31]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
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-RA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of the first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | block length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | block length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subflow-specific reports |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPRTCP-RA Type=0
The value indicates that the encapsulated block is a subflow report.
Path ID: 32 bits
This field is the identifier of the path associated with the subflow that
the endpoint is reporting about.
Subflow-specific reports: variable
Subflow-specific report contains all the reports associated with the path
ID. For a sender, it MUST include a Subflow-specific Sender Report (SSR).
For a receiver, it MUST include a Subflow-specific Receiver Report (SRR).
Additionally, if the receiver supports subflow-specific extension reports
then it MUST append them to the SRR.
An example of SSR is shown below:
Leiwm, et al. Expires September 12, 2013 [Page 32]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
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-RA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of the first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | block length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.2.2 MPRTCP-RA Extensions for Subflow Path Probe
The Relay Node block describes a method to represent capacity information of
the relay node in a block format.
(to be continued)
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-RA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of the first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |block length=3 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPRTCP-RA Type=1
The value indicates that the encapsulated block is a subflow path probe.
Leiwm, et al. Expires September 12, 2013 [Page 33]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
11.2.3 MPRTCP-RA Extensions for Subflow Keep Alive
This sub-section defines the RTCP header extension for keeping alive a relay
path.
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-RA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of the first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |block length=3 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPRTCP_Type=2
The value indicates that the encapsulated block is a subflow Keep Alive.
Path ID: 32 bits
This field is the identifier of the path that the endpoint is keeping
alive.
12. SDP Considerations
The indication of the presence of the RTP header extension, and the
advertisement of MPRTP-RA capability and relay paths, MUST be performed out-
of-band, for example, as part of a SIP offer/answer exchange using SDP. This
section defines dedicated extensions in SDP. SDP syntax and procedures are
available that can be re-used or easily adapted to provide the necessary
capabilities.
12.1 Signaling MPRTP-RA Header Extension in SDP
The RTP header extensions (see Section 11) which used in a MPRTP-RA session
need to be signaled in the out-of-band signaling during session setup. As
defined in RFC5285, the sender MUST use the following URI in extmap:
urn:ietf:params:rtp-hdrext:mprtp-relay. This is a media level parameter.
Legacy RTP clients will ignore this header extension.
Example:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
Leiwm, et al. Expires September 12, 2013 [Page 34]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
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-relay
12.2 Signaling MPRTP-RA Capability in SDP
A MPRTP-RA-capable participant of a media session MUST use SDP to indicate
that it supports MPRTP-RA. The mprtp-relay attribute defined here will be
used to indicate the support for MPRTP-RA. The syntax of the mprtp-relay
attribute is defined using the following Augmented BNF, as defined in
[RFC5234].
mprtp-relay-attrib = "a=" "mprtp-relay" CRLF ; flag to enable MPRTP-RA
The endpoint MUST use "a=mprtp-relay" if it supports MPRTP-RA and would
like to use it in the specific media session being signaling. The mprtp-
relay attribute is a media level parameter.
A MPRTP-RA-capable sender multiplexes RTP and RTCP packets of each subflow
on a single port. To be compatible with legacy endpoints, the MPRTP-RA-
capable endpoint MUST indicate support of multiplexing by adding "a=rtcp-
mux" in SDP [RFC5761]. When an MPRTP-RA-capable endpoint receives an SDP
containing "a=mprtp-relay" but without "a=rtcp-mux", the endpoint MUST
infer that the peer, if as a sender, supports multiplexing of RTP and RTCP
packets.
The MPRTP-RA-capable sender MAY use multiple paths concurrently to increase
throughput. If the desired media rate exceeds the current media rate, the
MPRTP-RA-capable sender MUST renegotiate the application specific
("b=AS:xxx") [RFC4566] bandwidth.
12.3 Relay Path Advertisement in SDP
The information of candidate relay paths MUST be advertised to the sender in
the out-of-band signaling. The relay-path attribute is extended to advertise
candidate relay paths in SDP. The syntax of the mprtp-relay attribute is
defined using the following Augmented BNF, as defined in [RFC5234]. The
definitions of DIGIT, SP and CRLF are according to RFC4234.
relay-path-attrib = "a=" relay-path-label ":" counter SP path-id SP
transport-address CRLF
relay-path-label = "relay-path"
counter = 1*DIGIT
path-id = 32token-char
transport-address = addrtype ":" unicast-address ":" port
Leiwm, et al. Expires September 12, 2013 [Page 35]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
; addrtype from RFC4566, typically "IP4" | "IP6"
; port from RFC4566
unicast-address = IP4-address / IP6-address
; IP4-address from RFC4566
; IP6-address from RFC4566
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-
7E
The path identifier and the next-hop transport address of the sender for
each candidate relay path is encapsulated in a relay-path attribute.
The <counter> parameter indicates the priority of the associated relay path
and it is a monotonically increasing positive integer starting at 1. Number
1 is the highest priority. The counter must be reset for each media line.
The relay-path attributes are ordered based on a decreasing priority level.
The <path-id> parameter indicates the path identifier of the associated
relay path.
The <transport-address> is the next-hop transport address of the sender for
associated candidate relay path. The <addrtype> is the address type. This
document only defines IP4 and IP6 for IPv4 addresses and IPv6 addresses
respectively.
Example:
a=relay-path:1 1a3b6c9d0e2f6g1qazxsw23edcvfr45t IP4/192.0.3.2/10000
12.4 Offer/Answer
When SDP is used to negotiate MPRTP-RA sessions following the offer/answer
mode [RFC3264], the "mprtp-relay" attribute indicates the desire to
transport media flow on multiple paths. If the offerer wishes to use MPRTP-
RA, it MUST include a media-level "a=mprtp-relay" attribution in the
initial SDP offer. If the answerer wishes to use MPRTP-RA, it MUST include
this attribute in the answer.
Even if the other party does not support MPRTP-RA, the offerer or the
answerer can still unilaterally enable MPRTP-RA which is backwards
compatible.
When SDP is used in a declarative manner, the "mprtp-relay" attribute
indicates that the message sender can send or receive media data over
multiple paths. The message receiver SHOULD be capable to stream media to
multiple paths or be prepared to receive media from multiple paths.
The following sub-section shows an example of SDP offer and answer to
negotiate MPRTP-RA sessions.
Leiwm, et al. Expires September 12, 2013 [Page 36]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
12.4.1 An Example
We take the usage scenario shown in Figure 4 in Section 7.1 as an example.
In this example, both the endpoints are MPRTP-RA capable.
User A includes an initial SDP offer in the session invitation message. The
initial SDP offer is shown as following.
Initial Offer:
v=0
o=alice 2890866901 2890866902 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 39160 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E
a=rtcp-mux
a=mprtp-relay
When the invitation message is processed by the server system, two candidate
relay paths are assigned for the media flow from user B to user A. The
initial SDP offer in the session invitation message is modified as shown
below. The IP addresses of RTP relay-1/relay-2/relay-3 are 192.0.3.1,
192.0.4.1 and 192.0.5.1 respectively.
Modified Offer:
v=0
o=alice 2890866901 2890866902 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 39160 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E
a=rtcp-mux
a=mprtp-relay
a=relay-path:1 1a3b6c9d0e2f6g1qazxsw23edcvfr45t IP4/192.0.3.1/10000
a=relay-path:2 0o9i8u7y6t5r4e3w2q0okm9ijn8uhb7y IP4/192.0.5.1/10000
If User B accepts the invitation, it includes an initial SDP answer in the
session reply message. The initial SDP answer is shown as following.
Initial Answer:
v=0
o=bob 2890866903 2890866904 IN IP4 192.0.6.1
s=
c=IN IP4 192.0.6.1
Leiwm, et al. Expires September 12, 2013 [Page 37]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
t=0 0
m=video 36120 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=mprtp-relay
When the relay message is processed by the server system, two candidate
relay paths are assigned for the media flow from user A to user B. The
initial SDP answer in the session invitation message is modified as shown
below.
Modified Answer:
v=0
o=bob 2890866903 2890866904 IN IP4 192.0.6.1
s=
c=IN IP4 192.0.6.1
t=0 0
m=video 36120 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=mprtp-relay
a=relay-path:1 2w3e4r5t6y7u8i9o0p1q2wsx3edc4rfv IP4/192.0.3.1/10000
a=relay-path:2 4r5t6y7u8i9o0p1q2w3e4rfv5tgb6yhn IP4/192.0.4.1/10000
13. IANA Considerations
The following contact information shall be used for all registrations in
this document:
Contact: Weimin Lei
mailto:leiweimin@ise.neu.edu.cn
tel:+86-24-8368-3048
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.
13.1 MPRTP-RA Header Extension
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:
Extension URI: urn:ietf:params:rtp-hdrext:mprtp-relay
Description: Multipath RTP based on relay
Reference: RFC XXXX
Leiwm, et al. Expires September 12, 2013 [Page 38]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
13.2 MPRTCP-RA Packet Type
A new RTCP packet format has been registered with the RTCP Packet type (PT)
Registry:
Name: MPRTCP-RA
Long name: Multipath RTCP base on Relay Application
Value: 211
Reference: RFC XXXX.
This document defines a substructure for MPRTCP-RA packets. A new
sub-registry has been set up for the sub-report block type (MPRTCP-RA Type)
values for the MPRTCP-RA packet, with the following registrations created
initially:
Name: Subflow Specific Report
Long name: Subflow Specific Report for Multipath RTP based on Relay
Application
Value: 0
Reference: RFC XXXX.
Name: Path Probe
Long name: Path Probe for Multipath RTP based on Relay Application
Value: 1
Reference: RFC XXXX.
Name: Keep Alive
Long name: Keep Alive for Multipath RTP based on Relay Application
Value: 2
Reference: RFC XXXX.
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 [RFC4566] apply.
13.3 SDP Attributes
In the registry for SDP parameters, the attributes named "mprtp-relay" and
"relay-path" have been registered as follows:
SDP Attribute ("att-field"):
Attribute Name: mprtp-relay
Long form: Multipath RTP based on Relay Application
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: This attribute is used to indicate support for
Multipath RTP based on Relay Application.
Leiwm, et al. Expires September 12, 2013 [Page 39]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
Reference: See this document
Values: See this document.
SDP Attribute ("att-field"):
Attribute Name: relay-path
Long form: Relay Path of Multipath RTP based on Relay
Application
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: This attribute is used to describe the path
identifier and the next-hop transport address of the
sender for a relay path.
Reference: See this document
Values: See this document.
14. Security Considerations
TBD
All drafts are required to have a security considerations section. See RFC
3552 [13] for a guide.
15. References
15.1 Normative References
[1] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July
2003.
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended
RTP Profile for Real-time Transport Control Protocol (RTCP)-Based
Feedback (RTP/AVPF)", RFC 4585, July 2006.
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", STD 68, RFC 5234, January 2008.
[7] Singer, D. and H. Desineni, "A General Mechanism for RTP Header
Extensions", RFC 5285, July 2008.
Leiwm, et al. Expires September 12, 2013 [Page 40]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
[8] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time
Transport Control Protocol (RTCP): Opportunities and Consequences", RFC
5506, April 2009.
[9] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control
Packets on a Single Port", RFC 5761, April 2010.
15.2 Informative References
[10] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Streaming Protocol
(RTSP)", RFC2326, April 1998.
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson,
J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session
Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description
Protocol", RFC 4566, July 2006.
[15] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January
2008.
[16] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive
the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP)
Flows", RFC 6263, June 2011.
Authors' Addresses
Weimin Lei
Northeastern University
Institute of Communication and Information System
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China
Phone: +86-24-8368-3048
Email: leiweimin@ise.neu.edu.cn
Wei Zhang
Northeastern University
Institute of Communication and Information System
Leiwm, et al. Expires September 12, 2013 [Page 41]
Internet-Draft MPRTP: Multipath RTP based on RTP Relay Application Mar 2013
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China
Email: zhangwei1@ise.neu.edu.cn
Shaowei Liu
Northeastern University
Institute of Communication and Information System
College of Information Science and Engineering
Shenyang, China, 110819
P. R. China
Email: liushaowei@research.neu.edu.cn
Leiwm, et al. Expires 2013 [Page 42]
