An Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-06

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at 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 August 28, 2008.

Abstract

This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Solution Overview
3.  RTSP Extensions
    3.1.  ICE Transport Lower Layer
    3.2.  ICE Candidate Transport Header Parameter
    3.3.  ICE Password and Username Transport Header Parameters
    3.4.  ICE Feature Tag
    3.5.  Status Codes
        3.5.1.  150 ICE connectivity checks in progress
        3.5.2.  480 ICE Processing Failed
    3.6.  Server Side SDP Attribute for ICE Support
    3.7.  ICE Features Not Required in RTSP
        3.7.1.  ICE-Lite
        3.7.2.  ICE-Mismatch
        3.7.3.  ICE Remote Candidate Transport Header Parameter
4.  Detailed Solution
    4.1.  Session description and RTSP DESCRIBE (optional)
    4.2.  Setting up the Media Resources
    4.3.  RTSP SETUP Request
    4.4.  Gathering Candidates
    4.5.  RTSP Server Response
    4.6.  Server to Client ICE Connectivity Checks
    4.7.  Client to Server ICE Connectivity Check
    4.8.  Client Connectivity Checks Complete
    4.9.  Server Connectivity Checks Complete
    4.10.  Releasing Candidates
    4.11.  Steady State
    4.12.  re-SETUP
5.  ICE and Proxies
    5.1.  Media Handling Proxies
    5.2.  Signalling Only Proxies
    5.3.  Non-supporting Proxies
6.  RTP and RTCP Multiplexing
7.  Open Issues
8.  IANA Considerations
    8.1.  RTSP Feature Tags
    8.2.  Transport Protocol Specifications
    8.3.  RTSP Transport Parameters
    8.4.  RTSP Status Codes
    8.5.  SDP Attribute
9.  Security Considerations
    9.1.  ICE and RTSP
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Real-time Streaming Protocol (RTSP) [RFC2326] (Schulzrinne, H., Rao, A., and R. Lanphier, “Real Time Streaming Protocol (RTSP),” April 1998.)[I‑D.ietf‑mmusic‑rfc2326bis] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” March 2010.) is a protocol used to setup and control one or more media streams delivering media to receivers. It is RTSP's functionality of setting up media streams that get into serious issues with Network Address Translators (NAT) [RFC3022] (Srisuresh, P. and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” January 2001.). Commonly the media will be totally blocked by the NAT unless extra provisions are taken by the protocol. There is a clear and present need for NAT traversal mechanism for the media setup using RTSP.

RTSP 1.0 [RFC2326] (Schulzrinne, H., Rao, A., and R. Lanphier, “Real Time Streaming Protocol (RTSP),” April 1998.) has suffered from the lack of a standardized NAT traversal mechanism for a long time, however due to quality of the RTSP 1.0 specification, the work has had to wait on the recently defined RTSP 2.0 [I‑D.ietf‑mmusic‑rfc2326bis] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” March 2010.). RTSP 2.0 is similar to RTSP 1.0 in many respects but significantly for this work, it contains a well defined extension mechanism so allowing a NAT traversal extension to be defined that is backwards compatible with RTSP 2.0 peers not supporting the extension. This extension mechanism was not possible in RTSP 1.0 as it would break RTSP 1.0 syntax so causing compatibility issues.

There have been a number of suggested ways of resolving the NAT-traversal of media for RTSP of which a large number are already used in implementations. The evaluation of these NAT traversal solutions in[I‑D.ietf‑mmusic‑rtsp‑nat‑evaluation] (Westerlund, M. and T. Zeng, “The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP),” January 2010.) has shown that there are many issues to consider, so after extensive evaluation, we selected a mechanism based on Interactive Connectivity Establishment (ICE). This was mainly two reasons: Firstly the mechanism supports RTSP servers behind NATs and secondly the mechanism solves the security threat that uses RTSP servers as Distributed Denial of Service (DDoS) attack tools.

The NAT problem for RTSP signalling traffic itself is beyond the scope of this document and is left for future study should the need arise, because it is a less prevalent problem than the NAT problem for RTSP media streams.

2.  Solution Overview

This overview assumes that the reader has some familiarity with how ICE [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) works, as it primarily points out how the different ICE steps are accomplished in RTSP.

