Running an application with WebRTC within a local network that doesn't have internet access

Question

I'm looking to use WebRTC in a project where I need to livestream video from one computer, a robot with a wifi hotspot and USB camera, over a local network to another computer, a controller for the robot. Both computers in this case are single board computers and the video stream is one-way. I'd also like the two computers to communicate data to each other in both directions. I found WebRTC in my research and it seems to have both of these functionalities that I'm looking for.

From initial testing with the demo NodeJS programs, WebRTC seems to be almost exactly what I'm looking for. One big bump I've been trying to get over though is that it seems to require by default an online signaling server to be used between the two clients. I researched and found that it's possible to create the signaling server within the local network with a third computer, but such a setup isn't appropriate for my project.

I've looked into other solutions and came across OpenVidu which implements WebRTC but allows the signaling server to be built into one of the client computers (at least that's what I've read in another stack overflow post). I have yet to test this tool to see if it resolves my issue, but I'm blocked currently by the docker image used by the project not supporting ARM processors, which are employed by my single board computers, and thus requiring special installation.

Before I go through that process which may or may not work, I wanted to ask if there's another simpler solution to running WebRTC without internet access and without needing a third computer as a signaling server or if there were any suggestions for tools other than WebRTC that would be better for my application. I'm very new to the technology and could definitely be missing an easy or existing solution. Any help on this matter would be greatly appreciated.

For those curious, the single board computers being used are NVidia Jetson Nanos.

Answer 1

Found the solution. Using the Google Codelabs example, the fix involved just removing the default ice server in the config. Essentially, it meant changing

const config = {
  iceServers: [
    {urls: ["stun:stun.l.google.com:19302"]}
  ]
}

to

const config = {
  iceServers: []
}