Implement different WebRTC protocol topologies such as ICE-TCP/UDP

[ehfd]

Can be AI-driven: Yes, as long as all cases are tested carefully in real-life by people as well as automated tests.
Expected to be workable with: Fable 5, GPT-5.6 Sol, Kimi-K3, Opus 5, or equivalent (risky with Opus 4.8 or under).
Prompt or reference: Comments below, https://neko.m1k1o.net/docs/v3/configuration/webrtc, https://github.com/pion/ice, https://github.com/pion/webrtc.

---

Different protocol topologies to TURN and STUN (such as ICE-TCP/UDP)

https://neko.m1k1o.net/docs/v3/configuration/webrtc

Pion provides various WebRTC configurations and protocols including EPR, UDPMUX, TCPMUX, NAT1TO1, ICE-LITE, ICE-TCP, etc. These techniques allow more setup flexibility in addition to TURN/STUN and allow limiting port ranges or using a single port for many numbers of connections.

Same as TCPMUX and UDPMUX in Pion and Neko - more information in https://neko.m1k1o.net/docs/v3/configuration/webrtc

[junkerderprovinz]

Hi @PMohanJ, now that the ICE stack lives in-tree (e171691), the smallest slice of this issue, a configurable UDP port range for host candidates, has become a fairly contained change: a bind-in-range loop where the host sockets currently take ephemeral ports, plus one setting threaded through the same way webrtc_public_ip was. Since I worked on the NAT1TO1 part of that commit I would be happy to pick up that slice as a standalone PR, if you are not already on it and @ehfd agrees. The bigger asks here (ICE-TCP, mux, lite) I would leave untouched. Just say the word either way.

[PMohanJ]

Sorry for the delayed response.
Sure if you wish to pick up that part, feel free to draft a PR, later I'll rebase the rest of the parts on that branch. It'll take few more day for me get back on track.

[junkerderprovinz]

Quick update after digging into the host-candidate binding: the ephemeral ports are allocated inside aioice's gather_candidates (Connection has no port-range knob in 0.10.x or on main), so the port-range slice cannot land as a selkies-only change the way the public-IP rewrite did. It needs the range in aioice first.

There was prior art upstream (aioice#47 requests exactly this, aioice#63 implemented a version but has been stale and conflicting since 2022), so rather than a fragile monkeypatch here I put up a fresh, rebased aioice PR: aiortc/aioice#112 . It adds an optional host-candidate port range, leaves STUN/TURN/mDNS untouched, and addresses the original review notes, with tests.

Once that lands and releases, the selkies side is the small thread-through we discussed: a setting wired the same way as webrtc_public_ip that passes the range to the ICE Connection. I'll follow up here with that PR then. The bigger asks on this issue (ICE-TCP, mux, lite) I'm still leaving untouched.

[danoki-jm]

This issue also covers a requirement we have encountered in a scheduler-managed deployment: constraining the UDP ports used by direct ICE host candidates.

Our immediate requirement is narrower than implementing UDP mux, TCP mux, or ICE-TCP. We need the current direct ICE topology to bind its local candidate sockets within an operator-defined UDP range.

At present, Selkies’ vendored ICE implementation creates these endpoints with:
local_addr=(address, 0)

This lets the operating system select an arbitrary ephemeral port. In shared compute environments, each Selkies session may instead receive a small UDP range from the scheduler. Allowing unrestricted ephemeral ports would require opening a very large firewall range and would prevent reliable isolation between concurrent sessions.

This is separate from TURN_MIN_PORT and TURN_MAX_PORT: those settings constrain TURN relay ports, whereas this requirement applies to the local sockets used to produce direct ICE host candidates.

A possible minimal interface would be:

SELKIES_ICE_PORT_MIN=50000
SELKIES_ICE_PORT_MAX=50100

with equivalent command-line options if appropriate.

Suggested behavior:

• Preserve the existing port 0/ephemeral behavior when neither setting is provided.
• Require both boundaries to be provided together.
• Validate 1 <= min <= max <= 65535.
• Try ports within the configured range, preferably in randomized order so concurrent processes do not all contend for the first port.
• Treat the socket bind as the authoritative reservation instead of probing availability beforehand.
• If the range is exhausted, fail with a clear error instead of silently binding outside it.
• Keep this independent from TURN relay-port configuration.

We currently carry a small downstream patch implementing these semantics in the vendored ICE candidate endpoint creation. It works for our direct WebRTC sessions, but we don't want to keep downstream Selkies patches.

Would a bounded direct-ICE UDP range be acceptable as an initial, independently testable part of this issue, before the more complex UDP-mux/TCP-mux topologies are implemented? We can provide the downstream patch and its validation cases as a reference.