1. RTSP server can indicate it has support for ICE via an SDP [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) attribute in, for example, the SDP returned in RTSP DESCRIBE message. This allows RTSP clients to only send the new ICE interchanges with servers that support ICE so as to limit the overhead on current non-ICE supporting RTSP servers. If RTSP DESCRIBE is used the normal capability determination mechanism can be used, i.e. "Supported" header and the defined feature tag.
2. RTSP client reviews the session description returned, for example by an RTSP DESCRIBE message, to determine what media resources that need to be setup. For each of these media resources where the transport protocol supports Session Traversal Utilities for (NAT) (STUN) [I‑D.ietf‑behave‑rfc3489bis] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.) based connectivity checks, the client gathers candidate addresses. See section 4.1.1 in [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.). The client also installs the STUN servers on each of the local candidates.
3. RTSP client sends a SETUP request with both a transport specification with a lower layer indicating ICE and a new RTSP Transport header parameter listing the ICE candidates for each media resource. RTSP proxies in non-ICE transport specifications should be treated at lower priority than those transport specifications supporting ICE.
4. After receiving the list of candidates from a client, the RTSP server gathers its own candidates. If the server has a public IP address then a single candidate per address family (e.g. IPv4 and IPv6) can be included to reduce the number of combinations and speed up the completion.
5. The server sets up the media and if successful responds to the SETUP request with a 200 OK response. In that response the server selects the transport specification using ICE and includes its candidates in the server candidate parameter.
6. If the server is behind a NAT then it starts the connectivity checks following the procedures described in Section 5.7 and 5.8 of [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.). If the server has a public IP address with a single candidate then it can refrain from server initiated connectivity checks and rely on triggered checks.
7. The client receives the SETUP response and learns the candidate address to use for the connectivity checks, and then initiates its connectivity check, following the procedures in Section 6 of [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.).
8. When a connectivity check from the client reaches the server it will result in a triggered check from the server. This is why servers with a public IP address can wait until this triggered check to send out any checks for itself so saving resources and mitigating the DDoS potential from server connectivity checks.
9. When the client has concluded its connectivity checks and has corresponding received the server connectivity checks on the promoted candidates for all components of all media streams, it can issue a PLAY request. If the connectivity checks have not concluded successfully then the client may send a new SETUP request assuming it has any new information or believes the server may be able to do more that can result in successful checks.
10. When the RTSP servers receives a PLAY request it checks to see the connectivity checks has concluded successfully and only then can play the stream. If there is a problem with the checks then the server sends to the client either a 150 (ICE connectivity checks in progress) response to show that it is still working on the connectivity checks or a 480 (ICE Processing Failed) response to indicate a failure of the checks. If the checks are successful then the server sends a 200 OK response and starts delivering media.

The client may release unused candidates when the ICE processing has concluded and a single candidate per component has been promoted.

The client shall continue to use STUN to send keep-alive for the used bindings. This is important as often RTSP media sessions only contain media traffic from the server to the client so the bindings in the NAT needs to be refreshed by the client to server traffic provided by the STUN keep-alive.

3.  RTSP Extensions

This section defines the necessary RTSP extensions for performing ICE with RTSP. Note that these extensions are based on the SDP attributes in the ICE specification unless expressly indicated.

3.1.  ICE Transport Lower Layer

A new lower layer "D-ICE" for transport specifications is defined. This lower layer is datagram clean except that the protocol used must be demultiplexiable with STUN messages (see STUN [I‑D.ietf‑behave‑rfc3489bis] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.)). With datagram clean we mean that it must be capable of describing the length of the datagram, transport that datagram (as a binary chunk of data) and provide it at the receiving side as one single item. This lower layer can be any transport type defined for ICE which does provide datagram transport capabilities. Though only UDP is defined at present, however TCP with framing may be specified and used in the future.

This lower layer uses ICE to determine which of the different candidates shall be used and then when the ICE processing has concluded, uses the selected candidate to transport the datagrams over this transport.

This lower layer transport can be combined with all upper layer media transport protocols that are possible to demultiplex with STUN and which use datagrams. This specification defines the following combinations:

• RTP/AVP/D-ICE
• RTP/AVPF/D-ICE
• RTP/SAVP/D-ICE
• RTP/SAVPF/D-ICE

This list can easily be extended with more transport specifications after having performed the evaluation that they are compatible with D-ICE as lower layer.

