Jitsi Meet and Videobridge on separate Virtual Machines in production environment

#1

Hello,

I have installed jitsi meet and apache server in one virtual machine and the public ip or the domain name is mapped to the private ip of this virtual machine.

I have installed jitsi-videobridge, jicofo and prosody in another virtual machine which is not having any public ip. The videobridge is using 443 port.

Now as this is very restricted production environment in cloud so only 443/80 port are open in my first virtual machine which is mapped to a public ip. Both the virtual machines can talk to each other easily.

ISSUES: I am able to access jitsi meet and able to join room but when 2nd user joins the same room, camera of remote user gets disconnected and muted.

Queries:

1.  Is it because client cannot connect directly to videobridge in 2nd virtual machine ?
2.  What other minimum ports need to be opened at the 1st virtual machine
3.  If i run the videobridge in 1st virtual machine then i cannot use the 443 port as i need to use 
    apache for other applications

Kindly give your advice.

#2

In order to use jitsi-videobridge clients need to be able to send media to it. Address and port for jvb is your choice. By default jvb needs two ports one for tcp incoming media and one for udp incoming media, where media over tcp is not recommended and should be left as a fallback.
By default jvb will use port 443 or 4443 if the first one is in use and udp 10000.

Normally we separate components another way. We install webserver, prosody and jicofo in one host where we call this a signaling node and jvb instances are separated in multiple other machines which are the media part, this way you can spread the load and bandwidth and every jvb is using its own public address.

#3

Thanks for your reply. I will use jitsi-videobridge on the 1st Virtual Machine which is mapped to public ip. I Will try to test the application over 443 itself as i dont need to open any further ports on firewall. But for this i need to drop apache for serving jitsi meet. Instead of this i need to use jitsi videobridge as front end for jitsi meet as well as media using https://github.com/jitsi/jitsi-videobridge/blob/master/doc/http.md

Is it OK ? Once i test it between three users i can go for two seperate public ips. One for apache server to serve the jitsi-meet and one for the jitsi video bridge. And as per your suggestion i would open tcp port 443 and udp port 10000 on the 2nd virtual machine for the videobridge access.

#4

This is the default deployment of jitsi-meet if you do not have a webserver installed on the machine when installing jitsi-meet.

#5

I have done all the settings for prosody, jicofo, jitsi-meet and videobridge with jetty. But i got two issues

  1. in the JVB log i am getting

JVB 2019-05-16 02:22:21.284 WARNING: [41] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 71d25d2bce2d860d not ready yet.
JVB 2019-05-16 02:22:21.284 WARNING: [41] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2019-05-16 02:22:21.284 WARNING: [41] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with 2f298e4f4d94541f not ready yet.
JVB 2019-05-16 02:22:21.284 WARNING: [41] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can’t send a message
JVB 2019-05-16 02:22:21.297 INFO: [44] org.jitsi.videobridge.health.Health.log() Performed a successful health check in 38ms. Sticky failure: false

  1. When i access my domain i am getting error “Uncaught ReferenceError: interfaceConfig is not defined” in chrome browser.

what could be the issue ? I am not getting any exception in any of the logs

#6

This means that ssi includes does not work. Can you give more details about your setup like OS, version, default java, was there any webserver installed before proceeding with jitsi-meet?

#7

This is a local virtual machine with internet and without firewall. I am trying to test jitsi meet first at my local machine and then i am planning to replicate the same in production. My OS is Cent OS 7, i have built jitis-meet, videobridge, jicofo from source and prosody i installd from OS itself. I have apache installed in my OS and i was able use jitsi meet among different users using this setup (Apache 2, Jitsi-meet, videobridge, jicofo and prosody).

But now i was trying to configure the same setup with JETTY without using apache as i have only 443 port open on firewall in the production setup.

#8

Have you configured jetty as the debian packages do?
Like this: https://github.com/jitsi/jitsi-meet/blob/master/debian/jitsi-meet-web-config.postinst#L126 you need to add all those resource stuff.

#9

Yes i have followed that link. Just now i am able to access my jitsi-meet room by replacing <!–#include virtual" with in index.html. Is it fine to modify the index.html file like that.

#10

Thanks damencho for your support. I am able to access and perform conference using the jetty as webserver in the production machine which is mapped to a public ip though behind NAT. i am running the prosody and jicofo in another virtual machine. The setup is working fine though speed is very slow during conference over 443.

Is there any mechanism to use apache as webserve for config.js or jitsi-meet and forward the Media to jvb running on private virtual machine without public IP via apache or any other means ?

Is it possible to run the jvb on private VM with public IP on some other port and when media comes to that port via the public address then it could be forwarded to the private ip of jvb ?

#11

I think there were some modules for nginx that maybe can do this, differentiate http traffic and media traffic… but all those are with a penalty of latency… never have tested it and not sure will those will work at all.

Yes this is possible. You can chenge the announced port and the port the jvb listens for media. https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md#orgjitsivideobridgetcp_harvester_mapped_port

Mind that when using media over tcp quality will always suffer.

If you want to use media over tcp the best is to configure a turn server that will be used as a tcp relay. The turn server will listen on port 443 with valid certificate and when needed media between turn and client will be tcp 443 and from there coturn server will forward it to jvb.

This is how nowadays meet.jit.si handles tcp fallback.