Error: WebRTC: ICE failed, add a TURN server and see about:webrtc for more details

[TheOnionMaker]

Affected Version
latest (FROM DOCKER HUB sha256:4dd51c3266955d5ee499776a817720ad7aa4672057ec82fdf4b18c93f1ccd0d0)

Describe the bug
After upgrading ispyagent to latest version, it could not start, and stuck at connecting. This is error from browser console (tested on chrome, firefox, edge):

WebRTC: ICE failed, add a TURN server and see about:webrtc for more details

and this is error from docker:
StartUp: Error adding remote ICE candidate. Remote ICE candidate was empty. 1 udp 0 0 typ host generation 0

Steps To Reproduce
Just open the web browser and navigate to ispydvragent.

Expected behavior
Connect to CCTVs.

[jo-gross]

I am experiencing the same issue: after submitting the login form, it fails with the message "Try another browser" (I have tried Firefox, Chrome, and Safari), and the browser console displays the same error message as described above.

[ispysoftware]

It's due to the port range for the RTC server - new versions are using 50000 to 50100 but this docker version is only forwarding 50000 to 50010

#765

[TheOnionMaker]

Actually I was forwarded 50000 to 50100 before, but the problem source was from other side. I have installed CodeProject AI but it was on IP+Port (not domain), so after upgrading the ispyconnect, it could not load.

I reinitiate the container from scratch and put AI Server behind a domain (without uncommon port) and insert the domain in the AI server location and problem resolved.

Maybe it can be another issue to be fixed?!

Thanks

[jo-gross]

@ispysoftware I’ve extended the range of the ports in my docker-compose, removed the existing container and image, pulled the latest version, and started everything again. I also cleared the browser cache but I’m still encountering the same error:

WebRTC: Using five or more STUN/TURN servers slows down discovery

Is there anything else I need to check? Do you have any idea what could be causing this issue?
Shall i provide the browsers console log?
(I access the page directly by the ip, without any certificate - if this matters)
Is it possible that the config files got corrupted?

[ispysoftware]

have you tried the docker version on the download page?

[jo-gross]

What docker version from which download page do you mean?
I removed the container and the image and started it again. When i pull the version again, it says it up to date.

Thats my docker-compose:

services:
  ispy:
    image: doitandbedone/ispyagentdvr
    container_name: ispyagentdvr
    restart: unless-stopped
    environment:
      - TZ=Europe/Berlin
    ports:
      - 80:8090
      - 3478:3478/udp
      - "50000-50100:50000-50100/udp"
    volumes:
      - ./config/:/agent/Media/XML/
      - ./media/:/agent/Media/WebServerRoot/Media/
      - ./commands:/agent/Commands/

I´ve changed the port range from 50010 to 50100, but that haven´t changed anything.

Some other system specs:
Docker version 27.3.1
Ubuntu 20.04.6 LTS

EDIT:

I also tried the https://www.ispyconnect.com/download Docker command, does not work aswell (also tested on an other machine)

[ispysoftware]

@jo-gross will need more info than "does not work" - it's working fine here.
Maybe some info like are you on IPv6, firewall, antivirus, VPN, browser console logs, logs from Agent (at /logs.html) etc etc. Have you tried it in host mode? Very hard to suggest anything otherwise.
Is it working from the same computer Docker is running on?

[jo-gross]

@ispysoftware by "does not work," I meant that the same issue as described above persists, and a simple upgrade to "mekayelanik/ispyagentdvr:5.9.2.0-beta" (the latest version suggested on the download page) did not resolve the problem.

I also tried the "network_mode: host" and this works - nice hint, thanks a lot! :)

Only for interest, do you have any ideas what could cause this with not host mode? A missing port (docker-compose already posted)? I am using IPv4, no firewall, no antivirus or no vpn.

Container Log:
ispyagentdvr_logs.txt
Browser Log:
console-export.txt

[ispysoftware]

The updated webrtc library doesn't have a TURN server built into it, only STUN. I guess in some NATs the only connection possible is via the TURN server. Pretty weird as it's working fine in all my tests on multiple computers. I'll look into packaging coturn with it.

[gbl08ma]

I think there's something going on besides the lack of a TURN server. I am trying to upgrade from Agent 4.x which ran fine behind Docker (without network_mode: host), and from what I can see in my browser's about:webrtc page, it isn't using TURN when communicating with this older version, meaning that WebRTC is working fine (despite Agent not being able to "guess" the LAN IP of the Docker host, thus its SDP offers only propose the public IP and the Docker virtual network IPs which are not useful to clients in the home LAN). But for some reason with 6.x the ICE dance just fails and I am yet to figure out what exactly is different between the two versions. Unless TURN is being used and browsers are being very subtle about it.
Using network_mode: host in the docker compose "fixes" this but I'd rather not use it.

My internet connection typically has no problems with WebRTC stuff (in fact, I've been messing around with it for a project of mine, and I never had to specify a TURN server).