STUN and ICE server changes


Hi all — I’ve just finished migrating ice and stun services to redundant servers in an active-passive failover configuration. This means for things to properly work you need to talk to the proper servers, and considering DNS changes you need to get new resolutions for the relevant hostnames.

Please restart your stack managers and interface clients to make sure you’re talking to the right systems.



Hey @leo where can I learn more about the role and architecture of these servers in the big picture?
Much appreciated.


Hi @VR_Architect — STUN (which stands for Session Traversal Utilities for NAT) basically discovers what your public and private socket are, mostly considering clients behind NAT that will not be directly accesible, rather through port mappings from public counterparts.

The ICE server keeps a dictionary of agents (eg. interface clients), their IDs and their sockets as identified by the STUN server.


@leo I think you need to add the zlib.dll to the stack manager download. My domain won’t start

edited to add:… oops I see this was an old post. so… probably not leo… but I did update my stack manager on a remote machine and got the missing zlib, program can not start error message and when I go to the domain, no servers, no content.


Also seeing this issue.


@Twa_Hinkle @AlphaVersionD a recent merge modified the zlib external sourcing including it as a cmake external, and the resulting dll filename differed from the system zlib which is what is getting bundled in requirements. Please close and open your stack manager to get an updated requirements having removed the system zlib from the bundling process.


Fixed now! Thanks Yaay!


Fixed. Thanks leo! and post must be 20 characters long…


I do have a relevant question:

@davedub did an EEG machine that uses localhost meaning a websocketd is running on his PC. I spent all weekend on this and I think I know the direction that will fulfill my requirement. Under assumption that a normal user will be unwilling to run a WebSocket server, I cannot expect them to just willingly install a WebSocket Server on their Interface machine… it just isn’t gonna happen. Using the Stack Manager logs, I found the response from the ICE/STUN to be no more than my Gateway IP address. This isn’t sufficient to complete the task. I have a WebSockets Gateway Server running on my Stack Manager machine but I need to edit the config .xml AND point users AT IT, via some other means.

@leo I realize I’m asking a lot here, but can you point me at an example that leverages a solution to my problem?

  • an example of a .js that uses a WebSocket protocol between Interface and the domain running on a StackManager. (this assumes a ws:// or wss:// can be initialized with StackManager domain - again, I’m not telling, I’m asking)


  • an example of a .js that can use a WebSocket protocol between Interface and the MACHINE running StackManager. (in this example, I am running KAAZING Gateway AMQP as a stand-alone service along with StackManager)

Maybe I can use some of the tech presented here?

I sank over 20 hours on this over the weekend. I’m at the final bridge, and cannot cross. Please help me.
cc: @Menithal

Ports Used by High Fidelity

Unfortunately WebSockets are limited to having a Server-Client paradigm.
So you must have something listening for the Websocket calls, and something which serves.

You could technically have an Assignment Client running on the Web Socket Server. Its job would be receives the socket calls and translates them into events for the client

The ICE / STUN does give the gateway address, but you have to fill in the blanks for the ports used.
This way, and request done would be done of the ws://place But the documentation for Assignment Clients is a tad bit spotty, so I have no idea where we may find examples or if there are any available… Needs more testing.

However there may be another method, but I am unsure if the QTBrowser supports it:


I’ve been theoretically mind storming a possible scenario where two WebRTC
clients are communicating with each other after an initial match up with a handshake server,
but WebRTC has not been tested with High Fidelity. It would allow for P2P connections.

However I haven’t put the effort yet into investigating if it actually works at all
It has not been tested yet. This means I do not have any examples available :frowning:

Sorry that couldn’t be much help for now, Havent been doing enough actual experimentation in this part (only by mentally).


That’s essentially what I have setup from a hardware perspective. Could you possibly take this one step further? What I need to do, is to tell StackManager to then TELL the Agent, "hey, I’m also running a WebSocket service, it’s on [ip:i_cannot_globally_declare] " the thing in brackets is my final roadblock. If we consider the fact that the InterfaceAgent can already communicate directly to a PC behind a NAT (core purpose of ICE/STUN for those not paying attention) then there MUST be a way to run a WebSocket service on the same machine, and ALLOW InterfaceAgent to communicate with it.


@AlphaVersionD so just to clarify the current state of affairs: interface agent punches a hole in your firewall - in other words, binds to a local port, talks to STUN/ICE to determine how that locally bound port is being translated to the public internet, and adds that mapping to the known sockets for the interface agent. At this point you know what UDP port the interface agent is listening on both locally and as well as to how you can reach that punched hole over the internet.

The thing is, you could attemtp to replicate this process leveraging the existing services, consider I’m making some assumptions about the state of our code I’m uncertain if are and you’d also have to definitely add some logic to the C++ code of interface and the assignment-client to get this done:

  1. you could have your web socket server talk to our STUN (or a STUN whatsoever) to identify how this behind-NAT service can be reached- consider the challenges of hole punching differ between UDP and TCP though.

  2. then you’d have to have an assignment client be an intermediary, and this likely needs to be a new type of assignment-client, sort of a “service-discovery AC type” - this assignment-client type would serve 2 purposes:

  • it would establish itself as a node in the “high fidelity realm of things”, in other words, it would be seen as a new server type, and would get a UUID and engage interface using UDP streams, same as the rest
  • it would attempt to reach a list of known services, eg. a websocket server, that you would specify via configuration or some discovery mechanism.
  1. The interface agent, just as it “engages” the entities server or audio mixer, would see this service discovery AC and report itself so the AC adds it as a node, then interface would have to send it a “tell me what services are available packet” to which the AC would reply with a “list of services and sockets” packet

  2. And then what you do with the info on that response is up to you, you could make it available to scripts so they can engage these other services over non-hifi protocols, etc.

Now, all this is just some monday morning ramblings of what could be a design, however there’s probably other approaches to this architecture — also bare in mind I think there’s a lot of work involved into getting this in place, particularly writing a whole new AC type that is configurable with 3rd party services and/or discoveres those, and then the interface client work to get it talking to this AC and then exposing whatever necessary to the javascript api so the received information is actionable.


And thinking further about this, this overlaps the function of the domain-server right now - interface connects to it and the domain-server sends the agent a list of other agents and assignment-clients in the network, another alternative is, write a websocket service that on one “leg” talks udp with the domain server and registers ITSELF as an assignment-client so interface talks to it using existing methods, and on top of that “leg” it tells interface on what socket to reach its other leg, which is the websocket side of things.

This alternative presents other challenges, as to “what type of AC it would register as?”, authentication, etc, since you’re basically writing a 3rd party consumer of the nodelist.