One document matched: draft-singh-mmusic-mprtp-sdp-extension-02.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-avtcore-mprtp PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-avtcore-mprtp.xml">
<!ENTITY I-D.keranen-mmusic-ice-address-selection PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.keranen-mmusic-ice-address-selection.xml">
<!ENTITY I-D.ivov-mmusic-trickle-ice PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ivov-mmusic-trickle-ice.xml">
<!ENTITY I-D.ivov-mmusic-trickle-ice-sip PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ivov-mmusic-trickle-ice-sip.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="yes" ?>
<!-- sort the reference entries alphabetically -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-singh-mmusic-mprtp-sdp-extension-02" 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 in SDP">Multipath RTP (MPRTP) attribute in
Session Description Protocol</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Varun Singh" initials="V" surname="Singh">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>varun@comnet.tkk.fi</email>
<uri>http://www.netlab.tkk.fi/~varun/</uri>
</address>
</author>
<author fullname="Joerg Ott" initials="J" surname="Ott">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>jo@comnet.tkk.fi</email>
</address>
</author>
<author fullname="Teemu Karkkainen" initials="T" surname="Karkkainen">
<organization>Aalto University</organization>
<address>
<postal>
<street>School of Science and Technology</street>
<street>Otakaari 5 A</street>
<city>Espoo</city>
<region>FIN</region>
<code>02150</code>
<country>Finland</country>
</postal>
<email>teemuk@comnet.tkk.fi</email>
</address>
</author>
<author fullname="Ralf Globisch" initials="R" surname="Globisch">
<organization>Fraunhofer HHI</organization>
<address>
<postal>
<street>Einsteinufer 37</street>
<city>Berlin</city>
<code>D-10587</code>
<country>Germany</country>
</postal>
<email>ralf.globisch@gmail.com</email>
</address>
</author>
<author fullname="Thomas Schierl" initials="T" surname="Schierl">
<organization>Fraunhofer HHI</organization>
<address>
<postal>
<street>Einsteinufer 37</street>
<city>Berlin</city>
<code>D-10587</code>
<country>Germany</country>
</postal>
<phone>+49-30-31002-227</phone>
<email>ts@thomas-schierl.de</email>
</address>
</author>
<date year="2013" />
<!-- <area>RAI</area> <workgroup>AVT Working
Group</workgroup> -->
<area>Internet Engineering Task Force</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>RTCP</keyword>
<keyword>multipath</keyword>
<keyword>streaming</keyword>
<abstract>
<t>Multipath RTP (MPRTP) is an extension to the Real-time Transport
Protocol (RTP) that allows multi-homed endpoints to take advantage of
the availability of multiple Internet paths between endpoints to
send/receive media packets. This document describes how to express the
interface advertisement and negotiation during session setup in SDP
(Session Description Protocol).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.singh-avtcore-mprtp">Multipath RTP (MPRTP)</xref>
is an extension to <xref target="RFC3550">RTP</xref> that allows
splitting a single RTP stream into multiple subflows, which are then
transmitted over different Internet paths. <xref
target="I-D.singh-avtcore-mprtp">Multipath RTCP (MPRTCP)</xref> is an
extension to RTCP. It is used along with MPRTP to report per-path
sender and receiver characteristics.</t>
<t>A Multipath RTP 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 using in-band signaling (e.g., in <xref
target="I-D.singh-avtcore-mprtp">RTCP</xref>).</t>
<t>This document defines an extension to the SDP attribute 'a=mprtp'
defined in the <xref target="I-D.singh-avtcore-mprtp">base MPRTP
specification</xref>. Using this extension an endpoint can advertise
its multiple interfaces.</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> The definitions for the words Endpoint, Interface, Path and Subflow
in this document are as per <xref target="I-D.singh-avtcore-mprtp"
/>.</t>
</section>
</section>
<section anchor="sec-mprtp-sdp" title="SDP Considerations">
<t>The <xref target="I-D.singh-avtcore-mprtp" >base Multipath RTP
specification</xref> defines the 'a=mprtp' attribute to indicate
support for MPRTP. In the following section, we extend the
'a=mprtp' attribute to advertise an endpoint's multiple interfaces in
SDP instead of advertising the interfaces <xref
target="I-D.singh-avtcore-mprtp" >in-band in RTCP</xref>.</t>
<section title="MPRTP Interface Advertisement in SDP (out-of-band
signaling)" anchor="mprtp-sdp-ia-sdp">
<t>If the endpoint is aware of its multiple interfaces and wants to use
them for MPRTP, it MAY use SDP to advertise these interfaces.
Alternatively, it MAY use in-band signaling to advertise its
interfaces, as defined in <xref target="I-D.singh-avtcore-mprtp" />.
The receiving endpoint MUST use the same mechanism to respond to an
interface advertisement. In particular, if an endpoint receives an SDP
containing multiple MPRTP interfaces, then it MUST respond to the offer
in SDP with its set of MPRTP interfaces.</t>
<section title=""interface" attribute"
anchor="mprtp-sdp-ice-mprtp-interface-attribute">
<t>The interface attribute is an optional media-level attribute and
is used to advertise an endpoint's interface address.</t>
<!--TODO: optional in small or caps -->
<t>The syntax of the interface attribute is defined using the
following Augmented BNF, as defined in <xref target="RFC5234" />.
The definitions of unicast-address, port, token, SP, and CRLF are
according to <xref target="RFC4566">RFC4566</xref>.</t>
<figure>
<artwork><![CDATA[
mprtp-optional-parameter = mprtp-interface
; other optional parameters may be added later
mprtp-interface = "interface" ":" counter SP unicast-address
":" rtp_port
*(SP interface-description-extension)
counter = 1*DIGIT
rtp_port = port ;port from RFC4566
]]></artwork>
</figure>
<t><mprtp-interface>: specifies one unicast IP address, the RTP
port number of the endpoint (<xref target="I-D.singh-avtcore-mprtp"
>MPRTP</xref> uses RTP/RTCP port multiplexing). The unicast address
with lowest counter value MUST match the connection address ('c='
line). Similarly, the RTP and RTCP ports MUST match the RTP and RTCP
ports in the associated 'm=' line. The counter SHOULD start at 1 and
increment with each additional interface. Multiple interface lines
MUST be ordered in a decreasing priority level as is the case with the
Interface Advertisement blocks in in-band signaling (See <xref
target="I-D.singh-avtcore-mprtp" />).</t>
<t><unicast-address>: is taken from <xref
target="RFC4566">RFC4566</xref>. It is one of the IP addresses of the
endpoint and allows the use of IPv4 addresses, IPv6 addresses and
Fully Qualified Domain Names (FQDN). When choosing IPv6 addresses the
endpoint MUST perform the IPv6 address prioritization and selection as
proposed in <xref
target="I-D.keranen-mmusic-ice-address-selection"/>.</t>
<!--An endpoint MUST
only include the IP address for which the connectivity checks have
succeeded. -->
<t><port>: is from <xref target="RFC4566">RFC4566</xref>. It is
the RTP port associated with the unicast address and note that the RTP
and RTCP ports are multiplexed for MPRTP subflows according to <xref
target="RFC5761" />.</t>
<t><counter>: is a monotonically increasing positive integer
starting at 1. The counter MUST reset for each media line. The counter
value for an 'mprtp-interface' should remain the same for the
session, unless the priorities of the interfaces change.</t>
<t>[Editor's note: do we need a counter?]</t>
<!-- counter... why did we need it? -->
<t>The 'mprtp-interface' can be extended using the
'interface-description-extension' parameter. An endpoint MUST ignore
any extensions it does not understand.</t>
</section>
<section title="Example">
<t>The ABNF grammar is illustrated by means of an example:</t>
<figure>
<artwork><![CDATA[
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp
a=rtcp-mux
a=mprtp interface:1 192.0.2.1:49170 ;primary interface
a=mprtp interface:2 198.51.100.1:51372 ;additional interface
]]></artwork>
</figure>
</section>
</section>
<section title="MPRTP with ICE" anchor="mprtp-sdp-ia-ice-sdp">
<t>If the endpoints intend to use <xref target="RFC5245">ICE</xref> for
discovering interfaces and running connectivity checks, the following
two step procedure MUST be followed: </t>
<!--changed from -02 draft: [Christer/MMUSIC]:these endpoints MUST NOT
use in-band interface advertisement and the associated connectivity
checks, as described in <xref target="sec-mprtp-pkt-format-hdrext-cc"
/> (MPID=0x01). -->
<t><list style="numbers">
<t>Advertise ICE candidates: in the initial OFFER the endpoints
exchange candidates, as defined in <xref
target="RFC5245">ICE</xref>. Thereafter the endpoints run
connectivity checks.</t>
<t>Advertise MPRTP interfaces: When a sufficient number of
connectivity checks succeed, the endpoint MUST send an updated offer
containing the interfaces that they want to use for MPRTP.</t>
</list> </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 the connectivity check of more than one ICE
candidate succeeded, then an MPRTP endpoint MAY advertise (some of) these
as MPRTP interfaces in an updated offer.</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 MAY use
in-band signaling to advertise its interfaces, as defined in <xref
target="I-D.singh-avtcore-mprtp" />. Additionally, it MAY send an
updated offer when the transience stabilizes.</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 'mprtp
interface' with the lowest counter value 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 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 new ICE candidate. Similarly, the initiating endpoint starts
connectivity checks between the new interface and all the received ICE
candidates in the answer. If the connectivity checks succeed, the
initiating endpoint MAY send an updated offer with the new interface
as an additional 'mprtp interface'.</t>
<t>[Editor's Note: should we also consider using trickle ICE for MPRTP?
Trickle ICE is introduced in:
<xref target="I-D.ivov-mmusic-trickle-ice" /> and for SIP in
<xref target="I-D.ivov-mmusic-trickle-ice-sip" />.]</t>
<!--This process enables the participants to use MPRTP capabilities from
the start of a media session-->
</section>
<section title="Offer/Answer">
<t>When SDP <xref target="RFC4566" /> is used to negotiate MPRTP
interfaces (see <xref target="mprtp-sdp-ia-sdp" />) following the
offer/answer model <xref target="RFC3264" />, the collection of
"a=mprtp interface" attribute lines indicates the interfaces the
endpoint wishes to use for sending and/or receiving media data. The SDP
offer MUST include this attribute at the media level. If the answerer
wishes to also use SDP for advertising MPRTP interfaces, it MUST also
include its interfaces at the media-level "a=mprtp interface" attribute
in the answer. If the answer does not contain an "a=mprtp interface"
attribute, the offerer MUST use in-band signaling <xref
target="I-D.singh-avtcore-mprtp" /> for advertising interfaces.</t>
<t>When SDP is used in a declarative manner, the presence of an
"a=mprtp interface" attribute signals that the sender can send or
receive media data over multiple interfaces. The receiver SHOULD be
capable of streaming 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).</t>
</section>
<section title="Out-of-band Signaling Example">
<t>If multiple interfaces are included in an SDP offer then the
MPRTP-capable receiver MUST respond to the request with an SDP
answer containing one or more interfaces. If the SDP answer does
not contain "a=mprtp", the offerer can conclude that the endpoint
does not support MPRTP and continue the session using a single
path.</t>
<section title="Without ICE">
<t> In this example, the offerer advertises two interfaces and the
answerer responds with a single interface description. The
endpoint MAY use one or both paths depending on the end-to-end
characteristics of each path.</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=mprtp interface:1 192.0.2.1:49170
a=mprtp interface:2 198.51.100.1:51372
]]></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 interface:1 192.0.2.2:4000
]]></artwork>
</figure>
</section>
<section title="With ICE">
<t>In this example, the endpoint first sends its ICE candidates in
the initial offer and the other endpoint answers with its ICE
candidates.</t>
<t>Initial offer (with ICE candidates):</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=mprtp
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host
a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Answer:
v=0
o=bob 2890844528 2890844529 IN IP4 192.0.2.2
s=
c=IN IP4 192.0.2.2
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=mprtp
m=video 4000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host
]]></artwork>
</figure>
<t>Thereafter, each endpoint conducts ICE connectivity checks and when
sufficient number of connectivity checks succeed, the endpoint sends
an updated offer. In the updated offer, the endpoint advertises its
multiple interfaces for MPRTP.</t>
<t>Updated offer (with MPRTP interfaces):</t>
<figure>
<artwork><![CDATA[
Offer:
v=0
o=alice 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 192.0.2.1 49170 typ host
a=candidate:2 1 UDP 1694498815 198.51.100.1 51372 typ host
a=mprtp interface:1 192.0.2.1:49170
a=mprtp interface:2 198.51.100.1:51372
]]></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=candidate:1 1 UDP 2130706431 192.0.2.2 4000 typ host
a=mprtp interface:1 192.0.2.2:4000
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="mprtp-sdp-inc-througput" title="Increased Throughput">
<t>The MPRTP layer MAY choose to augment paths to increase throughput.
If the desired media rate exceeds the current media rate, the
endpoints MUST renegotiate the application specific ("b=AS:xxx") <xref
target="RFC4566" /> bandwidth.</t>
</section>
<section title="Increased Reliability" anchor="mprtp-sdp-reliability">
<t>TBD</t>
</section>
<section title="Decoding dependency" anchor="mprtp-sdp-decdep">
<t>TBD</t>
</section>
</section>
<section title="MPRTP in RTSP">
<t>Endpoints MUST use <xref target="I-D.ietf-mmusic-rfc2326bis">RTSP
2.0</xref> for session setup. Endpoints MUST multiplex RTP and RTCP on a
single port <xref target="RFC5761" /> and follow the recommendations made
in Appendix C of <xref target="I-D.ietf-mmusic-rfc2326bis"/>.</t>
<section title="Solution Overview without ICE">
<t><list style="numbers">
<t>The RTSP Server should include all of its interfaces via the
SDP attribute ("a=mprtp interface") in the RTSP DESCRIBE
message.</t>
<t>The RTSP Client should include its multiple interfaces
in the RTSP SETUP message using the new attribute
("dest_mprtp_addr=") in the Transport header. <cref
anchor="note-rtsp" source="Editor">Do we need a new lower
layer transport MPRTP?.</cref></t>
<t>The RTSP Server responds to the RTSP SETUP message with a
200 OK containing its MPRTP interfaces (using the
"src_mprtp_header=") in the Transport header. After this, the
RTSP Client can issue a PLAY request.</t>
<t>If a new interface appears or an existing one disappear at the
RTSP Client during playback, it should send a new RTSP SETUP
message containing the updated interfaces ("dest_mprtp_addr")
in the Transport header.
<!--TODO: SHOULD or should? do I explain when it could do it
and when not?-->
<cref anchor="note-rtsp-resetup" source="Editor"> Sending a
Re-SETUP to update the interfaces during PLAY state would
require a change in behavior of the server. Similar to Section
5.12 of [draft-ietf-mmusic-rtsp-nat]. </cref></t>
<t>If a new interface appears or an existing one disappears at the
RTSP Server during playback, the RTSP Server should send a
PLAY_NOTIFY message with a new Notify-Reason:
"src-mprtp-interface-update". The request must contain the
updated interfaces ("dest_mprtp_addr") in the
"MPRTP-Interfaces" header.</t>
<!--TODO: SHOULD or should? do I explain when it could do it
and when not? What about MUST vs must-->
<t>Alternatively, the RTSP Server or Client may use the RTCP
(in-band) mechanism to advertise their interfaces.</t>
<!--TODO: may or MAY-->
</list> </t>
<t><cref anchor="note-rtsp-in-out1" source="Editor">Does it make
sense to advertise out-of-band (in RTSP SETUP) when advertising
in-band in RTCP is less complex?</cref></t>
<t>The overview is illustrated by means of an example:</t>
<figure>
<artwork><![CDATA[
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 111
User-Agent: PhonyClient 1.3
Accept: application/sdp, application/example
Supported: setup.mprtp, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 111
Date: 23 Jan 2011 15:35:06 GMT
Server: PhonyServer 1.3
Content-Type: application/sdp
Content-Length: 367
Supported: setup.mprtp, setup.rtp.rtcp.mux
v=0
o=mprtp-rtsp-server 2890844526 2890844527 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=extmap:1 urn:ietf:params:rtp-hdrext:mprtp
a=rtcp-mux
a=mprtp interface:1 192.0.2.1:49170
a=mprtp interface:2 198.51.100.1:51372
]]></artwork>
</figure>
<t>On receiving the response to the RTSP DESCRIBE message, the RTSP
Client sends an RTSP SETUP message containing its MPRTP interfaces
in the Transport header using the "dest_mprtp_addr=" attribute. The
RTSP Server responds with a 200 OK containing both the RTSP
Client's and the RTSP Server's MPRTP interfaces.</t>
<figure>
<artwork><![CDATA[
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 112
Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr="
1 192.0.2.2 4000"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient 1.3
Supported: setup.mprtp, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 112
Session: 12345678
Transport: RTP/AVPF/UDP; unicast; dest_mprtp_addr="
1 192.0.2.2 4000";
src_mprtp_addr="1 192.0.2.1 49170;
2 198.51.100.1 51372"; RTCP-mux
Accept-Ranges: NPT
Date: 23 Jan 2012 15:35:06 GMT
Server: PhonyServer 1.3
Supported: setup.mprtp, setup.rtp.rtcp.mux
]]></artwork>
</figure>
<t>The RTSP Client can issue a PLAY request on receiving the 200 OK
and media can start to stream once the RTSP Server receives the
PLAY request.</t>
</section>
<section title="Solution Overview with ICE">
<t>This overview uses the <xref
target="I-D.ietf-mmusic-rtsp-nat">ICE mechanisms</xref> defined
for <xref target="I-D.ietf-mmusic-rfc2326bis">RTSP 2.0</xref>.</t>
<t><list style="numbers">
<t>The RTSP Server should include the "a=rtsp-ice-d-m"
attribute and also indicate that it supports MPRTP by including
the "a=mprtp" attribute in the SDP of the RTSP DESCRIBE
message.</t>
<t>The client sends an RTSP SETUP message containing the D-ICE
in lower level transport and ICE candidates in the Transport
header. The RTSP Server and Client then follow the procedures
(Steps 2 to 8) described in <xref
target="I-D.ietf-mmusic-rtsp-nat" />.</t>
<t>When the connectivity checks conclude, the RTSP Client can
send an updated RTSP SETUP message with its MPRTP interfaces
(ICE candidates that were successful) in the Transport header
("dest_mprtp_addr="). The RTSP Server responds to the RTSP
SETUP message with a 200 OK containing its MPRTP interfaces
(ICE candidates that were successful) in the Transport header
("src_mprtp_header="). After receiving the 200 OK, the RTSP
Client can issue the PLAY request.</t>
<t>Alternatively, after the connectivity checks conclude, the
RTSP Client can issue the PLAY request (Step 9 and 10 of
<xref target="I-D.ietf-mmusic-rtsp-nat" />) and the endpoints
can use the RTCP (in-band) mechanism to advertise their
interfaces.</t>
<t>If a new interface appears or an existing one disappears, the
RTSP Client should issue an updated SETUP message with the new
candidates (See Section 5.12 of <xref
target="I-D.ietf-mmusic-rtsp-nat" />) or the RTSP Server
should send a PLAY_NOTIFY message (See Section 5.13 of <xref
target="I-D.ietf-mmusic-rtsp-nat" />). After connectivity
checks succeed for the new interfaces, the RTSP Client can
proceed with the instructions in Step 3 or 4.</t>
</list> </t>
<t>The overview is illustrated by means of an example:</t>
<figure> <artwork><![CDATA[
C->S: DESCRIBE rtsp://server.example.com/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.3
Accept: application/sdp, application/example
Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 2012 15:35:06 GMT
Server: PhonyServer 1.3
Content-Type: application/sdp
Content-Length: 367
Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux
v=0
o=mprtp-rtsp-server 2890844526 2890842807 IN IP4 192.0.2.1
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
t=2873397496 2873404696
a=recvonly
a=rtsp-ice-d-m
a=control: *
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E;
a=rtcp-mux
a=mprtp
a=control: /video
]]></artwork> </figure>
<figure> <artwork><![CDATA[
C->S: SETUP rtsp://server.example.com/foo/video RTSP/2.0
CSeq: 302
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=9uB6;
ICE-Password=YH75Fviy6338Vbrhrlp8Yh;
candidates="1 1 UDP 2130706431 192.0.2.2
4000 typ host"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient 1.3
Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 302
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux;
ICE-ufrag=8hhY; ICE-Password=
asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 192.0.2.1 49170 typ host;
2 1 UDP 1694498815 198.51.100.1 51372 typ host"
Accept-Ranges: NPT
Date: 23 Jan 2012 15:35:06 GMT
Server: PhonyServer 1.3
Supported: setup.mprtp, setup.ice-d-m, setup.rtp.rtcp.mux
]]></artwork> </figure>
<t>After the connectivity checks complete, the RTSP Client can send an
updated RTSP SETUP message containing the MPRTP interfaces for which
the connectivity checks were successful. These steps are the same
as the ones in the previous example.</t>
</section>
<section title="RTSP Extensions" anchor="mprtp-rtsp">
<section title="MPRTP Interface Transport Header Parameter"
anchor="mprtp-rtsp-hdr-param">
<t>This section defines a new RTSP Transport parameter for
carrying MPRTP interfaces. The transport parameters may only occur
once in each transport specification. The parameter can contain
one or more MPRTP interfaces. If the RTSP Server supports MPRTP it
MUST include one or more MPRTP interfaces in the SETUP response.
<figure> <artwork><![CDATA[
trns-parameter = <Defined in Section 20.2.3 of
[I-D.ietf-mmusic-rfc2326bis]>
trns-parameter =/ SEMI dest-mprtp-interface-par
trns-parameter =/ SEMI src-mprtp-interface-par
dest-mprtp-interface-par = "dest_mprtp_addr" EQUAL DQUOTE SWS
interface *(SEMI interface) SWS DQUOTE
src-mprtp-interface-par = "src_mprtp_addr" EQUAL DQUOTE SWS
interface *(SEMI interface) SWS DQUOTE
interface = counter SP
unicast-address SP
rtp_port SP
*(SP interface-description-extension)
counter = See section 2.3.1
unicast-address = See section 2.3.1
rtp_port = See section 2.3.1
interface-description-extension = See section 2.3.1
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQUOTE = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
]]></artwork> </figure> </t>
</section>
<section title="MPRTP Feature Tag" anchor="mprtp-rtsp-ft">
<t>A feature tag is defined for indicating MPRTP support in the
RTSP capabilities mechanism: "setup.mprtp". This feature tag
indicates that the endpoint supports all the mandatory extensions
defined in this specification and is applicable to all types of
RTSP agents; clients, servers and proxies. </t>
<t>The MPRTP compliant RTSP Client MUST send the feature tag
"setup.mprtp" in the "Supported" header of all DESCRIBE and SETUP
requests.</t>
</section>
<section title="Status Codes" anchor="mprtp-rtsp-statuscodes">
<t>TBD</t>
</section>
<section title="New Reason for PLAY_NOTIFY" anchor="mprtp-rtsp-pnot">
<t>A new value used in the PLAY_NOTIFY methods Notify-Reason
header is defined: "src-mprtp-interface-update". This reason
indicates that the RTSP Server has updated set of MPRTP
interfaces.
<figure> <artwork><![CDATA[
Notify-Reas-val =/ "src-mprtp-interface-update"
]]></artwork> </figure>
</t>
<t>PLAY_NOTIFY requests with
Notify-Reason header set to src-mprtp-interface-update MUST
include a mprtp-interfaces header.
<figure> <artwork><![CDATA[
mprtp-interfaces = "mprtp-interfaces" HCOLON interface
*(COMMA interface)
interface = counter SP
unicast-address SP
rtp_port SP
*(SP interface-description-extension)
counter = See section 2.3.1
unicast-address = See section 2.3.1
rtp_port = See section 2.3.1
interface-description-extension = See section 2.3.1
]]></artwork> </figure>
<cref anchor="note-rtsp-play-notify" source="Editor">Do we need to
add a new header attribute?. Alternatively, the RTSP Server could
just send the PLAY_NOTIFY and let the RTSP Client initiate a new
RTSP SETUP message with its current interfaces and the RTSP Server
can then respond with its updated set of interfaces. This will
make it a 3-way exchange as opposed to a 1-way notification.
Alternatively, using SET_PARAMETER reduces it to a 2-way exchange
and can be initiated by both the RTSP Server and the RTSP Client.
However, SET_PARAMETER can only be used when the endpoints are in
SETUP state.</cref>
</t>
<t>Example:
<figure> <artwork><![CDATA[
S->C: PLAY_NOTIFY rtsp://server.example.com/foo RTSP/2.0
CSeq: 305
Notify-Reason: src-mprtp-interface-update
Session: 12345678
mprtp-interfaces: 2 192.0.2.10 48211, 3 198.51.100.11 38703
Server: PhonyServer 1.3
C->S: RTSP/2.0 200 OK
CSeq: 305
User-Agent: PhonyClient 1.3
]]></artwork> </figure></t>
</section>
<section title="Re-SETUP">
<t>The server SHALL support SETUP requests in PLAYING state if it
is only updating the transport parameter (dest_mprtp_addr). If the
session is established using ICE then the RTSP Server and Client
MUST also follow the procedures described for Re-SETUP in <xref
target="I-D.ietf-mmusic-rtsp-nat" />.</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="SDP Attributes">
<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 extended to signal one of
many possible interfaces for communication. These interface
addresses may have been validated using ICE procedures.</t>
<t>Appropriate Values: <xref
target="mprtp-sdp-ice-mprtp-interface-attribute" /> of RFC
XXXX.</t>
</list></t>
</section>
</section>
<section title="RTSP">
<t>This document requests registration in a number of registries for
RTSP.</t>
<section title="RTSP Feature Tag">
<t>This document request that one RTSP 2.0 feature tag be
registered in the "RTSP 2.0 feature tag" registry:</t>
<t>setup.mprtp See <xref target="mprtp-rtsp-ft" />.</t>
</section>
<section title="RTSP Transport Parameters">
<t>This document requests that 2 transport parameters be
registered in RTSP 2.0's "Transport Parameters":</t>
<t>"dest_mprtp_addr": See <xref target="mprtp-rtsp-hdr-param"
/>.</t>
<t>"src_mprtp_addr": See <xref target="mprtp-rtsp-hdr-param"
/>.</t>
</section>
<!-- mprtp-rtsp-pnot -->
<section title="Notify-Reason value">
<t>This document requests that one assignment be done in the RTSP
2.0 Notify-Reason header value registry. The defined value is:</t>
<t>"src-mprtp-interface-update": See <xref
target="mprtp-rtsp-pnot" />.</t>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> Varun Singh, Saba Ahsan, and Teemu Karkkainen are supported by
Trilogy (http://www.trilogy-project.org), a research project
(ICT-216372) partially funded by the European Community under its
Seventh Framework Program. </t>
<t>The work of Varun Singh, Joerg Ott, Ralf Globisch and Thomas Schierl
has been partially supported by the European Institute of Innovation and
Technology (EIT) ICT Labs activity RCLD 11882. </t>
<t>The views expressed here are those of the author(s) only. Neither the
European Commission nor the EITICT labs is liable for any use that may be
made of the information in this document. </t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Contributors" title="Contributors">
<t><figure> <artwork><![CDATA[
Saba Ahsan
Aalto University
School of Science and Technology
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: sahsan@cc.hut.fi
]]></artwork> </figure></t>
<t> <figure> <artwork><![CDATA[
Lars Eggert
NetApp
Sonnenallee 1
Kirchheim 85551
Germany
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org/
]]></artwork> </figure></t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119; <!-- keywords -->
&rfc5245; <!-- ice -->
&rfc3550; <!-- rtp -->
&rfc5234; <!-- abnf -->
&rfc5761; <!-- multiplexing -->
&I-D.singh-avtcore-mprtp;
&I-D.keranen-mmusic-ice-address-selection; <!-- IPv6 address -->
</references>
<references title="Informative References">
&rfc3552; <!-- guideline for sec considerations -->
<!-- &rfc3611; rtcp xr -->
&I-D.ietf-mmusic-rfc2326bis; <!--rtsp 2.0-->
&I-D.ietf-mmusic-rtsp-nat; <!--ICE for RTSP-->
&rfc3261; <!-- SIP -->
&rfc3264; <!-- o/a with SDP -->
&rfc4566; <!-- sdp -->
&I-D.ivov-mmusic-trickle-ice;
&I-D.ivov-mmusic-trickle-ice-sip;
</references>
<!--
<section anchor="App-a" title="Example Scenarios">
<t>TBD</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-mmusic-mprtp-sdp-extension-02">
<t><list style="symbols">
<t>Mainly editorial fixes.</t>
<t>Changed DQ to DQUOTE in ABNF definition.</t>
</list></t>
</section>
<section title="Changes in draft-singh-mmusic-mprtp-sdp-extension-01">
<t><list style="symbols">
<t>Added IPv6 address selection.</t>
<t>Editorial fixes.</t>
</list></t>
</section>
<section title="Changes in draft-singh-mmusic-mprtp-sdp-extension-00">
<t><list style="symbols">
<t>The document is created by splitting the
draft-singh-avtcore-mprtp-04 into 2 parts. The RTP related
stuff is kept in the former while the SDP related discussion
is moved to this new document.</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 21:42:22 |