The lower-layer "D-ICE" has the following rules for the inclusion of transport parameters:

unicast:

As ICE only supports unicast operations, thus it is REQUIRED that one include the unicast indicator parameter, see section 16.46 in [I‑D.ietf‑mmusic‑rfc2326bis] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” March 2010.).

candidates:

The "candidates" parameter SHALL be included as this specify at least one candidate to try to establish a working transport path with.

dest_addr:

This parameter SHALL NOT be included as "candidates" is used instead to provide the necessary address information.

ICE-Password:

This parameter SHALL be included.

ICE-Userfrag:

This parameter SHALL be included.

3.2.  ICE Candidate Transport Header Parameter

This section defines a new RTSP transport parameter for carrying ICE candidates related to the transport specification they appear within, which may then be validated with an end-to-end connectivity check using STUN (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.) [I‑D.ietf‑behave‑rfc3489bis]. Transport parameters may only occur once in each transport specification. For transport specification using "D-ICE" as lower layer, this parameter needs to be present. The parameter can contain one or more ICE candidates. In the SETUP response there is only a single transport specification, and if that uses the "D-ICE" lower layer this parameter also needs to present including the server side candidates.

tr-parameter  =/ SEMI ice-trn-par
ice-trn-par   = "candidates" EQUAL DQ SWS ice-candidate
                                   *(SEMI ice-candidate) SWS DQ
ice-candidate = foundation SP
                component-id SP
                transport SP
                priority SP
                connection-address SP
                port SP
                cand-type
                [SP rel-addr]
                [SP rel-port]
                *(SP extension-att-name SP extension-att-value)

foundation            = <See section 15.1 of [I-D.ietf-mmusic-ice]>
component-id          = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport             = <See section 15.1 of [I-D.ietf-mmusic-ice]>
transport-extension   = <See section 15.1 of [I-D.ietf-mmusic-ice]>
priority              = <See section 15.1 of [I-D.ietf-mmusic-ice]>
cand-type             = <See section 15.1 of [I-D.ietf-mmusic-ice]>
candidate-types       = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-addr              = <See section 15.1 of [I-D.ietf-mmusic-ice]>
rel-port              = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-name    = <See section 15.1 of [I-D.ietf-mmusic-ice]>
extension-att-value   = <See section 15.1 of [I-D.ietf-mmusic-ice]>
ice-char              = <See section 15.1 of [I-D.ietf-mmusic-ice]>
connection-address    = <See [RFC4566]>
port                  = <See [RFC4566]>
EQUAL                 = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
DQ                    = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SWS                   = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI                  = <Defined in [I-D.ietf-mmusic-rfc2326bis]>

<connection-address>: is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses and Fully qualified domain names (FQDN), taken from [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.). The connection address SHOULD be on the same format (explicit IP or FQDN) as in the dest_addr parameter used to express default for the matching candidate. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing.

<port>: is the port of the candidate taken from RFC 4566 [RFC4566].

<transport>: indicates the transport protocol for the candidate. The ICE specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE, such as TCP or the Datagram Congestion Control Protocol (DCCP) [RFC4340].

<foundation>: is an identifier that is equivalent for two candidates that are of the same type, share the same base, and come from the same STUN server, and is composed of one to thirty two <ice-char>. The foundation is used to optimize ICE performance in the Frozen algorithm.

<component-id>: identifies the specific component of the media stream for which this is a candidate and os a positive integer between 1 and 256. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2. Other types of media streams which require multiple components MUST develop specifications which define the mapping of components to component IDs. See Section 14 for additional discussion on extending ICE to new media streams.

<priority>: is a positive integer between 1 and (2**31 - 1).

<cand-type>: encodes the type of candidate. The ICE specification defines the values "host", "srflx", "prflx" and "relay" for host, server reflexive, peer reflexive and relayed candidates, respectively. The set of candidate types is extensible for the future.

<rel-addr> and <rel-port>: convey transport addresses related to the candidate, useful for diagnostics and other purposes. <rel-addr> and <rel-port> MUST be present for server reflexive, peer reflexive and relayed candidates. If a candidate is server or peer reflexive, <rel-addr> and <rel-port> is equal to the base for that server or peer reflexive candidate. If the candidate is relayed, <rel-addr> and <rel-port> is equal to the mapped address in the Allocate Response that provided the client with that relayed candidate (see Appendix B.3 for a discussion of its purpose). If the candidate is a host candidate <rel-addr> and <rel-port> MUST be omitted.

