draft-ietf-mmusic-rtsp-nat-09.txt   draft-ietf-mmusic-rtsp-nat-10.txt 
Network Working Group J. Goldberg Network Working Group J. Goldberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: July 24, 2010 Ericsson Expires: September 15, 2011 Ericsson
T. Zeng T. Zeng
Nextwave Wireless, Inc. Nextwave Wireless, Inc.
January 20, 2010 March 14, 2011
A Network Address Translator (NAT) Traversal mechanism for media A Network Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP) controlled by Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-09 draft-ietf-mmusic-rtsp-nat-10
Abstract Abstract
This document defines a solution for Network Address Translation This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams setup and controlled (NAT) traversal for datagram based media streams setup and controlled
with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses
Interactive Connectivity Establishment (ICE) adapted to use RTSP as a Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
signalling channel, defining the necessary extra RTSP extensions and signalling channel, defining the necessary extra RTSP extensions and
procedures. procedures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 15, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 6 4. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. ICE Candidate Transport Header Parameter . . . . . . . . . 8 4.1. ICE Transport Lower Layer . . . . . . . . . . . . . . . . 7
3.3. ICE Password and Username Transport Header Parameters . . 11 4.2. ICE Candidate Transport Header Parameter . . . . . . . . . 8
3.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11 4.3. ICE Password and Username Transport Header Parameters . . 11
3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. ICE Feature Tag . . . . . . . . . . . . . . . . . . . . . 11
3.5.1. 150 ICE connectivity checks in progress . . . . . . . 12 4.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12 4.5.1. 150 ICE connectivity checks in progress . . . . . . . 12
3.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . . 12 4.5.2. 480 ICE Processing Failed . . . . . . . . . . . . . . 12
3.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12 4.6. New Reason for PLAY_NOTIFY . . . . . . . . . . . . . . . . 12
3.8. ICE Features Not Required in RTSP . . . . . . . . . . . . 13 4.7. Server Side SDP Attribute for ICE Support . . . . . . . . 12
3.8.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 13 4.8. ICE Features Not Required in RTSP . . . . . . . . . . . . 13
3.8.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 13 4.8.1. ICE-Lite . . . . . . . . . . . . . . . . . . . . . . . 13
3.8.3. ICE Remote Candidate Transport Header Parameter . . . 13 4.8.2. ICE-Mismatch . . . . . . . . . . . . . . . . . . . . . 13
4. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 13 4.8.3. ICE Remote Candidate Transport Header Parameter . . . 13
4.1. Session description and RTSP DESCRIBE (optional) . . . . . 14 5. Detailed Solution . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15 5.1. Session description and RTSP DESCRIBE (optional) . . . . . 13
4.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15 5.2. Setting up the Media Streams . . . . . . . . . . . . . . . 15
4.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 16 5.3. RTSP SETUP Request . . . . . . . . . . . . . . . . . . . . 15
4.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 17 5.4. Gathering Candidates . . . . . . . . . . . . . . . . . . . 15
4.6. Server to Client ICE Connectivity Checks . . . . . . . . . 17 5.5. RTSP Server Response . . . . . . . . . . . . . . . . . . . 16
4.7. Client to Server ICE Connectivity Check . . . . . . . . . 18 5.6. Server to Client ICE Connectivity Checks . . . . . . . . . 17
4.8. Client Connectivity Checks Complete . . . . . . . . . . . 18 5.7. Client to Server ICE Connectivity Check . . . . . . . . . 17
4.9. Server Connectivity Checks Complete . . . . . . . . . . . 18 5.8. Client Connectivity Checks Complete . . . . . . . . . . . 18
4.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 19 5.9. Server Connectivity Checks Complete . . . . . . . . . . . 18
4.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 19 5.10. Releasing Candidates . . . . . . . . . . . . . . . . . . . 18
4.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.11. Steady State . . . . . . . . . . . . . . . . . . . . . . . 18
4.13. Server Side Changes After Steady State . . . . . . . . . . 19 5.12. re-SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 21 5.13. Server Side Changes After Steady State . . . . . . . . . . 19
5.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 22 6. ICE and Proxies . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22 6.1. Media Handling Proxies . . . . . . . . . . . . . . . . . . 21
5.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 22 6.2. Signalling Only Proxies . . . . . . . . . . . . . . . . . 22
6. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 23 6.3. Non-supporting Proxies . . . . . . . . . . . . . . . . . . 22
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.2. Transport Protocol Specifications . . . . . . . . . . . . 24 9.1. RTSP Feature Tags . . . . . . . . . . . . . . . . . . . . 24
8.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 25 9.2. Transport Protocol Specifications . . . . . . . . . . . . 25
8.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 25 9.3. RTSP Transport Parameters . . . . . . . . . . . . . . . . 25
8.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 25 9.4. RTSP Status Codes . . . . . . . . . . . . . . . . . . . . 25
8.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 25 9.5. Notify-Reason value . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.6. SDP Attribute . . . . . . . . . . . . . . . . . . . . . . 25
9.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. ICE and RTSP . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Real-time Streaming Protocol (RTSP) Real-time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0
[RFC2326][I-D.ietf-mmusic-rfc2326bis] is a protocol used to setup and [I-D.ietf-mmusic-rfc2326bis] is protocols used to setup and control
control one or more media streams delivering media to receivers. It one or more media streams delivering media to receivers. It is
is RTSP's functionality of setting up media streams that cause RTSP's functionality of setting up media streams that cause serious
serious issues with Network Address Translators (NAT) [RFC3022] issues with Network Address Translators (NAT) [RFC3022] unless extra
unless extra provisions are taken by the protocol. There is thus a provisions are taken by the protocol. There is thus a need for a NAT
need for a NAT traversal mechanism for the media setup using RTSP. traversal mechanism 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 has had to wait on the recently RTSP 1.0 specification, the work has had to wait on the specification
defined RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis]. RTSP 2.0 is similar to
to RTSP 1.0 in many respects but significantly for this work, it RTSP 1.0 in many respects but significantly for this work, it
contains a well defined extension mechanism so allowing a NAT contains a well defined extension mechanism so allowing a NAT
traversal extension to be defined that is backwards compatible with traversal extension to be defined that is backwards compatible with
RTSP 2.0 peers not supporting the extension. This extension RTSP 2.0 peers not supporting the extension. This extension
mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0
syntax so causing compatibility issues. syntax so causing 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 which a large number are already used traversal of media for RTSP of which a large number 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 in [I-D.ietf-mmusic-rtsp-nat-evaluation] has shown that there are
issues to consider, so after extensive evaluation, we selected a many issues to consider, so after extensive evaluation, we selected a
mechanism based on Interactive Connectivity Establishment (ICE). mechanism based on Interactive Connectivity Establishment (ICE).
This was mainly two reasons: Firstly the mechanism supports RTSP This was mainly two reasons: Firstly the mechanism supports RTSP
servers behind NATs and secondly the mechanism solves the security servers behind NATs and secondly the mechanism solves the security
threat that uses RTSP servers as Distributed Denial of Service (DDoS) threat that uses RTSP servers as Distributed Denial of Service (DDoS)
attack tools. 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 server to client. If in the future extensions are media delivery server to client. If in the future extensions are
specified for other delivery modes than PLAY, then the optimizations specified for other delivery modes than PLAY, then the optimizations
in regards to when PLAY request are sent needs to be reconsidered. in regards to when PLAY request are sent needs to be reconsidered.
The NAT problem for RTSP signalling traffic itself is beyond the The NAT problem for RTSP signalling traffic itself is beyond the
scope of this document and is left for future study should the need scope of this document and is left for future study should the need
arise, because it is a less prevalent problem than the NAT problem arise, because it is a less prevalent problem than the NAT problem
for RTSP media streams. for RTSP media streams.
2. Solution Overview 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 [I-D.ietf-mmusic-ice] works, as it primarily points out how the ICE [RFC5245] in the context of "SIP: Session Initiation Protocol"
[RFC3261] and "An Offer/Answer Model with the Session Description
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. RTSP server can indicate it has support for ICE via an SDP 1. RTSP server should indicate it has support for ICE via an SDP
[RFC4566] attribute in, for example, the SDP returned in RTSP [RFC4566] attribute ("a=rtsp-ice-d-m") in, for example, the SDP
DESCRIBE message. This allows RTSP clients to only send the new returned in RTSP DESCRIBE message. This allows RTSP clients to
ICE interchanges with servers that support ICE so as to limit only send the new ICE interchanges with servers that support ICE
the overhead on current non-ICE supporting RTSP servers. If so as to limit the overhead on current non-ICE supporting RTSP
RTSP DESCRIBE is used the normal capability determination servers. If RTSP DESCRIBE is used the normal capability
mechanism can be used, i.e. "Supported" header and the defined determination mechanism should also be used, i.e. "Supported"
feature tag. header and the defined feature tag. Note: Both mechanisms
should be used as there are use cases when either of them are
not used.
2. RTSP client reviews the session description returned, for 2. The RTSP client reviews the session description returned, for
example by an RTSP DESCRIBE message, to determine what media example by an RTSP DESCRIBE message, to determine what media
streams need to be setup. For each of these media streams where streams need to be setup. For each of these media streams where
the transport protocol supports Session Traversal Utilities for the transport protocol supports Session Traversal Utilities for
(NAT) (STUN) [RFC5389] based connectivity checks, the client (NAT) (STUN) [RFC5389] based connectivity checks, the client
gathers candidate addresses. See section 4.1.1 in gathers candidate addresses. See section 4.1.1 in ICE
[I-D.ietf-mmusic-ice]. The client also installs the STUN [RFC5245]. The client also installs the STUN servers on each of
servers on each of the local candidates. the local candidates.
3. RTSP client sends SETUP requests with both a transport 3. The RTSP client sends SETUP requests with both a transport
specification with a lower layer indicating ICE and a new RTSP specification with a lower layer indicating ICE and a new RTSP
Transport header parameter listing the ICE candidates for each Transport header parameter listing the ICE candidates for each
media stream. media stream.
4. After receiving the list of candidates from a client, the RTSP 4. After receiving the list of candidates from a client, the RTSP
server gathers its own candidates. If the server has a public server gathers its own candidates. If the server has a public
IP address, then a single candidate per address family (e.g. IP address, then a single candidate per address family (e.g.
IPv4 and IPv6), media stream and media component tuple can be IPv4 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 server candidate parameter. includes its candidates in the server candidate 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 procedures described in Section 5.7 and 5.8 of ICE [RFC5245].
[I-D.ietf-mmusic-ice]. If the server has a public IP address If the server has a public IP address with a single candidate
with a single candidate per media stream, component and address per media stream, component and address family then one may
family then one may configure the server to not initiate configure the server 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
address to use for the connectivity checks, and then initiates address 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
[I-D.ietf-mmusic-ice]. ICE [RFC5245].
8. When a connectivity check from the client reaches the server it 8. When a connectivity check from the client reaches the server it
will result in a triggered check from the server. This is why will result in a triggered check from the server. This is why
servers with a public IP address can wait until this triggered servers with a public IP address can wait until this triggered
check to send out any checks for itself so saving resources and check to send out any checks for itself so saving resources and
mitigating the DDoS potential from server connectivity checks. mitigating the DDoS potential from server connectivity checks.
9. When the client has concluded its connectivity checks and has 9. When the client has concluded its connectivity checks, including
correspondingly received the server connectivity checks on the promoting candidates, and has correspondingly received the
promoted candidates for all mandatory components of all media server connectivity checks on the promoted candidates for all
streams, it can issue a PLAY request. If the connectivity mandatory components of all media streams, it can issue a PLAY
checks have not concluded successfully then the client may send request. If the connectivity checks have not concluded
a new SETUP request assuming it has any new information or successfully then the client may send a new SETUP request
believes the server may be able to do more that can result in assuming it has any new information or believes the server may
successful checks. be able to do more that can result in successful checks.
10. When the RTSP servers receives a PLAY request it checks to see 10. When the RTSP servers receives a PLAY request it checks to see
the connectivity checks has concluded successfully and only then the connectivity checks has concluded successfully and only then
can play the stream. If there is a problem with the checks then can play the stream. If there is a problem with the checks then
the server sends to the client either a 150 (ICE connectivity the server sends to the client either a 150 (ICE connectivity
checks in progress) response to show that it is still working on checks in progress) response to show that it is still working on
the connectivity checks or a 480 (ICE Processing Failed) the connectivity checks or a 480 (ICE Processing Failed)
response to indicate a failure of the checks. If the checks are response to indicate a failure of the checks. If the checks are
successful then the server sends a 200 OK response and starts successful then the server sends a 200 OK response and starts
delivering media. delivering media.
The client and server may release unused candidates when the ICE The client and server may release unused candidates when the ICE
processing has concluded and a single candidate per component has processing has concluded and a single candidate per component has
been promoted. been promoted and a PLAY response has been receiver or sent.
The client shall continue to use STUN to send keep-alive for the used The client shall continue to use STUN to send keep-alive for the used
bindings. This is important as often RTSP media sessions only bindings. This is important as often RTSP media sessions only
contain media traffic from the server to the client so the bindings contain media traffic from the server to the client so the bindings
in the NAT needs to be refreshed by the client to server traffic in the NAT needs to be refreshed by the client to server traffic
provided by the STUN keep-alive. provided by the STUN keep-alive.
3. 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.
3.1. ICE Transport Lower Layer 4.1. ICE Transport Lower Layer
A new lower layer "D-ICE" for transport specifications is defined. A new lower layer "D-ICE" for transport specifications is defined.
This lower layer is datagram clean except that the protocol used must This lower layer is datagram clean except that the protocol used must
be demultiplexiable with STUN messages (see STUN [RFC5389]). With be demultiplexiable with STUN messages (see STUN [RFC5389]). With
datagram clean we mean that it must be capable of describing the datagram clean we mean that it must be capable of describing the
length of the datagram, transport that datagram (as a binary chunk of length of the datagram, transport that datagram (as a binary chunk of
data) and provide it at the receiving side as one single item. This data) and provide it at the receiving side as one single item. This
lower layer can be any transport type defined for ICE which does lower layer can be any transport type defined for ICE which does
provide datagram transport capabilities. Though only UDP is defined provide datagram transport capabilities. Though only UDP is defined
at present, however DCCP or TCP with framing may be specified and at present, however "Datagram Congestion Control Protocol (DCCP)"
used in the future. [RFC4340] or "Transmission Control Protocol" (TCP) [RFC0793] with
framing may be specified and used 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 which use datagrams. This specification defines the following
combinations: combinations:
skipping to change at page 8, line 38 skipping to change at page 7, line 47
This list can easily be extended with more transport specifications This list can easily be extended with more transport specifications
after having performed the evaluation that they are compatible with after having performed the evaluation that they are compatible with
D-ICE as lower layer. D-ICE as lower layer.
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
transport parameters: transport parameters:
unicast: As ICE only supports unicast operations, thus it is unicast: As ICE only supports unicast operations, thus it is
REQUIRED that one include the unicast indicator parameter, see REQUIRED that one include the unicast indicator parameter, see
section 16.46 in [I-D.ietf-mmusic-rfc2326bis]. section 16.46 in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis].
candidates: The "candidates" parameter SHALL be included as this candidates: The "candidates" parameter SHALL be included as this
specify at least one candidate to try to establish a working specify at least one candidate to try to establish a working
transport path with. transport path with.
dest_addr: This parameter SHALL NOT be included as "candidates" is dest_addr: This parameter SHALL NOT be included as "candidates" is
used instead to provide the necessary address information. used instead to provide the necessary address information.
ICE-Password: This parameter SHALL be included. ICE-Password: This parameter SHALL be included.
ICE-ufrag: This parameter SHALL be included. ICE-ufrag: This parameter SHALL be included.
3.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 specification using each transport specification. For transport specification using
"D-ICE" as lower layer, this parameter needs to be present. The "D-ICE" as lower layer, this parameter needs to 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, and 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
skipping to change at page 10, line 21 skipping to change at page 9, line 21
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 extension-att-name SP extension-att-value) *(SP extension-att-name SP extension-att-value)
foundation = <See section 15.1 of [I-D.ietf-mmusic-ice]> foundation = <See section 15.1 of [RFC5245]>
component-id = <See section 15.1 of [I-D.ietf-mmusic-ice]> component-id = <See section 15.1 of [RFC5245]>
transport = <See section 15.1 of [I-D.ietf-mmusic-ice]> transport = <See section 15.1 of [RFC5245]>
transport-extension = <See section 15.1 of [I-D.ietf-mmusic-ice]> transport-extension = <See section 15.1 of [RFC5245]>
priority = <See section 15.1 of [I-D.ietf-mmusic-ice]> priority = <See section 15.1 of [RFC5245]>
cand-type = <See section 15.1 of [I-D.ietf-mmusic-ice]> cand-type = <See section 15.1 of [RFC5245]>
candidate-types = <See section 15.1 of [I-D.ietf-mmusic-ice]> candidate-types = <See section 15.1 of [RFC5245]>
rel-addr = <See section 15.1 of [I-D.ietf-mmusic-ice]> rel-addr = <See section 15.1 of [RFC5245]>
rel-port = <See section 15.1 of [I-D.ietf-mmusic-ice]> rel-port = <See section 15.1 of [RFC5245]>
extension-att-name = <See section 15.1 of [I-D.ietf-mmusic-ice]> extension-att-name = <See section 15.1 of [RFC5245]>
extension-att-value = <See section 15.1 of [I-D.ietf-mmusic-ice]> extension-att-value = <See section 15.1 of [RFC5245]>
ice-char = <See section 15.1 of [I-D.ietf-mmusic-ice]> ice-char = <See section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]> connection-address = <See [RFC4566]>
port = <See [RFC4566]> port = <See [RFC4566]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]> EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]> DQ = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SWS = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
<connection-address>: is the IP address of the candidate, allowing <connection-address>: is the IP address of the candidate, allowing
for IPv4 addresses, IPv6 addresses and Fully qualified domain names for IPv4 addresses, IPv6 addresses and Fully qualified domain names
(FQDN), taken from [RFC4566]. The connection address SHOULD be on (FQDN), taken from ICE [RFC4566]. The connection address SHOULD be
the same format (explicit IP or FQDN) as in the dest_addr parameter on the same format (explicit IP or FQDN) as in the dest_addr
used to express fallbacks. An IP address SHOULD be used, but an FQDN parameter used to express fallbacks. An IP address SHOULD be used,
MAY be used in place of an IP address. In that case, when receiving but an FQDN MAY be used in place of an IP address. In that case,
an SETUP request or response containing an FQDN in an candidate when receiving an SETUP request or response containing an FQDN in an
parameter, the FQDN is looked up in the DNS first using an AAAA candidate parameter, the FQDN is looked up in the DNS first using an
record (assuming the agent supports IPv6), and if no result is found AAAA record (assuming the agent supports IPv6), and if no result is
or the agent only supports IPv4, using an A record. If the DNS query found or the agent only supports IPv4, using an A record. If the DNS
returns more than one IP address, one is chosen, and then used for query returns more than one IP address, one is chosen, and then used
the remainder of ICE processing which in RTSP is subsequent RTSP for the remainder of ICE processing which in RTSP is subsequent RTSP
SETUPs for the same RTSP session. SETUPs for the same RTSP session.
<port>: is the port of the candidate taken from RFC 4566 [RFC4566]. <port>: is the port of the candidate taken from SDP [RFC4566].
<transport>: indicates the transport protocol for the candidate. The <transport>: indicates the transport protocol for the candidate. The
ICE specification only defines UDP. However, extensibility is ICE specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with ICE, provided to allow for future transport protocols to be used with ICE,
such as TCP or the Datagram Congestion Control Protocol (DCCP) such as TCP [RFC0793] or the Datagram Congestion Control Protocol
[RFC4340]. (DCCP) [RFC4340].
<foundation>: is an identifier that is equivalent for two candidates <foundation>: is an identifier that is equivalent for two candidates
that are of the same type, share the same base, and come from the that are of the same type, share the same base, and come from the
same STUN server, and is composed of one to thirty two <ice-char>. same STUN server, and is composed of one to thirty two <ice-char>.
The foundation is used to optimize ICE performance in the Frozen The foundation is used to optimize ICE performance in the Frozen
algorithm. algorithm.
<component-id>: identifies the specific component of the media stream <component-id>: identifies the specific component of the media stream
for which this is a candidate and os a positive integer between 1 and for which this is a candidate and os a positive integer between 1 and
256. It MUST start at 1 and MUST increment by 1 for each component 256. It MUST start at 1 and MUST increment by 1 for each component
skipping to change at page 11, line 46 skipping to change at page 10, line 46
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> and candidate, useful for diagnostics and other purposes. <rel-addr> and
<rel-port> MUST be present for server reflexive, peer reflexive and <rel-port> MUST be present for server reflexive, peer reflexive and
relayed candidates. If a candidate is server or peer reflexive, relayed candidates. If a candidate is server or peer reflexive,
<rel-addr> and <rel-port> is equal to the base for that server or <rel-addr> and <rel-port> is equal to the base for that server or
peer reflexive candidate. If the candidate is relayed, <rel-addr> peer reflexive candidate. If the candidate is relayed, <rel-addr>
and <rel-port> is equal to the mapped address in the Allocate and <rel-port> is equal to the mapped address in the Allocate
Response that provided the client with that relayed candidate (see Response that provided the client with that relayed candidate (see
Appendix B.3 of [I-D.ietf-mmusic-ice] for a discussion of its Appendix B.3 of ICE [RFC5245] for a discussion of its purpose). If
purpose). If the candidate is a host candidate <rel-addr> and <rel- the candidate is a host candidate <rel-addr> and <rel-port> MUST be
port> MUST be omitted. omitted.
3.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 needs to be transported
using RTSP. For that purpose new transport header parameters are using RTSP. For that purpose new transport header parameters are
defined. defined.
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. If two SETUP requests in the same RTSP session have
identical ICE-ufrag's, they MUST have identical ICE-Password's. The identical ICE-ufrag's, they MUST have identical ICE-Password's. The
ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the ICE-ufrag and ICE-Password attributes MUST be chosen randomly at the
beginning of a session. The ICE-ufrag attribute MUST contain at beginning of a session. The ICE-ufrag attribute MUST contain at
skipping to change at page 12, line 32 skipping to change at page 11, line 32
course, up to 256 characters. The upper limit allows for buffer course, up to 256 characters. The upper limit allows for buffer
sizing in implementations. Its large upper limit allows for sizing in implementations. Its large upper limit allows for
increased amounts of randomness to be added over time. increased amounts of randomness to be added over time.
The ABNF [RFC5234] for these parameters are: The ABNF [RFC5234] for these parameters are:
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 password ice-password-par = "ICE-Password" EQUAL password
ice-ufrag-par = "ICE-ufrag" EQUAL ufrag ice-ufrag-par = "ICE-ufrag" EQUAL ufrag
password = <Defined in [I-D.ietf-mmusic-ice]> password = <Defined in [RFC5245]>
ufrag = <Defined in [I-D.ietf-mmusic-ice]> ufrag = <Defined in [RFC5245]>
EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]> EQUAL = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]> SEMI = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
3.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. lower layer transport.
3.5. Status Codes 4.5. Status Codes
ICE needs two new RTSP response codes to indicate correctly progress ICE needs two new RTSP response codes to indicate correctly progress
and errors. and errors.
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY | | 150 | Server still working on ICE connectivity | PLAY |
| | checks | | | | checks | |
| 480 | ICE Connectivity check failure | PLAY, SETUP | | 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+ +------+----------------------------------------------+-------------+
Table 1: New Status codes and their usage with RTSP methods Table 1: New Status codes and their usage with RTSP methods
3.5.1. 150 ICE connectivity checks in progress 4.5.1. 150 ICE connectivity checks in progress
The 150 response code indicates that ICE connectivity checks are The 150 response code indicates that ICE connectivity checks are
still in progress and haven't concluded. This response SHALL be sent still in progress and haven't concluded. This response SHALL be sent
within 200 milliseconds of receiving a PLAY request that currently within 200 milliseconds of receiving a PLAY request that currently
can't be fulfilled because ICE connectivity checks are still running. can't be fulfilled because ICE connectivity checks are still running.
Subsequently, every 3 seconds after the previous sent one, a 150 Subsequently, every 3 seconds after the previous sent one, a 150
reply shall be sent until the ICE connectivity checks conclude either reply shall be sent until the ICE connectivity checks conclude either
successfully or in failure, and a final response for the request can successfully or in failure, and a final response for the request can
be provided. be provided.
3.5.2. 480 ICE Processing Failed 4.5.2. 480 ICE Processing Failed
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
that all the connectivity checks have timed out. This error message that all the connectivity checks have timed out. This error message
can appear either in response to a SETUP request to indicate that no can appear either in response to a SETUP request to indicate that no
candidate pair can be constructed or to a PLAY request that the candidate pair can be constructed or to a PLAY request that the
server's connectivity checks resulted in failure. server's connectivity checks resulted in failure.
3.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 a ICE restart defined: "ice-restart". This reason indicates that a 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"
3.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 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 the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing
content served by the server. This is an session level attribute. content served by the server. This is an session level attribute.
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m" rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"
3.8. ICE Features Not Required in RTSP 4.8. ICE Features Not Required in RTSP
A number of ICE signalling features are not needed with RTSP and are A number of ICE signalling features are not needed with RTSP and are
discussed below. discussed below.
3.8.1. ICE-Lite 4.8.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 are used to protect against making the RTSP server a denial of which are used to protect against making the RTSP server a denial of
service tool. This document defines another variation implementation service tool. This document defines another variation implementation
of ICE, called ICE-RTSP. It has its own set of simplifications of ICE, called ICE-RTSP. It has its own set of simplifications
suitable to RTSP. Conceptually, this implementation of ICE-RTSP is suitable to RTSP. Conceptually, this implementation of ICE-RTSP is
between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL
for clients. for clients.
3.8.2. ICE-Mismatch 4.8.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.
3.8.3. ICE Remote Candidate Transport Header Parameter 4.8.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 a independent ICE following reasons. Each SETUP results in a independent ICE
processing chain which either fails or results in promoting a single processing chain which either fails or results in promoting a single
candidate pair to usage. If a new SETUP request for the same media candidate pair to usage. If a new SETUP request for the same media
is sent this needs to use a new userfragment and password to avoid is sent this needs to use a new userfragment and password to avoid
any race conditions or uncertainty for which processing round the any race conditions or uncertainty for which processing round the
STUN requests relate to. STUN requests relate to.
4. Detailed Solution 5. Detailed Solution
This section describes in detail how the interaction and flow of ICE This section describes in detail how the interaction and flow of ICE
works with RTSP messages. works with RTSP messages.
4.1. Session description and RTSP DESCRIBE (optional) 5.1. Session description and RTSP DESCRIBE (optional)
The RTSP server should indicate it has support for ICE by sending the The RTSP server should indicate it has support for ICE by sending the
"rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE "a=rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE
message if SDP is used. This allows RTSP clients to only send the message if SDP is used. This allows RTSP clients to only send the
new ICE interchanges with servers that support ICE so limiting the new ICE interchanges with servers that support ICE so limiting the
overhead on current non-ICE supporting RTSP servers. When not using overhead on current non-ICE supporting RTSP servers. When not using
RTSP DESCRIBE it is still recommended to use the SDP attribute for RTSP DESCRIBE it is still recommended to use the SDP attribute for
session description. 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". Any proxy upon seeing the "Supported" header will
skipping to change at page 16, line 10 skipping to change at page 14, line 26
its own version of the Supported header so enabling a client to its own version of the Supported header so enabling a client to
determine if all involved parties support ICE or not. Note that even determine if all involved parties support ICE or not. Note that even
if a proxy is present in the chain that doesn't indicate support for if a proxy is present in the chain that doesn't indicate support for
ICE, it may still work. ICE, it may still work.
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 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
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 367 Content-Length: 367
Supported: setup.ice-d-m Supported: setup.ice-d-m, setup.rtp.rtcp.mux
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
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
4.2. Setting up the Media Streams 5.2. Setting up the Media Streams
The RTSP client reviews the session description returned, for example The RTSP client reviews the session description returned, for example
by an RTSP DESCRIBE message, to determine what media resources that by an RTSP DESCRIBE message, to determine what media resources that
need to be setup. For each of these media streams where the need to be setup. For each of these media streams where the
transport protocol supports ICE connectivity checks, the client shall transport protocol supports ICE connectivity checks, the client SHALL
gather candidate addresses as described in section 4.1.1 in gather candidate addresses as described in section 4.1.1 in ICE
[I-D.ietf-mmusic-ice] according to standard ICE rather than the ICE- [RFC5245] according to standard ICE rather than the ICE-Lite
Lite implementation. implementation.
4.3. RTSP SETUP Request 5.3. RTSP SETUP Request
The RTSP client will then send at least one SETUP request per media The RTSP client will then send at least one SETUP request per media
stream to establish the media streams required for the desired stream to establish the media streams required for the desired
session. For each media stream where it desires to use ICE it will session. For each media stream where it desires to use ICE it will
include a transport specification with "D-ICE" as the lower layer, include a transport specification with "D-ICE" as the lower layer,
and each media stream SHALL have its own unique ICE candidates. This and each media stream SHALL have its own unique ICE candidates. This
transport specification SHOULD be placed first in the list to give it transport specification SHOULD be placed first in the list to give it
highest priority. It is RECOMMENDED that additional transport highest priority. It is RECOMMENDED that additional transport
specifications are provided as a fallback in case of non ICE specifications are provided as a fallback in case of non ICE
supporting proxies. For example (Note that some lines are broken in supporting proxies. 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: 302 CSeq: 302
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 9002", raddr 10.0.1.17 rport 9002"; 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 Supported: setup.ice-d-m, setup.rtp.rtcp.mux
The RTSP client will be initiating and thus the controlling party in The RTSP client will be initiating and thus the controlling party in
the ICE processing. the ICE processing.
4.4. Gathering Candidates 5.4. Gathering Candidates
Upon receiving a SETUP request the server can determine what media Upon receiving a SETUP request the server can determine what media
resource should be delivered and which transport alternatives that resource should be delivered and which transport alternatives that
the client supports. If one based on D-ICE is on the list of the client supports. If one based on D-ICE is on the list of
supported transports and prefered among the support, the below supported transports and prefered among the support, the below
applies. applies.
The transport specification will provide which media protocol is to The transport specification will provide which media protocol is to
be used and based on this and the clients candidates, the server be used and based on this and the clients candidates, the server
determines the protocol and if it supports ICE with that protocol. determines the protocol and if it supports ICE with that protocol.
The server shall then gather its candidates according to section The server shall then gather its candidates according to section
4.1.1 in [I-D.ietf-mmusic-ice]. Servers that have an address that is 4.1.1 in ICE [RFC5245]. Servers that have an address that is
generally reachable by any clients within the address scope the generally reachable by any clients within the address scope the
server intends to serve MAY be specially configured (high- server intends to serve MAY be specially configured (high-
reachability configuration). This special configuration has the goal reachability configuration). This special configuration has the goal
of reducing the server side candidate to preferably a single one per of reducing the server side candidate to preferably a single one per
(address family, media stream, media component) tuple. Instead of (address family, media stream, media component) tuple. Instead of
gathering all possible addresses including relayed and server gathering all possible addresses including relayed and server
reflexive addresses, the server uses a single address per address reflexive addresses, the server uses a single address per address
family that it knows it should be reachable by a client behind one or family that it knows it should be reachable by a client behind one or
more NATs. The reason for this special configuration is two fold: more NATs. The reason for this special configuration is two fold:
Firstly it reduces the load on the server in address gathering and in Firstly it reduces the load on the server in address gathering and in
ICE processing during the connectivity checks. Secondly it will ICE processing during the connectivity checks. Secondly it will
reduce the number of permutations for candidate pairs significantly reduce the number of permutations for candidate pairs significantly
thus potentially speeding up the conclusion of the ICE processing. thus potentially speeding up the conclusion of the ICE processing.
Note however that using this option on a server that doesn't fulfill Note however that using this option on a server that doesn't fulfill
the requirement of being reachable is counter-productive and it is the requirement of being reachable is counter-productive and it is
important that this is correctly configured. important that this is correctly configured.
4.5. RTSP Server Response 5.5. RTSP Server Response
The server determines if the SETUP request is successful from the The server determines if the SETUP request is successful from the
other perspectives and will return a 200 OK response, otherwise other perspectives and will return a 200 OK response, otherwise
returning an error code from the list in Table 4 in returning an error code from the list in Table 4 in
[I-D.ietf-mmusic-rfc2326bis]. At that point the server, having [I-D.ietf-mmusic-rfc2326bis]. At that point the server, having
selected a transport specification using the "D-ICE" lower layer, selected a transport specification using the "D-ICE" lower layer,
will need to include that transport specification in the response will need to include that transport specification in the response
message. The transport specification shall include the candidates message. The transport specification shall include the candidates
gathered in SectionSection 4.4 in the "candidates" transport header gathered in Section 5.4 in the "candidates" transport header
parameter as well as the server's username and password. In the case parameter as well as the server's username and password. In the case
that there are no valid candidate pairs with the combination of the that there are no valid candidate pairs with the combination of the
client and servers candidates, a 480 (ICE Processing Failed) error client and servers candidates, a 480 (ICE Processing Failed) error
response shall be returned which must include the servers' response shall be returned which must include the servers'
candidates. The return of a 480 error allows both the server and candidates. The return of a 480 error allows both the server and
client to release its candidates. client to release its candidates.
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Session: 12345678 Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; 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 Supported: setup.ice-d-m, setup.rtp.rtcp.mux
4.6. Server to Client ICE Connectivity Checks 5.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 [I-D.ietf-mmusic-ice] procedures described in Section 5.7 and 5.8 of ICE [RFC5245] unless
unless it is configured to use the high-reachability option. If it it is configured to use the high-reachability option. If it is then
is then it can suppress its own checks until the servers checks are it can suppress its own checks until the servers checks are triggered
triggered by the client's connectivity checks. by the client's connectivity checks.
Please note that section 5.8 does specify that the start of Please note that section 5.8 does specify that the initiation of the
initiation of the checks are paced and new ones are only started checks are paced and new ones are only started every Ta milliseconds.
every Ta seconds. The motivation for this is documented in Appendix The motivation for this is documented in Appendix B.1 of ICE
B.1 of [I-D.ietf-mmusic-ice] as for SIP/SDP all media streams within [RFC5245] as for SIP/SDP all media streams within an offer/answer
an offer/answer dialog are running using the same queue. To ensure dialog are running using the same queue. To ensure the same behavior
the same behavior with RTSP, the server SHALL use a single pacer with RTSP, the server SHALL use a single pacer queue for all media
queue for all media streams within each RTSP session. 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 some minimum values defined in the ICE can be configured but have some minimum values defined in the ICE
specification. specification.
When a connectivity check from the client reaches the server it will When a connectivity check from the client reaches the server it will
result in a triggered check from the server as specified in section result in a triggered check from the server as specified in section
7.2.1.4 of [I-D.ietf-mmusic-ice]. This is why servers with a high 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.
4.7. Client to Server ICE Connectivity Check 5.7. Client to Server ICE Connectivity Check
The client receives the SETUP response and learns the candidate The client receives the SETUP response and learns the candidate
address to use for the connectivity checks. The client shall address to use for the connectivity checks. The client shall
initiate its connectivity check, following the procedures in Section initiate its connectivity check, following the procedures in Section
6 of [I-D.ietf-mmusic-ice]. The STUN transaction pacer SHALL be used 6 of [RFC5245]. The STUN transaction pacer SHALL be used across all
across all media streams part of the same RTSP session. media streams part of the same RTSP session.
Aggressive nomination SHALL be used with RTSP. This doesn't have the Aggressive nomination SHALL be used with RTSP. This doesn't have the
negative impact that it has in offer/answer as media playing only negative impact that it has in offer/answer as media playing only
starts after issuing a PLAY request. starts after issuing a PLAY request.
4.8. Client Connectivity Checks Complete 5.8. Client Connectivity Checks Complete
When the client has concluded all of its connectivity checks and has When the client has concluded all of its connectivity checks and has
nominated its desired candidate for a particular media stream, it MAY nominated its desired candidate for a particular media stream, it MAY
issue a PLAY request for that stream. Note, that due to the issue a PLAY request for that stream. Note, that due to the
aggressive nomination, there is a risk that any outstanding check may aggressive nomination, there is a risk that any outstanding check may
nominate another pair than what was already nominated. If the client nominate another pair than what was already nominated. If the client
has locally determined that its checks have failed it may try has locally determined that its checks have failed it may try
providing an extended set of candidates and update the server providing an extended set of candidates and update the server
candidate list by issuing a new SETUP request for the media stream. candidate list by issuing a new SETUP request for the media stream.
If the client concluded its connectivity checks successfully and If the client concluded its connectivity checks successfully and
therefore sent a PLAY request but the server cannot conclude therefore sent a PLAY request but the server cannot conclude
successfully, the server will respond with a 480 (ICE Processing successfully, the server will respond with a 480 (ICE Processing
Failed). Upon receiving the 480 (ICE Processing Failed) response, Failed). Upon receiving the 480 (ICE Processing Failed) response,
the client may send a new SETUP request assuming it has any new the client may send a new SETUP request assuming it has any new
information that can be included in the candidate list. If the information that can be included in the candidate list. If the
server is still performing the checks it will respond with a 150 (CE server is still performing the checks it will respond with a 150 (CE
connectivity checks in progress) response to indicate this. connectivity checks in progress) response to indicate this.
4.9. Server Connectivity Checks Complete 5.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 completely successfully. If the server has checks for that stream completely successfully. If the server has
not concluded its connectivity checks the server indicates that by not concluded its connectivity checks the server indicates that by
sending the 150 (ICE connectivity checks in progress) sending the 150 (ICE connectivity checks in progress)
(Section 3.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 to the client a 480 response to indicate a failure of server sends to the client a 480 response to indicate a failure of
the checks. If the checks are successful then the server sends a 200 the checks. If the checks are successful then the server sends a 200
OK response and starts delivering media. OK response and starts delivering media.
4.10. Releasing Candidates 5.10. Releasing Candidates
Both server and client may release its non nominated candidates as Both server and client may release its non nominated candidates as
soon as a 200 PLAY response has been issued/received and no soon as a 200 PLAY response has been issued/received and no
outstanding connectivity checks exist. outstanding connectivity checks exist.
4.11. Steady State 5.11. Steady State
The client will continue to use STUN to send keep-alive for the used The client will continue to use STUN to send keep-alive for the
bindings. This is important as normally RTSP play mode sessions only nominated candidate pair(s). This is important as normally RTSP play
contain traffic from the server to the client so the bindings in the mode sessions only contain traffic from the server to the client so
NAT need to be refreshed by the client to server traffic provided by the bindings in the NAT need to be refreshed by the client to server
the STUN keep-alive. traffic provided by the STUN keep-alive.
4.12. re-SETUP 5.12. re-SETUP
The server SHALL support SETUP requests in PLAYING state, as long as The server SHALL support SETUP requests in PLAYING state, as long as
the SETUP changes only the ICE parameters, which are: ICE-Password, the SETUP changes only the ICE parameters, which are: ICE-Password,
ICE-ufrag and the content of ICE candidates. ICE-ufrag and the content of ICE candidates.
If the client decides to change any parameter related to the media If the client decides to change any parameters related to the media
stream SETUP it will send a new SETUP request. In this new SETUP stream setup it will send a new SETUP request. In this new SETUP
request the client SHALL include a new different username and request the client SHALL include a new different username and
password to use in the ICE processing. This request will also cause password to use in the ICE processing. This request will also cause
the ICE processing to start from the beginning again. the ICE processing to start from the beginning again.
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, the ICE connectivity checks SHALL use Regular SETUP request, the ICE connectivity checks SHALL use Regular
nomination. Any ongoing media delivery continues on the previously nomination. Any ongoing media delivery continues on the previously
nominated candidate pairs until the new pairs have been nominated for nominated candidate pairs until the new pairs have been nominated for
the individual candidate. Once the nomination of the new candidate the individual candidate. Once the nomination of the new candidate
pair has completed, all unused candidates may be released. pair has completed, all unused candidates may be released.
4.13. Server Side Changes After Steady State 5.13. Server Side Changes After Steady State
A Server may require an ICE restart because of server side load A Server may require an ICE restart because of server side load
balancing or a failure resulting in an IP address and a port number balancing or a failure resulting in an IP address and a port number
change. It shall use the PLAY_NOTIFY method to inform the client change. It shall use the PLAY_NOTIFY method to inform the client
(Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason (Section 13.5 [I-D.ietf-mmusic-rfc2326bis]) with a new Notify-Reason
header: ice-restart. The server will identify if the change is for a header: ice-restart. The server will identify if the change is for a
single media or for the complete session by including the single media or for the complete session by including the
corresponding URI in the PLAY_NOTIFY request. corresponding URI in the PLAY_NOTIFY request.
Upon receiving and responding to this PLAY_NOTIFY with ice-restart Upon receiving and responding to this PLAY_NOTIFY with ice-restart
reason the client SHALL gather new ICE candidates, send SETUP reason the client SHALL gather new ICE candidates, send SETUP
requests for each media stream part of the session. The server requests for each media stream part of the session. The server
provides its candidates in the SETUP response the same way as for the provides its candidates in the SETUP response the same way as for the
first time ICE processing. Both server and client shall provide new first time ICE processing. Both server and client shall provide new
ICE usernames and passwords. The client MAY issue the SETUP request ICE 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 keepalives on the previous set of candidate pairs should Note that keepalives on the previous set of candidate pairs should
continue until all new candidate pairs have been nominated. After continue until all new candidate pairs have been nominated. After
having nominated a new set of candidate pairs, the client may having nominated a new set of candidate pairs, the client may
continue to receive media for some additional time. Even if the continue to receive media for some additional time. Even if the
server stops delivering media over that candidate pair at the time of server stops delivering media over that candidate pair at the time of
nomination, media may arrive for up to one maximum segment lifetime nomination, media may arrive for up to one maximum segment lifetime
as defined in TCP (2 minutes). Unfortuntately, if the RTSP server is as defined in TCP (2 minutes). Unfortuntately, if the RTSP server is
skipping to change at page 21, line 48 skipping to change at page 20, line 27
Server: PhonyServer 1.1 Server: PhonyServer 1.1
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
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: 302 CSeq: 302
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C; Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates =" ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; 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 51456 typ srflx 2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
raddr 10.0.1.17 rport 9002", raddr 10.0.1.17 rport 9002"; 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
C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0 C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
CSeq: 303 CSeq: 303
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9; Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates=" ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
1 1 UDP 2130706431 10.0.1.17 9000 typ host; 1 1 UDP 2130706431 10.0.1.17 9000 typ host;
2 1 UDP 1694498815 192.0.2.3 51576 typ srflx 2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
raddr 10.0.1.17 rport 9004", raddr 10.0.1.17 rport 9004"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973", RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
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
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=CbDm; Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates=" ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; 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:43:12 GMT Date: 11 March 2011 13:17:46 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 303 CSeq: 303
Session: uZ3ci0K+Ld Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; 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: 23 Jan 1997 15:43:13 GMT Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
5. ICE and Proxies 6. ICE and Proxies
RTSP allows for proxies which can be of two fundamental types RTSP allows for proxies which can be of two fundamental types
depending if they relay and potentially cache the media or not. depending if they relay and potentially cache the media or not.
Their differing impact on the RTSP NAT traversal solution, including Their differing impact on the RTSP NAT traversal solution, including
backwards compatibility, is explained below. backwards compatibility, is explained below.
5.1. Media Handling Proxies 6.1. Media Handling Proxies
An RTSP proxy that relays or caches the media stream for a particular An RTSP proxy that relays or caches the media stream for a particular
media session can be considered to split the media transport into two media session can be considered to split the media transport into two
parts: A media transport between the server and the proxy according parts: A media transport between the server and the proxy according
to the proxies need, and delivery from the proxy to the client. This to the proxies need, and delivery from the proxy to the client. This
split means that the NAT traversal solution will need to be run on split means that the NAT traversal solution will need to be run on
each individual media leg according to need. each individual media leg according to need.
It is RECOMMENDED that any media handling proxy support the media NAT It is RECOMMENDED that any media handling proxy support the media NAT
traversal defined within this specification. This is for two traversal defined within this specification. This is for two
skipping to change at page 23, line 28 skipping to change at page 22, line 5
be topology independent so able to support performing NAT traversal be topology independent so able to support performing NAT traversal
for non-NAT traversal capable clients present in the same address for non-NAT traversal capable clients present in the same address
domain. domain.
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 ready as both a controlling and a controlled ICE peer. The proxy be ready as both a controlling and a controlled ICE peer. The proxy
also SHALL include the "setup.ice-d-m" feature tag in any applicable also SHALL include the "setup.ice-d-m" feature tag in any applicable
capability negotiation headers, such as "Proxy-Supported." capability negotiation headers, such as "Proxy-Supported."
5.2. Signalling Only Proxies 6.2. Signalling Only Proxies
A signalling only proxy handles only the RTSP signalling and does not A signalling only proxy handles only the RTSP signalling and does not
have the media relayed through proxy functions. This type of proxy have the media relayed through proxy functions. This type of proxy
is not likely to work unless the media NAT traversal solution is in is not likely to work unless the media NAT traversal solution is in
place between the client and the server, because the DoS protection place between the client and the server, because the DoS protection
measures usually prevent media delivery to other addresses other than measures usually prevent media delivery to other addresses other than
from where the RTSP signalling arrives at the server. from where the RTSP signalling arrives at the server.
The solution for the Signalling Only proxy is that it must forward The solution for the Signalling Only proxy is that it must forward
the RTSP SETUP requests including any transport specification with the RTSP SETUP requests including any transport specification with
the "D-ICE" lower layer and the related transport parameters. A the "D-ICE" lower layer and the related transport parameters. A
proxy supporting this functionality SHOULD indicate its capability by proxy supporting this functionality SHOULD indicate its capability by
always including the "setup.ice-d-m" feature tag in the "Proxy- always including the "setup.ice-d-m" feature tag in the "Proxy-
Supported" header. Supported" header.
5.3. Non-supporting Proxies 6.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 prefered method as a NAT between the proxy and although with a less prefered method as a NAT between the proxy and
the client will likely result in failure of the media path. the client will likely result in failure of the media path.
A non-media handling transport proxy is expected to ignore and simply A non-media handling transport proxy is expected to ignore and simply
skipping to change at page 24, line 28 skipping to change at page 23, line 5
require tag wasn't present. This variance in results is the reason require tag wasn't present. This variance in results is the reason
we don't recommend the usage of the Proxy-Require header. Instead we we don't recommend the usage of the Proxy-Require header. Instead we
recommend the usage of the Supported header to force proxies to recommend the usage of the Supported header to force proxies to
include the feature tags they support in the proxy-supported which include the feature tags they support in the proxy-supported which
will provide a positive indication when all proxies in the chain will provide a positive indication when all proxies in the chain
between the client and server support the functionality. Even if not between the client and server support the functionality. Even if not
explicitly indicating support, any SETUP response including a explicitly indicating support, any SETUP response including a
transport specification with "D-ICE" will be implicit indication that transport specification with "D-ICE" will be implicit indication that
the proxy chain supports at least passthrough of this media. the proxy chain supports at least passthrough of this media.
6. RTP and RTCP Multiplexing 7. RTP and RTCP Multiplexing
[I-D.ietf-avt-rtp-and-rtcp-mux] specifies how and when RTP and RTCP "Multiplexing RTP Data and Control Packets on a Single Port"
can be multiplexed on the same port. This multiplexing SHALL be [RFC5761] specifies how and when RTP and RTCP can be multiplexed on
combined with ICE as it makes RTP and RTCP need only a single the same port. This multiplexing SHALL be combined with ICE as it
component per media stream instead of two, so reducing the load on makes RTP and RTCP need only a single component per media stream
the connectivity checks. For details on how one negotiate RTP and instead of two, so reducing the load on the connectivity checks. For
RTCP multiplexing, see Appendix B [I-D.ietf-mmusic-rfc2326bis]. details on how one negotiate RTP and RTCP multiplexing, see Appendix
B of RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis].
Multiplexing RTP and RTCP has the benefit that it avoids the need for Multiplexing RTP and RTCP has the benefit that it avoids the need for
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 fpr 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 associate state. Multiplexing will also reduce the combinations the associate 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 de-multiplexer
between the STUN, and RTP or RTCP packets below the RTP/RTCP between the STUN, and RTP or RTCP packets below the RTP/RTCP
implementation anyway, so the additional work of one new implementation anyway, so the additional work of one new
demultiplexing point directly connected to the STUN and RTP/RTCP demultiplexing point directly connected to the STUN and RTP/RTCP
seems small relative to the benefits provided. seems small relative to the benefits provided.
Due to the above mentioned benefits, RTSP servers and clients that Due to the above mentioned benefits, RTSP servers and clients that
supports "D-ICE" lower layer transport in combination with RTP SHALL supports "D-ICE" lower layer transport in combination with RTP SHALL
also implement RTP and RTCP multiplexing as specified in this section also implement RTP and RTCP multiplexing as specified in this section
and [I-D.ietf-avt-rtp-and-rtcp-mux]. and [RFC5761].
7. Open Issues 8. Fallback
Below is listed the known open issues and questions that needs to be The need for fallback from ICE in RTSP should be less than for SIP
resolved: using ICE in SDP offer/answer where a default destination candidate
is very important. This as capability determination for ICE can
happen prior to the RTSP SETUP request. Thus a client should
normally not needed to include fallback alternatives when offering
ICE, as the capability for ICE will already be determined. Thus this
section likely applies more to the cases where the server is not ICE
capable and the client wishes to use part of the ICE functionality to
improve NAT/Firewall traversal.
1. None Section 4.1.4 of the ICE [RFC5245] specification does recommend that
the default destination, i.e. what is used in fallback if the peer
isn't ICE capable is a candidate of relayed type to maximize the
likelyhood of succesfull transport of media. This is based on that
the peer in SIP SDP offer/answer is almost as likely as the RTSP
client to be behind a NAT. For RTSP the deployement of servers are
much more heavily weighted towards deployment with public
reachability. In fact due to that servers behind NAT either needs to
support ICE or have static configurations that allow traversal one
can assume that the server will have a public address or support ICE.
Thus, the selection of the default destination address for RTSP can
be differently prioritized.
8. IANA Considerations As an ICE enabled client needs to configured with a STUN server
address to be able to gather candidates successfully, this can be
utilized to derive a server reflexive candidate for the clients port.
How useful this is for an RTSP client as default candidate depends on
the properties of the NAT. As long as the NAT use an address
independent mapping, then using a STUN derived reflexive candidate is
likely to be successfully. This is however brittle in several ways.
First, the NATs behavior can be determined using STUN as described in
[RFC3489], however this might not be represenative of the behavior
encountered in another mapping. Secondly, filter state towards the
ports used by the server needs to be established. This requires that
the server actually include both address and ports in its response to
the SETUP request. Thirdly messages needs to be sent to these ports
for keep-alive at a regular interval. How a server reacts to such
unsolicited traffic is unknown. This brittleness may be accepted in
fallback due to lack of support on the server side.
Fallback addresses needs to be provided in their own transport
specification using a specifier that do not include the "D-ICE" lower
layer transport. Instead the selected protocol, e.g. UDP needs to
be explicitly or implictly indicated. Secondly the selected default
candidate needs to be included in the SETUP request. If this
candidate is server reflexive or relayed the aspect of keep-alive
needs to be ensured.
9. IANA Considerations
This document request registration in a number of registries, both This document request registration in a number of registries, both
for RTSP and SDP. for RTSP and SDP.
8.1. RTSP Feature Tags 9.1. RTSP Feature Tags
This document request that one RTSP 2.0 feature tags are registered This document request that one RTSP 2.0 feature tags are registered
in the "RTSP feature tag" registry: in the "RTSP 2.0 feature tag" registry:
setup.ice-d-m See Section Section 3.4. setup.ice-d-m See Section 4.4.
8.2. Transport Protocol Specifications 9.2. Transport Protocol Specifications
This document needs to register a number of transport protocol This document needs to register a number of transport protocol
combinations are registered in RTSP's "Transport Protocol combinations are registered in RTSP 2.0's "Transport Protocol
Specifications" registry. Specifications" registry.
"RTP/AVP/D-ICE" "RTP/AVP/D-ICE"
"RTP/AVPF/D-ICE" "RTP/AVPF/D-ICE"
"RTP/SAVP/D-ICE" "RTP/SAVP/D-ICE"
"RTP/SAVPF/D-ICE" "RTP/SAVPF/D-ICE"
8.3. RTSP Transport Parameters 9.3. RTSP Transport Parameters
This document requests that 3 transport parameters are registered in This document requests that 3 transport parameters are registered in
RTSP's "Transport Parameters": RTSP 2.0's "Transport Parameters":
"candidates": See Section Section 3.2. "candidates": See Section Section 4.2.
"ICE-Password": See Section Section 3.3. "ICE-Password": See Section Section 4.3.
"ICE-ufrag": See Section Section 3.3. "ICE-ufrag": See Section Section 4.3.
8.4. RTSP Status Codes 9.4. RTSP Status Codes
This document requests that 2 assignments are done in the "RTSP This document requests that 2 assignments are done in the "RTSP 2.0
Status Codes" registry. The suggested values are: Status Codes" registry. The suggested values are:
150: See Section Section 3.5.1. 150: See Section Section 4.5.1.
480: See Section Section 3.5.2. 480: See Section Section 4.5.2.
8.5. Notify-Reason value 9.5. Notify-Reason value
This document requests that one assignment is done in the Notify- This document requests that one assignment is done in the RTSP 2.0
Reason header value registry. The suggested value is: Notify-Reason header value registry. The defined value is:
ice-restart: See section Section 3.6. ice-restart: See section Section 4.6.
8.6. SDP Attribute 9.6. SDP Attribute
The registration of one SDP attribute is requested: The registration of one SDP attribute is requested:
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal Long form: ICE for RTSP datagram media NAT traversal
Type of name: att-field Type of name: att-field
Type of attribute: Session level only Type of attribute: Session level only
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: No values defined. Values: No values defined.
skipping to change at page 27, line 5 skipping to change at page 26, line 19
Type of name: att-field Type of name: att-field
Type of attribute: Session level only Type of attribute: Session level only
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: No values defined. Values: No values defined.
Contact: Magnus Westerlund Contact: Magnus Westerlund
E-mail: magnus.westerlund@ericsson.com E-mail: magnus.westerlund@ericsson.com
phone: +46 10 714 82 87 phone: +46 10 714 82 87
9. Security Considerations 10. Security Considerations
ICE [I-D.ietf-mmusic-ice] provides an extensive discussion on ICE [RFC5245] provides an extensive discussion on security
security considerations which applies here as well. considerations which applies here as well.
9.1. ICE and RTSP 10.1. ICE and RTSP
A long-standing risk with transmitting a packet stream over UDP is A long-standing risk with transmitting a packet stream over UDP is
that the host may not be interested in receiving the stream. On that the host may not be interested in receiving the stream. On
today's Internet many hosts are behind NATs or operate host firewalls today's Internet many hosts are behind NATs or operate host firewalls
which do not respond to unsolicited packets with an ICMP port which do not respond to unsolicited packets with an ICMP port
unreachable error. Thus, an attacker can construct SDP with a unreachable error. Thus, an attacker can construct RTSP SETUP
victim's IP address and cause a flood of media packets to be sent to requests with a victim's IP address and cause a flood of media
a victim. The addition of ICE, as described in this document, packets to be sent to a victim. The addition of ICE, as described in
provides protection from the attack described above. By performing this document, provides protection from the attack described above.
the ICE connectivity check, the media server receives confirmation By performing the ICE connectivity check, the media server receives
that the RTSP client wants the media. While this protection could confirmation that the RTSP client wants the media. While this
also be implemented by requiring the IP addresses in the SDP match protection could also be implemented by requiring the IP addresses in
the IP address of the RTSP signaling packet, such a mechanism does the SDP match the IP address of the RTSP signaling packet, such a
not protect other hosts with the same IP address (such as behind the mechanism does not protect other hosts with the same IP address (such
same NAT), and such a mechanism would prohibit separating the RTSP as behind the same NAT), and such a mechanism would prohibit
controller from the media playout device (e.g., an IP-enabled remote separating the RTSP controller from the media playout device (e.g.,
control and an IP-enabled television). an IP-enabled remote control and an IP-enabled television), it also
forces RTSP proxies to relay the media streams through them, even if
they only are signalling proxies.
10. Acknowledgements 11. Acknowledgements
The authors would like to thank Remi Denis-Courmont for suggesting The authors would like to thank Remi Denis-Courmont for suggesting
the method of integrating ICE in RTSP signalling, Dan Wing for help the method of integrating ICE in RTSP signalling, Dan Wing for help
with the security section and numerous other issues. with the security section and numerous other issues.
11. References 12. References
11.1. Normative References
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-mmusic-ice] 12.1. Normative References
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in
progress), July 2009. progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
11.2. Informative References [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
12.2. Informative References
[I-D.ietf-mmusic-rtsp-nat-evaluation] [I-D.ietf-mmusic-rtsp-nat-evaluation]
Westerlund, M. and T. Zeng, "The evaluation of different Westerlund, M. and T. Zeng, "The evaluation of different
NAT traversal Techniques for media controlled by Real- NAT traversal Techniques for media controlled by Real-time
time Streaming Protocol (RTSP)", Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in
progress), January 2010. progress), January 2010.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
Authors' Addresses Authors' Addresses
Jeff Goldberg Jeff Goldberg
Cisco Cisco
11 New Square, Bedfont Lakes 11 New Square, Bedfont Lakes
Feltham,, Middx TW14 8HA Feltham,, Middx TW14 8HA
United Kingdom United Kingdom
 End of changes. 128 change blocks. 
291 lines changed or deleted 349 lines changed or added

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