draft-ietf-mmusic-rtsp-nat-14.txt   draft-ietf-mmusic-rtsp-nat-15.txt 
Network Working Group J. Goldberg Network Working Group J.I. Goldberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: May 19, 2013 Ericsson Expires: November 03, 2013 Ericsson
T. Zeng T. Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
November 15, 2012 May 02, 2013
A Network Address Translator (NAT) Traversal mechanism for media A Network Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP) controlled by Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-14 draft-ietf-mmusic-rtsp-nat-15
Abstract Abstract
This document defines a solution for Network Address Translation This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams setup and controlled (NAT) traversal for datagram based media streams setup and controlled
with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Interactive Connectivity Establishment (ICE) adapted to use RTSP as a Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
signalling channel, defining the necessary extra RTSP extensions and signalling channel, defining the necessary extra RTSP extensions and
procedures. procedures.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2013. This Internet-Draft will expire on November 03, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 7 4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 7 4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6
4.2. ICE Candidate Transport Header Parameter . . . . . . . . . 8 4.2. ICE Candidate Transport Header Parameter . . . . . . . . 8
4.3. ICE Password and Username Transport Header Parameters . . 11 4.3. ICE Password and Username Transport Header Parameters . . 10
4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11
4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1. 150 ICE connectivity checks in progress . . . . . . . 12 4.5.1. 150 ICE connectivity checks in progress . . . . . . . 11
4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12
4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . . 12 4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . 12
4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 13 4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12
4.8. ICE Features Not Required in RTSP . . . . . . . . . . . . 13 5. ICE-RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. ICE Features Not Required . . . . . . . . . . . . . . . . 13
4.8.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . 13
4.8.3. ICE Remote Candidate Transport Header Parameter . . . 13 5.1.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . 13
5. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 14 5.1.3. ICE Remote Candidate Transport Header Parameter . . . 13
5.1. Session description and RTSP DESCRIBE (optional) . . . . . 14 5.2. High-Reachability Configuration . . . . . . . . . . . . . 13
5.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15 6. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 14
5.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15 6.1. Session description and RTSP DESCRIBE (optional) . . . . 14
5.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 16 6.2. Setting up the Media Streams . . . . . . . . . . . . . . 15
5.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 17 6.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . 15
5.6. Server to Client ICE Connectivity Checks . . . . . . . . . 18 6.4. Gathering Candidates . . . . . . . . . . . . . . . . . . 16
5.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 6.5. RTSP Server Response . . . . . . . . . . . . . . . . . . 16
5.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 6.6. Server to Client ICE Connectivity Checks . . . . . . . . 17
5.9. Server Connectivity Checks Complete . . . . . . . . . . . 19 6.7. Client to Server ICE Connectivity Check . . . . . . . . . 18
5.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 19 6.8. Client Connectivity Checks Complete . . . . . . . . . . . 19
5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19 6.9. Server Connectivity Checks Complete . . . . . . . . . . . 19
5.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.10. Freeing Candidates . . . . . . . . . . . . . . . . . . . 19
5.13. Server Side Changes After Steady State . . . . . . . . . . 20 6.11. Steady State . . . . . . . . . . . . . . . . . . . . . . 20
6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22 6.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22 6.13. Server Side Changes After Steady State . . . . . . . . . 21
6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 7. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 23 7.1. Media Handling Proxies . . . . . . . . . . . . . . . . . 23
7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 24 7.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 23
8. Fallback and Using Partial ICE functionality to improve 7.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . 23
NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . . 24 8. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Fallback and Using Partial ICE functionality to improve
9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 26 NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . 25
9.2. Transport Protocol Specifications . . . . . . . . . . . . 26
9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 27 10.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . 27
9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 27 10.2. Transport Protocol Specifications . . . . . . . . . . . 27
9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 27 10.3. RTSP Transport Parameters . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 28
10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 28 10.5. Notify-Reason value . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0
[I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control [I-D.ietf-mmusic-rfc2326bis] are protocols used to setup and control
one or more media streams delivering media to receivers. It is one or more media streams delivering media to receivers. It is
RTSP's functionality of setting up media streams that cause serious RTSP's functionality of setting up media streams that cause serious
issues with Network Address Translators (NAT) [RFC3022] unless extra issues with Network Address Translators (NAT) [RFC3022] unless extra
provisions are taken by the protocol. There is thus a need for a NAT provisions are taken by the protocol. There is thus a need for a NAT
traversal mechanism for the media setup using RTSP. traversal mechanism for the media setup using RTSP.
skipping to change at page 4, line 49 skipping to change at page 4, line 16
media delivery from server to client. If future extensions are media delivery from server to client. If future extensions are
specified for other delivery modes than "PLAY", then the specified for other delivery modes than "PLAY", then the
optimizations in regards to when PLAY request are sent needs to be optimizations in regards to when PLAY request are sent needs to be
reconsidered. reconsidered.
The NAT problem for RTSP signalling traffic itself is beyond the The NAT problem for RTSP signalling traffic itself is beyond the
scope of this document and is left for future study should the need 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 arise, because it is a less prevalent problem than the NAT problem
for RTSP media streams. for RTSP media streams.
The ICE usage defined in this specification is called ICE-RTSP and
does not match the full ICE for SIP/SDP or ICE-Lite as defined in the
ICE specification [RFC5245]. ICE-RTSP is tailored to the needs of
RTSP and is slightly simpler than ICE-Full for both clients and
servers.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Solution Overview 3. Solution Overview
This overview assumes that the reader has some familiarity with how This overview assumes that the reader has some familiarity with how
ICE [RFC5245] in the context of "SIP: Session Initiation Protocol" ICE [RFC5245] in the context of "SIP: Session Initiation Protocol"
skipping to change at page 5, line 31 skipping to change at page 5, line 11
header with a new ICE feature tag. Note: Both mechanisms should header with a new ICE feature tag. Note: Both mechanisms should
supported, as there are various use cases where only one of them supported, as there are various use cases where only one of them
is used. is used.
2. The RTSP client reviews the session description returned, for 2. The RTSP client reviews the session description returned, for
example by an RTSP DESCRIBE message, to determine what media example by an RTSP DESCRIBE message, to determine what media
streams need to be setup. For each of these media streams where streams need to be setup. For each of these media streams where
the transport protocol supports Session Traversal Utilities for the transport protocol supports Session Traversal Utilities for
(NAT) (STUN) [RFC5389] based connectivity checks, the client (NAT) (STUN) [RFC5389] based connectivity checks, the client
gathers candidate addresses. See section 4.1.1 in ICE gathers candidate addresses. See section 4.1.1 in ICE
[RFC5245]. The client then installs the STUN servers on each of [RFC5245]. The client then runs a STUN server on each of the
the local candidates transport addresses it has gathered. local candidates transport addresses it has gathered.
3. The RTSP client sends SETUP requests with both a transport 3. The RTSP client sends SETUP requests with both a transport
specification with a lower layer indicating ICE and a new RTSP specification with a lower layer indicating ICE and a new RTSP
Transport header parameter "candidates" listing the ICE Transport header parameter "candidates" listing the ICE
candidates for each media stream. candidates for each media stream.
4. After receiving the list of candidates from a client, the RTSP 4. After receiving the list of candidates from a client, the RTSP
server gathers its own candidates. If the server has a public server gathers its own candidates. If the server is not behind
IP address, then a single candidate per address family (e.g. a NAT, then a single candidate per address family (e.g. IPv4
IPv4 and IPv6), media stream and media component tuple can be and IPv6), media stream and media component tuple can be
included to reduce the number of combinations and speed up the included to reduce the number of combinations and speed up the
completion. completion.
5. The server sets up the media and if successful responds to the 5. The server sets up the media and if successful responds to the
SETUP request with a 200 OK response. In that response the SETUP request with a 200 OK response. In that response the
server selects the transport specification using ICE and server selects the transport specification using ICE and
includes its candidates in the candidates parameter. includes its candidates in the candidates parameter.
6. The server starts the connectivity checks following the 6. The server starts the connectivity checks following the
procedures described in Section 5.7 and 5.8 of ICE [RFC5245]. procedures described in Section 5.7 and 5.8 of ICE [RFC5245].
If the server has a public IP address with a single candidate If the server is not behind a NAT and uses a public IP address
per media stream, component and address family, then the server with a single candidate per media stream, component and address
may be configured to not initiate connectivity checks. family, then the server may be configured to not initiate
connectivity checks.
7. The client receives the SETUP response and learns the candidate 7. The client receives the SETUP response and learns the candidate
address to use for the connectivity checks, and then initiates addresses to use for the connectivity checks, and then initiates
its connectivity check, following the procedures in Section 6 of its connectivity check, following the procedures in Section 6 of
ICE [RFC5245]. ICE [RFC5245].
8. When a connectivity check from the client reaches the server it 8. When a connectivity check from the client reaches the server it
will result in a triggered check from the server. This is why will result in a triggered check from the server. This is why
servers with a public IP address can wait until this triggered servers not behind a NAT can wait until this triggered check to
check to send out any checks for itself, so saving resources and send out any checks for itself, so saving resources and
mitigating the DDoS potential from server connectivity checks. mitigating the DDoS potential from server connectivity checks.
9. When the client has concluded its connectivity checks, including 9. When the client has concluded its connectivity checks, including
promoting candidates, and has correspondingly received the promoting candidates, and has correspondingly received the
server connectivity checks on the promoted candidates for all server connectivity checks on the promoted candidates for all
mandatory components of all media streams, it can issue a PLAY mandatory components of all media streams, it can issue a PLAY
request. If the connectivity checks have not concluded request. If the connectivity checks have not concluded
successfully, then the client may send a new SETUP request if it successfully, then the client may send a new SETUP request if it
has any new information or believes the server may be able to do has any new information or believes the server may be able to do
more that can result in successful checks. more that can result in successful checks.
skipping to change at page 6, line 46 skipping to change at page 6, line 24
the connectivity checks, or a 480 (ICE Processing Failed) the connectivity checks, or a 480 (ICE Processing Failed)
response to indicate a failure of the checks. If the checks are response to indicate a failure of the checks. If the checks are
successful, then the server sends a 200 OK response and starts successful, then the server sends a 200 OK response and starts
delivering media. delivering media.
The client and server may release unused candidates when the ICE The client and server may release unused candidates when the ICE
processing has concluded and a single candidate per component has processing has concluded and a single candidate per component has
been promoted and a PLAY response has been received (Client) or sent been promoted and a PLAY response has been received (Client) or sent
(Server). (Server).
The client SHALL continue to use STUN to send keep-alive for the used The client needs to continue to use STUN as a keep-alive mechanism
bindings. This is important since RTSP media sessions often contain for the used candidate pairs to keep their NAT bindings current.
only media traffic from the server to the client so the bindings in RTSP Servers behind NATs will also need to send keep-alive messages
the NAT need to be refreshed by the client to server traffic provided when not sending media. This is important since RTSP media sessions
by the STUN keep-alive. often contain only media traffic from the server to the client so the
bindings in the NAT need to be refreshed by client to server traffic
provided by the STUN keep-alive.
4. RTSP Extensions 4. RTSP Extensions
This section defines the necessary RTSP extensions for performing ICE This section defines the necessary RTSP extensions for performing ICE
with RTSP. Note that these extensions are based on the SDP with RTSP. Note that these extensions are based on the SDP
attributes in the ICE specification unless expressly indicated. attributes in the ICE specification unless expressly indicated.
4.1. ICE Transport Lower Layer 4.1. ICE Transport Lower Layer
A new lower layer "D-ICE" for transport specifications is defined. A new lower layer "D-ICE" for transport specifications is defined.
This lower layer is datagram clean except that the protocol used must This lower layer is datagram clean except that the protocol used must
be demultiplexiable with STUN messages (see STUN [RFC5389]). With be possible to demultiplex from STUN messages (see STUN [RFC5389]).
datagram clean we mean that it must be capable of describing the 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 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 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 lower layer can be any transport type defined for ICE which does
provide datagram transport capabilities. UDP based transport provide datagram transport capabilities. UDP based transport
candidates are defined in ICE [RFC5245] and MUST be supported. It is candidates are defined in ICE [RFC5245] and MUST be supported. It is
OPTIONAL to also support TCP based candidates as defined by "TCP OPTIONAL to also support TCP based candidates as defined by "TCP
Candidates with Interactive Connectivity Establishment (ICE)" Candidates with Interactive Connectivity Establishment (ICE)"
[RFC6544]. The TCP based candidate fulfills the requirements on [RFC6544]. The TCP based candidate fulfills the requirements on
providing datagram transport and can thus be used in combination with providing datagram transport and can thus be used in combination with
RTP. Additional transport types for candidates may be defined in the RTP. Additional transport types for candidates may be defined in the
skipping to change at page 8, line 18 skipping to change at page 7, line 45
REQUIRED that one include the unicast indicator parameter, (see REQUIRED that one include the unicast indicator parameter, (see
section 18.52 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). section 18.52 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]).
candidates: The "candidates" parameter SHALL be included as this candidates: The "candidates" parameter SHALL be included as this
specify at least one candidate to try to establish a working specify at least one candidate to try to establish a working
transport path with. transport path with.
dest_addr: This parameter SHALL NOT be included as "candidates" is dest_addr: This parameter SHALL NOT be included as "candidates" is
used instead to provide the necessary address information. used instead to provide the necessary address information.
ICE-Password: This parameter SHALL be included (See Section ICE-Password: This parameter SHALL be included (See
Section 4.2). Section Section 4.2).
ICE-ufrag: This parameter SHALL be included (See Section ICE-ufrag: This parameter SHALL be included (See
Section 4.2). Section Section 4.2).
4.2. ICE Candidate Transport Header Parameter 4.2. ICE Candidate Transport Header Parameter
This section defines a new RTSP transport parameter for carrying ICE This section defines a new RTSP transport parameter for carrying ICE
candidates related to the transport specification they appear within, candidates related to the transport specification they appear within,
which may then be validated with an end-to-end connectivity check which may then be validated with an end-to-end connectivity check
using STUN [RFC5389]. Transport parameters may only occur once in using STUN [RFC5389]. Transport parameters may only occur once in
each transport specification. For transport specifications using each transport specification. For transport specifications using
"D-ICE" as lower layer, this parameter MUST be present. The "D-ICE" as lower layer, this parameter MUST be present. The
parameter can contain one or more ICE candidates. In the SETUP parameter can contain one or more ICE candidates. In the SETUP
skipping to change at page 9, line 38 skipping to change at page 9, line 4
rel-port = <See section 15.1 of [RFC5245]> rel-port = <See section 15.1 of [RFC5245]>
tcp-type-ext = <See section 4.5 of [RFC6544]> tcp-type-ext = <See section 4.5 of [RFC6544]>
extension-att-name = <See section 15.1 of [RFC5245]> extension-att-name = <See section 15.1 of [RFC5245]>
extension-att-value = <See section 15.1 of [RFC5245]> extension-att-value = <See section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]> connection-address = <See [RFC4566]>
port = <See [RFC4566]> port = <See [RFC4566]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]> EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]> DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
<connection-address>: is the unicast IP address of the candidate, <connection-address>: is the unicast IP address of the candidate,
allowing for IPv4 addresses, IPv6 addresses and Fully qualified allowing for IPv4 addresses, IPv6 addresses and Fully qualified
domain names (FQDN), taken from SDP [RFC4566]. Note, the syntax domain names (FQDN), taken from SDP [RFC4566]. Note, the syntax
allows multicast addresses, they SHALL NOT be used in this allows multicast addresses, but they SHALL NOT be used in this
context. The connection address SHOULD be on the same format context. The connection address SHOULD be on the same format
(explicit IP or FQDN) as in the dest_addr parameter used to (explicit IP or FQDN) as in the dest_addr parameter used to
express fallbacks. An IP address SHOULD be used, but an FQDN MAY express fallbacks. An IP address SHOULD be used, but an FQDN MAY
be used in place of an IP address. In that case, when receiving a be used in place of an IP address. In that case, when receiving a
SETUP request or response containing an FQDN in a candidate SETUP request or response containing an FQDN in a candidate
parameter, the FQDN is looked up in the DNS first using an AAAA parameter, the FQDN is looked up in the DNS first using an AAAA
record (assuming the agent supports IPv6), and if no result is record (assuming the agent supports IPv6), and if no result is
found or the agent only supports IPv4, using an A record. If the found or the agent only supports IPv4, using an A record. If the
DNS query returns more than one IP address, one is chosen, and DNS query returns more than one IP address, one is chosen, and
then used for the remainder of ICE processing which in RTSP is then used for the remainder of ICE processing which in RTSP is
skipping to change at page 10, line 21 skipping to change at page 9, line 35
Interactive Connectivity Establishment (ICE)" [RFC6544] defines Interactive Connectivity Establishment (ICE)" [RFC6544] defines
how TCP is used as candidates. Additional extensibility is how TCP is used as candidates. Additional extensibility is
provided to allow for future transport protocols to be used with provided to allow for future transport protocols to be used with
ICE, such as the Datagram Congestion Control Protocol (DCCP) ICE, such as the Datagram Congestion Control Protocol (DCCP)
[RFC4340]. [RFC4340].
<foundation>: is an identifier that is equivalent for two <foundation>: is an identifier that is equivalent for two
candidates that are of the same type, share the same base, and 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 come from the same STUN server, and is composed of one to thirty
two <ice-char>. The foundation is used to optimize ICE two <ice-char>. The foundation is used to optimize ICE
performance in the Frozen algorithm (as described in [RFC5245]. performance in the Frozen algorithm (as described in [RFC5245]).
<component-id>: identifies the specific component of the media <component-id>: identifies the specific component of the media
stream for which this is a candidate and is a positive integer stream for which this is a candidate and is a positive integer
between 1 and 256. It MUST start at 1 and MUST increment by 1 for 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 each component of a particular candidate. For media streams based
on RTP, candidates for the actual RTP media MUST have a component 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. ID of 1, and candidates for RTCP MUST have a component ID of 2
Other types of media streams which require multiple components unless RTP and RTCP Multiplexing (Section 8) is used when the
MUST develop specifications which define the mapping of components second component is omitted and RTP and RTCP is both transported
to component IDs. See Section 14 in [RFC5245] for additional over the first component. Other types of media streams which
discussion on extending ICE to new media streams. require multiple components MUST develop specifications which
define the mapping of components to component IDs. See Section 14
in [RFC5245] for additional discussion on extending ICE to new
media streams.
<priority>: is a positive integer between 1 and (2**31 - 1). <priority>: is a positive integer between 1 and (2**31 - 1).
<cand-type>: encodes the type of candidate. The ICE specification <cand-type>: encodes the type of candidate. The ICE specification
defines the values "host", "srflx", "prflx" and "relay" for host, defines the values "host", "srflx", "prflx" and "relay" for host,
server reflexive, peer reflexive and relayed candidates, server reflexive, peer reflexive and relayed candidates,
respectively. The set of candidate types is extensible for the respectively. The set of candidate types is extensible for the
future. future.
<rel-addr> and <rel-port>: convey transport addresses related to the <rel-addr> and <rel-port>: convey transport addresses related to the
candidate, useful for diagnostics and other purposes. <rel-addr> candidate, useful for diagnostics and other purposes. <rel-addr>
and <rel-port> MUST be present for server reflexive, peer and <rel-port> MUST be present for server reflexive, peer
reflexive and relayed candidates. If a candidate is server or reflexive and relayed candidates. If a candidate is server or
peer reflexive, <rel-addr> and <rel-port> is equal to the base for peer reflexive, <rel-addr> and <rel-port> is equal to the base for
that server or peer reflexive candidate. If the candidate is that server or peer reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> is equal to the mapped address relayed, <rel-addr> and <rel-port> is equal to the mapped address
in the Allocate Response that provided the client with that in the Allocate Response that provided the client with that
relayed candidate (see Appendix B.3 of ICE [RFC5245] for a relayed candidate (see Appendix B.3 of ICE [RFC5245] for a
discussion of its purpose). If the candidate is a host candidate discussion of its purpose). If the candidate is a host candidate
<rel-addr> and <rel-port> MUST be omitted. <rel-addr> and <rel-port> MUST be omitted.
skipping to change at page 12, line 14 skipping to change at page 11, line 32
The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the 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" "Supported" header in all SETUP requests that contain the "D-ICE"
lower layer transport. lower layer transport.
4.5. Status Codes 4.5. Status Codes
ICE needs two new RTSP response codes to indicate correctly progress ICE needs two new RTSP response codes to indicate correctly progress
and errors. and errors.
+------+----------------------------------------------+-------------+ +---------+------------------------------------------+--------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+----------------------------------------------+-------------+ +---------+------------------------------------------+--------------+
| 150 | Server still working on ICE connectivity | PLAY | | 150 | Server still working on ICE connectivity | PLAY |
| | checks | | | | checks | |
| 480 | ICE Connectivity check failure | PLAY, SETUP | | | | |
+------+----------------------------------------------+-------------+ | 480 | ICE Connectivity check failure | PLAY, SETUP |
+---------+------------------------------------------+--------------+
Table 1: New Status codes and their usage with RTSP methods Table 1: New Status codes and their usage with RTSP methods
4.5.1. 150 ICE connectivity checks in progress 4.5.1. 150 ICE connectivity checks in progress
The 150 response code indicates that ICE connectivity checks are The 150 response code indicates that ICE connectivity checks are
still in progress and haven't concluded. This response SHALL be sent still in progress and haven't concluded. This response SHALL be sent
within 200 milliseconds of receiving a PLAY request that currently within 200 milliseconds of receiving a PLAY request that currently
can't be fulfilled because ICE connectivity checks are still running. can't be fulfilled because ICE connectivity checks are still running.
Subsequently, every 3 seconds after the previous one was sent, a 150 Subsequently, every 3 seconds after the previous one was sent, a 150
reply shall be sent until the ICE connectivity checks conclude either reply shall be sent until the ICE connectivity checks conclude either
successfully or in failure, and a final response for the request can successfully or in failure, and a final response for the request can
be provided. be provided.
4.5.2. 480 ICE Processing Failed 4.5.2. 480 ICE Processing Failed
skipping to change at page 13, line 17 skipping to change at page 12, line 43
If the server supports the media NAT traversal for RTSP controlled If the server supports the media NAT traversal for RTSP controlled
sessions as described in this RFC, then the Server SHOULD include the sessions as described in this RFC, then the Server SHOULD include the
"a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing
content served by the server. This is an session level only content served by the server. This is an session level only
attribute. attribute.
The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is: The ABNF [RFC5234] for the "rtsp-ice-d-m" attribute is:
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
4.8. ICE Features Not Required in RTSP 5. ICE-RTSP
This section discusses differences between the regular ICE usage
defined in [RFC5245] and ICE-RTSP. The reasons for the differences
relate to the clearer client/server roles that RTSP provides and how
the RTSP Session establishment signalling occurs within RTSP compared
to SIP/SDP Offer/Answer.
5.1. ICE Features Not Required
A number of ICE signalling features are not needed with RTSP and are A number of ICE signalling features are not needed with RTSP and are
discussed below. discussed below.
4.8.1. ICE-Lite 5.1.1. ICE-Lite
The ICE-Lite attribute shall not be used in the context of RTSP. The The ICE-Lite attribute shall not be used in the context of RTSP. The
ICE specification describes two implementations of ICE: Full and ICE specification describes two implementations of ICE: Full and
Lite, where hosts that are not behind a NAT are allowed to implement Lite, where hosts that are not behind a NAT are allowed to implement
only Lite. For RTSP, the Lite implementation is insufficient because only Lite. For RTSP, the Lite implementation is insufficient because
it does not cause the media server to send a connectivity check, it does not cause the media server to send a connectivity check,
which is used to protect against making the RTSP server a denial of which is used to protect against making the RTSP server a denial of
service tool. This document defines another variation implementation service tool.
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.
4.8.2. ICE-Mismatch 5.1.2. ICE-Mismatch
The ice-mismatch parameter indicates that the offer arrived with a The ice-mismatch parameter indicates that the offer arrived with a
default destination for a media component that didn't have a default destination for a media component that didn't have a
corresponding candidate attribute. This is not needed for RTSP as corresponding candidate attribute. This is not needed for RTSP as
the ICE based lower layer transport specification either is supported the ICE based lower layer transport specification either is supported
or another alternative transport is used. This is always explicitly or another alternative transport is used. This is always explicitly
indicated in the SETUP request and response. indicated in the SETUP request and response.
4.8.3. ICE Remote Candidate Transport Header Parameter 5.1.3. ICE Remote Candidate Transport Header Parameter
The Remote candidate attribute is not needed for RTSP for the The Remote candidate attribute is not needed for RTSP for the
following reasons. Each SETUP results in an independent ICE following reasons. Each SETUP results in an independent ICE
processing chain which either fails or results in promoting a single processing chain which either fails or results in promoting a single
candidate pair to usage. If a new SETUP request for the same media candidate pair to usage. If a new SETUP request for the same media
is sent, this needs to use a new username fragment and password to is sent, this needs to use a new username fragment and password to
avoid any race conditions or uncertainty about which round of avoid any race conditions or uncertainty about which round of
processing the STUN requests relate to. processing the STUN requests relate to.
5. Detailed Solution 5.2. High-Reachability Configuration
ICE-RTSP contains a high-reachability configuration when the RTSP
Servers are not behind NATs. Please note that "not behind NATs" may
apply in some special cases also for RTSP Servers behind NATs given
that they are in an address space that has reachability for all the
RTSP clients intended to able to reach the server. The high-
reachability configuration is similar to ICE-Lite as it allows for
some reduction in the server's burden. However, due to the need to
still verify that the client is actually present, the server must
also initiate binding requests and await binding responses. The
reduction for the high-reachability configuration of ICE-RTSP is that
they don't need to initiate their own checks, and instead rely on
triggered checks for verification. This also removes a denial of
service threat where a RTSP SETUP request will trigger large amount
of STUN connectivity checks towards provided candidate addresses.
6. Detailed Solution
This section describes in detail how the interaction and flow of ICE This section describes in detail how the interaction and flow of ICE
works with RTSP messages. works with RTSP messages.
5.1. Session description and RTSP DESCRIBE (optional) 6.1. Session description and RTSP DESCRIBE (optional)
The RTSP server should indicate it has support for ICE by sending the The RTSP server should indicate it has support for ICE by sending the
"a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE "a=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 message if SDP is used. This allows RTSP clients to only send the
new ICE exchanges with servers that support ICE thereby limiting the new ICE exchanges with servers that support ICE thereby limiting the
overhead on current non-ICE supporting RTSP servers. When not using overhead on current non-ICE supporting RTSP servers. When not using
RTSP DESCRIBE it is still RECOMMENDED to use the SDP attribute for RTSP DESCRIBE it is still RECOMMENDED to use the SDP attribute for
the session description. the session description.
A Client can also use the DESCRIBE request to determine explicitly if A Client can also use the DESCRIBE request to determine explicitly if
skipping to change at page 15, line 35 skipping to change at page 15, line 15
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
a=rtsp-ice-d-m a=rtsp-ice-d-m
a=control: * a=control: *
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control: /audio a=control: /audio
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
a=control: /video a=control: /video
5.2. Setting up the Media Streams 6.2. Setting up the Media Streams
The RTSP client reviews the session description returned, for example The RTSP client reviews the session description returned, for example
by an RTSP DESCRIBE message, to determine what media resources need by an RTSP DESCRIBE message, to determine what media resources need
to be setup. For each of these media streams where the transport to be setup. For each of these media streams where the transport
protocol supports ICE connectivity checks, the client SHALL gather protocol supports ICE connectivity checks, the client SHALL gather
candidate addresses for UDP transport as described in section 4.1.1 candidate addresses for UDP transport as described in section 4.1.1
in ICE [RFC5245] according to standard ICE rather than the ICE-Lite in ICE [RFC5245] according to standard ICE rather than the ICE-Lite
implementation and according to section 5 of ICE TCP [RFC6544] for implementation and according to section 5 of ICE TCP [RFC6544] for
TCP based candidates. TCP based candidates.
5.3. RTSP SETUP Request 6.3. RTSP SETUP Request
The RTSP client will then send at least one SETUP request per media The RTSP client will then send at least one SETUP request per media
stream to establish the media streams required for the desired stream to establish the media streams required for the desired
session. For each media stream where it desires to use ICE it will session. For each media stream where it desires to use ICE it will
include a transport specification with "D-ICE" as the lower layer, include a transport specification with "D-ICE" as the lower layer,
and each media stream SHALL have its own unique combination of ICE and each media stream SHALL have its own unique combination of ICE
candidates and ICE-ufrag. This transport specification SHOULD be candidates and ICE-ufrag. This transport specification SHOULD be
placed first in the list to give it highest priority. It is placed first in the list to give it highest priority. It is
RECOMMENDED that additional transport specifications are provided as RECOMMENDED that additional transport specifications are provided as
a fallback in case of non-ICE supporting proxies. The RTSP client a fallback in case of non-ICE supporting proxies. The RTSP client
will be initiating and thus the controlling party in the ICE will be initiating and thus the controlling party in the ICE
processing. For example (Note that some lines are broken in processing. For example (Note that some lines are broken in
contradiction with the defined syntax due to space restrictions in contradiction with the defined syntax due to space restrictions in
the documenting format: the documenting format):
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313 CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host; 1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux, raddr 10.0.1.17 rport 8998"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
skipping to change at page 16, line 22 skipping to change at page 16, line 4
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0 C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313 CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY; Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates=" ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host; 1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux, raddr 10.0.1.17 rport 8998"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971", RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Supported: setup.ice-d-m, setup.rtp.rtcp.mux Supported: setup.ice-d-m, setup.rtp.rtcp.mux
5.4. Gathering Candidates 6.4. Gathering Candidates
Upon receiving a SETUP request the server can determine what media Upon receiving a SETUP request the server can determine what media
resource should be delivered and which transport alternatives that resource should be delivered and which transport alternatives that
the client supports. If one based on D-ICE is on the list of the client supports. If one based on D-ICE is on the list of
supported transports and preferred among the supported, the below supported transports and preferred among the supported, the below
applies. applies.
The transport specification will provide which media protocol is to The transport specification will provide which media protocol is to
be used and based on this and the clients candidates, the server be used and based on this and the clients candidates, the server
determines the protocol and if it supports ICE with that protocol. determines the protocol and if it supports ICE with that protocol.
skipping to change at page 17, line 19 skipping to change at page 16, line 50
is correctly configured. is correctly configured.
The above general consideration for servers applies also for TCP The above general consideration for servers applies also for TCP
based candidates. A general implementation should support several based candidates. A general implementation should support several
candidate collection techniques and connection types. For TCP based candidate collection techniques and connection types. For TCP based
candidates a high-reachability configured server is recommended to candidates a high-reachability configured server is recommended to
only offer Host candidates. In addition to passive connection types only offer Host candidates. In addition to passive connection types
the server can select to provide active or SO connection types to the server can select to provide active or SO connection types to
match the client's candidates. match the client's candidates.
5.5. RTSP Server Response 6.5. RTSP Server Response
The server determines if the SETUP request is successful from the The server determines if the SETUP request is successful from the
other perspectives and if so returns a 200 OK response; otherwise it other perspectives and if so returns a 200 OK response; otherwise it
returns an error code. At that point the server, having selected a returns an error code. At that point the server, having selected a
transport specification using the "D-ICE" lower layer, will need to transport specification using the "D-ICE" lower layer, will need to
include that transport specification in the response message. The include that transport specification in the response message. The
transport specification SHALL include the candidates gathered in transport specification SHALL include the candidates gathered in
Section 5.4 in the "candidates" transport header parameter as well as Section 6.4 in the "candidates" transport header parameter as well as
the server's username fragment and password. In the case that there the server's username fragment and password. In the case that there
are no valid candidate pairs with the combination of the client and are no valid candidate pairs with the combination of the client and
server candidates, a 480 (ICE Processing Failed) error response SHALL server candidates, a 480 (ICE Processing Failed) error response SHALL
be returned which MUST include the server's candidates. The return be returned which MUST include the server's candidates. The return
of a 480 error allows both the server and client to release their of a 480 error allows both the server and client to release their
candidates. candidates.
Example of a successful response to the request in Section 5.3. Example of a successful response to the request in Section 6.3.
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 313 CSeq: 313
Session: 12345678 Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3; Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates=" ICE-Password=pos12Dgp9FcAjpq82ppaF; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host" 1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT Accept-Ranges: NPT
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux Supported: setup.ice-d-m, setup.rtp.rtcp.mux
5.6. Server to Client ICE Connectivity Checks 6.6. Server to Client ICE Connectivity Checks
The server shall start the connectivity checks following the The server shall start the connectivity checks following the
procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless
it is configured to use the high-reachability option. If it is then it is configured to use the high-reachability option. If it is then
it MAY suppress its own checks until the servers checks are triggered it MAY suppress its own checks until the servers checks are triggered
by the client's connectivity checks. by the client's connectivity checks.
Please note that ICE [RFC5245] section 5.8 does specify that the Please note that ICE [RFC5245] section 5.8 does specify that the
initiation of the checks are paced and new ones are only started initiation of the checks are paced and new ones are only started
every Ta milliseconds. The motivation for this is documented in every Ta milliseconds. The motivation for this is documented in
Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within Appendix B.1 of ICE [RFC5245] as for SIP/SDP all media streams within
an offer/answer dialog are running using the same queue. To ensure an offer/answer dialog are running using the same queue. To ensure
the same behavior with RTSP, the server SHALL use a single pacer the same behavior with RTSP, the server SHALL use a single pacer
queue for all media streams within each RTSP session. queue for all media streams within each RTSP session.
The values for the pacing of STUN and TURN transactions Ta and RTO The values for the pacing of STUN and TURN transactions Ta and RTO
can be configured but have the same minimum values defined in the ICE can be configured but have the same minimum values defined in the ICE
specification. specification.
When a connectivity check from the client reaches the server it will When a connectivity check from the client reaches the server it will
result in a triggered check from the server as specified in section result in a triggered check from the server as specified in
7.2.1.4 of ICE [RFC5245]. This is why servers with a high Section 7.2.1.4 of ICE [RFC5245]. This is why servers with a high
reachability address can wait until this triggered check to send out reachability address can wait until this triggered check to send out
any checks for itself so saving resources and mitigating the DDoS any checks for itself so saving resources and mitigating the DDoS
potential. potential.
5.7. Client to Server ICE Connectivity Check 6.7. Client to Server ICE Connectivity Check
The client receives the SETUP response and learns the candidate The client receives the SETUP response and learns the candidate
address to use for the connectivity checks. The client SHALL addresses to use for the connectivity checks. The client SHALL
initiate its connectivity check, following the procedures in Section initiate its connectivity check, following the procedures in
6 of ICE [RFC5245]. The STUN transaction pacer SHALL be used across Section 6 of ICE [RFC5245]. The pacing of STUN transactions
all media streams part of the same RTSP session. (Section B.1 of [RFC5245]) SHALL be used across all media streams
that are part of the same RTSP session.
Aggressive nomination SHALL be used with RTSP. This doesn't have the Aggressive nomination SHOULD be used with RTSP during initial SETUP
negative impact that it has in offer/answer as media playing only for a resource. This doesn't have all the negative impact that it
starts after issuing a PLAY request. has in offer/answer as media playing only starts after issuing a PLAY
request. Thus the issue with a change of the media path being used
for delivery can be avoided by not issuing a PLAY request while STUN
connectivity checks are still outstanding. Aggressive nomination can
result in multiple candidate pairs having their nominated flag set
but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY
request is sent the media will arrive on the pair with the highest
priority. Note, different media resources may still end up with
different foundations.
5.8. Client Connectivity Checks Complete Note: The above does not change ICE and its handling of aggressive
nomination. Using aggressive nomination, a higher priority candidate
pair with an outstanding connectivity check message can move into the
Succeded state and will have its Nominated flag set. This happening
after another candidate pair for a given media stream having moved
into Succeded state. Thus moving the used pair to this higher
priority candidate pair. To avoid this occurring during actual media
transport, the RTSP client can add additional logic when the ICE
processing overall is completed to indicate if there is still higher
priority connectivity checks outstanding. If some check is still
outstanding, the implementation can choose to wait until some
additional timeout triggers or the outstanding checks completes
before progressing with a PLAY request. An alternative is to accept
the risk for a path change during media delivery and start playing
immediately.
RTSP clients that want to ensure that each media resource uses the
same path can use regular nomination where both the ICE processing
completion criteria can be controlled in addition to which media
streams being nominated for use. This does not affect the RTSP
server, as its role is the one of being controlled.
6.8. Client Connectivity Checks Complete
When the client has concluded all of its connectivity checks and has When the client has concluded all of its connectivity checks and has
nominated its desired candidate for a particular media stream, it MAY nominated its desired candidate pair for a particular media stream,
issue a PLAY request for that stream. Note, that due to the it MAY issue a PLAY request for that stream. Note, that due to the
aggressive nomination, there is a risk that any outstanding check may aggressive nomination, there is a risk that any outstanding check may
nominate another pair than what was already nominated. If the client nominate another pair than what was already nominated. The candidate
has locally determined that its checks have failed it may try pair with the highest priority will be used for the media. If the
client has locally determined that its checks have failed it may try
providing an extended set of candidates and update the server providing an extended set of candidates and update the server
candidate list by issuing a new SETUP request for the media stream. candidate list by issuing a new SETUP request for the media stream.
If the client concluded its connectivity checks successfully and If the client concluded its connectivity checks successfully and
therefore sent a PLAY request but the server cannot conclude therefore sent a PLAY request but the server cannot conclude
successfully, the server will respond with a 480 (ICE Processing successfully, the server will respond with a 480 (ICE Processing
Failed). Upon receiving the 480 (ICE Processing Failed) response, Failed). Upon receiving the 480 (ICE Processing Failed) response,
the client may send a new SETUP request assuming it has any new the client may send a new SETUP request assuming it has any new
information that can be included in the candidate list. If the information that can be included in the candidate list. If the
server is still performing the checks when receiving the PLAY request server is still performing the checks when receiving the PLAY request
it will respond with a 150 (CE connectivity checks in progress) it will respond with a 150 (ICE connectivity checks in progress)
response to indicate this. response to indicate this.
5.9. Server Connectivity Checks Complete 6.9. Server Connectivity Checks Complete
When the RTSP server receives a PLAY request, it checks to see that When the RTSP server receives a PLAY request, it checks to see that
the connectivity checks have concluded successfully and only then the connectivity checks have concluded successfully and only then
will it play the stream. If the PLAY request is for a particular will it play the stream. If the PLAY request is for a particular
media stream, the server only needs to check that the connectivity media stream, the server only needs to check that the connectivity
checks for that stream completed successfully. If the server has not checks for that stream completed successfully. If the server has not
concluded its connectivity checks, the server indicates that by concluded its connectivity checks, the server indicates that by
sending the 150 (ICE connectivity checks in progress) sending the 150 (ICE connectivity checks in progress)
(Section 4.5.1). If there is a problem with the checks, then the (Section 4.5.1). If there is a problem with the checks, then the
server sends a 480 response to indicate a failure of the checks. If server sends a 480 response to indicate a failure of the checks. If
the checks are successful then the server sends a 200 OK response and the checks are successful then the server sends a 200 OK response and
starts delivering media. starts delivering media.
5.10. Releasing Candidates 6.10. Freeing Candidates
Both server and client MAY release its non nominated candidates as Both server and client MAY free its non selected candidates as soon
soon as a 200 PLAY response has been issued/received and no as a 200 PLAY response has been issued/received and no outstanding
outstanding connectivity checks exist. connectivity checks exist.
5.11. Steady State 6.11. Steady State
The client and server SHALL use STUN to send keep-alive for the The client and server SHALL use STUN to send keep-alive messages for
nominated candidate pair(s) following the rules of Section 10 of ICE the nominated candidate pair(s) following the rules of Section 10 of
[RFC5245]. This is important as normally RTSP play mode sessions ICE [RFC5245]. This is important as normally RTSP play mode sessions
only contain traffic from the server to the client so the bindings in only contain traffic from the server to the client so the bindings in
the NAT need to be refreshed by the client to server traffic provided the NAT need to be refreshed by the client to server traffic provided
by the STUN keep-alive. by the STUN keep-alive.
5.12. Re-SETUP 6.12. Re-SETUP
The server SHALL support SETUP requests in PLAYING state, as long as
the SETUP changes only the ICE parameters, which are: ICE-Password,
ICE-ufrag and the content of ICE candidates.
If the client decides to change any parameters related to the media A client that decides to change any parameters related to the media
stream setup it will send a new SETUP request. In this new SETUP stream setup will send a new SETUP request. In this new SETUP
request the client MAY include a new different username fragment and request the client MAY include a new different username fragment and
password to use in the ICE processing. New username and password password to use in the ICE processing. New username and password
SHALL cause the ICE processing to start from the beginning again, SHALL cause the ICE processing to start from the beginning again,
i.e. an ICE restart. The client SHALL in case of ICE restart gather i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]). The client
candidates and include the candidates in the transport specification SHALL in case of ICE restart gather candidates and include the
for D-ICE. candidates in the transport specification for D-ICE.
ICE restarts may be triggered due to changes of clients or servers
attachment to the network, i.e. changes to the media streams
destination or source address or port. Most RTSP parameter changes
would not require an ICE restart, instead existing mechanisms in RTSP
for indicating from where in the RTP stream they apply should be
used. These include: Performing a pause prior to the parameter
change and then resume; or assuming the server supports using SETUP
during the PLAY state, using the RTP-Info header (Section 18.43 of
[I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media
stream the change shall apply.
The server SHALL support SETUP requests in PLAY state, as long as the
SETUP changes only the ICE parameters, which are: ICE-Password, ICE-
ufrag and the content of ICE candidates.
If the RTSP session is in playing state at the time of sending the If the RTSP session is in playing state at the time of sending the
SETUP request requiring ICE restart, then the ICE connectivity checks SETUP request requiring ICE restart, then the ICE connectivity checks
SHALL use Regular nomination. Any ongoing media delivery continues SHALL use Regular nomination. Any ongoing media delivery continues
on the previously nominated candidate pairs until the new pairs have on the previously nominated candidate pairs until the new pairs have
been nominated for the individual candidate. Once the nomination of been nominated for the individual candidate. Once the nomination of
the new candidate pair has completed, all unused candidates may be the new candidate pair has completed, all unused candidates may be
released. released.
5.13. Server Side Changes After Steady State 6.13. Server Side Changes After Steady State
A Server may require an ICE restart because of server side load A Server may require an ICE restart because of server side load
balancing or a failure resulting in an IP address and a port number balancing or a failure resulting in an IP address and a port number
change. It shall use the PLAY_NOTIFY method to inform the client change. It shall use the PLAY_NOTIFY method to inform the client
(Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason
header: ice-restart. The server will identify if the change is for a header: ice-restart. The server will identify if the change is for a
single media or for the complete session by including the single media or for the complete session by including the
corresponding URI in the PLAY_NOTIFY request. corresponding URI in the PLAY_NOTIFY request.
Upon receiving and responding to this PLAY_NOTIFY with ice-restart Upon receiving and responding to this PLAY_NOTIFY with ice-restart
reason the client SHALL gather new ICE candidates, send SETUP reason the client SHALL gather new ICE candidates, send SETUP
requests for each media stream part of the session. The server requests for each media stream part of the session. The server
provides its candidates in the SETUP response the same way as for the provides its candidates in the SETUP response the same way as for the
first time ICE processing. Both server and client shall provide new first time ICE processing. Both server and client shall provide new
ICE usernames and passwords. The client MAY issue the SETUP request ICE user names and passwords. The client MAY issue the SETUP request
while the session is in PLAYING state. while the session is in PLAYING state.
If the RTSP session is in PLAYING state when the client issues the If the RTSP session is in PLAYING state when the client issues the
SETUP request, the client SHALL use regular nomination. If not the SETUP request, the client SHALL use regular nomination. If not the
client will use the same procedures as for when first creating the client will use the same procedures as for when first creating the
session. session.
Note that keepalives on the previous set of candidate pairs should Note that keepalive messages on the previous set of candidate pairs
continue until all new candidate pairs have been nominated. After should continue until all new candidate pairs have been nominated.
having nominated a new set of candidate pairs, the client may After having nominated a new set of candidate pairs, the client may
continue to receive media for some additional time. Even if the continue to receive media for some additional time. Even if the
server stops delivering media over that candidate pair at the time of server stops delivering media over that candidate pair at the time of
nomination, media may arrive for up to one maximum segment lifetime nomination, media may arrive for up to one maximum segment lifetime
as defined in TCP (2 minutes). Unfortunately, if the RTSP server is as defined in TCP (2 minutes). Unfortunately, if the RTSP server is
divided into a separate controller and media stream, a failure may divided into a separate controller and media stream, a failure may
result in continued media delivery for a longer time than the maximum result in continued media delivery for a longer time than the maximum
segment lifetime, thus source filtering is RECOMMENDED. segment lifetime, thus source filtering is RECOMMENDED.
For example: For example:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854 CSeq: 854
Notify-Reason: ice-restart Notify-Reason: ice-restart
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Server: PhonyServer 1.1 Server: PhonyServer 1.1
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
skipping to change at page 22, line 15 skipping to change at page 22, line 48
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 315 CSeq: 315
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs; Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates=" ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
1 1 UDP 2130706431 192.0.2.56 47233 typ host" 1 1 UDP 2130706431 192.0.2.56 47233 typ host"
Accept-Ranges: NPT Accept-Ranges: NPT
Date: 11 March 2011 13:17:47 GMT Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
6. ICE and Proxies 7. ICE and Proxies
RTSP allows for proxies which can be of two fundamental types RTSP allows for proxies which can be of two fundamental types
depending on whether they relay and potentially cache the media or depending on whether they relay and potentially cache the media or
not. Their differing impact on the RTSP NAT traversal solution, not. Their differing impact on the RTSP NAT traversal solution,
including backwards compatibility, is explained below. including backwards compatibility, is explained below.
6.1. Media Handling Proxies 7.1. Media Handling Proxies
An RTSP proxy that relays or caches the media stream for a particular 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 media session can be considered to split the media transport into two
parts: A media transport between the server and the proxy according parts: A media transport between the server and the proxy according
to the proxy's need, and delivery from the proxy to the client. This to the proxy's need, and delivery from the proxy to the client. This
split means that the NAT traversal solution will need to be run on split means that the NAT traversal solution will need to be run on
each individual media leg according to need. each individual media leg according to need.
It is RECOMMENDED that any media handling proxy support the media NAT It is RECOMMENDED that any media handling proxy support the media NAT
traversal defined within this specification. This is for two traversal defined within this specification. This is for two
skipping to change at page 22, line 45 skipping to change at page 23, line 32
to be topology independent to support performing NAT traversal (to to be topology independent to support performing NAT traversal (to
the server) for non-NAT traversal capable clients present in the same the server) for non-NAT traversal capable clients present in the same
address domain as the proxy. address domain as the proxy.
For a proxy to support the media NAT traversal defined in this For a proxy to support the media NAT traversal defined in this
specification a proxy will need to implement the solution fully and specification a proxy will need to implement the solution fully and
be able to act as both a controlling and a controlled ICE peer. The be able to act as both a controlling and a controlled ICE peer. The
proxy also SHALL include the "setup.ice-d-m" feature tag in any proxy also SHALL include the "setup.ice-d-m" feature tag in any
applicable capability negotiation headers, such as "Proxy-Supported." applicable capability negotiation headers, such as "Proxy-Supported."
6.2. Signalling Only Proxies 7.2. Signalling Only Proxies
A signalling only proxy handles only the RTSP signalling and does not A signalling only proxy handles only the RTSP signalling and does not
have the media relayed through proxy functions. This type of proxy have the media relayed through proxy functions. This type of proxy
is not likely to work unless the media NAT traversal solution is in is not likely to work unless the media NAT traversal solution is in
place between the client and the server, because the Denial of place between the client and the server, because the Denial of
Service (DoS) protection measures, as discussed in Section 21.2.1 of Service (DoS) protection measures, as discussed in Section 21.2.1 of
RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery
to other addresses other than from where the RTSP signalling arrives to other addresses other than from where the RTSP signalling arrives
at the server. at the server.
The solution for the Signalling Only proxy is that it must forward The solution for the Signalling Only proxy is that it must forward
the RTSP SETUP requests including any transport specification with the RTSP SETUP requests including any transport specification with
the "D-ICE" lower layer and the related transport parameters. A the "D-ICE" lower layer and the related transport parameters. A
proxy supporting this functionality SHOULD indicate its capability by proxy supporting this functionality SHOULD indicate its capability by
always including the "setup.ice-d-m" feature tag in the "Proxy- always including the "setup.ice-d-m" feature tag in the "Proxy-
Supported" header. Supported" header.
6.3. Non-supporting Proxies 7.3. Non-supporting Proxies
A media handling proxy that doesn't support the ICE media NAT A media handling proxy that doesn't support the ICE media NAT
traversal specified here is assumed to remove the transport traversal specified here is assumed to remove the transport
specification and use any of the lower prioritized transport specification and use any of the lower prioritized transport
specifications if provided by the requester. The specification of specifications if provided by the requester. The specification of
such a non ICE transport enables the negotiation to complete, such a non ICE transport enables the negotiation to complete,
although with a less preferred method since a NAT between the proxy although with a less preferred method since a NAT between the proxy
and the client may result in failure of the media path. and the client may result in failure of the media path.
A non-media handling proxy is expected to ignore and simply forward A non-media handling proxy is expected to ignore and simply forward
all unknown transport specifications, however, this can only be all unknown transport specifications, however, this can only be
skipping to change at page 24, line 5 skipping to change at page 24, line 40
chain between the client and server support the functionality. In chain between the client and server support the functionality. In
case one or more proxy does not explicitly indicate support, it will case one or more proxy does not explicitly indicate support, it will
remove the feature tag "setup.ice-d-m". If that proxy is a non-media remove the feature tag "setup.ice-d-m". If that proxy is a non-media
handling one and the client would despite the lack of explicit handling one and the client would despite the lack of explicit
indication would attempt a setup using D-ICE transport, it is likely indication would attempt a setup using D-ICE transport, it is likely
to work. Thus giving the client explicit indication of support in to work. Thus giving the client explicit indication of support in
the SETUP response that the proxy chain supports at least passthrough the SETUP response that the proxy chain supports at least passthrough
of this media. Where the Require and Support RTSP headers failed to of this media. Where the Require and Support RTSP headers failed to
provide that information. provide that information.
7. RTP and RTCP Multiplexing 8. RTP and RTCP Multiplexing
"Multiplexing RTP Data and Control Packets on a Single Port" "Multiplexing RTP Data and Control Packets on a Single Port"
[RFC5761] specifies how and when RTP and RTCP can be multiplexed on [RFC5761] specifies how and when RTP and RTCP can be multiplexed on
the same port. This multiplexing SHALL be combined with ICE as it the same port. This multiplexing SHALL be combined with ICE as it
makes RTP and RTCP need only a single component per media stream makes RTP and RTCP need only a single component per media stream
instead of two, so reducing the load on the connectivity checks. For instead of two, so reducing the load on the connectivity checks. For
details on how to negotiate RTP and RTCP multiplexing, see Appendix C details on how to negotiate RTP and RTCP multiplexing, see Appendix C
of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis].
Multiplexing RTP and RTCP has the benefit that it avoids the need for Multiplexing RTP and RTCP has the benefit that it avoids the need for
skipping to change at page 24, line 40 skipping to change at page 25, line 27
between the STUN, and RTP or RTCP packets below the RTP/RTCP between the STUN, and RTP or RTCP packets below the RTP/RTCP
implementation anyway, so the additional work of one new implementation anyway, so the additional work of one new
demultiplexing point directly connected to the STUN and RTP/RTCP demultiplexing point directly connected to the STUN and RTP/RTCP
seems small relative to the benefits provided. seems small relative to the benefits provided.
Due to the above mentioned benefits, RTSP servers and clients that Due to the above mentioned benefits, RTSP servers and clients that
support "D-ICE" lower layer transport in combination with RTP SHALL support "D-ICE" lower layer transport in combination with RTP SHALL
also implement RTP and RTCP multiplexing as specified in this section also implement RTP and RTCP multiplexing as specified in this section
and [RFC5761]. and [RFC5761].
8. Fallback and Using Partial ICE functionality to improve NAT/Firewall 9. Fallback and Using Partial ICE functionality to improve NAT/Firewall
traversal traversal
The need for fallback from ICE in RTSP should be less than for SIP The need for fallback from ICE in RTSP should be less than for SIP
using ICE in SDP offer/answer where a default destination candidate using ICE in SDP offer/answer where a default destination candidate
is very important to enable interworking with non-ICE capable is very important to enable interworking with non-ICE capable
endpoints. In RTSP, capability determination for ICE can happen endpoints. In RTSP, capability determination for ICE can happen
prior to the RTSP SETUP request. This means a client should normally prior to the RTSP SETUP request. This means a client should normally
not need to include fallback alternatives when offering ICE, as the not need to include fallback alternatives when offering ICE, as the
capability for ICE will already be determined. However, as described capability for ICE will already be determined. However, as described
in this section, clients may wish to use part of the ICE in this section, clients may wish to use part of the ICE
functionality to improve NAT/Firewall traversal where the server is functionality to improve NAT/Firewall traversal where the server is
non-ICE capable. non-ICE capable.
Section 4.1.4 of the ICE [RFC5245] specification does recommend that Section 4.1.4 of the ICE [RFC5245] specification does recommend that
the default destination, i.e. what is used as fallback if the peer the default destination, i.e. what is used as fallback if the peer
isn't ICE capable, is a candidate of relayed type to maximize the isn't ICE capable, is a candidate of relayed type to maximize the
likelihood of successful transport of media. This is based on the likelihood of successful transport of media. This is based on the
peer in SIP SDP offer/answer is almost as likely as the RTSP client peer in SIP SDP offer/answer is almost as likely as the RTSP client
to be behind a NAT. For RTSP the deployment of servers are much more to be behind a NAT. For RTSP the deployment of servers are much more
heavily weighted towards deployment with public reachability. In heavily weighted towards deployment with public reachability. In
fact since publicly reachable servers behind NAT either need to fact since publicly reachable servers behind NAT either need to
support ICE or have static configurations that allow traversal, one support ICE or have static configurations that allow traversal, one
can assume that the server will have a public address or support ICE. can assume that the server will have a public address or support ICE.
Thus, the selection of the default destination address for RTSP can Thus, the selection of the default destination address for RTSP can
be differently prioritized. be differently prioritized.
skipping to change at page 26, line 5 skipping to change at page 27, line 5
and may be used as an alternative. and may be used as an alternative.
Fallback addresses need to be provided in their own transport Fallback addresses need to be provided in their own transport
specification using a specifier that does not include the "D-ICE" specification using a specifier that does not include the "D-ICE"
lower layer transport. Instead the selected protocol, e.g. UDP lower layer transport. Instead the selected protocol, e.g. UDP
needs to be explicitly or implicitly indicated. Secondly the needs to be explicitly or implicitly indicated. Secondly the
selected default candidate needs to be included in the SETUP request. selected default candidate needs to be included in the SETUP request.
If this candidate is server reflexive or relayed the aspect of keep- If this candidate is server reflexive or relayed the aspect of keep-
alive needs to be ensured. alive needs to be ensured.
9. IANA Considerations 10. IANA Considerations
This document requests registration in a number of registries, both This document requests registration in a number of registries, both
for RTSP and SDP. For all the below registrations the contact person for RTSP and SDP. For all the below registrations the contact person
on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address:
Farogatan 6, 164 80 Stockholm, Sweden; Email: Farogatan 6, 164 80 Stockholm, Sweden; Email:
magnus.westerlund@ericsson.com. magnus.westerlund@ericsson.com.
RFC-Editor Note: Please replace any occurrence of RFCXXXX in the RFC-Editor Note: Please replace any occurrence of RFCXXXX in the
below with the RFC number this specification is assigned. below with the RFC number this specification is assigned.
9.1. RTSP Feature Tags 10.1. RTSP Feature Tags
This document request that one RTSP 2.0 feature tag is registered in This document request that one RTSP 2.0 feature tag is registered in
the "RTSP 2.0 Feature-tags" registry: the "RTSP 2.0 Feature-tags" registry:
setup.ice-d-m A feature tag representing the support of the ICE setup.ice-d-m A feature tag representing the support of the ICE
based establishment of datagram media transport that is capable of based establishment of datagram media transport that is capable of
transport establishment through NAT and Firewalls. This feature transport establishment through NAT and Firewalls. This feature
tag applies to clients, servers and proxies and indicates that tag applies to clients, servers and proxies and indicates that
support of all the mandatory functions of this specification. support of all the mandatory functions of this specification.
9.2. Transport Protocol Specifications 10.2. Transport Protocol Specifications
This document needs to register a number of transport protocol This document needs to register a number of transport protocol
combinations in the RTSP 2.0 "Transport Protocol Specifications" combinations in the RTSP 2.0 "Transport Protocol Specifications"
registry. registry.
"RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established "RTP/AVP/D-ICE" RTP using the AVP profile over an ICE established
datagram flow. datagram flow.
"RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established "RTP/AVPF/D-ICE" RTP using the AVPF profile over an ICE established
datagram flow. datagram flow.
"RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established "RTP/SAVP/D-ICE" RTP using the SAVP profile over an ICE established
datagram flow. datagram flow.
"RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE "RTP/SAVPF/D-ICE" RTP using the SAVPF profile over an ICE
established datagram flow. established datagram flow.
9.3. RTSP Transport Parameters 10.3. RTSP Transport Parameters
This document requests that 3 transport parameters are registered in This document requests that 3 transport parameters are registered in
the RTSP 2.0's "Transport Parameters" registry: the RTSP 2.0's "Transport Parameters" registry:
"candidates": Listing the properties of one or more ICE candidate. "candidates": Listing the properties of one or more ICE candidate.
See Section Section 4.2 of RFCXXXX. See Section Section 4.2 of RFCXXXX.
"ICE-Password": The ICE password used to authenticate the STUN "ICE-Password": The ICE password used to authenticate the STUN
binding request in the ICE connectivity checks. See Section binding request in the ICE connectivity checks. See
Section 4.3 of RFCXXXX. Section Section 4.3 of RFCXXXX.
"ICE-ufrag": The ICE username fragment used to authenticate the STUN "ICE-ufrag": The ICE username fragment used to authenticate the STUN
binding requests in the ICE connectivity checks. See Section binding requests in the ICE connectivity checks. See
Section 4.3 of RFCXXXX. Section Section 4.3 of RFCXXXX.
9.4. RTSP Status Codes 10.4. RTSP Status Codes
This document requests that 2 assignments are done in the "RTSP 2.0 This document requests that 2 assignments are done in the "RTSP 2.0
Status Codes" registry. The values are: Status Codes" registry. The values are:
150: The 150 response code indicates that ICE connectivity checks 150: The 150 response code indicates that ICE connectivity checks
are still in progress and haven't concluded. This response SHALL are still in progress and haven't concluded. This response SHALL
be sent within 200 milliseconds of receiving a PLAY request that be sent within 200 milliseconds of receiving a PLAY request that
currently can't be fulfilled because ICE connectivity checks are currently can't be fulfilled because ICE connectivity checks are
still running. Subsequently, every 3 seconds after the previous still running. Subsequently, every 3 seconds after the previous
sent one, a 150 reply shall be sent until the ICE connectivity sent one, a 150 reply shall be sent until the ICE connectivity
checks conclude either successfully or in failure, and a final checks conclude either successfully or in failure, and a final
response for the request can be provided. response for the request can be provided.
480: The 480 client error response code is used in cases when the 480: 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, request can't be fulfilled due to a failure in the ICE processing,
such as that all the connectivity checks have timed out. This such as that all the connectivity checks have timed out. This
error message can appear either in response to a SETUP request to error message can appear either in response to a SETUP request to
indicate that no candidate pair can be constructed or to a PLAY indicate that no candidate pair can be constructed or to a PLAY
request that the server's connectivity checks resulted in failure. request that the server's connectivity checks resulted in failure.
9.5. Notify-Reason value 10.5. Notify-Reason value
This document requests that one assignment is done in the RTSP 2.0 This document requests that one assignment is done in the RTSP 2.0
Notify-Reason header value registry. The defined value is: Notify-Reason header value registry. The defined value is:
ice-restart: Server notifying the client about the need for an ICE ice-restart: Server notifying the client about the need for an ICE
restart. See section Section 4.6. restart. See section Section 4.6.
9.6. SDP Attribute 10.6. SDP Attribute
The registration of one SDP attribute is requested: The registration of one SDP attribute is requested:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session level only Type of attribute: Session level only
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX, Section 4.7 Purpose: RFC XXXX, Section 4.7
Values: No values defined. Values: No values defined.
Contact: Magnus Westerlund Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com E-mail: magnus.westerlund@ericsson.com
phone: +46 10 714 82 87 phone: +46 10 714 82 87
10. Security Considerations 11. Security Considerations
ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion ICE [RFC5245] and ICE TCP [RFC6544] provide an extensive discussion
on security considerations which apply here as well. on security considerations which apply here as well.
10.1. ICE and RTSP 11.1. ICE and RTSP
A long-standing risk with transmitting a packet stream over UDP is A long-standing risk with transmitting a packet stream over UDP is
that the host may not be interested in receiving the stream. On that the host may not be interested in receiving the stream. On
today's Internet many hosts are behind NATs or operate host firewalls today's Internet many hosts are behind NATs or operate host firewalls
which do not respond to unsolicited packets with an ICMP port which do not respond to unsolicited packets with an ICMP port
unreachable error. Thus, an attacker can construct RTSP SETUP unreachable error. Thus, an attacker can construct RTSP SETUP
requests with a victim's IP address and cause a flood of media requests 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 packets to be sent to a victim. The addition of ICE, as described in
this document, provides protection from the attack described above. this document, provides protection from the attack described above.
By performing the ICE connectivity check, the media server receives By performing the ICE connectivity check, the media server receives
confirmation that the RTSP client wants the media. While this confirmation that the RTSP client wants the media. While this
protection could also be implemented by requiring the IP addresses in protection could also be implemented by requiring the IP addresses in
the SDP match the IP address of the RTSP signaling packet, such a 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 mechanism does not protect other hosts with the same IP address (such
as behind the same NAT), and such a mechanism would prohibit as behind the same NAT), and such a mechanism would prohibit
separating the RTSP controller from the media playout device (e.g., separating the RTSP controller from the media play-out device (e.g.,
an IP-enabled remote control and an IP-enabled television); it also an IP-enabled remote control and an IP-enabled television); it also
forces RTSP proxies to relay the media streams through them, even if forces RTSP proxies to relay the media streams through them, even if
they would otherwise be only signalling proxies. they would otherwise be only signalling proxies.
To protect against the attacks in ICE based on signalling information To protect against the attacks in ICE based on signalling information
RTSP signalling should be protected using TLS to prevent RTSP signalling should be protected using TLS to prevent
eavesdropping and modification of information. eavesdropping and modification of information.
The STUN amplification attack described in Section 18.5.2 in ICE The STUN amplification attack described in Section 18.5.2 in ICE
[RFC5245] needs consideration. Servers that are able to run [RFC5245] needs consideration. Servers that are able to run
according to the high-reachability option have good mitigation according to the high-reachability option have good mitigation
against this attack as they only send connectivity checks towards an against this attack as they only send connectivity checks towards an
address and port pair they have received an incoming connectivity address and port pair they have received an incoming connectivity
check from. This means an attacker requires both the capability to check from. This means an attacker requires both the capability to
spoof source addresses and to signal the RTSP server a set of ICE spoof source addresses and to signal the RTSP server a set of ICE
candidates. Independently an ICE agent needs to implement the candidates. Independently an ICE agent needs to implement the
mitigation to reduce the volume of the amplification attack as mitigation to reduce the volume of the amplification attack as
described in the ICE specification. described in the ICE specification.
11. Acknowledgements 12. Acknowledgements
The authors would like to thank Remi Denis-Courmont for suggesting The authors would like to thank Remi Denis-Courmont for suggesting
the method of integrating ICE in RTSP signalling, Dan Wing for help the method of integrating ICE in RTSP signalling, Dan Wing for help
with the security section and numerous other issues. with the security section and numerous other issues, Ari Keranen for
review of the document and its ICE details.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-30 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in
progress), July 2012. progress), April 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B.
"TCP Candidates with Interactive Connectivity Roach, "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
12.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-rtsp-nat-evaluation] [I-D.ietf-mmusic-rtsp-nat-evaluation]
Westerlund, M. and T. Zeng, "The Evaluation of Different Westerlund, M. and T. Zeng, "The Evaluation of Different
Network Addres Translator (NAT) Traversal Techniques for Network Address Translator (NAT) Traversal Techniques for
Media Controlled by Real-time Streaming Protocol (RTSP)", Media Controlled by Real-time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-evaluation-05 (work in draft-ietf-mmusic-rtsp-nat-evaluation-06 (work in
progress), May 2012. progress), November 2012.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022, January
January 2001. 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
Authors' Addresses Authors' Addresses
Jeff Goldberg Jeff Goldberg
Cisco Cisco
11 New Square, Bedfont Lakes 11 New Square, Bedfont Lakes
Feltham,, Middx TW14 8HA Feltham,, Middx TW14 8HA
United Kingdom United Kingdom
Phone: +44 20 8824 1000 Phone: +44 20 8824 1000
Fax:
Email: jgoldber@cisco.com Email: jgoldber@cisco.com
URI:
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
Stockholm, SE-164 80 Stockholm SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI:
Thomas Zeng Thomas Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
12670 High Bluff Drive 12670 High Bluff Drive
San Diego, CA 92130 San Diego, CA 92130
USA USA
Phone: +1 858 480 3100 Phone: +1 858 480 3100
Fax:
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
URI:
 End of changes. 99 change blocks. 
206 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/