3.3.  ICE Password and Username Transport Header Parameters

The ICE password and username for each agent needs to be transported using RTSP. For that purpose new transport header parameters are defined.

There MUST be an "ICE-Password" and "ICE-Userfrag" parameter for each media stream. If two SETUP requests in the same RTSP session have identical ICE-Userfrag's, they MUST have identical ICE-Password's. The ICE-Userfrag and ICE-Password attributes MUST be chosen randomly at the beginning of a session. The ICE-Userfrag attribute MUST contain at least 24 bits of randomness, and the ICE-Password attribute MUST contain at least 128 bits of randomness. This means that the ICE-Userfrag attribute will be at least 4 characters long, and the ICE-Password at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The attributes MAY be longer than 4 and 22 characters respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time.

The ABNF (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] for these parameters are:

tr-parameter     =/ SEMI ice-password-par
tr-parameter     =/ SEMI ice-userfrag-par
ice-password-par = ICE-Password" HCOLON password
ice-userfrag-par = ICE-Userfrag" HCOLON ufrag
password         = <Defined in [I-D.ietf-mmusic-ice]>
ufrag            = <Defined in [I-D.ietf-mmusic-ice]>
HCOLON           = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
SEMI             = <Defined in [I-D.ietf-mmusic-rfc2326bis]>

3.4.  ICE Feature Tag

A feature tag is defined for usage in the RTSP capabilities mechanism for ICE support for media transport using datagrams: "setup.ice-d-m". This feature tag indicates that one support all the mandatory to support functions of this specification. It is applicable to all types of RTSP agents; clients, servers and proxies.

The RTSP client should send the feature tag "setup.ice-d-m" in the "Supported" header in all SETUP requests that contain the "D-ICE" lower layer transport.

3.5.  Status Codes

ICE needs two new RTSP response codes to indicate correctly progress and errors.

3.5.1.  150 ICE connectivity checks in progress

The 150 response code indicates that ICE connectivity checks are still in progress and haven't concluded. This response SHALL be sent within 200 milliseconds of receiving a PLAY request that currently can't be fulfilled because ICE connectivity checks are still running. Subsequently, every 3 seconds after the previous sent one, a 150 reply shall be sent until the ICE connectivity checks conclude either successfully or in failure, and a final response for the request can be provided.

3.5.2.  480 ICE Processing Failed

The 480 client error response code is used in cases when the request can't be fulfilled due to a failure in the ICE processing, such as that all the connectivity checks have timed out. This error message can appear either in response to a SETUP request to indicate that no candidate pair can be constructed or to a PLAY request that the server's connectivity checks resulted in failure.

3.6.  Server Side SDP Attribute for ICE Support

If the server supports the media NAT traversal for RTSP controlled sessions, as described in this RFC, then the Server SHALL include the "a=rtsp-ice-d-m" SDP attribute in any SDP (if used) describing content served by the server. This is an session level attribute.

rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"

3.7.  ICE Features Not Required in RTSP

A number of ICE signalling features are not needed with RTSP and are discussed below.

3.7.1.  ICE-Lite

The ICE-Lite attribute shall not be used in the context of RTSP. The ICE specification describes two implementations of ICE: Full and Lite, where hosts that are not behind a NAT are allowed to implement only Lite. For RTSP, the Lite implementation is insufficient because it does not cause the media server to send a connectivity check, which are used to protect against making the RTSP server a denial of service tool. This document defines another variation implementation of ICE, called ICE-RTSP. It has its own set of simplifications suitable to RTSP. Conceptually, this implementation of ICE-RTSP is between ICE-FULL and ICE-LITE for a server and simpler than ICE-FULL for clients.

3.7.2.  ICE-Mismatch

The ice-mismatch parameter indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. This is not needed for RTSP as the ICE based lower layer transport specification either is supported or another alternative transport is used. This is always explicitly indicated in the SETUP request and response.

3.7.3.  ICE Remote Candidate Transport Header Parameter

