Currently, mediasoup only supports ICE-lite, which has implementation simplicity as its primary advantage. However, there are several technical and practical reasons to support Full ICE.
Limitations of ICE-lite
- WHEP cannot be implemented with a single HTTP request
ICE-lite requires the remote peer (i.e., the client) to initiate connectivity checks. This makes it impossible to complete WHEP negotiation (SDP exchange + ICE connection) in a single HTTP request, as specified in WHEP. Instead, multiple round-trips are required, increasing connection latency and complexity.
With Full ICE, the server can act as the controlling agent, perform aggressive nomination, and complete ICE negotiation immediately, thus enabling WHEP in a single request.
- Lack of Consent Freshness and ICE disconnect detection
ICE-lite does not send STUN Binding Indications or perform connectivity checks after the initial connection is established. This means:
- The server cannot detect if the remote peer has silently disconnected.
- Media may continue to be sent to a peer that is no longer reachable.
- Server resources (RTP streams, Consumers, etc.) are unnecessarily consumed.
Full ICE would provide consent freshness as per RFC 7675, allowing the server to detect and clean up dead connections.
- Consumers must be created in a paused state
Due to ICE-lite limitations, mediasoup must pause newly created Consumers and wait for the client to respond before resuming. This is a workaround to avoid race conditions where media is sent before the client’s RTCPeerConnection is ready to handle it.
Code from mediasoup demo shows:
await consumerPeer.request(
'newConsumer',
{
peerId : producerPeer.id,
producerId : producer.id,
id : consumer.id,
kind : consumer.kind,
rtpParameters : consumer.rtpParameters,
type : consumer.type,
appData : producer.appData,
producerPaused : consumer.producerPaused
});
// Now that we got the positive response from the remote endpoint, resume
// the Consumer so the remote endpoint will receive the a first RTP packet
// of this new stream once its PeerConnection is already ready to process
// and associate it.
await consumer.resume();
consumerPeer.notify(
'consumerScore',
{
consumerId : consumer.id,
score : consumer.score
})
.catch(() => {});
resolve();
This is unnecessary with Full ICE, as the server can use aggressive nomination and determine the best candidate pair itself.
Practical Considerations
- ICE-lite reduces server-side processing slightly, but the difference is negligible compared to RTP encryption, SRTP handling, and network I/O.
- Most importantly, there are no meaningful CPU or network savings, and ICE-lite creates longer setup times.
- Implementing Full ICE will enable proper WHEP/WHIP support, improved reliability, and better standards compliance.
References
ICE allows a lite implementation to have a single IPv4 host candidate and several IPv6 addresses. In that case, candidate pairs are selected by the controlling agent using a static algorithm, such as the one in RFC 6724, which is recommended by this specification. However, static mechanisms for address selection are always prone to error, since they can never reflect the actual topology or provide actual guarantees on connectivity. They are always heuristics. Consequently, if an ICE agent is implementing ICE just to select between its IPv4 and IPv6 addresses, and none of its IP addresses are behind NAT, usage of full ICE is still RECOMMENDED in order to provide the most robust form of address selection possible.
It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet with just a single IPv4 address, a full implementation is preferable if achievable. A full implementation will reduce call setup times, since ICE’s aggressive mode can be used. Full implementations also obtain the security benefits of ICE unrelated to NAT traversal; in particular, the voice hammer attack described in Section 18 is prevented only for full implementations, not lite.