RFC 7825
A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
The Title Block ✨
okay bestie, this RFC is RFC 7825 💖 and the title is "A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)". it's a Standards Track document, so it's an actual Internet Standard and not just a vibe 🔥. it's dated December 2016, and its ISSN is 2070-1721 🌸
the authors are a squad of three 👑: J. Goldberg from Cisco, M. Westerlund from Ericsson, and T. Zeng from Nextwave Wireless, Inc. 🎀 the title block doesn't list anything it obsoletes or updates, so there's nothing to report on that front 🧚
Abstract ✨
okay so the abstract is giving "here's the whole plan in four sentences" 💅 this doc defines a fix for NAT traversal (aka getting media past Network Address Translation boxes 🦋) for datagram-based media streams. those streams get set up and controlled with RTSP 2.0. the fix uses Interactive Connectivity Establishment (ICE), but adapted so it uses RTSP as its signaling channel. it also defines the RTSP extensions and procedures that make it work 🫶
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💜 if you want more on Internet Standards, check out Section 2 of RFC 7841 🌈
for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7825 🍓
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. please actually read those, bestie, because they spell out your rights and restrictions for this doc 🙈
one important bit: any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, same as the Simplified BSD License says 🧚
Table of Contents
1. Introduction ....................................................3
2. Key Words .......................................................4
3. Solution Overview ...............................................4
4. RTSP Extensions .................................................6
4.1. ICE Transport Lower Layer ..................................6
4.2. ICE Candidate Transport Header Parameter ...................8
4.3. ICE Password and Username Transport Header Parameters .....11
4.4. ICE Feature Tag ...........................................11
4.5. Status Codes ..............................................12
4.5.1. 150 Server still working on ICE
connectivity checks ................................12
4.5.2. 480 ICE Connectivity check failure .................12
4.6. New Reason for PLAY_NOTIFY ................................12
4.7. Server-Side SDP Attribute for ICE Support .................13
5. ICE-RTSP .......................................................13
5.1. ICE Features Not Required .................................13
5.1.1. ICE-Lite ...........................................13
5.1.2. ICE-Mismatch .......................................13
5.1.3. ICE Remote Candidate Transport Header Parameter ....14
5.2. High-Reachability Configuration ...........................14
6. Detailed Solution ..............................................14
6.1. Session Description and RTSP DESCRIBE (Optional) ..........14
6.2. Setting Up the Media Streams ..............................15
6.3. RTSP SETUP Request ........................................16
6.4. Gathering Candidates ......................................16
6.5. RTSP Server Response ......................................17
6.6. Server-to-Client ICE Connectivity Checks ..................18
6.7. Client-to-Server ICE Connectivity Check ...................19
6.8. Client Connectivity Checks Complete .......................20
6.9. Server Connectivity Checks Complete .......................20
6.10. Freeing Candidates .......................................20
6.11. Steady State .............................................21
6.12. Re-SETUP .................................................21
6.13. Server-Side Changes after Steady State ...................22
7. ICE and Proxies ................................................24
7.1. Media-Handling Proxies ....................................24
7.2. Signaling-Only Proxies ....................................25
7.3. Non-supporting Proxies ....................................25
8. RTP and RTCP Multiplexing ......................................26
9. Fallback and Using Partial ICE Functionality to Improve
NAT/Firewall Traversal .........................................27
10. IANA Considerations ...........................................28
10.1. RTSP Feature Tags ........................................28
10.2. Transport Protocol Identifiers ...........................28
10.3. RTSP Transport Parameters ................................29
10.4. RTSP Status Codes ........................................29
10.5. Notify-Reason Value ......................................29
10.6. SDP Attribute ............................................29
11. Security Considerations .......................................30
11.1. ICE and RTSP .............................................30
11.2. Logging ..................................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgments ...................................................33
Authors' Addresses ................................................331. Introduction 🦋
okay so the big picture: Real Time Streaming Protocol (RTSP) [RFC2326] and RTSP 2.0 [RFC7826] are the protocols used to set up and control one or more media streams that deliver media to receivers 🎀. the thing is, setting up those streams is exactly what causes serious problems with Network Address Translators (NATs) [RFC3022], unless the protocol makes extra provisions for it 😭. so yes, there's a real need for a NAT traversal mechanism for media setup using RTSP 💅
RTSP 1.0 [RFC2326] has been missing a standardized NAT traversal mechanism for a long time 💀. the catch is that RTSP 1.0 is kind of messy to spec, so getting something interoperable was really hard. that's why this document is built on the RTSP 2.0 spec [RFC7826] instead 🫶. RTSP 2.0 is pretty similar to 1.0 in a lot of ways, but the big deal is that it has a well-defined extension mechanism. that lets you define a NAT traversal extension that's backwards compatible with RTSP 2.0 peers that don't support it 🔥. 1.0 couldn't do this, because the extension would've broken 1.0 syntax and caused compatibility chaos 🙈
there have been a bunch of ideas for NAT traversal of media in RTSP, and most of them are already in use in implementations 🌸. the evaluation of those solutions in [RFC7604] showed there are lots of issues to think through ✨. after all that evaluation, the team picked a mechanism based on Interactive Connectivity Establishment (ICE) [RFC5245] 👑. there were two main reasons: it supports RTSP servers sitting behind NATs, and it mitigates the security threat of RTSP servers being abused as Distributed Denial-of-Service (DDoS) attack tools 😤
this document specifies an ICE-based solution that's optimized for media delivery from server to client 🧚. if future extensions get specified for delivery modes other than "PLAY", then the optimizations around when PLAY requests get sent will need to be reconsidered 👀
the NAT problem for RTSP signaling traffic is a much less common problem than the NAT problem for RTSP media streams 🍓. so the signaling one is left for future study 🫠
the ICE usage defined here is called "ICE-RTSP" 🌈. it does not match full ICE for SIP/SDP (Session Description Protocol) or ICE-Lite as defined in the ICE specification [RFC5245]. ICE-RTSP is tailored to what RTSP needs, and it's a bit simpler than ICE-Full for both clients and servers ✨
2. Key Words ✨
this section is where the capital-letter key words live, and they're the official definitions 💅 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥
3. Solution Overview ✨
Okay bestie, so this overview assumes you already know how ICE [RFC5245] works, in the context of "SIP: Session Initiation Protocol" [RFC3261] and "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264]. It's mostly about showing how each ICE step gets done in RTSP 💖
- The RTSP server should indicate it has support for ICE via a new SDP [RFC4566] attribute (
a=rtsp-ice-d-m) in, for example, the SDP returned in the RTSP DESCRIBE message. This lets RTSP clients only do the new ICE exchanges with servers that support ICE 🎀 If RTSP DESCRIBE is used, the normal capability determination mechanism should also be used, i.e., aSupportedheader with a new ICE feature tag. Note: both mechanisms should be supported, because there are various use cases where only one of them gets used 🧚 - The RTSP client looks over the session description it got back, for example from an RTSP DESCRIBE message, to figure out which media streams need to be set up. For each of those media streams where the transport protocol supports connectivity checks based on Session Traversal Utilities for (NAT) (STUN) [RFC5389], the client gathers candidate addresses. See Section 4.1.1 in ICE [RFC5245]. Then the client runs a STUN server on each of the local candidate's transport addresses it has gathered 🦋
- The RTSP client sends SETUP requests containing a transport specification with a lower layer indicating ICE, plus a new RTSP Transport header parameter
candidateslisting the ICE candidates for each media stream 💅 - After getting the list of candidates from the client, the RTSP server gathers its own candidates. If the server is not behind a NAT, then a single candidate per address family (e.g., IPv4 and IPv6), media stream, and media component tuple can be included. This cuts down the number of combinations and speeds up completion ⚡
- The server sets up the media and, if that works, 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
candidatesparameter 🌸 - The server starts the connectivity checks by following the procedures in Sections 5.7 and 5.8 of ICE [RFC5245]. If the server is not behind a NAT, uses a public IP address, and has a single candidate per (media stream, component, address family) tuple, then the server may be configured to not initiate connectivity checks 🫶
- The client receives the SETUP response, learns which candidate addresses to use for the connectivity checks, and then starts its own connectivity check, following the procedures in Section 6 of ICE [RFC5245] 🔥
- When a connectivity check from the client reaches the server, it results in a triggered check from the server. This is why servers not behind a NAT can wait for this triggered check before sending out any checks of their own. That saves resources and mitigates the DDoS potential from server-initiated connectivity checks 👑
- When the client has finished its connectivity checks, including nominating candidates, and has received the server connectivity checks on the nominated candidates for all mandatory components of all media streams, it can issue a PLAY request. If the connectivity checks haven't concluded successfully, then the client may send a new SETUP request if it has any new information or believes the server may be able to do more that could result in successful checks 💜
- When the RTSP server receives a PLAY request, it checks that the connectivity checks have concluded successfully, and only then can it play the stream. If there's a problem with the checks, the server sends either a 150 (Server still working on ICE connectivity checks) response to show it's still working on the checks, or a 480 (ICE Connectivity check failure) response to indicate the checks failed. If the checks are successful, the server sends a 200 OK response and starts delivering media 🌈
The client and server may release unused candidates when ICE processing has concluded, a single candidate per component has been nominated, and a PLAY response has been received (client) or sent (server) 🧹
The client needs to keep using STUN as a keep-alive mechanism for the used candidate pairs so their NAT bindings stay current. RTSP servers behind NATs will also need to send keep-alive messages when they're not sending media. This matters because RTSP media sessions often contain only media traffic from the server to the client, so the NAT bindings need to be refreshed by client-to-server traffic, which the STUN keep-alive provides 🥺
4. 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 otherwise 💖
4.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 possible to demultiplex from STUN messages (see STUN [RFC5389]). By "datagram clean" we mean that it has to be capable of describing the length of the datagram, transporting that datagram (as a binary chunk of data), and providing it at the receiving side as one single item. This lower layer can be any transport type defined for ICE that does provide datagram transport capabilities. UDP-based transport candidates are defined in ICE [RFC5245] and MUST be supported. It is OPTIONAL to also support TCP-based candidates as defined by "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544]. The TCP-based candidate fulfills the requirements on providing datagram transport and can thus be used in combination with RTP. Additional transport types for candidates may be defined in the future ✨
This lower layer uses ICE to determine which of the different candidates shall be used and then, when 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 that use datagrams. This specification defines the following combinations:
RTP/AVP/D-ICERTP/AVPF/D-ICERTP/SAVP/D-ICERTP/SAVPF/D-ICE
This list can be extended with more transport specifications after an evaluation has confirmed they're compatible with D-ICE as a lower layer. The registration is required to follow the registry rules for the Transport Protocol Identifier (see Section 22.13.1 of [RFC7826]) 💅
The lower-layer "D-ICE" has the following rules for including the RTSP Transport header (Section 18.54 of RTSP 2.0 [RFC7826]) parameters:
unicast: ICE only supports unicast operations, so it is REQUIRED that one include the unicast indicator parameter (see Section 18.54 in RTSP 2.0 [RFC7826]) 🌸candidates: Thecandidatesparameter SHALL be included, as it specifies at least one candidate to try to establish a working transport path with 🫶dest_addr: This parameter MUST NOT be included, sincecandidatesis used instead to provide the necessary address information 🙈ICE-Password: This parameter SHALL be included (see Section 4.2) 🔐ICE-ufrag: This parameter SHALL be included (see Section 4.2) 🔐
4.2. ICE Candidate Transport Header Parameter ✨
okay bestie, this section introduces a brand new RTSP transport parameter 💖 for carrying ICE candidates that belong to the transport specification they appear in. Those candidates can then be checked end-to-end with a connectivity check using STUN [RFC5389] 🔥. A transport parameter can only occur once in each transport specification, so no doubling up 🙅♀️. If your transport spec uses "D-ICE" as its lower layer, this parameter MUST be present 🫶. The parameter can hold one or more ICE candidates. In the SETUP response there's only a single transport specification, so if that one uses the "D-ICE" lower layer, this parameter MUST be present and include the server-side candidates 💅.
The ABNF [RFC5234] for these transport header parameters looks like this:
trns-parameter = <Defined in Section 20.2.3 of [RFC7826]>
trns-parameter =/ SEMI ice-trn-par
ice-trn-par = "candidates" EQUAL DQUOTE SWS ice-candidate
*(SEMI ice-candidate) SWS DQUOTE
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 tcp-type-ext] ; Mandatory if transport = TCP
*(SP extension-att-name SP extension-att-value)
foundation = <See Section 15.1 of [RFC5245]>
component-id = <See Section 15.1 of [RFC5245]>
transport = <See Section 15.1 of [RFC5245]>
priority = <See Section 15.1 of [RFC5245]>
cand-type = <See Section 15.1 of [RFC5245]>
rel-addr = <See Section 15.1 of [RFC5245]>
rel-port = <See Section 15.1 of [RFC5245]>
tcp-type-ext = <See Section 4.5 of [RFC6544]>
extension-att-name = <See Section 15.1 of [RFC5245]>
extension-att-value = <See Section 15.1 of [RFC5245]>
connection-address = <See [RFC4566]>
port = <See [RFC4566]>
EQUAL = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>
SWS = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
SP = <Defined in [RFC7826]>Here's the lowdown on each piece 🎀:
<connection-address>is the unicast IP address of the candidate. You can use IPv4 addresses, IPv6 addresses, or Fully Qualified Domain Names (FQDNs), taken from SDP [RFC4566]. Note, this context MUST have a unicast address for this parameter, even though a multicast address would be syntactically valid. The connection address SHOULD use the same format (explicit IP or FQDN) as in thedest_addrparameter used in the transport specification that express any fallback. An IP address is preferred for simplicity, but both an IP Address and FQDN can be used. In the FQDN case, when receiving a SETUP request or response containing an FQDN in anice-candidateparameter, the FQDN is looked up in the DNS first using a AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A record. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing, which in RTSP is subsequent RTSP SETUPs for the same RTSP session.<port>is the port of the candidate. Its syntax is defined by SDP [RFC4566] 🦋.<transport>indicates the transport protocol for the candidate. The ICE specification defines UDP. "TCP Candidates with Interactive Connectivity Establishment (ICE)" [RFC6544] defines how TCP is used as candidates. There's extra extensibility so future transport protocols can be used with ICE too, such as the Datagram Congestion Control Protocol (DCCP) [RFC4340] 🌈.<foundation>is an identifier that's equivalent for two candidates that are of the same type, share the same base IP address, and come from the same STUN server. It's made up of one to thirty two<ice-char>. The foundation is used to optimize ICE performance in the Frozen algorithm (as described in [RFC5245]) ⭐.<component-id>identifies the specific component of the media stream this candidate is for. It's a positive integer in the range 1-256. It MUST start at 1 and MUST increment by 1 for each component of a particular media stream. For RTP-based media streams, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2, unless RTP and RTCP Multiplexing (Section 8) is used. In that case the second component is omitted and RTP and RTCP are both transported over the first component. Other types of media streams that require multiple components MUST develop specifications that define the mapping of components to component IDs. See Section 14 in [RFC5245] for additional discussion on extending ICE to new media streams 🧚.<priority>is a positive integer in the range 1 to(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, which are 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>are equal to the base for that server- or peer-reflexive candidate. If the candidate is relayed,<rel-addr>and<rel-port>are equal to the mapped address in the TURN Allocate Response that gave the client that relayed candidate (see Appendix B.3 of ICE [RFC5245] for a discussion of its purpose). If the candidate is a host candidate,<rel-addr>and<rel-port>MUST be omitted 🍓.<tcp-type-ext>conveys the candidate's connection type (active, passive, or simultaneous-open (S-O)) for TCP-based candidates. This MUST be included for candidates that have<transport>set to TCP, and MUST NOT be included for other transport types, including UDP 💜.<extension-att-name>and<extension-att-value>are prototypes for future extensions of the candidate line. The ABNF for these allows any 8-bit value except NUL, CR, or LF. However, the extensions will occur within a structured line that uses the DQUOTE, SEMI, SWS, and SP ABNF constructs as delimiters, so those delimiter characters MUST be escaped if they would occur within an extension-att-name or extension-att-value. The escape mechanism that MUST be used is the Percent-Encoding defined in Section 2.1 of [RFC3986]. This mechanism was picked because it already needs to be supported in an RTSP implementation to deal with URIs anyway 🔥. The byte values (in hex) that MUST be escaped are0x09,0x20,0x22,0x25, and0x3B😭.
4.3. ICE Password and Username Transport Header Parameters 🔐
The ICE password and username for each agent need to be carried over RTSP, so new Transport header parameters are defined for that (see Section 18.54 of [RFC7826]) ✨.
There MUST be an "ICE-Password" and "ICE-ufrag" parameter for each media stream. The ICE-ufrag and ICE-Password parameter values MUST be chosen randomly at the beginning of a session. The ICE-ufrag value MUST contain at least 24 bits of randomness, and the ICE-Password value MUST contain at least 128 bits of randomness. That means the ICE-ufrag value will be at least 4 characters long, and the ICE-Password value at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The values MAY be longer than 4 and 22 characters respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time 🌈.
The ABNF [RFC5234] for these parameters is:
trns-parameter =/ SEMI ice-password-par
trns-parameter =/ SEMI ice-ufrag-par
ice-password-par = "ICE-Password" EQUAL DQUOTE password DQUOTE
ice-ufrag-par = "ICE-ufrag" EQUAL DQUOTE ufrag DQUOTE
password = <Defined in [RFC5245], Section 15.4>
ufrag = <Defined in [RFC5245], Section 15.4>
EQUAL = <Defined in [RFC7826]>
SEMI = <Defined in [RFC7826]>
DQUOTE = <Defined in [RFC7826]>4.4. ICE Feature Tag 🎀
There's a feature tag for the RTSP capabilities mechanism that signals ICE support for media transport using datagrams: "setup.ice-d-m". It says that one supports all the mandatory functions of this specification. It applies 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. Note, this is not a "MUST" as an RTSP client can always attempt a SETUP using ICE to see if it works or fails 🙈. However, including the feature tag in the Supported header makes sure that proxies supporting this specification explicitly indicate that support (see Section 7) 💅.
4.5. Status Codes 🚦
For ICE, there are two new RTSP response codes to indicate progress and errors 💖.
+------+----------------------------------------------+-------------+
| Code | Description | Method |
+------+----------------------------------------------+-------------+
| 150 | Server still working on ICE connectivity | PLAY |
| | checks | |
| | | |
| 480 | ICE Connectivity check failure | PLAY, SETUP |
+------+----------------------------------------------+-------------+Table 1: New Status Codes and Their Usage with RTSP Methods
4.5.1. 150 Server still working on ICE connectivity checks ⏳
The 150 response code means the ICE connectivity checks are still in progress and haven't wrapped up yet. 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. A client can expect network delays between the server and client, so a response might take longer than 200 milliseconds 🌸. After that, every 3 seconds following the previous 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 🦋.
4.5.2. 480 ICE Connectivity check failure 💀
The 480 client error response code is used when the request can't be fulfilled because the ICE processing failed, for example when all the connectivity checks have timed out 😭. This error can show up either in response to a SETUP request, to indicate that no candidate pair can be constructed, or in response to a PLAY request, to indicate that the server's connectivity checks resulted in failure 🍓.
4.6. New Reason for PLAY_NOTIFY 💌
okay so there's a brand new value for the Notify-Reason header in PLAY_NOTIFY messages, and it's "ice-restart" 🔄 it tells the other side that an ICE restart needs to happen on the resource and session you're pointing at. no cap, it's a small addition but it's doing a lot
Notify-Reas-val =/ "ice-restart"4.7. Server-Side SDP Attribute for ICE Support 🎀
if the server supports media NAT traversal for RTSP-controlled sessions (the way this RFC describes it), then it SHOULD put the a=rtsp-ice-d-m SDP attribute into any SDP it uses to describe the content it serves 🫶 this one only lives at session level, so check [RFC4566] if you want the details
the ABNF from [RFC5234] for this attribute looks like this:
rtsp-ice-d-m-attr = "a=" "rtsp-ice-d-m"5. ICE-RTSP 🦋
okay this section is all about how ICE-RTSP is different from the regular ICE usage in [RFC5245] 💅 the differences come down to two things: RTSP gives you way clearer client and server roles, and session setup happens inside RTSP itself instead of going through the SIP/SDP offer/answer dance
5.1. ICE Features Not Required 🙈
a bunch of ICE signaling features just aren't needed with RTSP, so let's go through them
5.1.1. ICE-Lite 🚫
the ICE-Lite attribute SHALL NOT be used in RTSP, periodt 😭 ICE describes two implementations, Full and Lite, and hosts that aren't behind a NAT are allowed to do only Lite. for RTSP though, Lite just isn't enough. it doesn't make the media server send a connectivity check, and that check is what protects the RTSP server from becoming a denial-of-service tool 💀
5.1.2. ICE-Mismatch 🌸
the ice-mismatch parameter says the offer showed up with a default destination for a media component that didn't have a matching candidate attribute. RTSP doesn't need this one because the ICE-based lower-layer transport is either supported or it isn't, and you'll use some other transport instead. either way it's always spelled out explicitly in the SETUP request and response ✨
5.1.3. ICE Remote Candidate Transport Header Parameter 💜
the Remote candidate attribute isn't needed for RTSP, and here's the reasoning 🧠 every SETUP request kicks off its own independent ICE processing chain, and that chain either fails or nominates one single candidate pair to use. if you send a new SETUP for the same media, it has to use a new username fragment and password, so there's no race condition and nobody gets confused about which round of processing the STUN requests belong to 🔥
5.2. High-Reachability Configuration 🌈
ICE-RTSP has a high-reachability configuration for when the RTSP servers aren't behind NATs. quick note though: "not behind NATs" can also cover some special cases with RTSP servers that are behind NATs, as long as they sit in an address space that every intended RTSP client can reach 👑
this configuration is kind of like ICE-Lite because it takes some load off the server. but the server still has to verify that the client is actually there and wants the media stream, so the server must also send binding requests and wait for the binding responses. where it saves work is that these servers don't have to start their own checks and can rely on triggered checks for verification instead 🧚 this also kills a denial-of-service threat, where one RTSP SETUP request could set off a huge pile of STUN connectivity checks toward the candidate addresses it was given 💅
6. Detailed Solution ✨
this section walks through, step by step, how ICE works alongside RTSP messages 🦋
6.1. Session Description and RTSP DESCRIBE (Optional) 🎀
the RTSP server is RECOMMENDED to say it supports ICE by sending the a=rtsp-ice-d-m SDP attribute in its response to the RTSP DESCRIBE message, as long as SDP is being used 🌸 this way, clients only send the new ICE exchanges to servers that actually support ICE, so current non-ICE servers don't get extra overhead. and when DESCRIBE isn't in the picture, it's still RECOMMENDED to use the SDP attribute for the session description
a client can also use DESCRIBE to check explicitly whether both the server and any proxies support ICE 🕵️♀️ the client puts the Supported header in its request with its feature tags, including setup.ice-d-m. when a proxy sees the Supported header, it includes a Proxy-Supported header with the feature tags it supports
the server echoes back the Proxy-Supported header and its own version of the Supported header, so the client can tell whether every party in the chain supports ICE. heads up though: even if a proxy in the chain doesn't say it supports ICE, things may still work (see Section 7) 🫶
here's an 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, setup.rtp.rtcp.mux
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, setup.rtp.rtcp.mux
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: /video6.2. Setting Up the Media Streams 🎬
the RTSP client looks over the session description it got back (from an RTSP DESCRIBE message, for example) to figure out which media resources it needs to set up 💖 for each media stream where the transport protocol supports ICE connectivity checks, the client SHALL gather candidate addresses for UDP transport as described in Section 4.1.1 in ICE [RFC5245], using standard ICE and not the ICE-Lite implementation. for TCP-based candidates, it follows Section 5 of ICE TCP [RFC6544] ✨
6.3. RTSP SETUP Request 📨
next up, the RTSP client sends at least one SETUP request per media stream to set up the media streams the session needs 🌷 for each media stream where it wants to use ICE, it MUST include a transport specification with "D-ICE" as the lower layer. each media stream SHALL have its own unique combination of ICE candidates and ICE-ufrag, no sharing allowed 🙅♀️ that transport specification SHOULD go first in the list so it gets the highest priority. it is RECOMMENDED to add extra transport specifications as a fallback, in case there are proxies that don't support ICE 🛟 the RTSP client is the one initiating, so it's the controlling party in ICE processing 👑
here's an example (some lines are broken up in ways that don't match the defined syntax, because the document format doesn't have much room):
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 313
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=8hhY;
ICE-Password=asd88fgpdd777uzjYhagZg; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 45664 typ srflx
raddr 10.0.1.17 rport 8998"; RTCP-mux,
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, setup.rtp.rtcp.mux6.4. Gathering Candidates 🧭
when the server gets a SETUP request, it can work out which media resource should be delivered and which transport options the client supports 🔍 if D-ICE is on the list of supported transports and is the preferred one, the stuff below applies
the transport specification says which media protocol to use. based on that and the client's candidates, the server figures out the protocol and whether it supports ICE with that protocol. the server SHALL then gather its UDP candidates according to Section 4.1.1 in ICE [RFC5245], plus any TCP-based ones according to Section 5 of ICE TCP [RFC6544] 🌊
servers that have an address that's generally reachable by any client within the address scope the server intends to serve MAY be specially configured (the high-reachability configuration) 💫 the point of this special setup is to cut the server-side candidates down to preferably a single one per (address family, media stream, media component) tuple. instead of gathering every possible address, including relayed and server-reflexive ones, the server uses one address per address family that it knows should be reachable by a client behind one or more NATs. this helps for two reasons. first, it reduces the server's load for address gathering and for ICE processing during connectivity checks. second, it cuts way down on the number of candidate pair permutations, which can speed up finishing ICE processing 🏁 BUT, heads up: using this option on a server that isn't reachable is counterproductive, so it's super important to get the configuration right ⚠️
the general stuff above for servers also applies to TCP-based candidates. a general implementation should support several candidate collection techniques and connection types. for TCP-based candidates, a high-reachability configured server is recommended to only offer Host candidates. on top of passive connection types, the server can choose to offer active or S-O connection types to match the client's candidates 🎀
6.5. RTSP Server Response 💌
the server works out whether the SETUP request succeeded. if it did, it sends back a 200 OK response; if not, it sends an error code instead 🙏 once the server has picked a transport specification using the "D-ICE" lower layer, it needs to put that transport specification in the response message. the transport specification SHALL include the candidates gathered in Section 6.4 in the "candidates" transport header parameter, along with the server's ICE username fragment and password 🔑 if there aren't any valid candidate pairs from combining the client and server candidates, a 480 (ICE Connectivity check failure) error response SHALL be returned, and it MUST include the server's candidates 😭 getting a 480 might let both the server and client release their candidates. see Section 6.10 for more on that 🧹
here's an example of a successful response to the request from Section 6.3:
S->C: RTSP/2.0 200 OK
CSeq: 313
Session: 12345678
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=MkQ3;
ICE-Password=pos12Dgp9FcAjpq82ppaF; 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, setup.rtp.rtcp.mux6.6. Server-to-Client ICE Connectivity Checks ✨
Okay bestie, so the server SHALL start its connectivity checks by following Sections 5.7 and 5.8 of ICE [RFC5245] 💅 unless it's set up to use the high-reachability option. If it is, then it MAY hold off on its own checks until the client's connectivity checks trigger the server's checks. 🦋
Please note (lowkey important!!) that Section 5.8 of ICE [RFC5245] says the checks are paced, so new ones only start every Ta milliseconds. The reason is in Appendix B.1 of ICE [RFC5245]: in SIP/SDP, all the media streams in an offer/answer dialog run on the same queue. To get the same behavior with RTSP, the server SHALL use a single pacer queue for all media streams within each RTSP session. 🎀
The pacing values for STUN and TURN transactions, Ta and RTO, can be configured, but they have the same minimum values defined in the ICE specification. 🌸
When a connectivity check from the client reaches the server, it results in a triggered check from the server, as specified in Section 7.2.1.4 of ICE [RFC5245]. That's why servers with a high-reachability address can wait for this triggered check before they send out any checks of their own. It saves resources and mitigates the DDoS potential, which is so smart 🫶
6.7. Client-to-Server ICE Connectivity Check 🧚
The client gets the SETUP response and learns the candidate addresses to use for the connectivity checks. The client SHALL initiate its connectivity check(s), following the procedures in Section 6 of ICE [RFC5245]. The pacing of STUN transactions (Appendix B.1 of [RFC5245]) SHALL be used across all media streams that are part of the same RTSP session. 💖
Aggressive nomination SHOULD be used with RTSP during the initial SETUP for a resource. It doesn't have all the negative impact it has in offer/answer, because media only starts playing after a PLAY request is issued. So the problem of the media path changing mid-delivery can be avoided by not issuing a PLAY request while STUN connectivity checks are still outstanding. Aggressive nomination can result in multiple candidate pairs having their nominated flag set, but according to Section 8.1.1.2 of ICE [RFC5245], when the PLAY request is sent, the media will arrive on the pair with the highest priority. Note, different media resources may still end up with different foundations. 🔥
The above does not change ICE or how it handles aggressive nomination. When using aggressive nomination, a higher-priority candidate pair with an outstanding connectivity check message can move into the Succeeded state, and that pair will have its Nominated flag set. This means the higher-priority pair gets used instead of the previous pair, which is also in the Succeeded state. Plot twist, honestly 💀
To avoid this happening during actual media transport, the RTSP client can add extra logic once ICE processing is completed overall, to indicate whether there are still higher-priority connectivity checks outstanding. If a check is still outstanding, the implementation can choose to wait for some additional timeout to trigger, or for the outstanding checks to complete, before moving on with a PLAY request. The other option is to accept the risk of a path change during media delivery and start playing immediately. ✨
RTSP clients that want every media resource to use the same path can use regular nomination, where both 1) the ICE processing completion criteria and 2) which media streams are nominated for use can be controlled. This doesn't affect the RTSP server, since its role is the one of being controlled. 🦋
6.8. Client Connectivity Checks Complete 🍓
When the client has concluded all of its connectivity checks and has nominated its desired candidate pair for a particular media stream, it MAY issue a PLAY request for that stream. Heads up: because of aggressive nomination, there's a risk that an outstanding check nominates a different pair than the one already nominated. The candidate pair with the highest priority will be used for the media. If the client has locally determined that its checks have failed, it may try providing an extended set of candidates and update the server's candidate list by issuing a new SETUP request for the media stream. 🌈
If the client concluded its connectivity checks successfully and therefore sent a PLAY request, but the server cannot conclude successfully, the server will respond with 480 (ICE Connectivity check failure), an error response. After receiving that 480 (ICE Connectivity check failure) response, the client may send a new SETUP request, assuming it has new information to add to the candidate list. If the server is still performing its checks when it receives the PLAY request, it will respond with 150 (Server still working on ICE connectivity checks) to indicate this. ⏳
6.9. Server Connectivity Checks Complete 👑
When the RTSP server receives a PLAY request, it checks that the connectivity checks have concluded successfully, and only then will it play the stream. If the PLAY request is for a particular media stream, the server only needs to check that the connectivity checks for that stream completed successfully. If the server hasn't concluded its connectivity checks yet, it says so by sending 150 (Server still working on ICE connectivity checks) (Section 4.5.1). If there's a problem with the checks, the server sends a 480 response to indicate that the checks failed. If the checks are successful, the server sends a 200 OK response and starts delivering media. 🎬
6.10. Freeing Candidates 🧹
Both server and client MAY free their non-selected candidates as soon as a 200 OK response has been issued or received for the PLAY request and no outstanding connectivity checks exist. 💅
Clients and servers MAY free all of their gathered candidates after having received or sent, respectively, a 480 response to a SETUP request. Clients will likely free their candidates first, after trying any extra actions that might resolve the issue, e.g., verifying the address gathering, or using additional STUN or TURN servers. So a server has to weigh the cost of doing address gathering against keeping the gathered addresses around for a while, in case the client issues a new SETUP request. 🤔
If the 480 response is sent in response to a PLAY request, the server MUST NOT free its gathered candidates. Instead, it has to wait for more actions from the client, or terminate the RTSP session due to inactivity. 🙈
6.11. Steady State 💜
The client and server SHALL use STUN to send keep-alive messages for the nominated candidate pair(s), following the rules of Section 10 of ICE [RFC5245]. This is important, because RTSP play mode sessions normally only carry traffic from the server to the client. That means the NAT bindings need to be refreshed by client-to-server traffic, which is exactly what the STUN keep-alive provides. 🌙
6.12. Re-SETUP ✨
A client that decides to change any parameters related to the media stream setup will send a new SETUP request. In this new SETUP request, the client MAY include a new, different ICE username fragment and password to use in the ICE processing. The new ICE username and password SHALL cause the ICE processing to start from the beginning again, i.e., an ICE restart (Section 9.1.1.1 of [RFC5245]). In the case of an ICE restart, the client SHALL gather candidates and include them in the transport specification for D-ICE. 🔄
ICE restarts may be triggered by changes in the client's or server's attachment to the network, such as changes to the media stream's destination or source address or port. Most RTSP parameter changes wouldn't need an ICE restart. They use the existing RTSP mechanisms to indicate from what point in the RTP stream they apply. These include: pausing before the parameter change and then resuming; assuming the server supports using SETUP during the PLAY state; or using the RTP-Info header (Section 18.45 of [RFC7826]) to indicate from where in the media stream the change shall apply. 🎀
Even if the server doesn't normally support SETUP during the PLAY state, it SHALL support SETUP requests in the PLAY state for the purpose of changing only the ICE parameters, which are ICE-Password, ICE-ufrag, and the content of ICE candidates. 🫶
If the RTSP session is in the playing state when the SETUP request requiring an ICE restart is sent, 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 media stream. Once nomination of the new candidate pair has completed, all unused candidates may be released. If the ICE processing fails and no new candidate pairs are nominated for use, the media stream MAY continue to use the previously nominated candidate pairs while they still function. If they start to fail at transporting media packets, the client can pick between two actions: trying any actions that might make ICE work, or terminating the RTSP session. First, it can attempt any available actions that might make ICE work, like trying another STUN/TURN server or changing the transport parameters. In that case, the client modifies the RTSP session, and if ICE is still going to be used, the client restarts ICE once more. Second, if the client is unable to modify the transport or ICE parameters, it MUST NOT restart the ICE processing, and it SHOULD terminate the RTSP session. 🌸
6.13. Server-Side Changes after Steady State ✨
Okay so, a server might need an ICE restart 🔄 because of server-side load balancing, or because something failed and its IP address and port number changed. When that happens, the server SHALL use the PLAY_NOTIFY method to tell the client (Section 13.5 [RFC7826]) with a new Notify-Reason: ice-restart header 💌. The server also tells the client whether the change is for a single media stream or the whole session, by putting the matching URI in the PLAY_NOTIFY request.
Once the client gets this PLAY_NOTIFY with an ice-restart reason and responds to it, the client SHALL gather new ICE candidates and send SETUP requests for each media stream in the session 🎀. The server hands over its candidates in the SETUP response, the same way it did the very first time through ICE processing. Both the server and the client SHALL provide new ICE usernames and passwords 🔑. The client MAY send the SETUP request while the session is still in PLAYING state.
If the RTSP session is in PLAYING state when the client sends that SETUP request, the client SHALL use Regular nomination 👑. If it isn't, the client just follows the same procedures it used when it first created the session.
Now, the old candidate pairs don't just vanish. For each media stream, keep-alive messages on the previous set of candidate pairs SHOULD keep going until the new candidate pairs have been nominated 🫶. Once a new set is nominated, the client might still receive media for a bit longer. Even if the server stops sending media over that pair at the moment of nomination, media can still show up for up to one maximum segment lifetime as defined in TCP (2 minutes) 🕰️. Here's the tricky part 😭: if the RTSP server is split into a separate controller and media stream, a failure could keep media flowing for longer than that maximum segment lifetime. So source filtering is RECOMMENDED 🛡️.
Here's what the whole dance looks like:
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: ice-restart
Session: uZ3ci0K+Ld
Server: PhonyServer 1.1
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/audio RTSP/2.0
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=Kl1C;
ICE-Password=H4sICGjBsEcCA3Rlc3RzLX; candidates="
1 1 UDP 2130706431 10.0.1.17 8998 typ host;
2 1 UDP 1694498815 192.0.2.3 51456 typ srflx
raddr 10.0.1.17 rport 9002"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6970"/":6971",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://server.example.com/fizzle/foo/video RTSP/2.0
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; ICE-ufrag=hZv9;
ICE-Password=JAhA9myMHETTFNCrPtg+kJ; candidates="
1 1 UDP 2130706431 10.0.1.17 9000 typ host;
2 1 UDP 1694498815 192.0.2.3 51576 typ srflx
raddr 10.0.1.17 rport 9000"; RTCP-mux,
RTP/AVP/UDP; unicast; dest_addr=":6972"/":6973",
RTP/AVP/TCP; unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 314
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=CbDm;
ICE-Password=OfdXHws9XX0eBr6j2zz9Ak; candidates="
1 1 UDP 2130706431 192.0.2.56 50234 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:46 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux
S->C: RTSP/2.0 200 OK
CSeq: 315
Session: uZ3ci0K+Ld
Transport: RTP/AVP/D-ICE; unicast; RTCP-mux; ICE-ufrag=jigs;
ICE-Password=Dgx6fPj2lsa2WI8b7oJ7+s; candidates="
1 1 UDP 2130706431 192.0.2.56 47233 typ host"
Accept-Ranges: NPT
Date: 11 March 2011 13:17:47 GMT
Server: PhonyServer 1.1
Supported: setup.ice-d-m, setup.rtp.rtcp.mux7. ICE and Proxies 🧚
RTSP allows proxies, and they come in two main flavours 🍓. It depends on whether they relay (and maybe cache) the media or not. How each type affects the RTSP NAT traversal solution, including backwards compatibility, is explained below 👀.
7.1. Media-Handling Proxies
Picture a proxy that relays or caches the media for a particular media session. You can think of it as splitting the media transport into two parts 🪄. First, there's the media transport between the server and the proxy, shaped by what the proxy needs. Second, there's the delivery from the proxy to the client. Because of that split, the NAT traversal solution runs on each individual media leg, as needed 🦋.
It is RECOMMENDED that any media-handling proxy supports the media NAT traversal defined in this specification 💜. There are two reasons for this. First, it lets clients do NAT traversal for the media between the proxy and themselves. Second, it keeps the proxy topology independent, so it can do NAT traversal (toward the server) for clients that can't do NAT traversal themselves but sit in the same address domain as the proxy 🌸.
To support the media NAT traversal defined here, a proxy needs to implement the whole solution and be able to act as both a controlling and a controlled ICE peer 👑. The proxy also SHALL include the "setup.ice-d-m" feature tag in any applicable capability negotiation headers, such as Proxy-Supported ✨.
7.2. Signaling-Only Proxies
A signaling-only proxy handles only the RTSP signaling. The media doesn't get relayed through it 🙈. This kind of proxy probably won't work unless the media NAT traversal solution is in place between the client and the server. The reason is that the DoS protection measures (see Section 21.2.1 of RTSP 2.0 [RFC7826]) usually stop media from being delivered to addresses other than the one the RTSP signaling came from at the server 🚧.
The fix for a signaling-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 that supports this SHALL show it by always including the "setup.ice-d-m" feature tag in the Proxy-Supported header on any SETUP request or response 💅.
7.3. Non-supporting Proxies
A media-handling proxy that doesn't support the ICE media NAT traversal described here is assumed to drop the transport specification and use any lower-priority transport specifications the requester provided 🥺. Those non-ICE transports let the negotiation finish, even though they're less preferred, since a NAT between the proxy and the client might make the media path fail 😬.
A non-media-handling proxy is expected to ignore and simply forward all unknown transport specifications. But that's only a guarantee for proxies that follow the RTSP 2.0 specification [RFC7826] 📜.
Using the "setup.ice-d-m" feature tag in the Proxy-Require header is NOT RECOMMENDED, because it can give contradictory results 🙃. For a media-handling proxy that doesn't support ICE, including the tag makes it abort the setup and report that the feature isn't supported. That's handy if you want other fallbacks or transport configurations ready. For non-ICE-supporting, non-media-handling proxies, the setup gets aborted too. But the setup might have worked if the tag wasn't in the Proxy-Require header at all 😤. That inconsistency is exactly why we don't recommend Proxy-Require. Instead, we recommend using the Supported header, which forces proxies to put the feature tags for the intersection of what the whole proxy chain supports into their Proxy-Supported header 🫧. That gives a positive signal when every proxy between the client and server supports the functionality 🎉.
If a proxy doesn't support the "setup.ice-d-m" feature and it isn't media-handling, the ICE-based setup could still work, because that kind of proxy may just pass through any transport parameters 🌈. The catch is that the Proxy-Require and Proxy-Supported RTSP headers don't tell you that. The only way to find out is to try a SETUP with a Transport header that includes ICE transport specifications 🔍.
8. RTP and RTCP Multiplexing 💖
"Multiplexing RTP Data and Control Packets on a Single Port" [RFC5761] explains how and when RTP and RTCP can share the same port 🎀. Multiplexing pairs nicely with ICE for RTSP, because RTP and RTCP then only need a single component per media stream instead of two. That cuts the load on the connectivity checks 💅. For how to negotiate RTP and RTCP multiplexing, see Appendix C of RTSP 2.0 [RFC7826] 📖.
Multiplexing has a big perk: you don't have to handle two components per media stream when RTP is the media transport protocol 🙌. That gets rid of at least one STUN check per media stream. It also speeds up ICE processing by at least the time it takes to pace out the extra STUN checks, which can be up to one complete round-trip time for a single media stream ⚡. Plus, the server and client get simpler, because multiplexing halves the total number of STUN instances and the state they hold 🧠. It also shrinks the number of combinations and the length of the candidate list 🪶.
Yes, implementing RTP and RTCP multiplexing is extra work. But if you're implementing ICE, a server or client already needs a demultiplexer between STUN and RTP or RTCP packets below the RTP/RTCP implementation. So adding one more demultiplexing point, directly connected to STUN and RTP/RTCP, seems small next to the benefits 🥰.
Because of all those benefits, RTSP servers and clients that support the "D-ICE" lower-layer transport together with RTP SHALL also implement and use RTP and RTCP multiplexing, as specified in Appendix C.1.6.4 of [RFC7826] and [RFC5761] 💜✨
9. Fallback and Using Partial ICE Functionality to Improve NAT/Firewall Traversal ✨
okay so fallback in RTSP is way less of a big deal than in SIP 🌸 With SIP, ICE lives inside SDP offer/answer, and a default destination candidate is super important so you can still talk to endpoints that don't do ICE at all. In RTSP, you can figure out whether ICE is supported before the RTSP SETUP request even goes out 💅 So a client should normally not need to add fallback options when it offers ICE, because the capability is already known. BUT (and this is the lowkey cool part) clients can still borrow some ICE functionality to get better NAT/firewall traversal when the server isn't ICE capable 🦋
Section 4.1.4 of the ICE [RFC5245] specification does recommend that the default destination, meaning what gets used as the fallback when the peer isn't ICE capable, is a relayed candidate. The reason is to maximize the chance that media actually arrives 💖 That advice comes from SIP, where the peer using SDP offer/answer is almost as likely to be behind a NAT as the client. RTSP is different, though. Servers are way more likely to be publicly reachable 🌈 Honestly, a publicly reachable server behind a NAT either has to support ICE or be set up with static configuration that allows traversal. So you can assume the server has a public address or supports ICE, and the default destination for RTSP can be prioritized differently ✨
Now, an ICE-enabled client behind a NAT needs a STUN server address to gather candidates successfully 🎀 That same STUN server can be used to derive a server reflexive candidate for the client's port. How useful that is as a default candidate for a NATed RTSP client depends on how the NAT behaves. As long as the NAT uses an address-independent mapping, a STUN-derived reflexive candidate has a good shot at working 🧚 BUT it's brittle in a few ways, and this is exactly why the original STUN specification [RFC3489] and direct use of it for NAT traversal got obsoleted 💀 First, if you try to figure out the NAT's behavior with STUN as described in [RFC3489], the result might not reflect the behavior you hit on another mapping. Second, filter state toward the ports used by the server has to be established. For that to happen, the server has to include both address and port in its response to the SETUP request. Third, messages need to be sent to those ports for keep-alive at a regular interval. How a server reacts to that kind of unsolicited traffic is unknown 🙈 This brittleness might be acceptable for fallback if the server doesn't support ICE.
To maximize the likelihood that an RTSP client can receive media, a relay-based address should be chosen as the default fallback address 🫶 However, if the client doesn't have a relay server like a TURN server, or using one costs a lot, then a STUN-derived server reflexive address as the client default has a reasonable chance of working and can be used as an alternative 🍓
Fallback addresses need to be provided in their own transport specification. That specification uses a specifier that does NOT include the D-ICE lower-layer transport. Instead, the selected protocol, e.g., UDP, has to be indicated explicitly or implicitly 🔥 Second, the selected default candidate has to be included in the SETUP request. If that candidate is server reflexive or relayed, keep-alive needs to be taken care of too 💜
10. IANA Considerations 📋
okay so this section is where all the registrations go 🌸 There are registrations in a bunch of registries, for both RTSP and SDP. For all of the registrations below, the contact person on behalf of the IETF WG MMUSIC is Magnus Westerlund <magnus.westerlund@ericsson.com> 💅
10.1. RTSP Feature Tags
Per this document, one RTSP 2.0 feature tag was registered in the "RTSP 2.0 Feature-tags" registry ✨
setup.ice-d-m: A feature tag representing the support of the ICE-
based establishment of datagram media transport that is capable of
transport establishment through NAT and firewalls. This feature
tag applies to clients, servers, and proxies and indicates support
of all the mandatory functions of this specification.10.2. Transport Protocol Identifiers
Per this document, a number of transport protocol combinations were registered in the RTSP 2.0 "Transport Protocol Identifiers" registry 🦋
RTP/AVP/D-ICE: RTP using the AVP profile over an ICE-established
datagram flow.
RTP/AVPF/D-ICE: RTP using the AVPF profile over an ICE-established
datagram flow.
RTP/SAVP/D-ICE: RTP using the SAVP profile over an ICE-established
datagram flow.
RTP/SAVPF/D-ICE: RTP using the SAVPF profile over an ICE-established
datagram flow.10.3. RTSP Transport Parameters
Per this document, three transport parameters were registered in the RTSP 2.0 "Transport Parameters" registry 🎀
candidates: Listing the properties of one or more ICE candidates.
See Section 4.2.
ICE-Password: The ICE password used to authenticate the STUN binding
request in the ICE connectivity checks. See Section 4.3.
ICE-ufrag: The ICE username fragment used to authenticate the STUN
binding requests in the ICE connectivity checks. See Section 4.3.10.4. RTSP Status Codes
Per this document, two assignments were made in the "RTSP 2.0 Status Codes" registry. See Section 4.5. 🌈
10.5. Notify-Reason Value
Per this document, one assignment was made in the RTSP 2.0 Notify-Reason header value registry. The defined value is:
ice-restart: This Notify-Reason value allows the server to notify
the client about the need for an ICE restart. See Section 4.6.10.6. SDP Attribute
One SDP attribute was registered 🧚
SDP Attribute ("att-field"):
Attribute name: rtsp-ice-d-m
Long form: ICE for RTSP datagram media NAT traversal
Type of attribute: Session-level only
Subject to charset: No
Purpose: RFC 7825, Section 4.7
Values: No values defined
Contact: Magnus Westerlund
Email: magnus.westerlund@ericsson.com
Phone: +46 10 714 82 8711. Security Considerations 💀
okay this part is seriously important, bestie 😭 ICE [RFC5245] and ICE TCP [RFC6544] already have an extensive discussion of security considerations, and those apply here too 🔥
11.1. ICE and RTSP
A long-standing risk with sending a packet stream over UDP is that the host might not be interested in receiving it 💀 On today's Internet, lots of hosts are behind NATs or run host firewalls that don't answer unsolicited packets with an ICMP port unreachable error. So an attacker can craft RTSP SETUP requests using a victim's IP address and cause a flood of media packets to be sent to the victim 😱 The addition of ICE, as described in this document, protects against the attack above. By doing the ICE connectivity check, the media server gets confirmation that the RTSP client actually wants the media 🛡️ You could also protect against this by requiring the IP addresses in the SDP to match the IP address of the RTSP signaling packet. BUT that doesn't protect other hosts sharing the same IP address (like hosts behind the same NAT). It also prohibits separating the RTSP controller from the media play-out device, like an IP-enabled remote control and an IP-enabled television 📺 And it forces RTSP proxies to relay the media streams through themselves, even when they'd otherwise only be signaling proxies.
To protect against attacks on ICE that are based on signaling information, RTSP signaling SHOULD be protected using TLS to prevent eavesdropping and modification of information 🔒
The STUN amplification attack described in Section 18.5.2 in ICE [RFC5245] needs consideration 👀 Servers that can run according to the high-reachability option have good mitigation against this attack, because they only send connectivity checks toward an address and port pair they've received an incoming connectivity check from. That means an attacker needs both the ability to spoof source addresses AND the ability to signal the RTSP server a set of ICE candidates. Separately, an ICE agent needs to implement the mitigation that reduces the volume of the amplification attack, as described in the ICE specification 🫶
11.2. Logging
Logging NAT translations is super helpful to analysts, especially in enterprises, who need to be able to map sessions when they're investigating possible issues where the NAT is involved 🧐 When logging on the public Internet, the logs can get big and privacy invasive, so procedures for log flushing and privacy protection SHALL be in place. Be careful about protecting these logs, and think about log integrity, privacy protection, and purging logs (retention policies, etc.) 🗂️ Also, logging connection errors and other messages established by this document can be really important ✨
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <http://www.rfc-editor.org/info/rfc7826>.12.2. Informative References 📚
Okay bestie, these are the "good to know" receipts 🤓 Not required reading, but iykyk, they're where the whole vibe came from 💅
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[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,
DOI 10.17487/RFC3489, March 2003,
<http://www.rfc-editor.org/info/rfc3489>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<http://www.rfc-editor.org/info/rfc4340>.
[RFC7604] Westerlund, M. and T. Zeng, "Comparison of Different NAT
Traversal Techniques for Media Controlled by the Real-Time
Streaming Protocol (RTSP)", RFC 7604,
DOI 10.17487/RFC7604, September 2015,
<http://www.rfc-editor.org/info/rfc7604>.Acknowledgments 🫶
Okay, the authors had some people they absolutely needed to thank 💖 Remi Denis-Courmont gets a massive shoutout for suggesting the method of integrating ICE in RTSP signaling 🔥 Dan Wing helped with the security section and numerous other issues 💅 Ari Keranen reviewed the document and its ICE details 🦋 Flemming Andreasen and Alissa Cooper gave a thorough review 👑 And Bill Atwood dropped comments and suggestions for improvements 🌸 Literally the squad 😭
Authors' Addresses 🧚
Here's where you can find the authors 💜 (the contact details are copied exactly, obviously 🙈)
Jeff Goldberg
Cisco
32 Hamelacha St.
South Netanya 42504
Israel
Phone: +972 9 8927222
Email: jgoldber@cisco.com
Magnus Westerlund
Ericsson
Farogatan 6
Stockholm SE-164 80
Sweden
Phone: +46 8 719 0000
Email: magnus.westerlund@ericsson.com
Thomas Zeng
Nextwave Wireless, Inc.
12670 High Bluff Drive
San Diego, CA 92130
United States of America
Phone: +1 858 480 3100
Email: thomas.zeng@gmail.comThat's the whole RFC, bestie 🌈✨ RTSP is officially fully explained, and you ate this entire spec 💅🎀
📦 where this page comes from
- ietf: rfc7825 2016-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms