Merge pull request #315 from outis1one/claude/ionos-script-integration-x32ofw

Switch TURN test from -e <peer> to -y — real verification this time
This commit is contained in:
Outis
2026-08-11 22:29:51 -04:00
committed by GitHub
2 changed files with 29 additions and 14 deletions
+13 -5
View File
@@ -167,11 +167,19 @@ else
# matching comment — confirmed live this was the actual cause of a
# "Cannot complete Allocation" failure, not a real coturn problem.
#
# -e <peer> is also required — turnutils_uclient refuses to run at
# all without either -e or -y ("Either -e peer_address or -y must
# be specified", confirmed live). Loopback is fine since this runs
# via `docker exec` inside the coturn container itself.
OUT="$(docker exec coturn timeout 10 turnutils_uclient -u "$_u" -w "$_p" -e 127.0.0.1 "$TEST_HOST" -p "$COTURN_PORT" 2>&1)"
# -y ("client-to-client"), not -e <peer>: turnutils_uclient refuses
# to run at all without one of the two ("Either -e peer_address or
# -y must be specified", confirmed live), but -e needs an actual
# reachable, non-loopback peer — services/coturn.sh never sets
# --allow-loopback-peers, so -e 127.0.0.1 gets rejected with
# "channel bind: error 403 (Forbidden IP)" (confirmed live against
# a real local coturn instance built specifically to test this).
# -y negotiates both ends of a real relay through the server
# itself, no separate peer needed, and works over loopback —
# confirmed correctly reporting success (exit 0, real packet-loss
# stats) with valid credentials and failure ("Cannot complete
# Allocation", exit 255) with a wrong password.
OUT="$(docker exec coturn timeout 10 turnutils_uclient -u "$_u" -w "$_p" -y "$TEST_HOST" -p "$COTURN_PORT" 2>&1)"
RC=$?
if [ "$RC" -eq 0 ]; then
ok "$c: TURN allocation succeeded (credentials + relay range + reachability all confirmed working)"
+16 -9
View File
@@ -217,15 +217,22 @@ else
# cause of a "Cannot complete Allocation" failure against an
# otherwise fully working coturn instance.
#
# -e <peer> is required too — turnutils_uclient refuses to run at
# all without either -e or -y ("Either -e peer_address or -y must
# be specified", confirmed live), since without a peer address it
# has nothing to relay data to/from and there'd be no way to prove
# the allocation actually works end to end, not just that auth
# succeeded. Loopback is fine here — the test runs via `docker exec`
# inside the coturn container itself, so 127.0.0.1 is always
# reachable regardless of what's actually listening there.
OUT="$(docker exec "$COTURN_CONTAINER" timeout 10 turnutils_uclient -u "$TURN_USERNAME" -w "$TURN_PASSWORD" -e 127.0.0.1 127.0.0.1 -p "${TURN_PORT:-3478}" 2>&1)"
# turnutils_uclient also refuses to run at all without either -e
# <peer> or -y ("Either -e peer_address or -y must be specified",
# confirmed live). -e needs an actual reachable, non-loopback peer
# to relay through — services/coturn.sh never sets
# --allow-loopback-peers, so -e 127.0.0.1 gets rejected with
# "channel bind: error 403 (Forbidden IP)" (also confirmed live,
# against a real local coturn instance built to test this exact
# invocation). -y ("client-to-client") sidesteps this entirely: it
# negotiates both ends of a real relay through the server itself,
# no separate peer needed, and works fine over loopback since nothing
# about it is treated as an external peer address. Confirmed against
# a real coturn instance: -y correctly reports success (exit 0, real
# packet-loss stats) with valid credentials and correctly fails
# ("Cannot complete Allocation", exit 255) with a wrong password —
# a real pass/fail signal, not just "didn't crash."
OUT="$(docker exec "$COTURN_CONTAINER" timeout 10 turnutils_uclient -u "$TURN_USERNAME" -w "$TURN_PASSWORD" -y 127.0.0.1 -p "${TURN_PORT:-3478}" 2>&1)"
if [ $? -eq 0 ]; then
ok "Live TURN allocation succeeded with Asterisk's own configured credentials (user '$TURN_USERNAME')"
else