ICE-Lite vs Full ICE for AI Media Servers in 2026: Pick the One That Survives DoS

ICE-Lite ships in a day and gets your AI media server connected. Three months later you read about a botnet using your media path to flood third-party servers, and you realize there was a reason "Lite" had a small footprint.

Background

flowchart LR
 UA[SIP UA] -- REGISTER --> Reg[Registrar]
 UA -- INVITE --> Proxy[SIP Proxy]
 Proxy --> Dispatcher[Kamailio dispatcher]
 Dispatcher --> Worker1[FreeSWITCH worker]
 Dispatcher --> Worker2[FreeSWITCH worker]
 Worker1 --> AI[(AI agent)]
 Worker2 --> AI

Interactive Connectivity Establishment (ICE), defined in RFC 8445, is how two WebRTC endpoints find a working network path through NAT and firewalls. Full ICE agents gather host, server-reflexive (STUN), and relayed (TURN) candidates, run connectivity checks against the remote candidates, and converge on the best pair. ICE-Lite is a stripped-down profile for endpoints that already sit on the public internet: they skip candidate gathering for non-host candidates, do not initiate connectivity checks, and only respond to incoming STUN binding requests.

ICE-Lite was designed for SBCs and media servers that publish a stable public IP. The savings are real: simpler implementation, faster setup, no STUN servers needed on your side. The cost is real too: without sending its own connectivity checks, an ICE-Lite agent has weak consent verification on the media path.

Technical deep-dive

The setup time tradeoff is interesting. With Full ICE, both sides gather candidates in parallel and connectivity checks run concurrently with the SDP offer/answer; convergence can be sub-second. With ICE-Lite, the controlling side does all the work alone, which can extend setup by 200-500 ms on poor networks because checks proceed serially.

The security tradeoff is the bigger one. STUN binding requests in Full ICE include a USERNAME and MESSAGE-INTEGRITY HMAC tied to credentials negotiated in SDP. The connectivity check round-trip serves as proof that the remote endpoint actually wants to send media to that IP/port. An ICE-Lite agent only validates incoming binding requests but never verifies that the remote address is consenting to receive media; an attacker who hijacks signaling can redirect media to a victim IP and your media server happily blasts RTP at it.

# SDP from an ICE-Lite media server
v=0
o=- 1234567890 1 IN IP4 media.callsphere.ai
s=-
c=IN IP4 203.0.113.42
m=audio 49170 UDP/TLS/RTP/SAVPF 111
a=ice-lite
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-256 D2:9A:...:38
a=setup:passive
a=candidate:1 1 udp 2130706431 203.0.113.42 49170 typ host

The a=ice-lite attribute tells the peer "I am ICE-Lite, do not expect connectivity checks from me." A Full ICE peer adjusts its state machine accordingly.

CallSphere implementation

Explore a live demo and compare current plans to find the right fit for your business.

Implementation steps

1. If your media server is internet-facing with a stable public IP and you only accept browser clients, ICE-Lite is acceptable for v0.
2. Run rate limiting on STUN binding requests to defeat the obvious DoS amplification.
3. Validate ice-ufrag and ice-pwd against the SDP-asserted values; reject mismatches early.
4. Move to Full ICE when you scale past 100 concurrent calls or your media path crosses any partner who could spoof.
5. For SIP+RTP legs (no WebRTC), ICE does not apply; SBC topology rules govern.
6. Bind RTP source IPs to the SDP-advertised IP for the first 5 seconds of each call; reject media from unexpected sources.
7. Log STUN check failures; sustained failures from one peer indicate a misconfigured client or an attack.
8. Audit your candidate list; never publish private RFC 1918 IPs on c= or a=candidate for an internet-facing server.

FAQ

Does Twilio Voice SDK use ICE-Lite or Full? Twilio's edge media servers behave like Full ICE for WebRTC clients; the SIP trunk side uses RTP without ICE.

Will ICE-Lite improve setup time meaningfully for AI voice? Marginal in good networks; potentially 200-500 ms worse in bad networks because checks serialize.

Is ICE-Lite a HIPAA risk? Not directly. HIPAA cares about encryption and access control, not ICE flavor. The DoS-amplification concern is operational, not regulatory.

Should I run TURN for AI media? For browser-to-AI WebRTC, yes - some corporate networks block UDP and require TURN/TCP. Twilio bundles TURN with their network traversal service.

What about WebRTC over QUIC or WebTransport? 2026 status: experimental. The RTCWeb working group has draft protocols but Chrome/Safari interop is not stable enough for production AI voice yet.

Sources

• BlogGeek.me: ice-lite glossary entry
• RFC 8445: Interactive Connectivity Establishment
• WebRTC.ventures: ICE in WebRTC Server Setup and Performance

Explore a live demo and compare current plans to find the right fit for your business.