Proxying to jvb through a proxy server


#1

Hi,

I have users in one location who for network topology reasons do not have direct access to the jitsi (jvb server). so I would like the users to be able to hit some endpoint in a data centre near them which can then explicitly proxy the traffic to the central jitsi server.

My idea to accomplish this was to rewrite the ice candidate address in the offer sent by jitsi, e.g.:

a=candidate:1 1 udp 2130706431 10.67.1.1 12002 typ host generation 0

to:

a=candidate:1 1 udp 2130706431 192.168.142.100 12002 typ host generation 0

10.67.1.1 is the real IP of the jitsi server. but is not accessible from user devices. my idea is that 192.168.142.100 would be accessible from users and would just be a dumb relay to relay the packets to the real jvb, or for the purposes of illustration, would behave something like:

socat UDP4-RECVFROM:12002,fork UDP4-SENDTO:localhost:12002

I’m going to try this - but it would be really helpful if you could let me know any reasons you can see that this wouldn’t work.

Thanks,
RD

PS - I am discussing using socat as above only for the purposes of illustration. for a real solution I’d probably use iptables


#2

This sounds like you just need to configure a turn server which they can access. https://github.com/jitsi/jitsi-meet/blob/master/doc/turn.md

If you enable ‘useStunTurn: true’ in your config.js this will add the turn server and to the jvb connection. And this way it should work. This for sure works for tcp connections as we are using those for meet.jit.si, and for UDP should also work, but you need to test it.


#3

@damencho thanks for getting back to me.

I read that article but my understanding of it (which may be flawed) is that it is discussing using turn as an alternative to JVB not in conjunction with it. I am imagining a scenairo where user C in my original outline wants to join a conference already containing users A and B who are “near” the jitsi install and can access it directly.

are you saying that in the scenario I outlined, user C could explicitly contact a turn server routable to them which would then relay the bytes to the jvb?

If so then that does sound exactly what I would like to do. If that is possible I have 2 followup questions:

  1. how does the TURN server get to know about the JVB address? is that explicitly configured in the turn config or is it somehow part of the protocol exchange between the user and the turn server?

2.in my case I am not using jitsi meet. but instead I am using Andorid/IOS native apps with webrtc. is the same approach be possible in that environment?

Thanks,


#4

So this is candidate added to the peer connection of the client, and the one that succeeds is used. This is a standard thing, so I suppose you can use it with any webrtc app.
So when the turn candidate succeeds on the client side, this candidate is sent to jicofo, this is the address and port of the turn server and this candidate is sent to jvb, so jvb starts sending there and the turn server starts forwarding it to the client which already had opened the channel to the turn server.

I was recently fixing an ipv6 problem with turn, so I had set up the following scenario in order to be able to test. I have a deployment of jitsi-meet for testing and I have added a rule in the firewall there where I DROP connections to udp 10000 and tcp 4443 to that machine for the ip-address I’m loading the client in chrome. And for that deployment, I have a configured turn server that can be used for p2p and for the bridge. This way I’m only able to communicate using turn with the other clients when using jvb.