Federated calls fail due to Docker-internal IPs in ICE candidates (Janus nat_1_1_mapping + eturnal relay_ipv4_addr)

[schpitt]

Summary

Federated Talk calls (between two Nextcloud instances) fail with ICE FAILED because both Janus and eturnal advertise Docker-internal IPs (172.18.0.x) in their ICE candidates, which
are unreachable from remote participants.

Environment

• Nextcloud AIO (latest, official images from ghcr.io/nextcloud-releases/aio-*)
• Two AIO instances with federation enabled and standalone signaling (HPB)
• Talk container running Janus 1.3.3, eturnal 1.12.2, signaling 2.0.4

Problem

The start.sh script in the talk container sets relay_ipv4_addr to the container's internal Docker IP (hostname -i → e.g. 172.18.0.5). Janus has no nat_1_1_mapping configured
(default).

For local calls (same server), this works fine because all components (client → TURN → Janus) communicate within the same Docker network or through Docker port mapping.

For federated calls, the remote client connects to the local Janus MCU via the signaling server. ICE negotiation fails because:

1. eturnal advertises relay candidates with the Docker-internal IP (e.g. 172.18.0.5) — unreachable from the remote client
2. Janus sends host candidates with the Docker-internal IP (e.g. 172.18.0.5) — also unreachable

The remote client has no way to establish a media connection to the local Janus.

Reproduction

1. Set up two AIO instances (A and B) with Talk + HPB enabled
2. Create a federated conversation between a user on A and a user on B
3. Start a call from either side
4. Observe ICE FAILED — the SDP answer from Janus contains c=IN IP4 172.18.0.x and the only ICE candidate is candidate:1 1 udp 2015363327 172.18.0.x typ host

Analysis

In start.sh, the public IP is already resolved:
IPv4_ADDRESS_TALK=$(dig $TALK_HOST IN A +short) # → public IP (e.g. 51.178.55.246)
IPv4_ADDRESS_TALK_RELAY=$(hostname -i)# → Docker IP (e.g. 172.18.0.5)

But only the Docker IP is used for relay_ipv4_addr in the generated eturnal.yml. The public IP is only added to whitelist_peers.

I confirmed that manually changing relay_ipv4_addr to the public IP and reloading eturnal (eturnalctl reload) fixes the TURN relay candidates — they correctly show the public IP.
However, Janus still only sends Docker-internal candidates because nat_1_1_mapping is not set in janus.jcfg.

Suggested fix

For federated calls to work, both need to be addressed:

1. eturnal: Set relay_ipv4_addr to $IPv4_ADDRESS_TALK (the public IP) instead of $IPv4_ADDRESS_TALK_RELAY (Docker IP)
2. Janus: Set nat_1_1_mapping to the public IP in janus.jcfg

Both values are already available in start.sh via $IPv4_ADDRESS_TALK. This could potentially be gated behind a configuration flag if there are concerns about breaking non-NAT setups,
though the existing if [ "$IPv4_ADDRESS_TALK_RELAY" = "$IPv4_ADDRESS_TALK" ] check already handles the no-NAT case.

[szaimen]

Hi, thanks a lot for your report and analysis! Would you mind creating a PR that addresses this? Thanks in advance!

[szaimen]

Hi, any update here?