The Remote candidate attribute is not needed for RTSP for the following reasons. Each SETUP results in a independent ICE processing chain which either fails or results in promoting a single candidate pair to usage. If a new SETUP request for the same media is sent this needs to use a new userfragment and password to avoid any race conditions or uncertainty for which processing round the STUN requests relate to.

4.  Detailed Solution

This section describes in detail how the interaction and flow of ICE works with RTSP messages.

4.1.  Session description and RTSP DESCRIBE (optional)

The RTSP server should indicate it has support for ICE by sending the "rtsp-ice-d-m" SDP attribute in the response to the RTSP DESCRIBE message if SDP is used. This allows RTSP clients to only send the new ICE interchanges with servers that support ICE so limiting the overhead on current non-ICE supporting RTSP servers. When not using RTSP DESCRIBE it is still recommended to use the SDP attribute for session description.

A Client can also use the DESCRIBE request to determine explicitly if both server and any proxies support ICE. The client includes the "Supported" header with its supported feature tags, including "setup.ice-d-m". Any proxy upon seeing the "Supported" header will include the "Proxy-Supported" header with the feature tags it supports. The server will echo back the "Proxy-Supported" header and its own version of the Supported header so enabling a client to determine if all involved parties support ICE or not. Note that even if a proxy is present in the chain that doesn't indicate support for ICE, it may still work.

For example:
     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
           CSeq: 312
           User-Agent: PhonyClient 1.2
           Accept: application/sdp, application/example
           Supported: setup.ice-d-m

     S->C: RTSP/2.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.1
           Content-Type: application/sdp
           Content-Length: 367
           Supported: setup.ice-d-m

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.example.com/lectures/sdp.ps
           e=seminar@example.com (Seminar Management)
           t=2873397496 2873404696
           a=recvonly
           a=rtsp-ice-d-m
           a=control: *
           m=audio 3456 RTP/AVP 0
           a=control: /audio
           m=video 2232 RTP/AVP 31
           a=control: /video

4.2.  Setting up the Media Resources

The RTSP client reviews the session description returned, for example by an RTSP DESCRIBE message, to determine what media resources that need to be setup. For each of these media resources where the transport protocol supports ICE connectivity checks, the client shall gather candidate addresses as described in section 4.1.1 in [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) according to standard ICE rather than the ICE-Lite implementation.

4.3.  RTSP SETUP Request

The RTSP client will then send one or more SETUP requests to establish the media streams required for the desired session. For each media stream where it desires to use ICE it will include a transport specification with "D-ICE" as the lower layer. This transport specification SHOULD be placed first in the list to give it highest priority. It is RECOMMENDED that additional transport specifications are provided as a fallback in case of non ICE supporting proxies. For example (Note that some lines are broken in contradiction with the defined syntax due to space restrictions in the documenting format:

C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
      CSeq: 302
      Transport: RTP/AVP/D-ICE; unicast; candidates = "
                 1 1 UDP 2130706431 10.0.1.1 8998 typ host;
                 2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
                         raddr 10.0.1.1 rport 9002",
                 RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
                 RTP/AVP/TCP;unicast;interleaved=0-1
      Accept-Ranges: NPT, UTC
      User-Agent: PhonyClient/1.2
      Supported: setup.ice-d-m

The client will be initiating and thus the controlling party in the ICE processing.

4.4.  Gathering Candidates

Upon receiving a SETUP request the server can determine what media resource should be delivered and which transport alternatives that the client supports. If one based on D-ICE is first on the list of supported transports, the below applies, otherwise another transport method is preferred and supported.

The transport specification will provide which media protocol is to be used and based on this and the clients candidates, the server determines the protocol and if it supports ICE with that protocol. The server shall then gather its candidates according to section 4.1.1 in [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.). Servers that have an address that is generally reachable by any clients within the address scope the server intends to serve MAY be specially configured (high-reachability configuration). This special configuration has the goal of reducing the server side candidate to preferably a single one per address family. Instead of gathering all possible addresses including relayed and server reflexive addresses, the server uses a single address per address family that it knows it should be reachable by a client behind one or more NATs. The reason for this special configuration is two fold: Firstly it reduces the load on the server in address gathering and in ICE processing during the connectivity checks. Secondly it will reduce the number of permutations for candidate pairs significantly thus potentially speeding up the conclusion of the ICE processing. Note however that using this option on a server that doesn't fulfill the requirement of being reachable is counter-productive and it is important that this is correctly configured.

4.5.  RTSP Server Response

The server determines if the SETUP request is successful from the other perspectives and will return a 200 OK response, otherwise returning an error code from the list in Table 4 in [I‑D.ietf‑mmusic‑rfc2326bis] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” March 2010.). At that point the server, having selected a transport specification using the "D-ICE" lower layer, will need to include that transport specification in the response message. The transport specification shall include the candidates gathered in SectionSection 4.4 (Gathering Candidates) in the "candidates" transport header parameter as well as the server's username and password. In the case that there are no valid candidate pairs with the combination of the client and servers candidates, a 480 (ICE Processing Failed) error response shall be returned which must include the servers' candidates. The return of a 480 error may allow both the server and client to release its candidates.

