One document matched: draft-ietf-mmusic-ice-tcp-15.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc='yes'?>
<?rfc tocdepth='2'?>
<?rfc symrefs="yes"?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc category="std" docName="draft-ietf-mmusic-ice-tcp-15" ipr="pre5378Trust200902">
<front>
<title abbrev="ICE TCP">TCP Candidates with Interactive Connectivity
Establishment (ICE)</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>Skype</organization>
<address>
<email>jdrosen@jdrosen.net</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author fullname="Ari Keranen" initials="A." surname="Keranen">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>02420 Jorvas</city>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<author fullname="Bruce B. Lowekamp" initials="B.B." surname="Lowekamp">
<organization>Skype</organization>
<address>
<email>bbl@lowekamp.net</email>
</address>
</author>
<author fullname="Adam Roach" initials="A." surname="Roach">
<organization abbrev="Tekelec">Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas, TX 75252</city>
<country>US</country>
</postal>
<email>adam@nostrum.com</email>
</address>
</author>
<date day="20" month="September" year="2011"/>
<area>RAI</area>
<workgroup>MMUSIC</workgroup>
<keyword>ICE</keyword>
<keyword>TCP</keyword>
<keyword>NAT</keyword>
<keyword>NAT traversal</keyword>
<abstract>
<t> Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation. ICE works by providing a set
of candidate transport addresses for each media stream, which are then
validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN). ICE provides a general framework for
describing candidates, but only defines UDP-based transport protocols.
This specification extends ICE to TCP-based media, including the ability
to offer a mix of TCP and UDP-based candidates for a single stream.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/>
defines a mechanism for NAT traversal for multimedia communication
protocols based on the offer/answer model <xref target="RFC3264"/> of
session negotiation. ICE works by providing a set of candidate transport
addresses for each media stream, which are then validated with
peer-to-peer connectivity checks based on Session Traversal Utilities for
NAT (STUN) <xref target="RFC5389"/>. However, ICE only defines procedures
for UDP-based transport protocols. </t>
<t> There are many reasons why ICE support for TCP is important. Firstly,
there are media protocols that only run over TCP. Such protocols are
used, for example, for screen sharing and instant messaging <xref target="RFC4975"/>. For these protocols to work in the presence of NAT,
unless they define their own NAT traversal mechanisms, ICE support for
TCP is needed. In addition, RTP can also run over TCP <xref target="RFC4571"/>. Typically, it is preferable to run RTP over UDP, and
not TCP. However, in a variety of network environments, overly
restrictive NAT and firewall devices prevent UDP-based communications
altogether, but general TCP-based communications are permitted. In such
environments, sending RTP over TCP, and thus establishing the media
session, may be preferable to having it fail altogether. With this
specification, agents can gather UDP and TCP candidates for a media
stream, list the UDP ones with higher priority, and then only use the
TCP-based ones if the UDP ones fail. This provides a fallback mechanism
that allows multimedia communications to be highly reliable. </t>
<t> The usage of RTP over TCP is particularly useful when combined with
Traversal Using Relays around NAT (TURN) <xref target="RFC5766"/>. In
this case, one of the agents would connect to its TURN server using TCP,
and obtain a TCP-based relayed candidate. It would offer this to its peer
agent as a candidate. The answerer would initiate a TCP connection
towards the TURN server. When that connection is established, media can
flow over the connections, through the TURN server. The benefit of this
usage is that it only requires the agents to make outbound TCP
connections to a server on the public network. This kind of operation is
broadly interoperable through NAT and firewall devices. Since it is a
goal of ICE and this extension to provide highly reliable communications
that "just works" in as broad set of network deployments as possible,
this use case is particularly important. </t>
<t> This specification extends ICE by defining its usage with TCP
candidates. It also defines how ICE can be used with RTP and Secure RTP
(SRTP) to provide both TCP and UDP candidates. This specification does so
by following the outline of ICE itself, and calling out the additions and
changes necessary in each section of ICE to support TCP candidates. </t>
<t> It should be noted that since TCP NAT traversal is more complicated
than with UDP, ICE TCP is not in general as efficient as UDP-based
ICE. Discussion about this topic can be found in <xref target="limitations"/>. </t>
</section>
<section title="Terminology">
<t> 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 <xref target="RFC2119"/>. </t>
<t> This document uses the same terminology as ICE (see Section 3 of
<xref target="RFC5245"/>). </t>
</section>
<section title="Overview of Operation">
<t> The usage of ICE with TCP is relatively straightforward. The main
area of specification is around how and when connections are opened, and
how those connections relate to candidate pairs. </t>
<t> When the agents perform address allocations to gather TCP-based
candidates, three types of candidates can be obtained. These are active
candidates, passive candidates, and simultaneous-open (S-O)
candidates. An active candidate is one for which the agent will attempt
to open an outbound connection, but will not receive incoming connection
requests. A passive candidate is one for which the agent will receive
incoming connection attempts, but not attempt a connection. S-O candidate
is one for which the agent will attempt to open a connection
simultaneously with its peer. </t>
<t> When gathering candidates from a host interface, the agent typically
obtains active, passive, and S-O candidates. Similarly, one can use
different techniques for obtaining, e.g., server reflexive, NAT-assisted,
tunneled, or relayed candidates of these three types (see <xref target="cand-collection"/>). Connections to servers used for relayed and
server reflexive candidates are kept open during ICE processing. </t>
<t> When encoding these candidates into offers and answers, the type of
the candidate is signaled. In the case of active candidates, an IP
address and port is present, but the port is meaningless, as it is
ignored by the peer. As a consequence, active candidates do not need to
be physically allocated at the time of address gathering. Rather, the
physical allocations, which occur as a consequence of a connection
attempt, occur at the time of the connectivity checks. </t>
<t> When the candidates are paired together, active candidates are always
paired with passive, and S-O candidates with each other. When a
connectivity check is to be made on a candidate pair, each agent
determines whether it is to make a connection attempt for this pair. </t>
<t> The actual process of generating connectivity checks, managing the
state of the check list, and updating the Valid list, work identically
for TCP as they do for UDP. </t>
<t> ICE requires an agent to demultiplex STUN and application layer
traffic, since they appear on the same port. This demultiplexing is
described in <xref target="RFC5245"/>, and is done using the magic cookie
and other fields of the message. Stream-oriented transports introduce
another wrinkle, since they require a way to frame the connection so that
the application and STUN packets can be extracted in order to determine
which is which. For this reason, TCP media streams utilizing ICE use the
basic framing provided in RFC 4571 <xref target="RFC4571"/>, even if the
application layer protocol is not RTP. </t>
<t> When TLS or DTLS is used, they are also run over the RFC 4571 framing
shim, while STUN runs outside of the (D)TLS connection. The resulting ICE
TCP protocol stack is shown in <xref target="fig-icetcp"/>; with (D)TLS
on the left side and without it on the right side. </t>
<figure anchor="fig-icetcp" title="ICE TCP Stack With and Without (D)TLS">
<artwork align="center"><![CDATA[
+----------+
| |
| App |
+----------+----------+ +----------+----------+
| | | | | |
| STUN | (D)TLS | | STUN | App |
+----------+----------+ +----------+----------+
| | | |
| RFC 4571 | | RFC 4571 |
+---------------------+ +---------------------+
| | | |
| TCP | | TCP |
+---------------------+ +---------------------+
| | | |
| IP | | IP |
+---------------------+ +---------------------+
]]></artwork>
</figure>
<t> The implication of this is that, for any media stream protected by
(D)TLS, the agent will first run ICE procedures, exchanging STUN
messages. Then, once ICE completes, (D)TLS procedures begin. ICE and
(D)TLS are thus "peers" in the protocol stack. The STUN messages are not
sent over the (D)TLS connection, even ones sent for the purposes of
keepalive in the middle of the media session. </t>
<t> When an updated offer is generated by the controlling endpoint, the
Session Description Protocol (SDP) extensions for connection oriented
media <xref target="RFC4145"/> are used to signal that an existing
connection should be used, rather than opening a new one. </t>
</section>
<section anchor="sec-sending-init-offer" title="Sending the Initial Offer">
<t> For offerers making use of ICE for TCP streams, the procedures below
are used. Main differences compared to UDP candidates are the new methods
for gathering candidates, how TCP candidates are prioritized, and how
they are encoded in the SDP offer and answer. </t>
<section anchor="sec-gather" title="Gathering Candidates">
<t> Providers of real-time communications services may decide that it
is preferable to have no media at all than it is to have media over
TCP. To allow for choice, it is RECOMMENDED that agents be configurable
with whether they obtain TCP candidates for real time media. </t>
<t>
<list style="empty"> <t> Having it be configurable, and then
configuring it to be off, is far better than not having the capability
at all. An important goal of this specification is to provide a single
mechanism that can be used across all types of endpoints. As such, it
is preferable to account for provider and network variation through
configuration, instead of hard-coded limitations in an
implementation. Besides, network characteristics and connectivity
assumptions can, and will change over time. Just because an agent is
communicating with a server on the public network today, doesn't mean
that it won't need to communicate with one behind a NAT tomorrow. Just
because an agent is behind a NAT with endpoint-independent mapping
today, doesn't mean that tomorrow they won't pick up their agent and
take it to a public network access point where there is a NAT with
address and port-dependent mapping properties, or one that only allows
outbound TCP. The way to handle these cases and build a reliable system
is for agents to implement a diverse set of techniques for allocating
addresses, so that at least one of them is almost certainly going to
work in any situation. Implementors should consider very carefully any
assumptions that they make about deployments before electing not to
implement one of the mechanisms for address allocation. In particular,
implementors should consider whether the elements in the system may be
mobile, and connect through different networks with different
connectivity. They should also consider whether endpoints which are
under their control, in terms of location and network connectivity,
would always be under their control. In environments where mobility and
user control are possible, a multiplicity of techniques is essential
for reliability. </t>
</list> </t>
<t> First, agents SHOULD obtain host candidates as described in <xref target="host-candidates"/>. Then, each agent SHOULD "obtain" (allocate
a placeholder for) an active host candidate for each component of each
TCP-capable media stream on each interface that the host has. The agent
does not have to yet actually allocate a port for these candidates, but
they are used for the creation of the check lists. </t>
<t> The agent SHOULD then obtain server reflexive, NAT-assisted, and/or
UDP-tunneled candidates (see <xref target="server-reflexive"/>, <xref target="nat-assisted"/>, and <xref target="udp-tunneled"/>). The
mechanisms for establishing these candidates and the number of
candidates to collect vary from technique to technique. These
considerations are discussed in the relevant sections. </t>
<t> Next, the agents SHOULD obtain passive (and possibly S-O) relayed
candidates for each component as described in <xref target="relayed-cands"/>. Each agent SHOULD also allocate a placeholder
for an active relayed candidate for each component of each TCP-capable
media stream. </t>
<t> It is highly recommended that a host obtains at least one set of
host and one set of relayed candidates. Obtaining additional
candidates will increase the chance of successfully creating a direct
connection. </t>
<t> Once the candidates have been obtained, the agent MUST keep the TCP
connections open until ICE processing has completed. See <xref target="sec-impl"/> for important implementation guidelines. </t>
<t> If a media stream is UDP-based (such as RTP), an agent MAY use an
additional host TCP candidate to request a UDP-based candidate from a
TURN server (or some other relay with similar functionality). Usage of
such UDP candidates follows the procedures defined in ICE for UDP
candidates. </t>
<t> Like its UDP counterparts, TCP-based STUN transactions are paced
out at one every Ta seconds. This pacing refers strictly to STUN
transactions (both Binding and Allocate requests). If performance of
the transaction requires establishment of a TCP connection, then the
connection gets opened when the transaction is performed. </t>
</section>
<section anchor="priority" title="Prioritization">
<t> The transport protocol itself is a criteria for choosing one
candidate over another. If a particular media stream can run over UDP
or TCP, the UDP candidates might be preferred over the TCP candidates.
This allows ICE to use the lower latency UDP connectivity if it exists,
but fallback to TCP if UDP doesn't work. </t>
<?rfc needLines="3"?>
<t> In Section 4.1.2.1. of <xref target="RFC5245"/> a recommended
formula for UDP ICE candidate prioritization is defined. For the TCP
candidates the same formula and candidate type preferences SHOULD be
used and the RECOMMENDED type preferences for the new candidate types
defined in this document (see <xref target="cand-collection"/>) are 105
for NAT-assisted candidates and 75 for UDP-tunneled candidates. </t>
<t> When both UDP and TCP candidates are offered for the same media
stream, and one transport protocol should be preferred over the other,
the type preferences for the preferred transport protocol candidates
SHOULD be increased and/or the type preferences for the other transport
protocol candidates SHOULD be decreased. How much the values should be
increased or decreased depends on whether it is more important to
choose certain transport protocol or certain candidate type. If the
candidate type is more important (e.g., even if UDP is preferred, TCP
host candidates are preferred over UDP server reflexive candidates)
changing type preference values by one for the other transport protocol
candidates is enough. On the other hand, if the transport protocol is
more important (e.g., any UDP candidate is preferred over any TCP
candidate) all the preferred transport protocol candidates SHOULD have
type preference higher than the other transport protocol candidates.
However, it is RECOMMENDED that the relayed candidates are still
preferred lower than the other candidate types. For RTP-based media
streams, it is RECOMMENDED that UDP candidates are preferred over TCP
candidates. </t>
<t> With TCP candidates the local preference part of the recommended
priority formula is updated to include also the directionality (active,
passive, or simultaneous-open) of the TCP connection. The RECOMMENDED
local preference is then defined as:
<figure>
<artwork><![CDATA[
local preference = (2^13) * direction-pref + other-pref
]]></artwork>
</figure>
The direction-pref MUST be between 0 and 7 (both inclusive), with 7
being the most preferred. The other-pref MUST be between 0 and 8191
(both inclusive), with 8191 being the most preferred. It is
RECOMMENDED that the host, UDP-tunneled, and relayed TCP candidates
have the direction-pref assigned as follows: 6 for active, 4 for
passive, and 2 for S-O. For the NAT-assisted and server reflexive
candidates the RECOMMENDED values are: 6 for S-O, 4 for active, and 2
for passive. </t>
<t>
<list style="empty"> <t> The preference priorities listed here are
simply recommendations that try to strike a balance between success
probability and resulting path's efficiency. Depending on the scenario
where ICE TCP is used, different values may be appropriate. For
example, if the overhead of a UDP tunnel is not an issue, those
candidates should be prioritized higher since they are likely to have a
high success probability. Also, simultaneous-open is prioritized higher
than active and passive candidates for NAT-assisted and server
reflexive candidates since if TCP S-O is supported by the operating
systems of both endpoints, it should work at least as well as the
act-pass approach. If an implementation is uncertain whether S-O
candidates are supported, it may be reasonable to prioritize them
lower. For host, UDP-tunneled, and relayed candidates the S-O
candidates are prioritized lower than active and passive since act-pass
candidates should work with them at least as well as the S-O
candidates. </t> </list> </t>
<t> If any two candidates have the same type-preference and
direction-pref, they MUST have a unique other-pref. With this
specification, this usually only happens with multi-homed hosts, in
which case other-pref is the preference for the particular IP address
from which the candidate was obtained. When there is only a single IP
address, this value SHOULD be set to the maximum allowed value
(8191). </t>
</section>
<section anchor="default-cands" title="Choosing Default Candidates">
<t> The default candidate is chosen primarily based on the likelihood
of it working with a non-ICE peer. When media streams supporting mixed
modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, for
real-time streams (such as RTP), the default candidates be UDP-based.
However, the default SHOULD NOT be a simultaneous-open candidate. </t>
<t> If a media stream is inherently TCP-based, it is RECOMMENDED for an
offering full agent to select an active candidate as the default
candidate and use <xref target="RFC4145"/> "setup" attribute value
"active". This increases the chances for a successful NAT traversal
even without ICE support if the agent is behind a NAT and the peer is
not. For the same reason, for a lite agent, it is RECOMMENDED to use a
passive candidate and "setup" attribute value "passive" in the
offer. </t>
</section>
<section anchor="lite-reqs" title="Lite Implementation Requirements">
<t> If an offerer meets the criteria for the lite mode as described in
Appendix A of <xref target="RFC5245"/> (i.e., it will always have a
public, globally unique IP address), it MAY use the lite mode of ICE
also for TCP candidates. In the lite mode, for the TCP candidates,
only passive host candidates are gathered; unless active candidates are
needed as the default candidates. Otherwise the procedures described
for lite mode in <xref target="RFC5245"/> apply also to TCP
candidates. If UDP and TCP candidates are mixed in a media stream, the
mode (lite or full) applies to both UDP and TCP candidates. </t>
</section>
<section anchor="tcp-sdp-encoding" title="Encoding the SDP">
<t> TCP-based candidates are encoded into a=candidate lines like the
UDP candidates described in <xref target="RFC5245"/>. However, the
transport protocol (i.e., value of the transport-extension token
defined in <xref target="RFC5245"/> Section 15.1) is set to "TCP" and
the connection type (active, passive, or S-O) is encoded using a new
extension attribute. With TCP candidates, the candidate-attribute
syntax with Augmented BNF <xref target="RFC5234"/> is then: </t>
<figure>
<artwork align="center"><![CDATA[
candidate-attribute = "candidate" ":" foundation SP component-id SP
"TCP" SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
SP tcp-type-ext
*(SP extension-att-name SP
extension-att-value)
tcp-type-ext = "tcptype" SP tcp-type
tcp-type = "act" / "pass" / "so"
]]></artwork>
</figure>
<t> The connection-address encoded into the candidate attribute for
active candidates MUST be set to the IP address that will be used for
the attempt, but the port(s) MUST be set to 9 (i.e., Discard). For
active relayed candidates, the value for connection-address MUST be
identical to the IP address of a passive or simultaneous-open candidate
from the same relay server. </t>
<t> If the default candidate is TCP-based, the agent MUST include the
a=setup and a=connection attributes from RFC 4145 <xref target="RFC4145"/>, following the procedures defined there as if ICE
was not in use. In particular, if an agent is the answerer, the a=setup
attribute MUST meet the constraints in RFC 4145 based on the value in
the offer. </t>
<t> If an agent is utilizing SRTP <xref target="RFC3711"/>, it MAY
include a mix of UDP and TCP candidates. If ICE selects a TCP candidate
pair, the agent MUST still utilize SRTP, but run it over the connection
established by ICE. The alternative, RTP over TLS, MUST NOT be
used. This allows for the higher layer protocols (the security
handshakes and media transport) to be independent of the underlying
transport protocol. In the case of DTLS-SRTP <xref target="RFC5764"/>,
the directionality attributes (a=setup) are utilized strictly to
determine the direction of the DTLS handshake. Directionality of the
TCP connection establishment are determined by the ICE attributes and
procedures defined here. </t>
<t> If an agent is securing non-RTP media over TCP/TLS, the SDP MUST be
constructed as described in RFC 4572 <xref target="RFC4572"/>. The
directionality attributes (a=setup) are utilized strictly to determine
the direction of the TLS handshake. Directionality of the TCP
connection establishment are determined by the ICE attributes and
procedures defined here. </t>
<t> Examples of SDP offers and answers with ICE TCP extensions are
shown in <xref target="sdp-examples"/>.</t>
</section>
</section>
<section anchor="cand-collection" title="Candidate Collection Techniques">
<t> The following sections discuss a number of techniques that can be
used to obtain candidates for use with ICE TCP. It is important to note
that this list is not intended to be exhaustive, nor is implementation of
any specific technique beyond host candidates (<xref target="host-candidates"/>) considered mandatory. </t>
<t> Implementors are encouraged to implement as many of the following
techniques from the following list as is practical, as well as to explore
additional NAT-traversal techniques beyond those discussed in this
document. However, to get a reasonable success ratio, one SHOULD
implement at least one relayed technique (e.g., TURN) and one technique
for discovering the address given for the host by a NAT (e.g.,
STUN). </t>
<t> To increase the success probability with the techniques described
below and to aid with transition to IPv6, implementors SHOULD take
particular care to include both IPv4 and IPv6 candidates as part of the
process of gathering candidates. If the local network or host does not
support IPv6 addressing, then clients SHOULD make use of other
techniques, e.g., TURN-IPv6 <xref target="RFC6156"/>, Teredo <xref target="RFC4380"/> or SOCKS IPv4-IPv6 gatewaying <xref target="RFC3089"/>, for obtaining IPv6 candidates. </t>
<t> While implementations SHOULD support as many techniques as feasible,
they SHOULD also consider which of them to use if multiple options are
available. Since different candidates are paired with each other,
offering a large amount of candidates results in a large checklist and
potentially long lasting connectivity checks. For example, using multiple
NAT-assisted techniques with the same NAT usually results only in
redundant candidates. Similarly, out of multiple different UDP tunneling
or relaying techniques using just one is often enough. </t>
<section anchor="host-candidates" title="Host Candidates">
<t> Host candidates are the most simple candidates since they only
require opening TCP sockets on the host's interfaces and
sending/receiving connectivity checks from them. However, if the hosts
are behind different NATs, host candidates usually fail to work. On the
other hand, if there are no NATs between the hosts, host candidates are
the most efficient method since they require no additional NAT
traversal protocols or techniques. </t>
<t> For each TCP-capable media stream the agent wishes to use
(including ones, like RTP, which can either be UDP or TCP), the agent
SHOULD obtain two host candidates (each on a different port) for each
component of the media stream on each interface that the host has - one
for the simultaneous-open, and one for the passive candidate. If an
agent is not capable of acting in one of these modes it would omit
those candidates. </t>
</section>
<section anchor="server-reflexive" title="Server Reflexive Candidates">
<t> Server reflexive techniques aim to discover the address a NAT has
given for the host by asking that from a server on the other side of
the NAT and then creating proper bindings (unless such already exist)
on the NATs with connectivity checks sent between the hosts. Success of
these techniques depends on the NATs' mapping and filtering behavior
<xref target="RFC5382"/> and also whether the NATs and hosts support
the TCP simultaneous-open technique. </t>
<t> Obtaining server reflexive passive candidates may require
initiating connections from host's passive candidates; see <xref target="sec-impl"/> for implementation details on this. Server
reflexive active candidates can be derived from passive or S-O
candidates by using the same IP address as a passive or S-O server
reflexive candidate from the same interface has. It is useful to obtain
both server reflexive passive and S-O candidates since it depends on
the hosts and NATs which one actually works better. Furthermore, some
techniques (e.g., TURN relaying) require knowing the IP address of the
peer's active candidates beforehand, so also active server reflexive
candidates are needed for such techniques to function properly. </t>
<t> A widely used protocol for obtaining server reflexive candidates is
STUN, whose TCP-specific behavior is described in <xref target="RFC5389"/> Section 7.2.2. </t>
</section>
<section anchor="nat-assisted" title="NAT-Assisted Candidates">
<t> NAT-assisted techniques communicate with the NATs directly and this
way discover the address NAT has given to the host and also create
proper bindings on the NATs. The benefit of these techniques over the
server reflexive techniques is that the NATs can adjust their mapping
and filtering behavior so that connections can be successfully
created. A downside of NAT-assisted techniques is that they commonly
allow communicating only with a NAT that is in the same subnet as the
host and thus often fail in scenarios with multiple layers of
NATs. These techniques also rely on NATs supporting the specific
protocols and that the NATs allow the users to modify their
behavior. </t>
<t> These candidates are encoded in the ICE offer and answer like the
server reflexive candidates but they (commonly) use a higher priority
(as described in <xref target="priority"/>) and hence are tested before
the server reflexive candidates. </t>
<t> Currently, the UPnP forum's Internet Gateway Device (IGD) protocol
<xref target="UPnP-IGD"/> and the NAT Port Mapping Protocol (PMP) <xref target="I-D.cheshire-nat-pmp"/> are widely supported NAT-assisted
techniques. Other known protocols include Port Control Protocol (PCP)
<xref target="I-D.ietf-pcp-base"/>, SOCKS <xref target="RFC1928"/>,
Realm Specific IP (RSIP) <xref target="RFC3103"/>, and SIMCO <xref target="RFC4540"/>. Also, MIDCOM MIB <xref target="RFC5190"/> defines
an SNMP-based mechanism for controlling NATs. </t>
</section>
<section anchor="udp-tunneled" title="UDP-Tunneled Candidates">
<t> UDP-tunneled NAT traversal techniques utilize the fact that UDP NAT
traversal is simpler and more efficient than TCP NAT traversal. With
these techniques, the TCP packets (or possibly complete IP packets) are
encapsulated in UDP packets. Because of the encapsulation these
techniques increase the overhead for the connection and may require
support from both of the endpoints, but on the other hand UDP tunneling
commonly results in reliable and fairly simple TCP NAT traversal. </t>
<t> UDP-tunneled candidates can be encoded in the ICE offer and answer
either as relayed or server reflexive candidates, depending on whether
the tunneling protocol utilizes a relay between the hosts. The
UDP-tunneled candidates may appear to applications as host candidates
from a local pseudo-interface. Treating these candidates as host
candidates results in incorrect prioritization and possibly non-optimal
candidate selection. Implementations may attempt to detect
pseudo-interfaces, e.g., from the address prefix of the interface, but
detection details vary from technique to technique. </t>
<t> For example, the Teredo protocol <xref target="RFC4380"/> <xref target="RFC6081"/> provides automatic UDP tunneling and IPv6
interworking. The Teredo UDP tunnel is visible to the host application
as an IPv6 address and thus Teredo candidates are encoded as IPv6
addresses. </t>
</section>
<section anchor="relayed-cands" title="Relayed Candidates">
<t> Relaying packets through a relay server is often the NAT traversal
technique that has the highest success probability: communicating via a
relay that is in the public Internet looks like normal client-server
communication for the NATs and that is supported in practice by all
existing NATs, regardless of their filtering and mapping behavior.
However, using a relay has several drawbacks, e.g., it usually results
in a sub-optimal path for the packets, the relay needs to exist and it
needs to be discovered, the relay is a possible single point of
failure, relaying consumes potentially a lot of resources of the relay
server, etc. Therefore, relaying is often used as the last resort when
no direct path can be created with other NAT traversal techniques. </t>
<t> With relayed candidates the host commonly needs to obtain only a
passive candidate since any of the peer's server reflexive (and
NAT-assisted if the peer can communicate with the outermost NAT) active
candidates should work with the passive relayed candidate. However, if
the relay is behind a NAT or a firewall, using also active and S-O
candidates will increase success probability. </t>
<t> Relaying protocols capable of relaying TCP connections include TURN
TCP <xref target="RFC6062"/> and SOCKS <xref target="RFC1928"/> (which
can also be used for IPv4-IPv6 gatewaying <xref target="RFC3089"/>). It
is also possible to use, e.g., an SSH <xref target="RFC4251"/> tunnel
as a relayed candidate if a suitable server is available and the server
permits this. </t>
</section>
</section>
<section title="Receiving the Initial Offer and Answer">
<t> Handling an ICE offer with TCP candidates works in a similar way as
with UDP candidates. First, ICE support is verified (including the check
for ice-mismatch described in Section 5.1 of <xref target="RFC5245"/>)
and agent roles are determined. Candidates are gathered using the
techniques described in <xref target="cand-collection"/> and prioritized
as described in <xref target="priority"/>. Default candidates are
selected taking into account considerations of <xref target="default-cands"/>. The SDP answer is encoded as in Section 4.3 of
<xref target="RFC5245"/> with the exception of TCP candidates whose
encoding was described in <xref target="tcp-sdp-encoding"/>. </t>
<t> When the offerer receives the initial answer, it also verifies ICE
support and determines its role. If both of the agents use lite
implementations, the offerer takes the controlling role and uses the
procedures defined in <xref target="RFC4145"/> to select the most
preferred candidate pair with a new offer. </t>
<section title="Considerations with Two Lite Agents">
<t> If both agents are using the lite mode, and if the offerer uses
a=setup:active attribute <xref target="RFC4145"/> in the new offer, the
offerer MAY initiate the TCP connection on the selected pair in
parallel with the new offer to speedup the connection
establishment. Consequently, the answerer MUST still accept incoming
TCP connections to any of the passive candidates it listed in the
answer, from any of the IP addresses the offerer listed in the initial
offer. </t>
<t> If the answerer receives the new offer matching to the candidate
pair where connection was already created in parallel with the new
offer, it MUST accept the offer and respond to it while keeping the
already created connection. If the connection that was created in
parallel with the new offer does not match to the candidate pair in the
new offer, the connection MUST be closed and ICE restart SHOULD be
performed. </t>
<?rfc needLines="3"?>
<t> Since the connection endpoints are not authenticated using the
connectivity checks in the scenario where both agents use the lite
mode, unless media-level security (e.g., TLS) is used, it is
RECOMMENDED to use the full mode instead. For more lite vs. full
implementation considerations, see Appendix A of <xref target="RFC5245"/>. </t>
</section>
<section title="Forming the Check Lists">
<t> As with UDP, checklists are formed only by full ICE
implementations. When forming candidate pairs, the following types of
TCP candidates can be paired with each other: </t>
<figure>
<artwork><![CDATA[
Local Remote
Candidate Candidate
----------------------------
tcp-so tcp-so
tcp-act tcp-pass
tcp-pass tcp-act
]]></artwork>
</figure>
<t> When the agent prunes the check list, it MUST also remove any pair
for which the local candidate is a passive TCP candidate. With pruning,
the NAT-assisted candidates are treated like server reflexive
candidates if the base is used also as a host candidate. </t>
<t> The remainder of check list processing works like in the UDP
case. </t>
</section>
</section>
<section title="Connectivity Checks">
<t> The TCP connectivity checks, like with UDP, are generated only by
full implementations. The TCP candidate pairs are in the same checklist
with the UDP candidate pairs and they are scheduled for connectivity
checks, as described in Section 5.8 in <xref target="RFC5245"/>, based on
the priority order. </t>
<section title="STUN Client Procedures">
<t> When an agent wants to send a TCP-based connectivity check, it
first opens a TCP connection, if none yet exists, for the 5-tuple
defined by the candidate pair for which the check is to be sent. This
connection is opened from the local candidate of the pair to the remote
candidate of the pair. If the local candidate is tcp-act, the agent
MUST open a connection from the interface associated with that local
candidate. This connection SHOULD be opened from an unallocated
port. For host candidates, this is readily done by connecting from the
local candidate's interface. For relayed, NAT-assisted, and
UDP-tunneled candidates, the agent may need to use additional
procedures specific to the protocol. </t>
<t> Once the connection is established, the agent MUST utilize the shim
defined in RFC 4571 <xref target="RFC4571"/> for the duration this
connection remains open. The STUN Binding requests and responses are
sent on top of this shim, so that the length field defined in RFC 4571
precedes each STUN message. If TLS or DTLS-SRTP is to be utilized for
the media session, the TLS or DTLS-SRTP handshakes will take place on
top of this shim as well. However, they only start once ICE processing
has completed. In essence, the TLS or DTLS-SRTP handshakes are
considered a part of the media protocol. STUN is never run within the
TLS or DTLS-SRTP session. </t>
<t> If the TCP connection cannot be established, the check is
considered to have failed, and a full-mode agent MUST update
the pair state to Failed in the check list. See Section 7.2.2
in <xref target="RFC5389"/> for more details on STUN over
TCP.</t>
<t> Once the connection is established, client procedures are identical
to those for UDP candidates. However, retransmissions of the STUN
connectivity check messages are not needed, since TCP takes care of
reliable delivery of the messages. Note also that STUN responses
received on an active TCP candidate will typically produce a peer
reflexive candidate. If the response to the first connectivity check on
the established TCP connection is something other than a STUN message,
the remote candidate address apparently was not one of the peer's
addresses and the agent SHOULD close the connection and consider all
pairs with that remote candidate as failed. </t>
</section>
<section title="STUN Server Procedures">
<t> An ICE TCP agent, full or lite, MUST be prepared to receive
incoming TCP connection requests on the base of any TCP candidate that
is simultaneous-open or passive. When the connection request is
received, the agent MUST accept it. The agent MUST utilize the framing
defined in RFC 4571 <xref target="RFC4571"/> for the lifetime of this
connection. Due to this framing, the agent will receive data in
discrete frames. Each frame could be media (such as RTP or SRTP), TLS,
DTLS, or STUN packets. The STUN packets are extracted as described in
<xref target="sec-recvmedia"/>. </t>
<t> Once the connection is established, STUN server procedures are
identical to those for UDP candidates. Note that STUN requests received
on a passive TCP candidate will typically produce a remote peer
reflexive candidate. </t>
</section>
</section>
<section title="Concluding ICE Processing">
<t> If there are TCP candidates for a media stream, a controlling agent
MUST use the regular selection algorithm. </t>
<t> When ICE processing for a media stream completes, each agent SHOULD
close all TCP connections (that were opened due to this ICE session)
except the ones between the candidate pairs selected by ICE. </t>
<t>
<list style="empty">
<t> These two rules are related; the closure of
connection on completion of ICE implies that a regular selection
algorithm has to be used. This is because aggressive selection might
cause transient pairs to be selected. Once such a pair was selected, the
agents would close the other connections, one of which may be about to be
selected as a better choice. This race condition may result in TCP
connections being accidentally closed for the pair that ICE
selects. </t>
</list>
</t>
</section>
<section title="Subsequent Offer/Answer Exchanges">
<section title="ICE Restarts">
<t> If an ICE restart occurs for a media stream with TCP candidate
pairs that have been selected by ICE, the agents MUST NOT close the
connections after the restart. In the offer or answer that causes the
restart, an agent MAY include a simultaneous-open candidate whose
transport address matches the previously selected candidate. If both
agents do this, the result will be a simultaneous-open candidate pair
matching an existing TCP connection. In this case, the agents MUST NOT
attempt to open a new connection (or start new TLS or DTLS-SRTP
procedures). Instead, that existing connection is reused and STUN
checks are performed. </t>
<t> Once the restart completes, if the selected pair does not match the
previously selected pair, the TCP connection for the previously
selected pair SHOULD be closed by the agent. </t>
</section>
</section>
<section title="Media Handling">
<section title="Sending Media">
<t> When sending media, if the selected candidate pair matches an
existing TCP connection, that connection MUST be used for sending
media. </t>
<t> The framing defined in RFC 4571 MUST be used when sending
media. For media streams that are not RTP-based and do not normally use
RFC 4571, the agent treats the media stream as a byte stream, and
assumes that it has its own framing of some sort, if needed. It then
takes an arbitrary number of bytes from the byte stream, and places
that as a payload in the RFC 4571 frames, including the length. Next,
the sender checks to see if the resulting set of bytes would be viewed
as a STUN packet based on the rules in Sections 6 and 8 of <xref target="RFC5389"/>. This includes a check on the most significant two
bits, the magic cookie, the length, and the fingerprint. If, based on
those rules, the bytes would be viewed as a STUN message, the sender
MUST utilize a different number of bytes so that the length checks will
fail. Though it is normally highly unlikely that an arbitrary number of
bytes from a byte stream would resemble a STUN packet based on all of
the checks, it can happen if the content of the application stream
happens to contain a STUN message (for example, a file transfer of logs
from a client which includes STUN messages). </t>
<t> If TLS or DTLS-SRTP procedures are being utilized to protect the
media stream, those procedures start at the point that media is
permitted to flow, as defined in the ICE specification <xref target="RFC5245"/>. The TLS or DTLS-SRTP handshakes occur on top of the
RFC 4571 shim, and are considered part of the media stream for purposes
of this specification. </t>
</section>
<section anchor="sec-recvmedia" title="Receiving Media">
<t> The framing defined in RFC 4571 MUST be used when receiving
media. For media streams that are not RTP-based and do not normally use
RFC 4571, the agent extracts the payload of each RFC 4571 frame, and
determines if it is a STUN or an application layer data based on the
procedures in ICE <xref target="RFC5245"/>. If media is being protected
with DTLS-SRTP, the DTLS, RTP and STUN packets are demultiplexed as
described in Section 5.1.2 <xref target="RFC5764"/>. </t>
<t> For non-STUN data, the agent appends this to the ongoing byte
stream collected from the frames. It then parses the byte stream as if
it had been directly received over the TCP connection. This allows for
ICE TCP to work without regard to the framing mechanism used by the
application layer protocol. </t>
</section>
</section>
<section title="Connection Management">
<section title="Connections Formed During Connectivity Checks">
<t> Once a TCP or TCP/TLS connection is opened by ICE for the purpose
of connectivity checks, its life cycle depends on how it is used. If
that candidate pair is selected by ICE for usage for media, an agent
SHOULD keep the connection open until: <list style="symbols">
<t>The session terminates</t>
<t>The media stream is removed</t>
<t>An ICE restart takes place, resulting in the selection of a
different candidate pair. </t>
</list>
In these cases, the agent SHOULD close the connection when that event
occurs. This applies to both agents in a session, in which case
usually one of the agents will end up closing the connection
first. </t>
<t> If a connection has been selected by ICE, an agent MAY close it
anyway. As described in the next paragraph, this will cause it to be
reopened almost immediately, and in the interim media cannot be
sent. Consequently, such closures have a negative effect and are NOT
RECOMMENDED. However, there may be cases where an agent needs to close
a connection for some reason. </t>
<t> If an agent needs to send media on the selected candidate pair, and
its TCP connection has closed, either on purpose or due to some error,
then: <list style="symbols">
<t> If the agent's local candidate is tcp-act or tcp-so, it MUST
reopen a connection to the remote candidate of the selected
pair. </t>
<t> If the agent's local candidate is tcp-pass, the agent MUST
await an incoming connection request, and consequently, will not be
able to send media until it has been opened. </t>
</list>
If the TCP connection is established, the framing of RFC 4571 is
utilized. If the agent opened the connection, and is a full agent, it
MUST send a STUN connectivity check. An agent MUST be prepared to
receive a connectivity check over a connection it opened or accepted
(note that this is true in general; ICE requires that an agent be
prepared to receive a connectivity check at any time, even after ICE
processing completes). If a full agent receives a connectivity check
after re-establishment of the connection, it MUST generate a triggered
check over that connection in response if it has not already sent a
check. Once an agent has sent a check and received a successful
response, the connection is considered Valid and media can be sent
(which includes a TLS or DTLS-SRTP session resumption or restart). </t>
<t> If the TCP connection cannot be established, the controlling agent
SHOULD restart ICE for this media stream. This will happen in cases
where one of the agents is behind a NAT with connection-dependent
mapping properties <xref target="RFC5382"/>. </t>
</section>
<section title="Connections Formed for Gathering Candidates">
<t> If the agent opened a connection to a STUN server, or another
similar server, for the purposes of gathering a server reflexive
candidate, that connection SHOULD be closed by the client once ICE
processing has completed. This happens irregardless of whether the
candidate learned from the server was selected by ICE. </t>
<t> If the agent opened a connection to a TURN server for the purposes
of gathering a relayed candidate, that connection MUST be kept open by
the client for the duration of the media session if a relayed candidate
from the TURN server was selected by ICE. Otherwise, the connection to
the TURN server SHOULD be closed once ICE processing completes. </t>
<t> If, despite efforts of the client, a TCP connection to a TURN
server fails during the lifetime of the media session utilizing a
transport address allocated by that server, the client SHOULD reconnect
to the TURN server, obtain a new allocation, and restart ICE for that
media stream. Similar measures SHOULD apply also to other type
of relaying servers. </t>
</section>
</section>
<section title="Security Considerations">
<t> The main threat in ICE is hijacking of connections for the purposes
of directing media streams to DoS targets or to malicious users. When
full implementations are used, ICE TCP prevents that by only using TCP
connections that have been validated. Validation requires a STUN
transaction to take place over the connection. This transaction cannot
complete without both participants knowing a shared secret exchanged in
the rendezvous protocol used with ICE, such as SIP <xref target="RFC3261"/>. This shared secret, in turn, is protected by that
protocol exchange. In the case of SIP, the usage of the SIPS <xref target="RFC3261"/> mechanism is RECOMMENDED. When this is done, an
attacker, even if it knows or can guess the port on which an agent is
listening for incoming TCP connections, will not be able to open a
connection and send media to the agent. </t>
<t> A STUN amplification attack is described in Section 18.5.2 of <xref target="RFC5245"/>. Same considerations apply to TCP, but the
amplification effect with TCP is larger due to need for establishing a
TCP connection before any checks are performed. Therefore, an ICE agent
SHOULD NOT have more than 5 outstanding TCP connection attempts with the
same peer to the same IP address. </t>
<t> If both agents use the lite mode, no connectivity checks are sent,
and additional procedures (e.g., media-level security) are needed to
validate the connection. The lack of connectivity checks is especially
problematic if one of the hosts is behind a NAT and has an address from a
private address space: the peer may accidentally connect to a host in a
different subnet that uses the same private address space. This is one of
the reasons why the lite mode is not appropriate for an ICE agent located
behind a NAT. </t>
<t> A more detailed analysis of different attacks and the various ways
ICE prevents them are described in <xref target="RFC5245"/>. Those
considerations apply to this specification. </t>
</section>
<section title="IANA Considerations">
<t> IANA is requested to create a new registry "Interactive Connectivity
Establishment (ICE) Transport Extensions" for ICE candidate attribute
transport extensions. Initial value is given below; future assignments
are to be made through IETF Review or IESG Approval <xref target="RFC5226"/>. Assignments consist of an extension token (as defined
in Section 15.1 of <xref target="RFC5245"/>) and a reference to the
document defining the extension.
<figure>
<artwork><![CDATA[
Token Reference
----- ---------
TCP RFC XXXX Section 4.5
]]></artwork>
</figure>
[RFC Editor: please change XXXX to the RFC number of this document; and update
the section number if needed] </t>
</section>
<section title="Acknowledgements">
<t> The authors would like to thank Tim Moore, Saikat Guha, Francois
Audet, Roni Even, Simon Perreault, Alfred Heggestad, Hadriel Kaplan,
Jonathan Lennox, Flemming Andreasen, and Dan Wing for the reviews and
input on this document. Special thanks to Marc Petit-Huguenin for
providing the SDP examples. </t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.4145"?>
<?rfc include="reference.RFC.4571"?>
<?rfc include="reference.RFC.4572"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5234"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5764"?>
<?rfc include="reference.RFC.5766"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1928"?>
<?rfc include="reference.RFC.3089"?>
<?rfc include="reference.RFC.3103"?>
<?rfc include="reference.RFC.4251"?>
<?rfc include="reference.RFC.4380"?>
<?rfc include="reference.RFC.4540"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.5190"?>
<?rfc include="reference.RFC.5382"?>
<?rfc include="reference.RFC.6062"?>
<?rfc include="reference.RFC.6081"?>
<?rfc include="reference.RFC.6156"?>
<?rfc include="reference.I-D.ietf-pcp-base"?>
<?rfc include="reference.I-D.cheshire-nat-pmp"?>
<reference anchor="UPnP-IGD">
<front>
<title>Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0</title>
<date month="November" year="2001"/>
<author initials="U." surname="Warrier"/>
<author initials="P." surname="Iyer"/>
<author initials="F." surname="Pennerath"/>
<author initials="G." surname="Marynissen"/>
<author initials="M." surname="Schmitz"/>
<author initials="W." surname="Siddiqi"/>
<author initials="M." surname="Blaszczak"/>
</front>
<format octets="1480572" target="http://www.upnp.org/standardizeddcps/documents/UPnP_IGD_1.0.zip" type="ZIP"/>
</reference>
<reference anchor="IMC05">
<front>
<title>Characterization and Measurement of TCP Traversal through NATs and Firewalls</title>
<author fullname="S. Guha" initials="S." surname="Guha">
<organization>Cornell University</organization>
</author>
<author fullname="P. Francis" initials="P." surname="Francis">
<organization>Cornell University</organization>
</author>
<date year="2005"/>
</front>
<seriesInfo name="" value="Proceedings of the 5th ACM SIGCOMM conference on Internet Measurement"/>
<format target="http://www.usenix.org/events/imc05/tech/full_papers/guha/guha_html/index.html" type="HTML"/>
</reference>
</references>
<section anchor="limitations" title="Limitations of ICE TCP">
<t> Compared to UDP-based ICE, ICE TCP has in general lower success
probability for enabling connectivity without a relay if both of the
hosts are behind a NAT. This happens because many of the currently
deployed NATs have endpoint-dependent mapping behavior or they do not
support the flow of TCP handshake packets seen in case of TCP
simultaneous-open: e.g., some NATs do not allow incoming TCP SYN packets
from an address where a SYN packet has been sent to recently or the
subsequent SYN-ACK is not processed properly. </t>
<t> It has been reported in <xref target="IMC05"/> that with the
population of NATs deployed at the time of the measurements (2005), one
of the NAT traversal techniques described here, TCP simultaneous-open,
worked in roughly 45% of the cases. Also, all operating systems do not
implement TCP simultaneous-open properly and thus are not able to use
such candidates. However, when more NATs comply with the requirements set
by <xref target="RFC5382"/> and operating system TCP stacks are fixed,
the success probability of simultaneous-open is likely to increase. Also,
it is important to implement additional techniques with higher success
ratio, such as Teredo, whose success in different scenarios is described
in Figure 1 of <xref target="RFC6081"/>. </t>
<t> Finally, it should be noted that implementing various techniques
listed in <xref target="cand-collection"/> should increase the success
probability, but many of these techniques require support from the
endpoints and/or from some network elements (e.g., from the
NATs). Without comprehensive experimental data on how well different
techniques are supported the actual increase of success probability is
hard to evaluate. </t>
</section>
<section anchor="sec-impl" title="Implementation Considerations for BSD Sockets">
<t> This specification requires unusual handling of TCP connections, the
implementation of which in traditional BSD socket APIs is non-trivial.
</t>
<t> In particular, ICE requires an agent to obtain a local TCP candidate,
bound to a local IP and port, and then from that local port, initiate a
TCP connection (e.g., to the STUN server, in order to obtain server
reflexive candidates, to the TURN server, to obtain a relayed candidate,
or to the peer as part of a connectivity check), and be prepared to
receive incoming TCP connections (for passive and simultaneous-open
candidates). A "typical" BSD socket is used either for initiating or
receiving connections, and not for both. The code required to allow
incoming and outgoing connections on the same local IP and port is
non-obvious. The following pseudocode, contributed by Saikat Guha, has
been found to work on many platforms: </t>
<?rfc needLines="10" ?>
<figure>
<artwork><![CDATA[
for i in 0 to MAX
sock_i = socket()
set(sock_i, SO_REUSEADDR)
bind(sock_i, local)
listen(sock_0)
connect(sock_1, stun)
connect(sock_2, remote_a)
connect(sock_3, remote_b)]]></artwork>
</figure>
<t> The key here is that, prior to the listen() call, the full set of
sockets that need to be utilized for outgoing connections must be
allocated and bound to the local IP address and port. This number, MAX,
represents the maximum number of TCP connections to different
destinations that might need to be established from the same local
candidate. This number can be potentially large for simultaneous-open
candidates. If a request forks, ICE procedures may take place with
multiple peers. Furthermore, for each peer, connections would need to be
established to each passive or simultaneous-open candidate for the same
component. If we assume a worst case of 5 forked branches, and for each
peer, five simultaneous-open candidates, that results in MAX=25. </t>
</section>
<section anchor="sdp-examples" title="SDP Examples">
<t> This section shows two examples of SDP offer and answer when the ICE
TCP extension is used. Both examples are based on the simplified topology
of Figure 8 in <xref target="RFC5245"/>, with the same IP addresses. The
examples shown here should be considered as strictly informative. </t>
<t> In the first example, the offer contains only TCP candidates (lines
folded in examples to satisfy RFC formatting rules):</t>
<figure>
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=setup:active
a=connection:new
a=candidate:1 1 TCP 2128609279 10.0.1.1 9 typ host tcptype act
a=candidate:2 1 TCP 2124414975 10.0.1.1 8998 typ host tcptype pass
a=candidate:3 1 TCP 2120220671 10.0.1.1 8999 typ host tcptype so
a=candidate:4 1 TCP 1688207359 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype act
a=candidate:5 1 TCP 1684013055 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 tcptype pass
a=candidate:6 1 TCP 1692401663 192.0.2.3 45687 typ srflx raddr
10.0.1.1 rport 8999 tcptype so
]]></artwork>
</figure>
<?rfc needLines="18"?>
<t>The answer to that offer could look like this:</t>
<figure>
<artwork><![CDATA[
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=setup:passive
a=connection:new
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2128609279 192.0.2.1 9 typ host tcptype act
a=candidate:2 1 TCP 2124414975 192.0.2.1 3478 typ host tcptype pass
a=candidate:3 1 TCP 2120220671 192.0.2.1 3482 typ host tcptype so
]]></artwork>
</figure>
<t> In the second example, UDP and TCP media streams are mixed but S-O
candidates are omitted due to hosts not supporting TCP simultaneous-open
and UDP candidates are preferred (but preference order for candidate
types is kept the same) by decreasing the TCP candidate type preferences
by one (i.e., using type preference 125 for the host candidates and 99
for the server reflexive candidates): </t>
<figure>
<artwork><![CDATA[
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2111832063 10.0.1.1 9 typ host tcptype act
a=candidate:2 1 TCP 2107637759 10.0.1.1 9012 typ host tcptype pass
a=candidate:3 1 TCP 1671430143 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype act
a=candidate:4 1 TCP 1667235839 192.0.2.3 44642 typ srflx raddr
10.0.1.1 rport 9012 tcptype pass
a=candidate:5 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:6 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
]]></artwork>
</figure>
<?rfc needLines="16"?>
<t> The corresponding answer could look like this:</t>
<figure>
<artwork><![CDATA[
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2111832063 192.0.2.1 9 typ host tcptype act
a=candidate:2 1 TCP 2107637759 192.0.2.1 3478 typ host tcptype pass
a=candidate:3 1 UDP 2130706431 192.0.2.1 3478 typ host
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:17:46 |