1.6 Applicability Statement

This protocol is a full implementation, and requires the peer endpoint to perform Regular Nomination. It does not support or work with peer endpoints that perform Aggressive Nomination.

This protocol treats a Lite implementation peer as a peer that does not support ICE and does not follow the procedures for handling a Lite implementation peer.

This protocol treats each stream in a session independently for ICE processing, if the session has more than one stream. The procedures specified in this protocol are per media stream.

This protocol does not support ICE restarts.

This protocol requires TURN servers to be deployed to facilitate communication across NAT devices and firewalls. In the absence of TURN servers, this protocol might not be able to establish connectivity between endpoints in such topologies.

This protocol is appropriate for establishing a communication channel between two endpoints for media exchange.

This protocol can operate in two modes: regular and Transmission Control Protocol (TCP) only. This protocol cannot be used for establishing a communication channel through TCP in the absence of a TURN server in regular mode. Both the caller and callee endpoints need to support and operate in the same mode for this protocol to establish connectivity.

This protocol is used to establish connectivity for streaming Real-Time Transport Protocol (RTP) media. As a result, this protocol supports exactly two components for each candidate. It does not support scenarios that require less than two or greater than two components for each candidate.

This protocol does not guarantee consecutive ports for RTP and Real-Time Transport Control Protocol (RTCP). As a result, endpoints that need to communicate with an endpoint that implements this protocol are required to support sending and receiving media to RTP and RTCP on nonconsecutive ports, whether or not they support ICE itself.

This protocol multiplexes both components to the same IP address and port when the connection is established through TCP. The application layer is required to demultiplex the data sent for the two components if TCP candidates are used. For example, if the two components are RTP and RTCP, both RTP and RTCP are delivered to the same IP address and port. Both endpoints multiplex components over TCP.

This protocol supports the multiplexing of RTP and RTCP components to the same IP address and port when the connection is established over User Datagram Protocol (UDP) where multiplexing support is negotiated as described in [RFC5761].

During the connectivity checks, ICE keep-alive messages are sent for both RTP and RTCP components for validated component pairs and for candidate pairs whose local candidates are Relayed Candidates. For the candidate that is being used for media flow, the ICE keep-alive messages are sent only for the RTP component's transport addresses. RTCP packets are sent to keep the NAT bindings and Traversal Using Relay NAT (TURN) allocations active for the RTCP component's transport addresses. ICE keep-alive messages are sent regardless of whether UDP or TCP is the underlying transport.