One document matched: draft-ietf-mmusic-rtsp-nat-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mmusic-rtsp-nat-06" ipr="full3978">
<front>
<title abbrev="A Media NAT Traversal mechanism for RTSP">An Network
Address Translator (NAT) Traversal mechanism for media controlled by
Real-Time Streaming Protocol (RTSP)</title>
<author fullname="Jeff Goldberg" initials="J.I." surname="Goldberg">
<organization>Cisco</organization>
<address>
<postal>
<street>11 New Square, Bedfont Lakes</street>
<city>Feltham,</city>
<region>Middx</region>
<code>TW14 8HA</code>
<country>United Kingdom</country>
</postal>
<phone>+44 20 8824 1000</phone>
<facsimile></facsimile>
<email>jgoldber@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Torshamsgatan 23</street>
<city>Stockholm</city>
<region></region>
<code>SE-164 80</code>
<country>Sweden</country>
</postal>
<phone>+46 8 719 0000</phone>
<facsimile></facsimile>
<email>magnus.westerlund@ericsson.com</email>
<uri></uri>
</address>
</author>
<author fullname="Thomas Zeng" initials="T." surname="Zeng">
<organization>Nextwave Wireless, Inc.</organization>
<address>
<postal>
<street>12670 High Bluff Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92130</code>
<country>USA</country>
</postal>
<phone>+1 858 480 3100</phone>
<facsimile></facsimile>
<email>thomas.zeng@gmail.com</email>
<uri></uri>
</address>
</author>
<date day="25" month="February" year="2008" />
<abstract>
<t>This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams setup and controlled
with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
signalling channel, defining the necessary extra RTSP extensions and
procedures.</t>
</abstract>
<note 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">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Real-time Streaming Protocol (RTSP) <xref
target="RFC2326"></xref><xref
target="I-D.ietf-mmusic-rfc2326bis"></xref> is a protocol used to setup
and control one or more media streams delivering media to receivers. It
is RTSP's functionality of setting up media streams that get into
serious issues with Network Address Translators (NAT) <xref
target="RFC3022"></xref>. Commonly the media will be totally blocked by
the NAT unless extra provisions are taken by the protocol. There is a
clear and present need for NAT traversal mechanism for the media setup
using RTSP.</t>
<t>RTSP 1.0 <xref target="RFC2326"></xref> has suffered from the lack of
a standardized NAT traversal mechanism for a long time, however due to
quality of the RTSP 1.0 specification, the work has had to wait on the
recently defined RTSP 2.0 <xref
target="I-D.ietf-mmusic-rfc2326bis"></xref>. RTSP 2.0 is similar to RTSP
1.0 in many respects but significantly for this work, it contains a well
defined extension mechanism so allowing a NAT traversal extension to be
defined that is backwards compatible with RTSP 2.0 peers not supporting
the extension. This extension mechanism was not possible in RTSP 1.0 as
it would break RTSP 1.0 syntax so causing compatibility issues.</t>
<t>There have been a number of suggested ways of resolving the
NAT-traversal of media for RTSP of which a large number are already used
in implementations. The evaluation of these NAT traversal solutions
in<xref target="I-D.ietf-mmusic-rtsp-nat-evaluation"> </xref> has shown
that there are many issues to consider, so after extensive evaluation,
we selected a mechanism based on Interactive Connectivity Establishment
(ICE). This was mainly two reasons: Firstly the mechanism supports RTSP
servers behind NATs and secondly the mechanism solves the security
threat that uses RTSP servers as Distributed Denial of Service (DDoS)
attack tools.</t>
<t>The NAT problem for RTSP signalling traffic itself is beyond the
scope of this document and is left for future study should the need
arise, because it is a less prevalent problem than the NAT problem for
RTSP media streams.</t>
</section>
<section title="Solution Overview">
<t>This overview assumes that the reader has some familiarity with how
ICE <xref target="I-D.ietf-mmusic-ice"></xref> works, as it primarily
points out how the different ICE steps are accomplished in RTSP.</t>
<t><list style="numbers">
<t>RTSP server can indicate it has support for ICE via an SDP <xref
target="RFC4566"></xref> attribute in, for example, the SDP returned
in RTSP DESCRIBE message. This allows RTSP clients to only send the
new ICE interchanges with servers that support ICE so as to limit
the overhead on current non-ICE supporting RTSP servers. If RTSP
DESCRIBE is used the normal capability determination mechanism can
be used, i.e. "Supported" header and the defined feature tag.</t>
<t>RTSP client reviews the session description returned, for example
by an RTSP DESCRIBE message, to determine what media resources that
need to be setup. For each of these media resources where the
transport protocol supports Session Traversal Utilities for (NAT)
(STUN) <xref target="I-D.ietf-behave-rfc3489bis"></xref> based
connectivity checks, the client gathers candidate addresses. See
section 4.1.1 in <xref target="I-D.ietf-mmusic-ice"></xref>. The
client also installs the STUN servers on each of the local
candidates.</t>
<t>RTSP client sends a SETUP request with both a transport
specification with a lower layer indicating ICE and a new RTSP
Transport header parameter listing the ICE candidates for each media
resource. RTSP proxies in non-ICE transport specifications should be
treated at lower priority than those transport specifications
supporting ICE.</t>
<t>After receiving the list of candidates from a client, the RTSP
server gathers its own candidates. If the server has a public IP
address then a single candidate per address family (e.g. IPv4 and
IPv6) can be included to reduce the number of combinations and speed
up the completion.</t>
<t>The server sets up the media and if successful responds to the
SETUP request with a 200 OK response. In that response the server
selects the transport specification using ICE and includes its
candidates in the server candidate parameter.</t>
<t>If the server is behind a NAT then it starts the connectivity
checks following the procedures described in Section 5.7 and 5.8 of
<xref target="I-D.ietf-mmusic-ice"></xref>. If the server has a
public IP address with a single candidate then it can refrain from
server initiated connectivity checks and rely on triggered
checks.</t>
<t>The client receives the SETUP response and learns the candidate
address to use for the connectivity checks, and then initiates its
connectivity check, following the procedures in Section 6 of <xref
target="I-D.ietf-mmusic-ice"></xref>.</t>
<t>When a connectivity check from the client reaches the server it
will result in a triggered check from the server. This is why
servers with a public IP address can wait until this triggered check
to send out any checks for itself so saving resources and mitigating
the DDoS potential from server connectivity checks.</t>
<t>When the client has concluded its connectivity checks and has
corresponding received the server connectivity checks on the
promoted candidates for all components of all media streams, it can
issue a PLAY request. If the connectivity checks have not concluded
successfully then the client may send a new SETUP request assuming
it has any new information or believes the server may be able to do
more that can result in successful checks.</t>
<t>When the RTSP servers receives a PLAY request it checks to see
the connectivity checks has concluded successfully and only then can
play the stream. If there is a problem with the checks then the
server sends to the client either a 150 (ICE connectivity checks in
progress) response to show that it is still working on the
connectivity checks or a 480 (ICE Processing Failed) response to
indicate a failure of the checks. If the checks are successful then
the server sends a 200 OK response and starts delivering media.</t>
</list>The client may release unused candidates when the ICE
processing has concluded and a single candidate per component has been
promoted.</t>
<t>The client shall continue to use STUN to send keep-alive for the used
bindings. This is important as often RTSP media sessions only contain
media traffic from the server to the client so the bindings in the NAT
needs to be refreshed by the client to server traffic provided by the
STUN keep-alive.</t>
</section>
<section title="RTSP Extensions">
<t>This section defines the necessary RTSP extensions for performing ICE
with RTSP. Note that these extensions are based on the SDP attributes in
the ICE specification unless expressly indicated.</t>
<section anchor="sec-ice-tll" title="ICE Transport Lower Layer">
<t>A new lower layer "D-ICE" for transport specifications is defined.
This lower layer is datagram clean except that the protocol used must
be demultiplexiable with STUN messages (see STUN <xref
target="I-D.ietf-behave-rfc3489bis"></xref>). With datagram clean we
mean that it must be capable of describing the length of the datagram,
transport that datagram (as a binary chunk of data) and provide it at
the receiving side as one single item. This lower layer can be any
transport type defined for ICE which does provide datagram transport
capabilities. Though only UDP is defined at present, however TCP with
framing may be specified and used in the future.</t>
<t>This lower layer uses ICE to determine which of the different
candidates shall be used and then when the ICE processing has
concluded, uses the selected candidate to transport the datagrams over
this transport.</t>
<t>This lower layer transport can be combined with all upper layer
media transport protocols that are possible to demultiplex with STUN
and which use datagrams. This specification defines the following
combinations:</t>
<t><list style="symbols">
<t>RTP/AVP/D-ICE</t>
<t>RTP/AVPF/D-ICE</t>
<t>RTP/SAVP/D-ICE</t>
<t>RTP/SAVPF/D-ICE</t>
</list></t>
<t>This list can easily be extended with more transport specifications
after having performed the evaluation that they are compatible with
D-ICE as lower layer.</t>
<t>The lower-layer "D-ICE" has the following rules for the inclusion
of transport parameters:</t>
<t><list style="hanging">
<t hangText="unicast:">As ICE only supports unicast operations,
thus it is REQUIRED that one include the unicast indicator
parameter, see section 16.46 in <xref
target="I-D.ietf-mmusic-rfc2326bis"></xref>.</t>
<t hangText="candidates:">The "candidates" parameter SHALL be
included as this specify at least one candidate to try to
establish a working transport path with.</t>
<t hangText="dest_addr:">This parameter SHALL NOT be included as
"candidates" is used instead to provide the necessary address
information.</t>
<t hangText="ICE-Password:">This parameter SHALL be included.</t>
<t hangText="ICE-Userfrag:">This parameter SHALL be included.</t>
</list></t>
</section>
<section anchor="sec-ice-cand"
title="ICE Candidate Transport Header Parameter">
<t>This section defines a new RTSP transport parameter for carrying
ICE candidates related to the transport specification they appear
within, which may then be validated with an end-to-end connectivity
check using <xref target="I-D.ietf-behave-rfc3489bis">STUN</xref>.
Transport parameters may only occur once in each transport
specification. For transport specification using "D-ICE" as lower
layer, this parameter needs to be present. The parameter can contain
one or more ICE candidates. In the SETUP response there is only a
single transport specification, and if that uses the "D-ICE" lower
layer this parameter also needs to present including the server side
candidates.</t>
<t><figure>
<artwork><![CDATA[tr-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate
*(SEMI ice-candidate) SWS DQ
ice-candidate = foundation SP
component-id SP
transport SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
*(SP extension-att-name SP extension-att-value)
foundation = <See section 15.1 of [I-D.ietf-mmusic-ice]>
component-id = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport-extension = <See section 15.1 of [I-D.ietf-mmusic-ice]>
priority = <See section 15.1 of [I-D.ietf-mmusic-ice]>
cand-type = <See section 15.1 of [I-D.ietf-mmusic-ice]>
candidate-types = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-addr = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-port = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-name = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-value = <See section 15.1 of [I-D.ietf-mmusic-ice]>
ice-char = <See section 15.1 of [I-D.ietf-mmusic-ice]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQ = <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>
<t><connection-address>: is the IP address of the candidate,
allowing for IPv4 addresses, IPv6 addresses and Fully qualified domain
names (FQDN), taken from <xref target="RFC4566"></xref>. The
connection address SHOULD be on the same format (explicit IP or FQDN)
as in the dest_addr parameter used to express default for the matching
candidate. An IP address SHOULD be used, but an FQDN MAY be used in
place of an IP address. In that case, when receiving an offer or
answer containing an FQDN in an a=candidate attribute, the FQDN is
looked up in the DNS first using an AAAA record (assuming the agent
supports IPv6), and if no result is found or the agent only supports
IPv4, using an A. If the DNS query returns more than one IP address,
one is chosen, and then used for the remainder of ICE processing.</t>
<t><port>: is the port of the candidate taken from RFC 4566
[RFC4566].</t>
<t><transport>: indicates the transport protocol for the
candidate. The ICE specification only defines UDP. However,
extensibility is provided to allow for future transport protocols to
be used with ICE, such as TCP or the Datagram Congestion Control
Protocol (DCCP) [RFC4340].</t>
<t><foundation>: is an identifier that is equivalent for two
candidates that are of the same type, share the same base, and come
from the same STUN server, and is composed of one to thirty two
<ice-char>. The foundation is used to optimize ICE performance
in the Frozen algorithm.</t>
<t><component-id>: identifies the specific component of the
media stream for which this is a candidate and os a positive integer
between 1 and 256. It MUST start at 1 and MUST increment by 1 for each
component of a particular candidate. For media streams based on RTP,
candidates for the actual RTP media MUST have a component ID of 1, and
candidates for RTCP MUST have a component ID of 2. Other types of
media streams which require multiple components MUST develop
specifications which define the mapping of components to component
IDs. See Section 14 for additional discussion on extending ICE to new
media streams.</t>
<t><priority>: is a positive integer between 1 and (2**31 -
1).</t>
<t><cand-type>: encodes the type of candidate. The ICE
specification defines the values "host", "srflx", "prflx" and "relay"
for host, server reflexive, peer reflexive and relayed candidates,
respectively. The set of candidate types is extensible for the
future.</t>
<t><rel-addr> and <rel-port>: convey transport addresses
related to the candidate, useful for diagnostics and other purposes.
<rel-addr> and <rel-port> MUST be present for server
reflexive, peer reflexive and relayed candidates. If a candidate is
server or peer reflexive, <rel-addr> and <rel-port> is
equal to the base for that server or peer reflexive candidate. If the
candidate is relayed, <rel-addr> and <rel-port> is equal
to the mapped address in the Allocate Response that provided the
client with that relayed candidate (see Appendix B.3 for a discussion
of its purpose). If the candidate is a host candidate <rel-addr>
and <rel-port> MUST be omitted.</t>
</section>
<section anchor="sec-ice-pwd"
title="ICE Password and Username Transport Header Parameters">
<t>The ICE password and username for each agent needs to be
transported using RTSP. For that purpose new transport header
parameters are defined.</t>
<t>There MUST be an "ICE-Password" and "ICE-Userfrag" parameter for
each media stream. If two SETUP requests in the same RTSP session have
identical ICE-Userfrag's, they MUST have identical ICE-Password's. The
ICE-Userfrag and ICE-Password attributes MUST be chosen randomly at
the beginning of a session. The ICE-Userfrag attribute MUST contain at
least 24 bits of randomness, and the ICE-Password attribute MUST
contain at least 128 bits of randomness. This means that the
ICE-Userfrag attribute will be at least 4 characters long, and the
ICE-Password at least 22 characters long, since the grammar for these
attributes allows for 6 bits of randomness per character. The
attributes MAY be longer than 4 and 22 characters respectively, of
course, up to 256 characters. The upper limit allows for buffer sizing
in implementations. Its large upper limit allows for increased amounts
of randomness to be added over time.</t>
<t>The <xref target="RFC5234">ABNF</xref> for these parameters
are:</t>
<t><figure>
<artwork><![CDATA[tr-parameter =/ SEMI ice-password-par
tr-parameter =/ SEMI ice-userfrag-par
ice-password-par = ICE-Password" HCOLON password
ice-userfrag-par = ICE-Userfrag" HCOLON ufrag
password = <Defined in [I-D.ietf-mmusic-ice]>
ufrag = <Defined in [I-D.ietf-mmusic-ice]>
HCOLON = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
]]></artwork>
</figure></t>
</section>
<section anchor="ice-feature-tag" title="ICE Feature Tag">
<t>A feature tag is defined for usage in the RTSP capabilities
mechanism for ICE support for media transport using datagrams:
"setup.ice-d-m". This feature tag indicates that one support all the
mandatory to support functions of this specification. It is applicable
to all types of RTSP agents; clients, servers and proxies.</t>
<t>The RTSP client should send the feature tag "setup.ice-d-m" in the
"Supported" header in all SETUP requests that contain the "D-ICE"
lower layer transport.</t>
</section>
<section title="Status Codes">
<t>ICE needs two new RTSP response codes to indicate correctly
progress and errors.</t>
<t></t>
<texttable anchor="tab-status"
title="New Status codes and their usage with RTSP methods">
<preamble></preamble>
<ttcol align="left">Code</ttcol>
<ttcol align="left">Reason</ttcol>
<ttcol align="left">Method</ttcol>
<c>150</c>
<c>Server still working on ICE connectivity checks</c>
<c>PLAY</c>
<c></c>
<c></c>
<c></c>
<c>480</c>
<c>ICE Connectivity check failure</c>
<c>PLAY, SETUP</c>
</texttable>
<section anchor="sec-sc-150"
title="150 ICE connectivity checks in progress">
<t>The 150 response code indicates that ICE connectivity checks are
still in progress and haven't concluded. This response SHALL be sent
within 200 milliseconds of receiving a PLAY request that currently
can't be fulfilled because ICE connectivity checks are still
running. Subsequently, every 3 seconds after the previous sent one,
a 150 reply shall be sent until the ICE connectivity checks conclude
either successfully or in failure, and a final response for the
request can be provided.</t>
</section>
<section anchor="sec-sc-480" title="480 ICE Processing Failed">
<t>The 480 client error response code is used in cases when the
request can't be fulfilled due to a failure in the ICE processing,
such as that all the connectivity checks have timed out. This error
message can appear either in response to a SETUP request to indicate
that no candidate pair can be constructed or to a PLAY request that
the server's connectivity checks resulted in failure.</t>
</section>
</section>
<section title="Server Side SDP Attribute for ICE Support ">
<t>If the server supports the media NAT traversal for RTSP controlled
sessions, as described in this RFC, then the Server SHALL include the
"a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing content
served by the server. This is an session level attribute.</t>
<t><figure>
<artwork><![CDATA[rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
]]></artwork>
</figure></t>
<t></t>
</section>
<section title="ICE Features Not Required in RTSP">
<t>A number of ICE signalling features are not needed with RTSP and
are discussed below.</t>
<section title="ICE-Lite">
<t>The ICE-Lite attribute shall not be used in the context of RTSP.
The ICE specification describes two implementations of ICE: Full and
Lite, where hosts that are not behind a NAT are allowed to implement
only Lite. For RTSP, the Lite implementation is insufficient because
it does not cause the media server to send a connectivity check,
which are used to protect against making the RTSP server a denial of
service tool. This document defines another variation implementation
of ICE, called ICE-RTSP. It has its own set of simplifications
suitable to RTSP. Conceptually, this implementation of ICE-RTSP is
between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL
for clients.</t>
</section>
<section title="ICE-Mismatch">
<t>The ice-mismatch parameter indicates that the offer arrived with
a default destination for a media component that didn't have a
corresponding candidate attribute. This is not needed for RTSP as
the ICE based lower layer transport specification either is
supported or another alternative transport is used. This is always
explicitly indicated in the SETUP request and response.</t>
</section>
<section title="ICE Remote Candidate Transport Header Parameter">
<t>The Remote candidate attribute is not needed for RTSP for the
following reasons. Each SETUP results in a independent ICE
processing chain which either fails or results in promoting a single
candidate pair to usage. If a new SETUP request for the same media
is sent this needs to use a new userfragment and password to avoid
any race conditions or uncertainty for which processing round the
STUN requests relate to.</t>
</section>
<t></t>
</section>
</section>
<section title="Detailed Solution">
<t>This section describes in detail how the interaction and flow of ICE
works with RTSP messages.</t>
<t></t>
<section title="Session description and RTSP DESCRIBE (optional)">
<t>The RTSP server should indicate it has support for ICE by sending
the "rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE
message if SDP is used. This allows RTSP clients to only send the new
ICE interchanges with servers that support ICE so limiting the
overhead on current non-ICE supporting RTSP servers. When not using
RTSP DESCRIBE it is still recommended to use the SDP attribute for
session description.</t>
<t>A Client can also use the DESCRIBE request to determine explicitly
if both server and any proxies support ICE. The client includes the
"Supported" header with its supported feature tags, including
"setup.ice-d-m". Any proxy upon seeing the "Supported" header will
include the "Proxy-Supported" header with the feature tags it
supports. The server will echo back the "Proxy-Supported" header and
its own version of the Supported header so enabling a client to
determine if all involved parties support ICE or not. Note that even
if a proxy is present in the chain that doesn't indicate support for
ICE, it may still work.</t>
<t><figure>
<artwork><![CDATA[For example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
Supported: setup.ice-d-m
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
Supported: setup.ice-d-m
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
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=audio 3456 RTP/AVP 0
a=control: /audio
m=video 2232 RTP/AVP 31
a=control: /video
]]></artwork>
</figure></t>
</section>
<section title="Setting up the Media Resources">
<t>The RTSP client reviews the session description returned, for
example by an RTSP DESCRIBE message, to determine what media resources
that need to be setup. For each of these media resources where the
transport protocol supports ICE connectivity checks, the client shall
gather candidate addresses as described in section 4.1.1 in <xref
target="I-D.ietf-mmusic-ice"></xref> according to standard ICE rather
than the ICE-Lite implementation.</t>
</section>
<section title="RTSP SETUP Request">
<t>The RTSP client will then send one or more SETUP requests to
establish the media streams required for the desired session. For each
media stream where it desires to use ICE it will include a transport
specification with "D-ICE" as the lower layer. This transport
specification SHOULD be placed first in the list to give it highest
priority. It is RECOMMENDED that additional transport specifications
are provided as a fallback in case of non ICE supporting proxies. For
example (Note that some lines are broken in contradiction with the
defined syntax due to space restrictions in the documenting
format:</t>
<figure>
<artwork><![CDATA[C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 302
Transport: RTP/AVP/D-ICE; unicast; candidates = "
1 1 UDP 2130706431 10.0.1.1 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.1 rport 9002",
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m
]]></artwork>
</figure>
<t>The client will be initiating and thus the controlling party in the
ICE processing.</t>
</section>
<section anchor="server-gather" title="Gathering Candidates">
<t>Upon receiving a SETUP request the server can determine what media
resource should be delivered and which transport alternatives that the
client supports. If one based on D-ICE is first on the list of
supported transports, the below applies, otherwise another transport
method is preferred and supported.</t>
<t>The transport specification will provide which media protocol is to
be used and based on this and the clients candidates, the server
determines the protocol and if it supports ICE with that protocol. The
server shall then gather its candidates according to section 4.1.1 in
<xref target="I-D.ietf-mmusic-ice"></xref>. Servers that have an
address that is generally reachable by any clients within the address
scope the server intends to serve MAY be specially configured
(high-reachability configuration). This special configuration has the
goal of reducing the server side candidate to preferably a single one
per address family. Instead of gathering all possible addresses
including relayed and server reflexive addresses, the server uses a
single address per address family that it knows it should be reachable
by a client behind one or more NATs. The reason for this special
configuration is two fold: Firstly it reduces the load on the server
in address gathering and in ICE processing during the connectivity
checks. Secondly it will reduce the number of permutations for
candidate pairs significantly thus potentially speeding up the
conclusion of the ICE processing. Note however that using this option
on a server that doesn't fulfill the requirement of being reachable is
counter-productive and it is important that this is correctly
configured.</t>
</section>
<section title="RTSP Server Response">
<t>The server determines if the SETUP request is successful from the
other perspectives and will return a 200 OK response, otherwise
returning an error code from the list in Table 4 in <xref
target="I-D.ietf-mmusic-rfc2326bis"></xref>. At that point the server,
having selected a transport specification using the "D-ICE" lower
layer, will need to include that transport specification in the
response message. The transport specification shall include the
candidates gathered in Section<xref target="server-gather"></xref> in
the "candidates" transport header parameter as well as the server's
username and password. In the case that there are no valid candidate
pairs with the combination of the client and servers candidates, a 480
(ICE Processing Failed) error response shall be returned which must
include the servers' candidates. The return of a 480 error may allow
both the server and client to release its candidates.</t>
<t><figure>
<artwork><![CDATA[S->C: RTSP/2.0 200 OK
CSeq: 302
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; candidates = "
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m
]]></artwork>
</figure></t>
</section>
<section title="Server to Client ICE Connectivity Checks">
<t>The server shall start the connectivity checks following the
procedures described in Section 5.7 and 5.8 of <xref
target="I-D.ietf-mmusic-ice"></xref> unless it is configured to use
the high-reachability option. If it is then it can suppress its own
checks until the servers checks are triggered by the client's
connectivity checks.</t>
<t>The server SHALL use a single pacer for all STUN transactions
within a single RTSP session, i.e across all media streams that are
part of the same RTSP session.</t>
<t>When a connectivity check from the client reaches the server it
will result in a triggered check from the server as specified in
section 7.2.1.4 of <xref target="I-D.ietf-mmusic-ice"></xref>. This is
why servers with a high reachability address can wait until this
triggered check to send out any checks for itself so saving resources
and mitigating the DDoS potential.</t>
</section>
<section title="Client to Server ICE Connectivity Check">
<t>The client receives the SETUP response and learns the candidate
address to use for the connectivity checks. The client shall initiate
its connectivity check, following the procedures in Section 6 of <xref
target="I-D.ietf-mmusic-ice"></xref>.</t>
<t>Aggressive nomination SHALL be used with RTSP. This doesn't have
the negative impact that it has in offer/answer as media playing only
starts after issuing a PLAY request.</t>
</section>
<section title="Client Connectivity Checks Complete">
<t>When the client has concluded its connectivity checks and has
correspondingly received the server connectivity checks on the
promoted candidates for all the media components, it can issue a PLAY
request. If the client has locally determined that its checks have
failed it may try providing an extended set of candidates and update
the server candidate list by issuing a new SETUP request for the media
stream.</t>
<t>If the client concluded its connectivity checks succesfully and
therefore sent a PLAY request but the server have not concluded
successfully, the server will respond with a 480 (ICE Processing
Failed). Upon receiving the 480 (ICE Processing Failed) response, then
the client may send a new SETUP request assuming it has any new
information that can be included in the candidate list.</t>
</section>
<section title="Server Connectivity Checks Complete">
<t>When the RTSP server receives a PLAY request, it checks to see that
the connectivity checks have concluded successfully and only then will
it play the stream. If there is a problem with the checks then the
server sends to the client either a new 150 (ICE connectivity checks
in progress) response to show that it is still working on the
connectivity checks or a new 480 response to indicate a failure of the
checks. If the checks are successful then the server sends a 200 OK
response and starts delivering media. The new RTSP errors add to the
list in Table 4 in <xref target="I-D.ietf-mmusic-rfc2326bis"></xref>
as below:</t>
<t></t>
</section>
<section title="Releasing Candidates">
<t>Both server and client may release its non nominated candidates as
soon as a 200 PLAY response has been issued/received.</t>
</section>
<section title="Steady State">
<t>The client will continue to use STUN to send keep-alive for the
used bindings. This is important as normally RTSP play mode sessions
only contain traffic from the server to the client so the bindings in
the NAT needs to be refreshed by the cleint to server traffic provided
by the STUN keep-alive.</t>
<t></t>
</section>
<section title="re-SETUP">
<t>If the client decides to change any parameter related to the media
stream SETUP it will send a new SETUP request. In this new SETUP
request the client SHALL include a new different username and password
to use in the ICE processing. This request will also cause the ICE
processing to start from the beginning again.</t>
<t>If the RTSP session is in playing state at the time of sending the
SETUP request, the ICE connectivity checks SHALL use Regular
nomination. Any ongoing media delivery continues on the previously
nominated candidate pairs until the new pairs have been nominated for
the individual candidate. Once the nomination of the new candidate
pair has completed, all unused candidates may be released.</t>
</section>
</section>
<section title="ICE and Proxies">
<t>RTSP allows for proxies which can be of two fundamental types
depending if they relay and potentially cache the media or not. Their
differing impact on the RTSP NAT traversal solution including backwards
compatibility is explained below.</t>
<section title="Media Handling Proxies">
<t>An RTSP proxy that relays or caches the media stream for a
particular media session can be considered to split the media
transport into two parts: A media transport between the server and the
proxy according to the proxies need, and delivery from the proxy to
the client. This split means that the NAT traversal solution will need
to be run on each individual media leg according to need.</t>
<t>It is RECOMMENDED that any media handling proxy support the media
NAT traversal defined within this specification. This is for two
reasons: Firstly to enable clients to perform NAT traversal for the
media between the proxy and itself and secondly to allow the proxy to
be topology independent so able to support performing NAT traversal
for non-NAT traversal capable clients present in the same address
domain.</t>
<t>For a proxy to support the media NAT traversal defined in this
specification a proxy will need to implement the solution fully and be
ready as both a controlling and a controlled ICE peer. The proxy also
SHALL include the "setup.ice-d-m" feature tag in any applicable
capability negotiation headers, such as "Proxy-Supported".</t>
</section>
<section title="Signalling Only Proxies">
<t>A signalling only proxy handles only the RTSP signalling and does
not have the media relayed through proxy functions. This type of proxy
is not likely to work unless the media NAT traversal solution is in
place between the client and the server, because the DoS protection
measures usually prevent media delivery to other addresses other than
from where the RTSP signalling arrives at the server.</t>
<t>The solution for the Signalling Only proxy is that it must forward
the RTSP SETUP requests including any transport specification with the
"D-ICE" lower layer and the related transport parameters. A proxy
supporting this functionality SHOULD indicate its capability by always
including the "setup.ice-d-m" feature tag in the "Proxy-Supported"
header.</t>
</section>
<section title="Non-supporting Proxies">
<t>A media handling proxy that doesn't support the ICE media NAT
traversal specified here is assumed to remove the transport
specification and use any of the lower prioritized transport
specifications if provided by the requester. The specification of such
a non ICE transport enables the negotiation to complete, although with
a less prefered method as a NAT between the proxy and the client will
result in failure of the media path.</t>
<t>A non-media handling transport proxy is expected to ignore and
simply forward all unknown transport specifications, however, this can
only be guaranteed for proxies following the published RTSP 2.0
specification.</t>
<t>Unfortunately the usage of the "setup.ice-d-m" feature tag in the
proxy-require will have contradicting results. For a non ICE
supporting media handling proxy, the inclusion of the feature tag will
result in aborting the setup and indicating that it isn't supported,
which is desirable if you want to provide other fallbacks or other
transport configurations to handle the situation. For non-supporting
non-media handling proxies the result will also result in aborting the
setup, however, setup might have worked if the proxy-require tag
wasn't present. This variance in results makes usage of proxy-require
not recommended. We recommend instead the usage of the Supported
header to force proxies to include the feature tags they support in
the proxy-supported which will provide a positive indication when all
proxies in the chain between the client and server support the
functionality. Even if not explicitly indicating support, any SETUP
response including a transport specification with "D-ICE" will be
implicit indication that the proxy chain supports at least passthrough
of this media.</t>
<t></t>
</section>
</section>
<section anchor="rtp-mux" title="RTP and RTCP Multiplexing">
<t><xref target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref> specifies how
and when RTP and RTCP can be multiplexed on the same port. This
multiplexing is highly recommended to combine with ICE as it makes RTP
and RTCP only need a single component per media stream instead of two,
so reducing the load on the connectivity checks.</t>
<t>To enable signalling for the usage of RTP and RTCP multiplexing a new
RTSP transport header parameter is defined. The formal syntax (ABNF
<xref target="RFC5234"></xref>) of this parameter is the following:</t>
<t><figure>
<artwork><![CDATA[tr-parameter =/ SEMI rtcp-mux-par
rtcp-mux-par = "rtp-rtcp-mux"
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
]]></artwork>
</figure>The "rtp-rtcp-mux" parameter MAY be included in any transport
specification that use RTP where RTP and RTCP multiplexing is desired
and indicates in a SETUP request that multiplexing is requested. If the
SETUP response also includes the parameter then RTP and RTCP
multiplexing SHALL be used for that transport specification. A SETUP
request may indicate address information for both RTP and RTCP for
backwards compatibility reasons. If RTP and RTCP multiplexing is used
then only the information specified for RTP SHALL be used.</t>
<t>For capability exchange, an RTSP feature tag for RTP and RTCP
multiplexing is defined: "setup.rtp-mux".</t>
<t>RTSP servers and clients that supports "D-ICE" lower layer transport
in combination with RTP SHALL also implement RTP and RTCP multiplexing
as specified in this section and <xref
target="I-D.ietf-avt-rtp-and-rtcp-mux"></xref>.</t>
</section>
<section title="Open Issues">
<t>Below is listed the known open issues and questions that needs to be
resolved:</t>
<t><list style="numbers">
<t>Need a descriptive section on how ICE works for RTSP folks.</t>
<t>No solution has been specified for how RTSP server's can initiate
a ICE restart. Either to add candidates or to reinitate the
connectivity checks in response to lost bindings. Basically required
to find a solution for this.</t>
<t>Does we need to support multiple components?</t>
<t>Is the role and processing the most optimal one that can be
used?</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document request registration in a number of registries, both
for RTSP and SDP.</t>
<section title="RTSP Feature Tags">
<t>This document request that two RTSP feature tags are registered in
the "RTSP feature tag" registry:</t>
<t><list style="hanging">
<t hangText="setup.rtp-mux">See Section <xref
target="rtp-mux"></xref>.</t>
<t hangText="setup.ice-d-m">See Section <xref
target="ice-feature-tag"></xref>.</t>
</list></t>
</section>
<section title="Transport Protocol Specifications">
<t>This document needs to register a number of transport protocol
combinations are registered in RTSP's "Transport Protocol
Specifications" registry.</t>
<t><list style="hanging">
<t hangText=""RTP/AVP/D-ICE":"></t>
<t hangText=""RTP/AVPF/D-ICE":"></t>
<t hangText=""RTP/SAVP/D-ICE":"></t>
<t hangText=""RTP/SAVPF/D-ICE":"></t>
</list></t>
</section>
<section title="RTSP Transport Parameters">
<t>This document requests that 4 transport parameters are registered
in RTSP's "Transport Parameters":</t>
<t><list style="hanging">
<t hangText=""candidates":">See Section <xref
target="sec-ice-cand"></xref>.</t>
<t hangText=""ICE-Password":">See Section <xref
target="sec-ice-pwd"></xref>.</t>
<t hangText=""ICE-Userfrag":">See Section <xref
target="sec-ice-pwd"></xref>.</t>
<t hangText=""rtp-rtcp-mux":">See Section <xref
target="rtp-mux"></xref>.</t>
</list></t>
</section>
<section title="RTSP Status Codes">
<t>This document requests that 2 assignments are done in the "RTSP
Status Codes" registry. The suggested values are:</t>
<t><list style="hanging">
<t hangText="150:">See Section <xref
target="sec-sc-150"></xref>.</t>
<t hangText="480:">See Section <xref
target="sec-sc-480"></xref>.</t>
</list></t>
</section>
<section title="SDP Attribute">
<t>The registration of one SDP attribute is requested: <figure>
<artwork><![CDATA[ SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of name: att-field
Type of attribute: Session level only
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: No values defined.
Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com
phone: +46 8 404 82 87
]]></artwork>
</figure></t>
<t></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>ICE <xref target="I-D.ietf-mmusic-ice"></xref> provides an extensive
discussion on security considerations which applies here as well.</t>
<section title="ICE and RTSP">
<t>A long-standing risk with transmitting a packet stream over UDP is
that the host may not be interested in receiving the stream. On
today's Internet many hosts are behind NATs or operate host firewalls
which do not respond to unsolicited packets with an ICMP port
unreachable error. Thus, an attacker can construct SDP with a victim's
IP address and cause a flood of media packets to be sent to a victim.
The addition of ICE, as described in this document, provides
protection from the attack described above. By performing the ICE
connectivity check, the media server receives confirmation that the
RTSP client wants the media. While this protection could also be
implemented by requiring the IP addresses in the SDP match the IP
address of the RTSP signaling packet, such a mechanism does not
protect other hosts with the same IP address (such as behind the same
NAT), and such a mechanism would prohibit separating the RTSP
controller from the media playout device (e.g., an IP-enabled remote
control and an IP-enabled television).</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Rémi Denis-Courmont for
suggesting the method of integrating ICE in RTSP signalling, Dan Wing
for help with the security section and numerous other issues.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4566'?>
<?rfc include="reference.RFC.5234"?>
<?rfc include='reference.I-D.ietf-mmusic-rfc2326bis'?>
<?rfc include='reference.I-D.ietf-mmusic-ice'?>
<?rfc include='reference.I-D.ietf-avt-rtp-and-rtcp-mux'?>
<?rfc include='reference.I-D.ietf-behave-rfc3489bis'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-mmusic-rtsp-nat-evaluation'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.2326'?>
<?rfc include='reference.RFC.4340'?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:34:32 |