> Hi Boris,
> lets say I have 2 JVB instances registered with jicofo.
> Firstly, I am assuming that what a call is provisioned jicofo
> earmarks that call for a particular jvb pool member and only
> that pool member has been provisoned with the necessary state to
> know about the call.
> Please tell me if the above assumption is wrong. e.g. is it the
> case that the jvb pool members somehow have a shared state where
> any pool member can handle any call?
> Jicofo selects a single jitsi-videobridge instance for each
> conference. In the future it might select more than on
> jitsi-videobridge instance, but the selection logic is still in jicofo.
> So just to be clear: that means if jicofo selects jvb3 then *only* jvb3
> can handle the call (and not, say, jvb1 or jvb2)?
Correct. Note that jicofo actively communicates with the chosen jitsi-videobridge and configures it to accept a session from a given participant.
> Assuming the assumption about there being a neeed to dispatch to
> one particular pool member is true: what is the expected way to
> accomplish this? I can think of a few options:
> 1] multiple public IPs for each JVB pool member.
> I don't understand why you would need multiple IPs for a given pool
> member. We use it with a single public IP for each pool member.
> I think my wording was unclear. I mean each jvb has a distinct public
> IP so that the correct pool member can be unambiguously dispatched to by
> public IP:
> jvb1 is <public address 1>
> jvb2 is <public address 2>
> jvb3 is <public address 3>
> which is OK as it means the clients can connect to the correct jvb by
Yes, that makes sense.
> but what if I only have 1 public IP?
Unfortunately this is more tricky. See below.>
> 2] single public IP with a non-overlapping port range for each
> JVB (e.g. jvb1 is port range 10000 to 10099, jvb2 is 11000 to
> 11099 etc) so that a NAT can forward traffic to the correct port
> member dispatching on the port
> This works for UDP, but with TCP it defeats the purpose, as you want
> to specifically expose port 443 because of restrictive firewalls.
> I'm not sure what you mean wrt. TCP port 443 (I am not using meet, just
> videobridge, jicofo, xmpp from a native android application).
> To be clear, I am discussing the UDP SRTP media channels.
Some clients are behind restrictive firewalls which do not allow UDP. Because of this in production we have jitsi-videobridge use TCP/443 for the media connections (that is, SRTP goes over TCP/443). These firewalls often also block TCP ports other than 443, so multiplexing ports on the same IP address doesn't work.
Probably the easiest option is to use the port multiplexing which you suggested for UDP, and add a TURN server running on TCP/443, which then connects to jitsi-videobridge over UDP, i.e.:
client <-- tcp/443 --> TURN server <-- udp/10123 --> jitsi-videobridge
> 3] single public IP with a load balancer. but in that sense how
> would the load balancer know which pool member was correct?
> This could work, but you would need to implement the load balancer.
> but what would the load balancing logic be to target the correct pool
> member? if only jicofo knows which pool member is correct then what is
> the logic the load balancer can implement to target the correct pool member?
> NOTE: it may be I have some incorrect assumptions if my responses seem
> out of whack with your mental model. If so please clarify.
We're out of sync, but I'm not sure where. This is the flow of a conference with jitsi-meet:
1. jitsi-meet connects to jicofo
2. jicofo selects a jitsi-videobridge and allocates channels on it
3. jicofo provides jitsi-meet with the address of the jitsi-videobridge for the conference
4. jitsi-meet connects to jitsi-videobridge (with ICE)
So if the client connects to the correct jicofo instance, jicofo will take care to connect it to the correct jitsi-videobridge.
On 13/12/2017 13:21, Raoul Duke wrote:
> On Wed, Dec 13, 2017 at 6:02 PM, Boris Grozev <firstname.lastname@example.org > <mailto:email@example.com>> wrote:
> On 13/12/2017 10:41, Raoul Duke wrote: