Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support for specifying STUN server: configure client (2.5/3) (#1657)
Related #1460. Now that the [backend is able to re-write the Janus configuration to make Janus connect to a STUN server](#1646), this PR adds the client counterpart. That means when the user enabled STUN, the frontend’s WebRTC library will also be configured to use the same STUN server. This PR complements #1647, and strictly speaking, it even should have preceded it. Note that the PR review is only about the code itself, but it does **not** include an end-to-end test of the full STUN functionality on device. Charles thankfully [did that separately](#1460 (comment)). (To sum that up: the testing procedure turned out to be rather tricky, unfortunately… We still aren’t 100% confident that our STUN implementation reliably solves connection issues in remote access scenarios, but given the testing complexity, [we decided that the status quo has yielded enough evidence for us to move forward](#1460 (comment)).) Some notes on the code: - Since the STUN server address comes from the backend and are hence validated, I used a rather pragmatic approach in `createIceServerUrls` to account for IPv6 addresses. - `webrtc-video.js` is of type “module”, so it’s a bit tricky to pass parameters to it from the parent script. I think using global variables is not super beautiful, but it gets the job done. I’m open for better ideas, but the current mechanism would also be “good enough” for me. - There is, unfortunately, one quirk with ESLint and Jinja templates, regarding the `TINYPILOT_JANUS_STUN_PORT` assignment, where we have to apply a rather ugly workaround. As far as I can see, there is not much we can do about that.
- Loading branch information