S->C: RTSP/2.0 200 OK
      CSeq: 302
      Session: 12345678
      Transport: RTP/AVP/D-ICE; unicast; candidates = "
                 1 1 UDP 2130706431 192.0.2.56 50234 typ host"
      Accept-Ranges: NPT
      Date: 23 Jan 1997 15:35:06 GMT
      Server: PhonyServer 1.1
      Supported: setup.ice-d-m

4.6.  Server to Client ICE Connectivity Checks

The server shall start the connectivity checks following the procedures described in Section 5.7 and 5.8 of [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) unless it is configured to use the high-reachability option. If it is then it can suppress its own checks until the servers checks are triggered by the client's connectivity checks.

The server SHALL use a single pacer for all STUN transactions within a single RTSP session, i.e across all media streams that are part of the same RTSP session.

When a connectivity check from the client reaches the server it will result in a triggered check from the server as specified in section 7.2.1.4 of [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.). This is why servers with a high reachability address can wait until this triggered check to send out any checks for itself so saving resources and mitigating the DDoS potential.

4.7.  Client to Server ICE Connectivity Check

The client receives the SETUP response and learns the candidate address to use for the connectivity checks. The client shall initiate its connectivity check, following the procedures in Section 6 of [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.).

Aggressive nomination SHALL be used with RTSP. This doesn't have the negative impact that it has in offer/answer as media playing only starts after issuing a PLAY request.

4.8.  Client Connectivity Checks Complete

When the client has concluded its connectivity checks and has correspondingly received the server connectivity checks on the promoted candidates for all the media components, it can issue a PLAY request. If the client has locally determined that its checks have failed it may try providing an extended set of candidates and update the server candidate list by issuing a new SETUP request for the media stream.

If the client concluded its connectivity checks succesfully and therefore sent a PLAY request but the server have not concluded successfully, the server will respond with a 480 (ICE Processing Failed). Upon receiving the 480 (ICE Processing Failed) response, then the client may send a new SETUP request assuming it has any new information that can be included in the candidate list.

4.9.  Server Connectivity Checks Complete

When the RTSP server receives a PLAY request, it checks to see that the connectivity checks have concluded successfully and only then will it play the stream. If there is a problem with the checks then the server sends to the client either a new 150 (ICE connectivity checks in progress) response to show that it is still working on the connectivity checks or a new 480 response to indicate a failure of the checks. If the checks are successful then the server sends a 200 OK response and starts delivering media. The new RTSP errors add to the list in Table 4 in [I‑D.ietf‑mmusic‑rfc2326bis] (Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, “Real Time Streaming Protocol 2.0 (RTSP),” March 2010.) as below:

4.10.  Releasing Candidates

Both server and client may release its non nominated candidates as soon as a 200 PLAY response has been issued/received.

4.11.  Steady State

The client will continue to use STUN to send keep-alive for the used bindings. This is important as normally RTSP play mode sessions only contain traffic from the server to the client so the bindings in the NAT needs to be refreshed by the cleint to server traffic provided by the STUN keep-alive.

4.12.  re-SETUP

If the client decides to change any parameter related to the media stream SETUP it will send a new SETUP request. In this new SETUP request the client SHALL include a new different username and password to use in the ICE processing. This request will also cause the ICE processing to start from the beginning again.

If the RTSP session is in playing state at the time of sending the SETUP request, the ICE connectivity checks SHALL use Regular nomination. Any ongoing media delivery continues on the previously nominated candidate pairs until the new pairs have been nominated for the individual candidate. Once the nomination of the new candidate pair has completed, all unused candidates may be released.

