I have seen that with tbd, which opens 5198 and 5199 UDP on 127.0.0.1 for commands and chat respectively, while the default configuration has Echolink listening on 5198 and 5199 on 0.0.0.0, so there is hope. Will have to test further, though I was able to connect from my new proxy to one of the conferences on the same box.
I think your best and safest bet would be to find a conference server that can use a proxy. A service connected via a proxy has full functionality (this is different from a relay) and there is really no disadvantage to having a service connected to a proxy hosted on the same machine. Doing this, only the elproxy program has to open sockets for 0.0.0.0:5198 and 0.0.0.0:5199 and there are no conflicts.
Of course it would still be interesting to know if a program can be listening e.g. on 44.128.0.1:5198 (UDP) while another program on the same machine is listening on 0.0.0.0:5198 and will receive all UDP to port 5198 except to address 44.128.0.1
Rob
On 08/05/18 04:05, Rob Janssen wrote:
I think your best and safest bet would be to find a conference server that can use a proxy.
I don't understand what you mean, this looks self evident to me.
A service connected via a proxy has full functionality (this is different from a relay) and
I know that, and at this point in time, haven't setup any relays.
there is really no disadvantage to having a service connected to a proxy hosted on the same machine. Doing this, only the elproxy program has to open sockets for 0.0.0.0:5198 and 0.0.0.0:5199 and there are no conflicts.
I know, been doing it for years with the Java proxy server.
Of course it would still be interesting to know if a program can be listening e.g. on 44.128.0.1:5198 (UDP) while another program on the same machine is listening on 0.0.0.0:5198 and will receive all UDP to port 5198 except to address 44.128.0.1
This is the part we're not 100% certain about, though early indications suggest this does work, because in my tests, the proxy was able to connect to a conference bound to a specific IP.