draft-ietf-mmusic-rtsp-nat-22.txt   rfc7825.txt 
Network Working Group J. Goldberg Internet Engineering Task Force (IETF) J. Goldberg
Internet-Draft Cisco Request for Comments: 7825 Cisco
Intended status: Standards Track M. Westerlund Category: Standards Track M. Westerlund
Expires: January 11, 2015 Ericsson ISSN: 2070-1721 Ericsson
T. Zeng T. Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
July 10, 2014 December 2016
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 the Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-22
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 set up and (NAT) traversal for datagram-based media streams set up and
controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). controlled with the Real-Time Streaming Protocol version 2 (RTSP
It uses Interactive Connectivity Establishment (ICE) adapted to use 2.0). It uses Interactive Connectivity Establishment (ICE) adapted
RTSP as a signaling channel, defining the necessary RTSP extensions to use RTSP as a signaling channel, defining the necessary RTSP
and procedures. extensions and procedures.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on January 11, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7825.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Key Words .......................................................4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview ...............................................4
4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 4. RTSP Extensions .................................................6
4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6 4.1. ICE Transport Lower Layer ..................................6
4.2. ICE Candidate Transport Header Parameter . . . . . . . . 7 4.2. ICE Candidate Transport Header Parameter ...................8
4.3. ICE Password and Username Transport Header Parameters . . 10 4.3. ICE Password and Username Transport Header Parameters .....11
4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 4.4. ICE Feature Tag ...........................................11
4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Status Codes ..............................................12
4.5.1. 150 ICE Connectivity Checks in Progress . . . . . . . 12 4.5.1. 150 Server still working on ICE
4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 connectivity checks ................................12
4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . 12 4.5.2. 480 ICE Connectivity check failure .................12
4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12 4.6. New Reason for PLAY_NOTIFY ................................12
5. ICE-RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Server-Side SDP Attribute for ICE Support .................13
5.1. ICE Features Not Required . . . . . . . . . . . . . . . . 13 5. ICE-RTSP .......................................................13
5.1.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . 13 5.1. ICE Features Not Required .................................13
5.1.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ICE-Lite ...........................................13
5.1.3. ICE Remote Candidate Transport Header Parameter . . . 13 5.1.2. ICE-Mismatch .......................................13
5.2. High-Reachability Configuration . . . . . . . . . . . . . 14 5.1.3. ICE Remote Candidate Transport Header Parameter ....14
6. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 14 5.2. High-Reachability Configuration ...........................14
6.1. Session description and RTSP DESCRIBE (optional) . . . . 14 6. Detailed Solution ..............................................14
6.2. Setting up the Media Streams . . . . . . . . . . . . . . 15 6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
6.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . 15 6.2. Setting Up the Media Streams ..............................15
6.4. Gathering Candidates . . . . . . . . . . . . . . . . . . 16 6.3. RTSP SETUP Request ........................................16
6.5. RTSP Server Response . . . . . . . . . . . . . . . . . . 17 6.4. Gathering Candidates ......................................16
6.6. Server to Client ICE Connectivity Checks . . . . . . . . 17 6.5. RTSP Server Response ......................................17
6.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 6.6. Server-to-Client ICE Connectivity Checks ..................18
6.8. Client Connectivity Checks Complete . . . . . . . . . . . 19 6.7. Client-to-Server ICE Connectivity Check ...................19
6.9. Server Connectivity Checks Complete . . . . . . . . . . . 19 6.8. Client Connectivity Checks Complete .......................20
6.10. Freeing Candidates . . . . . . . . . . . . . . . . . . . 20 6.9. Server Connectivity Checks Complete .......................20
6.11. Steady State . . . . . . . . . . . . . . . . . . . . . . 20 6.10. Freeing Candidates .......................................20
6.12. Re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . 20 6.11. Steady State .............................................21
6.13. Server Side Changes After Steady State . . . . . . . . . 21 6.12. Re-SETUP .................................................21
7. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 23 6.13. Server-Side Changes after Steady State ...................22
7.1. Media-Handling Proxies . . . . . . . . . . . . . . . . . 23 7. ICE and Proxies ................................................24
7.2. Signaling-Only Proxies . . . . . . . . . . . . . . . . . 24 7.1. Media-Handling Proxies ....................................24
7.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . 24 7.2. Signaling-Only Proxies ....................................25
8. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 25 7.3. Non-supporting Proxies ....................................25
9. Fallback and Using Partial ICE functionality to improve 8. RTP and RTCP Multiplexing ......................................26
NAT/Firewall traversal . . . . . . . . . . . . . . . . . . . 26 9. Fallback and Using Partial ICE Functionality to Improve
NAT/Firewall Traversal .........................................27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations ...........................................28
10.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . 27 10.1. RTSP Feature Tags ........................................28
10.2. Transport Protocol Identifiers . . . . . . . . . . . . . 28 10.2. Transport Protocol Identifiers ...........................28
10.3. RTSP Transport Parameters . . . . . . . . . . . . . . . 28 10.3. RTSP Transport Parameters ................................29
10.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 28 10.4. RTSP Status Codes ........................................29
10.5. Notify-Reason value . . . . . . . . . . . . . . . . . . 28 10.5. Notify-Reason Value ......................................29
10.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . 29 10.6. SDP Attribute ............................................29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations .......................................30
11.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . 29 11.1. ICE and RTSP .............................................30
11.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . 30 11.2. Logging ..................................................30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 12. References ....................................................31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References .....................................31
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References ...................................32
13.2. Informative References . . . . . . . . . . . . . . . . . 31 Acknowledgments ...................................................33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses ................................................33
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 [RFC7826] are protocols used to set up and control one or more media
one or more media streams delivering media to receivers. It is streams delivering media to receivers. It is RTSP's functionality of
RTSP's functionality of setting up media streams that causes serious setting up media streams that causes serious issues with Network
issues with Network Address Translators (NAT) [RFC3022] unless extra Address Translators (NATs) [RFC3022] unless extra provisions are made
provisions are taken by the protocol. There is thus a need for a NAT by the protocol. Thus, there is a need for a NAT traversal mechanism
traversal mechanism for the media setup using RTSP. for the media setup using RTSP.
RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT RTSP 1.0 [RFC2326] has suffered from the lack of a standardized NAT
traversal mechanism for a long time, however due to quality of the traversal mechanism for a long time; however, due to quality of the
RTSP 1.0 specification, the work was difficult to specify in an RTSP 1.0 specification, the work was difficult to specify in an
interoperable fashion. This document is therefore built on the interoperable fashion. This document is therefore built on the
specification of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is specification of RTSP 2.0 [RFC7826]. RTSP 2.0 is similar to RTSP 1.0
similar to RTSP 1.0 in many respects but significantly for this work, in many respects, but, significantly for this work, it contains a
it contains a well defined extension mechanism that allows a NAT well-defined extension mechanism that allows a NAT traversal
traversal extension to be defined that is backwards compatible with extension to be defined that is backwards compatible with RTSP 2.0
RTSP 2.0 peers not supporting the extension. This extension peers not supporting the extension. This extension mechanism was not
mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 possible in RTSP 1.0 as it would break RTSP 1.0 syntax and cause
syntax and cause compatibility issues. compatibility issues.
There have been a number of suggested ways of resolving the NAT- There have been a number of suggested ways of resolving the NAT
traversal of media for RTSP of most of which are already used in traversal of media for RTSP, most of which are already used in
implementations. The evaluation of these NAT traversal solutions in implementations. The evaluation of these NAT-traversal solutions in
[I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are many [RFC7604] has shown that there are many issues to consider. After
issues to consider, so after extensive evaluation, a mechanism based extensive evaluation, a mechanism based on Interactive Connectivity
on Interactive Connectivity Establishment (ICE) [RFC5245] was Establishment (ICE) [RFC5245] was selected. There were mainly two
selected. There were mainly two reasons: Firstly, the mechanism reasons: the mechanism supports RTSP servers behind NATs and the
supports RTSP servers behind NATs and secondly, the mechanism mechanism mitigates the security threat of using RTSP servers as
mitigates the security threat of using RTSP servers as Distributed Distributed Denial-of-Service (DDoS) attack tools.
Denial of Service (DDoS) attack tools.
This document specifies an ICE-based solution that is optimized for This document specifies an ICE-based solution that is optimized for
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 requests are sent needs to be optimizations in regard to when PLAY requests are sent needs to be
reconsidered. reconsidered.
The NAT problem for RTSP signaling traffic is a less prevalent The NAT problem for RTSP signaling traffic is a less prevalent
problem than the NAT problem for RTSP media streams. Consequently, problem than the NAT problem for RTSP media streams. Consequently,
the former is left for future study. the former is left for future study.
The ICE usage defined in this specification is called ICE-RTSP and 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 does not match the full ICE for SIP/SDP (Session Description
ICE specification [RFC5245]. ICE-RTSP is tailored to the needs of Protocol) or ICE-Lite as defined in the ICE specification [RFC5245].
RTSP and is slightly simpler than ICE-Full for both clients and ICE-RTSP is tailored to the needs of RTSP and is slightly simpler
servers. than ICE-Full for both clients and servers.
2. Definitions 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 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"
[RFC3261] and "An Offer/Answer Model with the Session Description [RFC3261] and "An Offer/Answer Model with the Session Description
Protocol (SDP)" [RFC3264] works, as it primarily points out how the Protocol (SDP)" [RFC3264] works, as it primarily points out how the
different ICE steps are accomplished in RTSP. different ICE steps are accomplished in RTSP.
1. The RTSP server should indicate it has support for ICE via a new 1. The RTSP server should indicate it has support for ICE via a new
SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the
SDP returned in the RTSP DESCRIBE message. This allows RTSP SDP returned in the RTSP DESCRIBE message. This allows RTSP
clients to only perform the new ICE exchanges with servers that clients to only perform the new ICE exchanges with servers that
support ICE. If RTSP DESCRIBE is used, the normal capability support ICE. If RTSP DESCRIBE is used, the normal capability
determination mechanism should also be used, i.e., "Supported" determination mechanism should also be used, i.e., Supported
header with a new ICE feature tag. Note: Both mechanisms should header with a new ICE feature tag. Note: both mechanisms should
be supported, as there are various use cases where only one of be supported, as there are various use cases where only one of
them is used. them 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 set up. For each of these media streams
the transport protocol supports Session Traversal Utilities for where the transport protocol supports connectivity checks based
(NAT) (STUN) [RFC5389] based connectivity checks, the client on Session Traversal Utilities for (NAT) (STUN) [RFC5389], the
gathers candidate addresses. See section 4.1.1 in ICE client gathers candidate addresses. See Section 4.1.1 in ICE
[RFC5245]. The client then runs a STUN server on each of the [RFC5245]. The client then runs a STUN server on each of the
local candidates transport addresses it has gathered. local candidate's transport addresses it has gathered.
3. The RTSP client sends SETUP requests containing a transport 3. The RTSP client sends SETUP requests containing 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 is not behind server gathers its own candidates. If the server is not behind
a NAT, then a single candidate per address family (e.g., IPv4 a NAT, then a single candidate per address family (e.g., 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 Sections 5.7 and 5.8 of ICE [RFC5245].
If the server is not behind a NAT and uses a public IP address If the server is not behind a NAT and uses a public IP address
with a single candidate per (media stream, component, address with a single candidate per (media stream, component, address
family) tuple, then the server may be configured to not initiate family) tuple, then the server may be configured to not initiate
connectivity checks. connectivity checks.
7. The client receives the SETUP response and learns the candidate 7. The client receives the SETUP response and learns the candidate
addresses 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 not behind a NAT can wait until this triggered check to servers not behind a NAT can wait until this triggered 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 initiated connectivity mitigating the DDoS potential from server-initiated connectivity
checks. checks.
9. When the client has concluded its connectivity checks, including 9. When the client has concluded its connectivity checks, including
nominating candidates, and has correspondingly received the nominating candidates, and has correspondingly received the
server connectivity checks on the nominated candidates for all server connectivity checks on the nominated 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.
10. When the RTSP server receives a PLAY request, it checks to see 10. When the RTSP server receives a PLAY request, it checks to see
that the connectivity checks have concluded successfully, and that the connectivity checks have concluded successfully, and
only then can it play the stream. If there is a problem with only then can it play the stream. If there is a problem with
the checks then the server sends either a 150 (ICE connectivity the checks, then the server sends either a 150 (Server still
checks in progress) response to show that it is still working on working on ICE connectivity checks) response to show that it is
the connectivity checks, or a 480 (ICE Processing Failed) still working on the connectivity checks, or a 480 (ICE
response to indicate a failure of the checks. If the checks are Connectivity check failure) response to indicate a failure of
successful, then the server sends a 200 OK response and starts the checks. If the checks are successful, then the server sends
delivering media. a 200 OK response and starts 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, a single candidate per component has been
been nominated and a PLAY response has been received (Client) or sent nominated, and a PLAY response has been received (client) or sent
(Server). (server).
The client needs to continue to use STUN as a keep-alive mechanism The client needs to continue to use STUN as a keep-alive mechanism
for the used candidate pairs to keep their NAT bindings current. for the used candidate pairs to keep their NAT bindings current.
RTSP Servers behind NATs will also need to send keep-alive messages RTSP servers behind NATs will also need to send keep-alive messages
when not sending media. This is important since RTSP media sessions when not sending media. This is important since RTSP media sessions
often contain only media traffic from the server to the client so the 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 bindings in the NAT need to be refreshed by client-to-server traffic
provided by the STUN keep-alive. 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
otherwise. otherwise.
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 possible to demultiplex from STUN messages (see STUN [RFC5389]). be possible to demultiplex from STUN messages (see STUN [RFC5389]).
With datagram clean we mean that it has to be capable of describing By "datagram clean" we mean that it has to be capable of describing
the length of the datagram, transport that datagram (as a binary the length of the datagram, transport that datagram (as a binary
chunk of data) and provide it at the receiving side as one single chunk of data), and provide it at the receiving side as one single
item. This lower layer can be any transport type defined for ICE item. This lower layer can be any transport type defined for ICE
which does provide datagram transport capabilities. UDP based that does provide datagram transport capabilities. UDP-based
transport candidates are defined in ICE [RFC5245] and MUST be transport candidates are defined in ICE [RFC5245] and MUST be
supported. It is OPTIONAL to also support TCP based candidates as supported. It is OPTIONAL to also support TCP-based candidates as
defined by "TCP Candidates with Interactive Connectivity defined by "TCP Candidates with Interactive Connectivity
Establishment (ICE)" [RFC6544]. The TCP based candidate fulfills the Establishment (ICE)" [RFC6544]. The TCP-based candidate fulfills the
requirements on providing datagram transport and can thus be used in requirements on providing datagram transport and can thus be used in
combination with RTP. Additional transport types for candidates may combination with RTP. Additional transport types for candidates may
be defined in the future. be defined in the future.
This lower layer uses ICE to determine which of the different This lower layer uses ICE to determine which of the different
candidates shall be used and then, when the ICE processing has candidates shall be used and then, when the ICE processing has
concluded, uses the selected candidate to transport the datagrams concluded, uses the selected candidate to transport the datagrams
over this transport. over this transport.
This lower layer transport can be combined with all upper layer media This lower-layer transport can be combined with all upper-layer media
transport protocols that are possible to demultiplex with STUN and transport protocols that are possible to demultiplex with STUN and
which use datagrams. This specification defines the following that use datagrams. This specification defines the following
combinations: combinations:
o RTP/AVP/D-ICE o RTP/AVP/D-ICE
o RTP/AVPF/D-ICE o RTP/AVPF/D-ICE
o RTP/SAVP/D-ICE o RTP/SAVP/D-ICE
o RTP/SAVPF/D-ICE o RTP/SAVPF/D-ICE
This list can be extended with more transport specifications after This list can be extended with more transport specifications after
having performed the evaluation that they are compatible with D-ICE having performed the evaluation that they are compatible with D-ICE
as lower layer. The registration is required to follow the registry as lower layer. The registration is required to follow the registry
rules for the Transport Protocol Identifier (See Section 22.13.1 of rules for the Transport Protocol Identifier (see Section 22.13.1 of
[I-D.ietf-mmusic-rfc2326bis]). [RFC7826]).
The lower-layer "D-ICE" has the following rules for the inclusion of The lower-layer "D-ICE" has the following rules for the inclusion of
the RTSP transport header (Section 18.54 of RTSP 2.0 the RTSP Transport header (Section 18.54 of RTSP 2.0 [RFC7826])
[I-D.ietf-mmusic-rfc2326bis]) parameters: parameters:
unicast: ICE only supports unicast operations, thus it is REQUIRED unicast: ICE only supports unicast operations; thus, it is REQUIRED
that one include the unicast indicator parameter, (see section that one include the unicast indicator parameter (see
18.54 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]). Section 18.54 in RTSP 2.0 [RFC7826]).
candidates: The "candidates" parameter SHALL be included as this candidates: The "candidates" parameter SHALL be included as it
specifies at least one candidate to try to establish a working specifies at least one candidate with which to try to establish a
transport path with. working transport path.
dest_addr: This parameter MUST NOT be included since "candidates" is dest_addr: This parameter MUST NOT be included since "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 4.2). ICE-Password: This parameter SHALL be included (see Section 4.2).
ICE-ufrag: This parameter SHALL be included (See Section 4.2). ICE-ufrag: This parameter SHALL be included (see 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
response there is only a single transport specification, and if that response, there is only a single transport specification; if that
uses the "D-ICE" lower layer this parameter MUST be present and uses the "D-ICE" lower layer, this parameter MUST be present and
include the server side candidates. include the server-side candidates.
The ABNF [RFC5234] for these transport header parameters are: The ABNF [RFC5234] for these transport header parameters are:
trns-parameter = <Defined in Section 20.2.3 of trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
[I-D.ietf-mmusic-rfc2326bis]>
trns-parameter =/ SEMI ice-trn-par trns-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQ SWS ice-candidate ice-trn-par = "candidates" EQUAL DQUOTE SWS ice-candidate
*(SEMI ice-candidate) SWS DQ *(SEMI ice-candidate) SWS DQUOTE
ice-candidate = foundation SP ice-candidate = foundation SP
component-id SP component-id SP
transport SP transport SP
priority SP priority SP
connection-address SP connection-address SP
port SP port SP
cand-type cand-type
[SP rel-addr] [SP rel-addr]
[SP rel-port] [SP rel-port]
[SP tcp-type-ext] ; Mandatory if transport = TCP [SP tcp-type-ext] ; Mandatory if transport = TCP
*(SP extension-att-name SP extension-att-value) *(SP extension-att-name SP extension-att-value)
foundation = <See section 15.1 of [RFC5245]> foundation = <See Section 15.1 of [RFC5245]>
component-id = <See section 15.1 of [RFC5245]> component-id = <See Section 15.1 of [RFC5245]>
transport = <See section 15.1 of [RFC5245]> transport = <See Section 15.1 of [RFC5245]>
priority = <See section 15.1 of [RFC5245]> priority = <See Section 15.1 of [RFC5245]>
cand-type = <See section 15.1 of [RFC5245]> cand-type = <See Section 15.1 of [RFC5245]>
rel-addr = <See section 15.1 of [RFC5245]> rel-addr = <See Section 15.1 of [RFC5245]>
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 [RFC7826]>
DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]> DQUOTE = <Defined in [RFC7826]>
SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SWS = <Defined in [RFC7826]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SEMI = <Defined in [RFC7826]>
SP = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SP = <Defined in [RFC7826]>
<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, This context Domain Names (FQDNs), taken from SDP [RFC4566]. Note, this
MUST have a unicast address for this parameter, even though a context MUST have a unicast address for this parameter, even
multicast address would be syntactically valid. The connection though a multicast address would be syntactically valid. The
address SHOULD use the same format (explicit IP or FQDN) as in the connection address SHOULD use the same format (explicit IP or
dest_addr parameter used in the transport specification that FQDN) as in the dest_addr parameter used in the transport
express any fallback. An IP address is preferred for simplicity, specification that express any fallback. An IP address is
but both an IP Address and FQDN can be used. In the FQDN case, preferred for simplicity, but both an IP Address and FQDN can be
when receiving a SETUP request or response containing an FQDN in a used. In the FQDN case, when receiving a SETUP request or
candidate parameter, the FQDN is looked up in the DNS first using response containing an FQDN in an ice-candidate parameter, the
an AAAA record (assuming the agent supports IPv6), and if no FQDN is looked up in the DNS first using a AAAA record (assuming
result is found or the agent only supports IPv4, using an A the agent supports IPv6), and if no result is found or the agent
record. If the DNS query returns more than one IP address, one is only supports IPv4, using an A record. If the DNS query returns
chosen, and then used for the remainder of ICE processing which in more than one IP address, one is chosen, and then used for the
RTSP is subsequent RTSP SETUPs for the same RTSP session. remainder of ICE processing, which in RTSP is subsequent RTSP
SETUPs for the same RTSP session.
<port>: is the port of the candidate; the syntax is defined by SDP <port>: is the port of the candidate; the syntax is defined by SDP
[RFC4566]. [RFC4566].
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
The ICE specification defines UDP. "TCP Candidates with The ICE specification defines UDP. "TCP Candidates with
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)
skipping to change at page 9, line 45 skipping to change at page 10, line 6
<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
belonging to the range 1-256. It MUST start at 1 and MUST belonging to the range 1-256. It MUST start at 1 and MUST
increment by 1 for each component of a particular media stream. increment by 1 for each component of a particular media stream.
For media streams based on RTP, candidates for the actual RTP For media streams based on RTP, candidates for the actual RTP
media MUST have a component ID of 1, and candidates for RTCP MUST media MUST have a component ID of 1, and candidates for RTCP MUST
have a component ID of 2 unless RTP and RTCP Multiplexing have a component ID of 2 unless RTP and RTCP Multiplexing
(Section 8) is used, in which case the second component is omitted (Section 8) is used, in which case the second component is omitted
and RTP and RTCP are both transported over the first component. and RTP and RTCP are both transported over the first component.
Other types of media streams which require multiple components Other types of media streams that require multiple components MUST
MUST develop specifications which define the mapping of components develop specifications that define the mapping of components to
to component IDs. See Section 14 in [RFC5245] for additional component IDs. See Section 14 in [RFC5245] for additional
discussion on extending ICE to new media streams. discussion on extending ICE to new media streams.
<priority>: is a positive integer in the range 1 to (2**31 - 1). <priority>: is a positive integer in the range 1 to (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> are equal to the base peer-reflexive, <rel-addr> and <rel-port> are equal to the base
for that server or peer reflexive candidate. If the candidate is for that server- or peer-reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> are equal to the mapped address relayed, <rel-addr> and <rel-port> are equal to the mapped address
in the TURN Allocate Response that provided the client with that in the TURN 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.
<tcp-type-ext>: conveys the candidate's connection type (active, <tcp-type-ext>: conveys the candidate's connection type (active,
passive, or S-O) for TCP based candidates. This MUST be included passive, or simultaneous-open (S-O)) for TCP-based candidates.
for candidates that have <transport> set to TCP and MUST NOT be This MUST be included for candidates that have <transport> set to
included for other transport types, including UDP. TCP and MUST NOT be included for other transport types, including
UDP.
<extension-att-name> and <extension-att-value>: These are prototypes <extension-att-name> and <extension-att-value>: These are prototypes
for future extensions of the candidate line. The ABNF for these for future extensions of the candidate line. The ABNF for these
allow any 8-bit value except NUL, CR, or LF. However, the allows any 8-bit value except NUL, CR, or LF. However, the
extensions will occur within a structured line that uses the DQ, extensions will occur within a structured line that uses the
SEMI, SWS and SP ABNF constructs as delimiters, thus those DQUOTE, SEMI, SWS, and SP ABNF constructs as delimiters; thus,
delimiter characters MUST be escaped if they would occur within an those delimiter characters MUST be escaped if they would occur
extension-att-name or extension-att-value. The escape mechanism within an extension-att-name or extension-att-value. The escape
that MUST be used is the Percent-Encoding defined in Section 2.1 mechanism that MUST be used is the Percent-Encoding defined in
of [RFC3986]. This mechanism is selected as it anyway needs to be Section 2.1 of [RFC3986]. This mechanism is selected as it needs
supported in an RTSP implementation to deal with URIs. The byte to be supported in an RTSP implementation to deal with URIs
values (in hex) that MUST be escaped are the following ones: 0x09, anyway. The byte values (in hex) that MUST be escaped are the
0x20, 0x22, 0x25, 0x3B. following: 0x09, 0x20, 0x22, 0x25, and 0x3B.
4.3. ICE Password and Username Transport Header Parameters 4.3. ICE Password and Username Transport Header Parameters
The ICE password and username for each agent needs to be transported The ICE password and username for each agent need to be transported
using RTSP. For that purpose new Transport header parameters are using RTSP. For that purpose, new Transport header parameters are
defined (see section 18.54 of [I-D.ietf-mmusic-rfc2326bis]. defined (see Section 18.54 of [RFC7826].
There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each
media stream. If two SETUP requests in the same RTSP session have media stream. The ICE-ufrag and ICE-Password parameter values MUST
identical ICE-ufrag values, they MUST have identical ICE-Password be chosen randomly at the beginning of a session. The ICE-ufrag
values. value MUST contain at least 24 bits of randomness, and the ICE-
Password value MUST contain at least 128 bits of randomness. This
The ICE-ufrag and ICE-Password parameter values MUST be chosen means that the ICE-ufrag value will be at least 4 characters long,
randomly at the beginning of a session. The ICE-ufrag value MUST and the ICE-Password value at least 22 characters long, since the
contain at least 24 bits of randomness, and the ICE-Password value grammar for these attributes allows for 6 bits of randomness per
MUST contain at least 128 bits of randomness. This means that the character. The values MAY be longer than 4 and 22 characters
ICE-ufrag value will be at least 4 characters long, and the ICE- respectively, of course, up to 256 characters. The upper limit
Password value at least 22 characters long, since the grammar for allows for buffer sizing in implementations. Its large upper limit
these attributes allows for 6 bits of randomness per character. The allows for increased amounts of randomness to be added over time.
values MAY be longer than 4 and 22 characters respectively, of
course, up to 256 characters. The upper limit allows for buffer
sizing in implementations. Its large upper limit allows for
increased amounts of randomness to be added over time.
The ABNF [RFC5234] for these parameters are: The ABNF [RFC5234] for these parameters is:
trns-parameter =/ SEMI ice-password-par trns-parameter =/ SEMI ice-password-par
trns-parameter =/ SEMI ice-ufrag-par trns-parameter =/ SEMI ice-ufrag-par
ice-password-par = "ICE-Password" EQUAL DQ password DQ ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
ice-ufrag-par = "ICE-ufrag" EQUAL DQ ufrag DQ ice-ufrag-par = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
password = <Defined in [RFC5245], Section 15.4> password = <Defined in [RFC5245], Section 15.4>
ufrag = <Defined in [RFC5245], Section 15.4> ufrag = <Defined in [RFC5245], Section 15.4>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]> EQUAL = <Defined in [RFC7826]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SEMI = <Defined in [RFC7826]>
DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]> DQUOTE = <Defined in [RFC7826]>
4.4. ICE Feature Tag 4.4. ICE Feature Tag
A feature tag is defined for use in the RTSP capabilities mechanism A feature tag is defined for use in the RTSP capabilities mechanism
for ICE support of media transport using datagrams: "setup.ice-d-m". for ICE support of media transport using datagrams: "setup.ice-d-m".
This feature tag indicates that one supports all the mandatory This feature tag indicates that one supports all the mandatory
functions of this specification. It is applicable to all types of functions of this specification. It is applicable to all types of
RTSP agents: clients, servers and proxies. RTSP agents: clients, servers, and proxies.
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. Note, this is not a "MUST" as an RTSP client lower-layer transport. Note, this is not a "MUST" as an RTSP client
can always attempt to perform a SETUP using ICE to see if it can always attempt to perform a SETUP using ICE to see if it
functions or fails. However, including the feature tag in the functions or fails. However, including the feature tag in the
"Supported" header ensures that proxies supporting this specification Supported header ensures that proxies supporting this specification
explicitly indicate such support, see Section 7. explicitly indicate such support; see Section 7.
4.5. Status Codes 4.5. Status Codes
ICE needs two new RTSP response codes to indicate progress and For ICE, there are two new RTSP response codes to indicate progress
errors. and errors.
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| Code | Description | Method | | Code | Description | 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 Server still working on ICE connectivity checks
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.
A client can expect network delays between the server and client A client can expect network delays between the server and client
resulting in a response longer than 200 milliseconds. Subsequently, resulting in a response longer than 200 milliseconds. Subsequently,
every 3 seconds after the previous one was sent, a 150 reply SHALL be every 3 seconds after the previous one was sent, a 150 reply SHALL be
sent until the ICE connectivity checks conclude either successfully sent until the ICE connectivity checks conclude either successfully
or in failure, and a final response for the request can be provided. or in failure, and a final response for the request can be provided.
4.5.2. 480 ICE Processing Failed 4.5.2. 480 ICE Connectivity check failure
The 480 client error response code is used in cases when the request The 480 client error response code is used in cases when the request
can't be fulfilled due to a failure in the ICE processing, such as can't be fulfilled due to a failure in the ICE processing, such as
all the connectivity checks have timed out. This error message can all the connectivity checks have timed out. This error message can
appear either in response to a SETUP request to indicate that no appear either in response to a SETUP request to indicate that no
candidate pair can be constructed, or in response to a PLAY request candidate pair can be constructed or in response to a PLAY request to
to indicate that the server's connectivity checks resulted in indicate that the server's connectivity checks resulted in failure.
failure.
4.6. New Reason for PLAY_NOTIFY 4.6. New Reason for PLAY_NOTIFY
A new value used in the PLAY_NOTIFY methods Notify-Reason header is A new value used in the PLAY_NOTIFY methods Notify-Reason header is
defined: "ice-restart". This reason indicates that an ICE restart defined: "ice-restart". This reason indicates that an ICE restart
needs to happen on the identified resource and session. needs to happen on the identified resource and session.
Notify-Reas-val =/ "ice-restart" Notify-Reas-val =/ "ice-restart"
4.7. Server Side SDP Attribute for ICE Support 4.7. Server-Side SDP Attribute for ICE Support
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 a session-level only content served by the server. This is a session-level-only
attribute, see [RFC4566]. attribute; see [RFC4566].
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"
5. ICE-RTSP 5. ICE-RTSP
This section discusses differences between the regular ICE usage This section discusses differences between the regular ICE usage
defined in [RFC5245] and ICE-RTSP. The reasons for the differences defined in [RFC5245] and ICE-RTSP. The reasons for the differences
relate to the clearer client/server roles that RTSP provides and how relate to the clearer client/server roles that RTSP provides and how
the RTSP Session establishment signaling occurs within RTSP compared the RTSP session establishment signaling occurs within RTSP compared
to SIP/SDP Offer/Answer. to SIP/SDP offer/answer.
5.1. ICE Features Not Required 5.1. ICE Features Not Required
A number of ICE signaling features are not needed with RTSP and are A number of ICE signaling features are not needed with RTSP and are
discussed below. discussed below.
5.1.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. service tool.
5.1.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.
5.1.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 request results in an independent ICE
processing chain which either fails or results in nominating a single processing chain that either fails or results in nominating a single
candidate pair to usage. If a new SETUP request for the same media candidate pair to use. If a new SETUP request for the same media is
is sent, this needs to use a new username fragment and password to sent, it needs to use a new username fragment and password to avoid
avoid any race conditions or uncertainty about which round of any race conditions or uncertainty about to which round of processing
processing the STUN requests relate to. the STUN requests relate.
5.2. High-Reachability Configuration 5.2. High-Reachability Configuration
ICE-RTSP contains a high-reachability configuration when the RTSP ICE-RTSP contains a high-reachability configuration when the RTSP
servers are not behind NATs. Please note that "not behind NATs" may servers are not behind NATs. Please note that "not behind NATs" may
apply in some special cases also for RTSP servers behind NATs given 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 that they are in an address space that has reachability for all the
RTSP clients intended to able to reach the server. The high- RTSP clients intended to able to reach the server. The high-
reachability configuration is similar to ICE-Lite as it allows for reachability configuration is similar to ICE-Lite as it allows for
some reduction in the server's burden. However, due to the need to some reduction in the server's burden. However, due to the need to
still verify that the client is actually present and wants to receive still verify that the client is actually present and wants to receive
the media stream, the server must also initiate binding requests and the media stream, the server must also initiate binding requests and
await binding responses. The reduction for the high-reachability await binding responses. The reduction for the high-reachability
configuration of ICE-RTSP is that they don't need to initiate their configuration of ICE-RTSP is that they don't need to initiate their
own checks, and instead rely on triggered checks for verification. own checks and instead rely on triggered checks for verification.
This also removes a denial of service threat where a RTSP SETUP This also removes a denial-of-service threat where an RTSP SETUP
request will trigger large amount of STUN connectivity checks towards request will trigger large amount of STUN connectivity checks towards
provided candidate addresses. provided candidate addresses.
6. Detailed Solution 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
works with RTSP messages. ICE works with RTSP messages.
6.1. Session description and RTSP DESCRIBE (optional) 6.1. Session Description and RTSP DESCRIBE (Optional)
The RTSP server is RECOMMENDED to indicate it has support for ICE by The RTSP server is RECOMMENDED to indicate it has support for ICE by
sending the "a=rtsp-ice-d-m" SDP attribute in the response to the sending the "a=rtsp-ice-d-m" SDP attribute in the response to the
RTSP DESCRIBE message if SDP is used. This allows RTSP clients to RTSP DESCRIBE message if SDP is used. This allows RTSP clients to
only send the new ICE exchanges with servers that support ICE thereby only send the new ICE exchanges with servers that support ICE thereby
limiting the overhead on current non-ICE supporting RTSP servers. limiting the overhead on current non-ICE supporting RTSP servers.
When not using RTSP DESCRIBE it is still RECOMMENDED to use the SDP When not using RTSP DESCRIBE, it is still RECOMMENDED to use the SDP
attribute for the session description. attribute for 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
both server and any proxies support ICE. The client includes the both server and any proxies support ICE. The client includes the
"Supported" header with its supported feature tags, including Supported header with its supported feature tags, including
"setup.ice-d-m". Any proxy upon seeing the "Supported" header will "setup.ice-d-m". Upon seeing the Supported header, any proxy will
include the "Proxy-Supported" header with the feature tags it include the Proxy-Supported header with the feature tags it supports.
supports. The server will echo back the "Proxy-Supported" header and
its own version of the Supported header so enabling a client to The server will echo back the Proxy-Supported header and its own
determine if all involved parties support ICE or not. Note that even version of the Supported header so enabling a client to determine
if a proxy is present in the chain that doesn't indicate support for whether or not all involved parties support ICE. Note that even if a
ICE, it may still work (see Section 7). proxy is present in the chain that doesn't indicate support for ICE,
it may still work (see Section 7).
For example: For example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
Supported: setup.ice-d-m, setup.rtp.rtcp.mux Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
skipping to change at page 15, line 35 skipping to change at page 15, line 42
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
6.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
by an RTSP DESCRIBE message, to determine what media resources need example, by an RTSP DESCRIBE message, to determine what media
to be setup. For each of these media streams where the transport resources need to be set up. For each of these media streams where
protocol supports ICE connectivity checks, the client SHALL gather the transport protocol supports ICE connectivity checks, the client
candidate addresses for UDP transport as described in section 4.1.1 SHALL gather candidate addresses for UDP transport as described in
in ICE [RFC5245] according to standard ICE rather than the ICE-Lite Section 4.1.1 in ICE [RFC5245] according to standard ICE rather than
implementation and according to section 5 of ICE TCP [RFC6544] for the ICE-Lite implementation and according to Section 5 of ICE TCP
TCP based candidates. [RFC6544] for TCP-based candidates.
6.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 MUST session. For each media stream where it desires to use ICE, it MUST
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 be provided as a
a fallback in case of non-ICE supporting proxies. The RTSP client fallback in case of proxies that do not support ICE. 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
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
6.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 the resource should be delivered and which transport alternatives the
client supports. If one based on D-ICE is on the list of supported client supports. If one based on D-ICE is on the list of supported
transports and preferred among the supported, the below applies. transports and preferred among the supported, the below applies.
The transport specification will indicate which media protocol is to The transport specification will indicate which media protocol is to
be used and based on this and the client's candidates, the server be used and, based on this and the client's 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.
The server SHALL then gather its UDP candidates according to section The server SHALL then gather its UDP candidates according to
4.1.1 in ICE [RFC5245] and any TCP based ones according to section 5 Section 4.1.1 in ICE [RFC5245] and any TCP-based ones according to
of ICE TCP [RFC6544]. Section 5 of ICE TCP [RFC6544].
Servers that have an address that is generally reachable by any Servers that have an address that is generally reachable by any
client within the address scope the server intends to serve MAY be client within the address scope the server intends to serve MAY be
specially configured (high-reachability configuration). This special specially configured (high-reachability configuration). This special
configuration has the goal of reducing the server side candidate to configuration has the goal of reducing the server-side candidate to
preferably a single one per (address family, media stream, media preferably a single one per (address family, media stream, media
component) tuple. Instead of gathering all possible addresses component) tuple. Instead of gathering all possible addresses
including relayed and server reflexive addresses, the server uses a including relayed and server-reflexive addresses, the server uses a
single address per address family that the server knows should be single address per address family that the server knows should be
reachable by a client behind one or more NATs. The reason for this reachable by a client behind one or more NATs. The reason for this
special configuration is twofold: Firstly, it reduces the load on the special configuration is twofold: Firstly, it reduces the load on the
server in address gathering and in ICE processing during the server in address gathering and in ICE processing during the
connectivity checks. Secondly, it will reduce the number of connectivity checks. Secondly, it will reduce the number of
permutations for candidate pairs significantly thus potentially permutations for candidate pairs significantly thus potentially
speeding up the conclusion of the ICE processing. Note however that speeding up the conclusion of the ICE processing. However, note that
using this option on a server that doesn't fulfill the requirement of using this option on a server that doesn't fulfill the requirement of
being reachable is counter-productive and it is important that this being reachable is counterproductive, and it is important that this
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 simultaneous-open (S-O) the server can select to provide active or S-O connection types to
connection types to match the client's candidates. match the client's candidates.
6.5. RTSP Server Response 6.5. RTSP Server Response
The server determines if the SETUP request is successful, and if so The server determines if the SETUP request is successful and, if so,
returns a 200 OK response; otherwise it returns an error code. At returns a 200 OK response; otherwise, it returns an error code. At
that point the server, having selected a transport specification that point, the server, having selected a transport specification
using the "D-ICE" lower layer, will need to include that transport using the "D-ICE" lower layer, will need to include that transport
specification in the response message. The transport specification specification in the response message. The transport specification
SHALL include the candidates gathered in Section 6.4 in the SHALL include the candidates gathered in Section 6.4 in the
"candidates" transport header parameter as well as the server's ICE "candidates" transport header parameter as well as the server's ICE
username fragment and password. In the case that there are no valid username fragment and password. In the case that there are no valid
candidate pairs with the combination of the client and server candidate pairs with the combination of the client and server
candidates, a 480 (ICE Processing Failed) error response SHALL be candidates, a 480 (ICE Connectivity check failure) error response
returned which MUST include the server's candidates. The return of a SHALL be returned, which MUST include the server's candidates. The
480 error may allow both the server and client to release their return of a 480 error may allow both the server and client to release
candidates, see Section 6.10. their candidates; see Section 6.10.
Example of a successful response to the request in Section 6.3. Below is an 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
6.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 Sections 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 server's checks are it MAY suppress its own checks until the server's checks are
triggered by the client's connectivity checks. triggered by the client's connectivity checks.
Please note that ICE [RFC5245] section 5.8 does specify that the Please note that Section 5.8 of ICE [RFC5245] 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 result in a triggered check from the server as specified in
Section 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.
6.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
addresses to use for the connectivity checks. The client SHALL addresses to use for the connectivity checks. The client SHALL
initiate its connectivity check(s), following the procedures in initiate its connectivity check(s), following the procedures in
Section 6 of ICE [RFC5245]. The pacing of STUN transactions Section 6 of ICE [RFC5245]. The pacing of STUN transactions
(Section B.1 of [RFC5245]) SHALL be used across all media streams (Appendix B.1 of [RFC5245]) SHALL be used across all media streams
that are part of the same RTSP session. that are part of the same RTSP session.
Aggressive nomination SHOULD be used with RTSP during initial SETUP Aggressive nomination SHOULD be used with RTSP during initial SETUP
for a resource. This doesn't have all the negative impact that it for a resource. This doesn't have all the negative impact that it
has in offer/answer as media playing only starts after issuing a PLAY 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 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 for delivery can be avoided by not issuing a PLAY request while STUN
connectivity checks are still outstanding. Aggressive nomination can connectivity checks are still outstanding. Aggressive nomination can
result in multiple candidate pairs having their nominated flag set result in multiple candidate pairs having their nominated flag set,
but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY 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 request is sent, the media will arrive on the pair with the highest
priority. Note, different media resources may still end up with priority. Note, different media resources may still end up with
different foundations. different foundations.
The above does not change ICE and its handling of aggressive The above does not change ICE and its handling of aggressive
nomination. When using aggressive nomination, a higher priority nomination. When using aggressive nomination, a higher-priority
candidate pair with an outstanding connectivity check message can candidate pair with an outstanding connectivity check message can
move into the Succeeded state and the candidate pair will have its move into the Succeeded state and the candidate pair will have its
Nominated flag set. This results in the higher priority candidate Nominated flag set. This results in the higher-priority candidate
pair being used instead of the previous pair, which is also in the pair being used instead of the previous pair, which is also in the
Succeeded state. Succeeded state.
To avoid this occurring during actual media transport, the RTSP To avoid this occurring during actual media transport, the RTSP
client can add additional logic when the ICE processing overall is client can add additional logic when the ICE processing overall is
completed to indicate if there is still higher priority connectivity completed to indicate if there are still higher-priority connectivity
checks outstanding. If some check is still outstanding, the checks outstanding. If some check is still outstanding, the
implementation can choose to wait until some additional timeout implementation can choose to wait until some additional timeout is
triggers or the outstanding checks completes before progressing with triggered or the outstanding checks complete before progressing with
a PLAY request. An alternative is to accept the risk for a path a PLAY request. An alternative is to accept the risk for a path
change during media delivery and start playing immediately. change during media delivery and start playing immediately.
RTSP clients that want to ensure that each media resource uses the RTSP clients that want to ensure that each media resource uses the
same path can use regular nomination where both the ICE processing same path can use regular nomination where both 1) the ICE processing
completion criteria can be controlled in addition to which media completion criteria and 2) which media streams are nominated for use
streams being nominated for use. This does not affect the RTSP can be controlled. This does not affect the RTSP server, as its role
server, as its role is the one of being controlled. is the one of being controlled.
6.8. Client Connectivity Checks Complete 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 pair for a particular media stream, nominated its desired candidate pair for a particular media stream,
it MAY 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. The candidate nominate another pair than what was already nominated. The candidate
pair with the highest priority will be used for the media. If the 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 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 Connectivity
Failed). Upon receiving the 480 (ICE Processing Failed) response, check failure) error response. Upon receiving the 480 (ICE
the client may send a new SETUP request assuming it has any new Connectivity check failure) response, the client may send a new SETUP
information that can be included in the candidate list. If the request assuming it has any new information that can be included in
server is still performing the checks when receiving the PLAY request the candidate list. If the server is still performing the checks
it will respond with a 150 (ICE connectivity checks in progress) when receiving the PLAY request, it will respond with a 150 (Server
response to indicate this. still working on ICE connectivity checks) response to indicate this.
6.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 (Server still working on ICE connectivity checks)
(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
starts delivering media. and starts delivering media.
6.10. Freeing Candidates 6.10. Freeing Candidates
Both server and client MAY free their non-selected candidates as soon Both server and client MAY free their non-selected candidates as soon
as a 200 PLAY response has been issued/received and no outstanding as a 200 OK response has been issued/received for the PLAY request
connectivity checks exist. and no outstanding connectivity checks exist.
Clients and servers MAY free all their gathered candidates after Clients and servers MAY free all their gathered candidates after
having received or sent, respectively, a 480 response to a SETUP having received or sent, respectively, a 480 response to a SETUP
request. Clients will likely free their candidates first after request. Clients will likely free their candidates first after
having tried any additional actions that may resolve the issue, e.g., having tried any additional actions that may resolve the issue, e.g.,
verifying the address gathering, or use additional STUN or TURN verifying the address gathering, or use additional STUN or TURN
servers. Thus, a server will have to weigh the cost of doing address servers. Thus, a server will have to weigh the cost of doing address
gathering versus maintaining the gathered address for some time to gathering versus maintaining the gathered address for some time to
allow any new SETUP request to be issued by the client. allow any new SETUP request to be issued by the client.
If the 480 response is sent in response to a PLAY request, the server If the 480 response is sent in response to a PLAY request, the server
MUST NOT free its gathered candidates. Instead it will have to wait MUST NOT free its gathered candidates. Instead, it will have to wait
for additional actions from the client, or to terminate the RTSP for additional actions from the client or terminate the RTSP session
session due to inactivity. due to inactivity.
6.11. Steady State 6.11. Steady State
The client and server SHALL use STUN to send keep-alive messages for The client and server SHALL use STUN to send keep-alive messages for
the nominated candidate pair(s) following the rules of Section 10 of the nominated candidate pair(s) following the rules of Section 10 of
ICE [RFC5245]. This is important, as normally RTSP play mode ICE [RFC5245]. This is important, as normally RTSP play mode
sessions only contain traffic from the server to the client so the sessions only contain traffic from the server to the client so the
bindings in the NAT need to be refreshed by the client-to-server bindings in the NAT need to be refreshed by the client-to-server
traffic provided by the STUN keep-alive. traffic provided by the STUN keep-alive.
6.12. Re-SETUP 6.12. Re-SETUP
A client that decides to change any parameters related to the media A client that decides to change any parameters related to the media
stream setup 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 ICE username fragment request, the client MAY include a new different ICE username fragment
and password to use in the ICE processing. New ICE username and and password to use in the ICE processing. The new ICE username and
password SHALL cause the ICE processing to start from the beginning password SHALL cause the ICE processing to start from the beginning
again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). The again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). The
client SHALL in case of ICE restart gather candidates and include the client SHALL in case of ICE restart, gather candidates and include
candidates in the transport specification for D-ICE. the candidates in the transport specification for D-ICE.
ICE restarts may be triggered due to changes of client or server ICE restarts may be triggered due to changes of client or server
attachment to the network, such as changes to the media streams attachment to the network, such as changes to the media streams
destination or source address or port. Most RTSP parameter changes destination or source address or port. Most RTSP parameter changes
would not require an ICE restart, but would use existing mechanisms would not require an ICE restart, but would use existing mechanisms
in RTSP to indicate from what point in the RTP stream they apply. in RTSP to indicate from what point in the RTP stream they apply.
These include: Performing a pause prior to the parameter change and These include the following: performing a pause prior to the
then resume; or assuming the server supports using SETUP during the parameter change and then resume; assuming the server supports using
PLAY state, using the RTP-Info header (Section 18.45 of SETUP during the PLAY state; or using the RTP-Info header
[I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media (Section 18.45 of [RFC7826]) to indicate from where in the media
stream the change shall apply. stream the change shall apply.
Even if the server does not normally support SETUP during PLAY state, Even if the server does not normally support SETUP during PLAY state,
it SHALL support SETUP requests in PLAY state for the purpose of it SHALL support SETUP requests in PLAY state for the purpose of
changing only the ICE parameters, which are ICE-Password, ICE-ufrag, changing only the ICE parameters, which are ICE-Password, ICE-ufrag,
and the content of ICE candidates. 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 media stream. Once the nomination been nominated for the individual media stream. Once the nomination
of the new candidate pair has completed, all unused candidates may be of the new candidate pair has completed, all unused candidates may be
released. If the ICE processing fails and no new candidate pairs are released. If the ICE processing fails and no new candidate pairs are
nominated for use, then the media stream MAY continue to use the nominated for use, then the media stream MAY continue to use the
previously nominated candidate pairs while they still function. If previously nominated candidate pairs while they still function. If
they appear to fail to transport media packets anymore then the they appear to fail to transport media packets anymore, then the
client can select between two actions. First, it can attempt any client can select between two actions: attempting any actions that
actions available that might make ICE work, like trying another STUN/ might make ICE work or terminating the RTSP session. Firstly, it can
TURN server, or changing the transport parameters. In that case, the attempt any actions available that might make ICE work, like trying
client modifies the RTSP session, and if ICE is still to be used, the another STUN/TURN server or changing the transport parameters. In
client restarts ICE once more. If the client is unable to modify the that case, the client modifies the RTSP session, and if ICE is still
transport or ICE parameters, it MUST NOT restart the ICE processing, to be used, the client restarts ICE once more. Secondly, if the
and it SHOULD terminate the RTSP session. client is unable to modify the transport or ICE parameters, it MUST
NOT restart the ICE processing, and it SHOULD terminate the RTSP
session.
6.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. In that case the server SHALL use the PLAY_NOTIFY method to change. In that case, the server SHALL use the PLAY_NOTIFY method to
inform the client (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a inform the client (Section 13.5 [RFC7826]) with a new Notify-Reason
new Notify-Reason header: ice-restart. The server will identify if header: ice-restart. The server will identify if the change is for a
the change is for a single media or for the complete session by single media or for the complete session by including the
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 an ice-restart
reason the client SHALL gather new ICE candidates and send SETUP reason, the client SHALL gather new ICE candidates and 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 user names and passwords. The client MAY issue the SETUP request ICE usernames 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 keepalive messages on the previous set of candidate pairs Note that for each media stream keep-alive messages on the previous
SHOULD continue until all new candidate pairs have been nominated. set of candidate pairs SHOULD continue until new candidate pairs have
After having nominated a new set of candidate pairs, the client may been nominated. After having nominated a new set of candidate pairs,
continue to receive media for some additional time. Even if the the client may continue to receive media for some additional time.
server stops delivering media over that candidate pair at the time of Even if the server stops delivering media over that candidate pair at
nomination, media may arrive for up to one maximum segment lifetime the time of nomination, media may arrive for up to one maximum
as defined in TCP (2 minutes). Unfortunately, if the RTSP server is segment lifetime as defined in TCP (2 minutes). Unfortunately, if
divided into a separate controller and media stream, a failure may the RTSP server is divided into a separate controller and media
result in continued media delivery for a longer time than the maximum stream, a failure may result in continued media delivery for a longer
segment lifetime, thus source filtering is RECOMMENDED. time than the maximum 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
skipping to change at page 23, line 39 skipping to change at page 24, line 25
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
Supported: setup.ice-d-m, setup.rtp.rtcp.mux Supported: setup.ice-d-m, setup.rtp.rtcp.mux
7. ICE and Proxies 7. ICE and Proxies
RTSP allows for proxies which can be of two fundamental types RTSP allows for proxies that can be of two fundamental types
depending on whether they relay and potentially cache the media or depending on whether or not they relay and potentially cache the
not. Their differing impact on the RTSP NAT traversal solution, media. Their differing impact on the RTSP NAT traversal solution,
including backwards compatibility, is explained below. including backwards compatibility, is explained below.
7.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: firstly, a media transport between the server and the proxy
to the proxy's need, and delivery from the proxy to the client. This according to the proxy's need, and, secondly, delivery from the proxy
split means that the NAT traversal solution will be run on each to the client. This split means that the NAT traversal solution will
individual media leg according to need. be run on 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
reasons: Firstly, to enable clients to perform NAT traversal for the reasons: firstly, to enable clients to perform NAT traversal for the
media between the proxy and itself, and secondly to allow the proxy media between the proxy and itself and secondly to allow the proxy to
to be topology independent to support performing NAT traversal (to be topology independent to support performing NAT traversal (to the
the server) for non-NAT traversal capable clients present in the same server) for clients not capable of NAT traversal 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.
7.2. Signaling-Only Proxies 7.2. Signaling-Only Proxies
A signaling-only proxy handles only the RTSP signaling and does not A signaling-only proxy handles only the RTSP signaling 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 DoS protection
Service (DoS) protection measures, as discussed in Section 21.2.1 of measures, as discussed in Section 21.2.1 of RTSP 2.0 [RFC7826],
RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis], usually prevent media delivery usually prevent media delivery to addresses other than from where the
to addresses other than from where the RTSP signaling arrives at the RTSP signaling arrives at the server.
server.
The solution for the signaling-only proxy is that it must forward the The solution for the signaling-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 proxy "D-ICE" lower layer and the related transport parameters. A proxy
supporting this functionality SHALL indicate its capability by always supporting this functionality SHALL indicate its capability by always
including the "setup.ice-d-m" feature tag in the "Proxy-Supported" including the "setup.ice-d-m" feature tag in the Proxy-Supported
header in any SETUP request or response. header in any SETUP request or response.
7.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
guaranteed for proxies following the RTSP 2.0 specification guaranteed for proxies following the RTSP 2.0 specification
[I-D.ietf-mmusic-rfc2326bis]. [RFC7826].
The usage of the "setup.ice-d-m" feature tag in the Proxy-Require The usage of the "setup.ice-d-m" feature tag in the Proxy-Require
header is NOT RECOMMENDED because it can have contradictory results. header is NOT RECOMMENDED because it can have contradictory results.
For a non ICE supporting but media-handling proxy, the inclusion of For a proxy that does not support ICE but is media handling, the
the feature tag will result in aborting the setup and indicating that inclusion of the feature tag will result in aborting the setup and
it isn't supported, which is desirable if it is desirable to provide indicating that it isn't supported, which is desirable if providing
other fallbacks or other transport configurations to handle the other fallbacks or other transport configurations to handle the
situation. For non-ICE supporting non-media-handling proxies the situation is wanted. For non-ICE-supporting non-media-handling
result will be aborting the setup. However, setup might have worked proxies, the result will be aborting the setup. However, the setup
if the feature tag wasn't present in the Proxy-Require header. This might have worked if the feature tag wasn't present in the Proxy-
variance in results is the reason we don't recommend the usage of the Require header. This variance in results is the reason we don't
Proxy-Require header. Instead we recommend the usage of the recommend the usage of the Proxy-Require header. Instead, we
Supported header to force proxies to include the feature tags for the recommend the usage of the Supported header to force proxies to
intersection of what the proxy chain supports in the Proxy-Supported include the feature tags for the intersection of what the proxy chain
header. This will provide a positive indication when all proxies in supports in the Proxy-Supported header. This will provide a positive
the chain between the client and server support the functionality. indication when all proxies in the chain between the client and
server support the functionality.
If a proxy doesn't support the setup.ice-d-m feature, but that proxy If a proxy doesn't support the "setup.ice-d-m" feature, but that
is not a media-handling proxy, the ICE-based setup could still work, proxy is not a media-handling proxy, the ICE-based setup could still
since such a proxy may do passthrough on any transport parameters. work, since such a proxy may do pass through on any transport
Unfortunately the Proxy-Require and Proxy-Supported RTSP headers parameters. Unfortunately ,the Proxy-Require and Proxy-Supported
failed to provide that information. The only way of finding if this RTSP headers failed to provide that information. The only way of
is the case or not is to try perform a SETUP including a Transport finding whether or not this is the case is to try perform a SETUP
header with transport specifications using ICE. including a Transport header with transport specifications using ICE.
8. 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 is beneficial when combined with the same port. This multiplexing is beneficial when combined with
ICE for RTSP as it makes RTP and RTCP need only a single component ICE for RTSP as it makes RTP and RTCP need only a single component
per media stream instead of two, so reducing the load on the per media stream instead of two, so reducing the load on the
connectivity checks. For details on how to negotiate RTP and RTCP connectivity checks. For details on how to negotiate RTP and RTCP
multiplexing, see Appendix C of RTSP 2.0 multiplexing, see Appendix C of RTSP 2.0 [RFC7826].
[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
handling two components per media stream when RTP is used as the handling two components per media stream when RTP is used as the
media transport protocol. This eliminates at least one STUN check media transport protocol. This eliminates at least one STUN check
per media stream and will also reduce the time needed to complete the per media stream and will also reduce the time needed to complete the
ICE processing by at least the time it takes to pace out the ICE processing by at least the time it takes to pace out the
additional STUN checks of up to one complete round trip time for a additional STUN checks of up to one complete round-trip time for a
single media stream. In addition to the protocol performance single media stream. In addition to the protocol performance
improvements, the server and client side complexities are reduced as improvements, the server and client-side complexities are reduced as
multiplexing halves the total number of STUN instances and holding multiplexing halves the total number of STUN instances and holding
the associated state. Multiplexing will also reduce the combinations the associated state. Multiplexing will also reduce the combinations
and length of the list of possible candidates. and length of the list of possible candidates.
The implementation of RTP and RTCP multiplexing is additional work The implementation of RTP and RTCP multiplexing is additional work
required for this solution. However, when implementing the ICE required for this solution. However, when implementing the ICE
solution a server or client will need to implement a de-multiplexer solution, a server or client will need to implement a demultiplexer
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 benefits mentioned above, 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 and use RTP and RTCP multiplexing as specified in also implement and use RTP and RTCP multiplexing as specified in
Appendix C.1.6.4 of [I-D.ietf-mmusic-rfc2326bis] and [RFC5761]. Appendix C.1.6.4 of [RFC7826] and [RFC5761].
9. 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. not 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 using SDP offer/answer is almost as likely as the RTSP peer in SIP using SDP offer/answer is almost as likely as the RTSP
client to be behind a NAT. For RTSP the deployment of servers are client to be behind a NAT. For RTSP, the deployment of servers is
much more heavily weighted towards deployment with public much more heavily weighted towards deployment with public
reachability. In fact since publicly reachable servers behind NAT reachability. In fact, since publicly reachable servers behind NAT
either need to support ICE or have static configurations that allow either need to support ICE or have static configurations that allow
traversal, one can assume that the server will have a public address traversal, one can assume that the server will have a public address
or support ICE. Thus, the selection of the default destination or support ICE. Thus, the selection of the default destination
address for RTSP can be differently prioritized. address for RTSP can be differently prioritized.
As an ICE enabled client behind a NAT needs to be configured with a As an ICE-enabled client behind a NAT needs to be configured with a
STUN server address to be able to gather candidates successfully, STUN server address to be able to gather candidates successfully,
this can be used to derive a server reflexive candidate for the this can be used to derive a server reflexive candidate for the
client's port. How useful this is for a NAT'ed RTSP client as a client's port. How useful this is for a NATed RTSP client as a
default candidate depends on the properties of the NAT. As long as default candidate depends on the properties of the NAT. As long as
the NAT uses an address independent mapping, then using a STUN the NAT uses an address-independent mapping, then using a STUN-
derived reflexive candidate is likely to be successful. This is derived reflexive candidate is likely to be successful. However,
however brittle in several ways, and the main reason why the original this is brittle in several ways, and the main reason why the original
specification of STUN [RFC3489] and direct usage for NAT traversal specification of STUN [RFC3489] and direct usage for NAT traversal
was obsoleted. First, if the NATs behavior is attempted to be was obsoleted. First, if the NAT's behavior is attempted to be
determined using STUN as described in [RFC3489], the determined determined using STUN as described in [RFC3489], the determined
behavior might not be representative of the behavior encountered in behavior might not be representative of the behavior encountered in
another mapping. Secondly, filter state towards the ports used by another mapping. Secondly, filter state towards the ports used by
the server needs to be established. This requires that the server the server needs to be established. This requires that the server
actually includes both address and ports in its response to the SETUP actually includes both address and ports in its response to the SETUP
request. Thirdly messages need to be sent to these ports for keep- request. Thirdly, messages need to be sent to these ports for keep-
alive at a regular interval. How a server reacts to such unsolicited alive at a regular interval. How a server reacts to such unsolicited
traffic is unknown. This brittleness may be accepted in fallback due traffic is unknown. This brittleness may be accepted in fallback due
to lack of support on the server side. to lack of support on the server side.
To maximize the likelihood that an RTSP client is capable of To maximize the likelihood that an RTSP client is capable of
receiving media a relay based address should be chosen as the default receiving media, a relay-based address should be chosen as the
fallback address. However, for RTSP clients lacking a relay server, default fallback address. However, for RTSP clients lacking a relay
such as a TURN server, or where usage of such a server has server, such as a TURN server, or where usage of such a server has
significant cost associated with it, the usage of a STUN-derived significant cost associated with it, the usage of a STUN-derived
server reflexive address as client default has a reasonable server reflexive address as client default has a reasonable
likelihood of functioning and may be used as an alternative. likelihood of functioning 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.
10. IANA Considerations 10. IANA Considerations
This document requests registration in a number of registries, both Per this document, registrations have been made in a number of
for RTSP and SDP. For all the below registrations the contact person registries, both for RTSP and SDP. For all the below registrations,
on behalf of the IETF WG MMUSIC is Magnus Westerlund; Postal address: the contact person on behalf of the IETF WG MMUSIC is Magnus
Farogatan 6, 164 80 Stockholm, Sweden; Email: Westerlund <magnus.westerlund@ericsson.com>.
magnus.westerlund@ericsson.com.
RFC-Editor Note: Please replace any occurrence of RFCXXXX in the
below with the RFC number this specification is assigned.
10.1. RTSP Feature Tags 10.1. RTSP Feature Tags
This document requests that one RTSP 2.0 feature tag is registered in Per this document, one RTSP 2.0 feature tag has been 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 support tag applies to clients, servers, and proxies and indicates support
of all the mandatory functions of this specification. of all the mandatory functions of this specification.
10.2. Transport Protocol Identifiers 10.2. Transport Protocol Identifiers
This document needs to register a number of transport protocol Per this document, a number of transport protocol combinations have
combinations in the RTSP 2.0 "Transport Protocol Identifiers" been registered in the RTSP 2.0 "Transport Protocol Identifiers"
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
established datagram flow. datagram flow.
10.3. RTSP Transport Parameters 10.3. RTSP Transport Parameters
This document requests that 3 transport parameters are registered in Per this document, three transport parameters have been 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 candidates.
See Section 4.2 of RFCXXXX. See Section 4.2.
"ICE-Password": The ICE password used to authenticate the STUN ICE-Password: The ICE password used to authenticate the STUN binding
binding request in the ICE connectivity checks. See Section 4.3 request in the ICE connectivity checks. See 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 4.3 binding requests in the ICE connectivity checks. See Section 4.3.
of RFCXXXX.
10.4. RTSP Status Codes 10.4. RTSP Status Codes
This document requests that 2 assignments are done in the "RTSP 2.0 Per this document, two assignments have been made in the "RTSP 2.0
Status Codes" registry. See Section 4.5 of RFCXXXX. Status Codes" registry. See Section 4.5.
10.5. Notify-Reason value 10.5. Notify-Reason Value
This document requests that one assignment is done in the RTSP 2.0 Per this document, one assignment has been made 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: This Notify-Reason value allows the server to notify
restart. See Section 4.6. the client about the need for an ICE restart. See Section 4.6.
10.6. SDP Attribute 10.6. SDP Attribute
The registration of one SDP attribute is requested: One SDP attribute has been registered:
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 7825, Section 4.7
Values: No values defined Values: No values defined
Contact: Magnus Westerlund Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
phone: +46 10 714 82 87 Phone: +46 10 714 82 87
11. 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 that apply here as well.
11.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 today's Internet, many hosts are behind NATs or operate host
firewalls which do not respond to unsolicited packets with an ICMP firewalls that do not respond to unsolicited packets with an ICMP
port unreachable error. Thus, an attacker can construct RTSP SETUP port 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 play-out 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 signaling proxies. they would otherwise be only signaling proxies.
To protect against attacks on ICE based on signalling information, To protect against attacks on ICE based on signaling information,
RTSP signalling SHOULD be protected using TLS to prevent RTSP signaling SHOULD be protected using TLS to prevent eavesdropping
eavesdropping and modification of information. 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 of
against this attack as they only send connectivity checks towards an this attack as they only send connectivity checks towards an address
address and port pair they have received an incoming connectivity and port pair from which they have received an incoming connectivity
check from. This means an attacker requires both the capability to check. This means an attacker requires both the capability to spoof
spoof source addresses and to signal the RTSP server a set of ICE 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.2. Logging 11.2. Logging
The logging of NAT translations is helpful to analysts who need to be The logging of NAT translations is helpful to analysts, particularly
able to map sessions when investigating possible issues where the NAT in enterprises, who need to be able to map sessions when
happens. Care should be taken in the protection of these logs and investigating possible issues where the NAT happens. When using
consideration taken to log integrity, privacy protection, and purging logging on the public Internet, it is possible that the logs are
logs occasionally (retention policies, etc.). Also, logging of large and privacy invasive, so procedures for log flushing and
connection errors and other messages established by this draft may be privacy protection SHALL be in place. Care should be taken in the
important. protection of these logs and consideration taken to log integrity,
privacy protection, and purging logs (retention policies, etc.).
12. Acknowledgments Also, logging of connection errors and other messages established by
this document can be important.
The authors would like to thank Remi Denis-Courmont for suggesting
the method of integrating ICE in RTSP signaling, Dan Wing for help
with the security section and numerous other issues, Ari Keranen for
review of the document and its ICE details. Flemming Andreasen and
Alissa Cooper for a thorough review. In addition Bill Atwood has
provided comments and suggestions for improvements.
13. References
13.1. Normative References 12. References
[I-D.ietf-mmusic-rfc2326bis] 12.1. Normative References
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-40 (work in
progress), February 2014.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[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, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[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, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[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,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
13.2. Informative References [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <http://www.rfc-editor.org/info/rfc7826>.
[I-D.ietf-mmusic-rtsp-nat-evaluation] 12.2. Informative References
Westerlund, M. and T. Zeng, "The Evaluation of Different
Network Address Translator (NAT) Traversal Techniques for
Media Controlled by Real-time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-evaluation-14 (work in
progress), May 2014.
[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,
DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January Address Translator (Traditional NAT)", RFC 3022,
2001. DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[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. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[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, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[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. DOI 10.17487/RFC3489, March 2003,
<http://www.rfc-editor.org/info/rfc3489>.
[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,
DOI 10.17487/RFC4340, March 2006,
<http://www.rfc-editor.org/info/rfc4340>.
[RFC7604] Westerlund, M. and T. Zeng, "Comparison of Different NAT
Traversal Techniques for Media Controlled by the Real-Time
Streaming Protocol (RTSP)", RFC 7604,
DOI 10.17487/RFC7604, September 2015,
<http://www.rfc-editor.org/info/rfc7604>.
Acknowledgments
The authors would like to thank: Remi Denis-Courmont for suggesting
the method of integrating ICE in RTSP signaling, Dan Wing for help
with the security section and numerous other issues, Ari Keranen for
review of the document and its ICE details, and Flemming Andreasen
and Alissa Cooper for a thorough review. In addition, Bill Atwood
has provided comments and suggestions for improvements.
Authors' Addresses Authors' Addresses
Jeff Goldberg Jeff Goldberg
Cisco Cisco
11 New Square, Bedfont Lakes 32 Hamelacha St.
Feltham,, Middx TW14 8HA South Netanya 42504
United Kingdom Israel
Phone: +44 20 8824 1000 Phone: +972 9 8927222
Email: jgoldber@cisco.com Email: jgoldber@cisco.com
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
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
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 United States of America
Phone: +1 858 480 3100 Phone: +1 858 480 3100
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
 End of changes. 203 change blocks. 
567 lines changed or deleted 576 lines changed or added

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