5.  ICE and Proxies

RTSP allows for proxies which can be of two fundamental types depending if they relay and potentially cache the media or not. Their differing impact on the RTSP NAT traversal solution including backwards compatibility is explained below.

5.1.  Media Handling Proxies

An RTSP proxy that relays or caches the media stream for a particular media session can be considered to split the media transport into two parts: A media transport between the server and the proxy according to the proxies need, and delivery from the proxy to the client. This split means that the NAT traversal solution will need to be run on each individual media leg according to need.

It is RECOMMENDED that any media handling proxy support the media NAT traversal defined within this specification. This is for two reasons: Firstly to enable clients to perform NAT traversal for the media between the proxy and itself and secondly to allow the proxy to be topology independent so able to support performing NAT traversal for non-NAT traversal capable clients present in the same address domain.

For a proxy to support the media NAT traversal defined in this specification a proxy will need to implement the solution fully and be ready as both a controlling and a controlled ICE peer. The proxy also SHALL include the "setup.ice-d-m" feature tag in any applicable capability negotiation headers, such as "Proxy-Supported".

5.2.  Signalling Only Proxies

A signalling only proxy handles only the RTSP signalling and does not have the media relayed through proxy functions. This type of proxy is not likely to work unless the media NAT traversal solution is in place between the client and the server, because the DoS protection measures usually prevent media delivery to other addresses other than from where the RTSP signalling arrives at the server.

The solution for the Signalling Only proxy is that it must forward the RTSP SETUP requests including any transport specification with the "D-ICE" lower layer and the related transport parameters. A proxy supporting this functionality SHOULD indicate its capability by always including the "setup.ice-d-m" feature tag in the "Proxy-Supported" header.

5.3.  Non-supporting Proxies

A media handling proxy that doesn't support the ICE media NAT traversal specified here is assumed to remove the transport specification and use any of the lower prioritized transport specifications if provided by the requester. The specification of such a non ICE transport enables the negotiation to complete, although with a less prefered method as a NAT between the proxy and the client will result in failure of the media path.

A non-media handling transport proxy is expected to ignore and simply forward all unknown transport specifications, however, this can only be guaranteed for proxies following the published RTSP 2.0 specification.

Unfortunately the usage of the "setup.ice-d-m" feature tag in the proxy-require will have contradicting results. For a non ICE supporting media handling proxy, the inclusion of the feature tag will result in aborting the setup and indicating that it isn't supported, which is desirable if you want to provide other fallbacks or other transport configurations to handle the situation. For non-supporting non-media handling proxies the result will also result in aborting the setup, however, setup might have worked if the proxy-require tag wasn't present. This variance in results makes usage of proxy-require not recommended. We recommend instead the usage of the Supported header to force proxies to include the feature tags they support in the proxy-supported which will provide a positive indication when all proxies in the chain between the client and server support the functionality. Even if not explicitly indicating support, any SETUP response including a transport specification with "D-ICE" will be implicit indication that the proxy chain supports at least passthrough of this media.

6.  RTP and RTCP Multiplexing

[I‑D.ietf‑avt‑rtp‑and‑rtcp‑mux] (Perkins, C. and M. Westerlund, “Multiplexing RTP Data and Control Packets on a Single Port,” August 2007.) specifies how and when RTP and RTCP can be multiplexed on the same port. This multiplexing is highly recommended to combine with ICE as it makes RTP and RTCP only need a single component per media stream instead of two, so reducing the load on the connectivity checks.

To enable signalling for the usage of RTP and RTCP multiplexing a new RTSP transport header parameter is defined. The formal syntax (ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.)) of this parameter is the following:

tr-parameter  =/ SEMI rtcp-mux-par
rtcp-mux-par  = "rtp-rtcp-mux"
SEMI          = <Defined in [I-D.ietf-mmusic-rfc2326bis]>
EQUAL         = <Defined in [I-D.ietf-mmusic-rfc2326bis]>

The "rtp-rtcp-mux" parameter MAY be included in any transport specification that use RTP where RTP and RTCP multiplexing is desired and indicates in a SETUP request that multiplexing is requested. If the SETUP response also includes the parameter then RTP and RTCP multiplexing SHALL be used for that transport specification. A SETUP request may indicate address information for both RTP and RTCP for backwards compatibility reasons. If RTP and RTCP multiplexing is used then only the information specified for RTP SHALL be used.

For capability exchange, an RTSP feature tag for RTP and RTCP multiplexing is defined: "setup.rtp-mux".

RTSP servers and clients that supports "D-ICE" lower layer transport in combination with RTP SHALL also implement RTP and RTCP multiplexing as specified in this section and [I‑D.ietf‑avt‑rtp‑and‑rtcp‑mux] (Perkins, C. and M. Westerlund, “Multiplexing RTP Data and Control Packets on a Single Port,” August 2007.).

7.  Open Issues

Below is listed the known open issues and questions that needs to be resolved:

1. Need a descriptive section on how ICE works for RTSP folks.
2. No solution has been specified for how RTSP server's can initiate a ICE restart. Either to add candidates or to reinitate the connectivity checks in response to lost bindings. Basically required to find a solution for this.
3. Does we need to support multiple components?
4. Is the role and processing the most optimal one that can be used?

8.  IANA Considerations

This document request registration in a number of registries, both for RTSP and SDP.

8.1.  RTSP Feature Tags

This document request that two RTSP feature tags are registered in the "RTSP feature tag" registry:

setup.rtp-mux

See Section Section 6 (RTP and RTCP Multiplexing).

setup.ice-d-m

See Section Section 3.4 (ICE Feature Tag).

8.2.  Transport Protocol Specifications

This document needs to register a number of transport protocol combinations are registered in RTSP's "Transport Protocol Specifications" registry.

"RTP/AVP/D-ICE":

"RTP/AVPF/D-ICE":

"RTP/SAVP/D-ICE":

"RTP/SAVPF/D-ICE":

8.3.  RTSP Transport Parameters

This document requests that 4 transport parameters are registered in RTSP's "Transport Parameters":

"candidates":

See Section Section 3.2 (ICE Candidate Transport Header Parameter).

"ICE-Password":

See Section Section 3.3 (ICE Password and Username Transport Header Parameters).

"ICE-Userfrag":

See Section Section 3.3 (ICE Password and Username Transport Header Parameters).

"rtp-rtcp-mux":

See Section Section 6 (RTP and RTCP Multiplexing).

8.4.  RTSP Status Codes

This document requests that 2 assignments are done in the "RTSP Status Codes" registry. The suggested values are:

150:

See Section Section 3.5.1 (150 ICE connectivity checks in progress).

480:

See Section Section 3.5.2 (480 ICE Processing Failed).

8.5.  SDP Attribute

The registration of one SDP attribute is requested:

   SDP Attribute ("att-field"):

     Attribute name:     rtsp-ice-d-m
     Long form:          ICE for RTSP datagram media NAT traversal
     Type of name:       att-field
     Type of attribute:  Session level only
     Subject to charset: No
     Purpose:            RFC XXXX
     Reference:          RFC XXXX
     Values:             No values defined.
     Contact:            Magnus Westerlund
                         E-mail: magnus.westerlund@ericsson.com
                         phone: +46 8 404 82 87

9.  Security Considerations

ICE [I‑D.ietf‑mmusic‑ice] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) provides an extensive discussion on security considerations which applies here as well.

9.1.  ICE and RTSP

A long-standing risk with transmitting a packet stream over UDP is that the host may not be interested in receiving the stream. On today's Internet many hosts are behind NATs or operate host firewalls which do not respond to unsolicited packets with an ICMP port unreachable error. Thus, an attacker can construct SDP with a victim's IP address and cause a flood of media packets to be sent to a victim. The addition of ICE, as described in this document, provides protection from the attack described above. By performing the ICE connectivity check, the media server receives confirmation that the RTSP client wants the media. While this protection could also be implemented by requiring the IP addresses in the SDP match the IP address of the RTSP signaling packet, such a mechanism does not protect other hosts with the same IP address (such as behind the same NAT), and such a mechanism would prohibit separating the RTSP controller from the media playout device (e.g., an IP-enabled remote control and an IP-enabled television).

10.  Acknowledgements

The authors would like to thank Rémi Denis-Courmont for suggesting the method of integrating ICE in RTSP signalling, Dan Wing for help with the security section and numerous other issues.

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.