Can't access public colibri/stats

I am unable to view colibri/stats using the public address on port 8080. port 8080 is open on my firewall.

I am able to see the Colibri stats locally with the following.
curl -v http://127.0.0.1:8080/colibri/stats

in /etc/jitsi/videobridge/sip-communicator.properties I have the following

org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri,rest

Also I have added
org.jitsi.videobridge.rest.private.jetty.port=8080
but I have read this is not necessary in a current Jitsi installation.

In /etc/jitsi/videobridge/config I have the following.

JVB_OPTS="--apis=rest,xmpp"

Before finishing this post I found the answer.

in /etc/jitsi/videobridge/sip-communicator.properties I put the following

#org.jitsi.videobridge.rest.jetty.port=8080
org.jitsi.videobridge.rest.private.jetty.port=8080
org.jitsi.videobridge.rest.private.jetty.host=0.0.0.0

(I commented out org.jitsi.videobridge.rest.jetty.port=8080 line)

@jpkelly did you solve this issue?

I’ve got the same problem, and also for the health API.

Yes. see the 2nd post.

Yes, it seems there has been some change in the videobridge, and now the following line is required for the private api to work at /colibri/stats:

org.jitsi.videobridge.rest.private.jetty.host=0.0.0.0

I was doing a new install and my previous configuration stopped working, event though the installation process was identical.

The documentation of the REST API should probably be updated to include this

not true for me (latest unstable). curl http://localhost:8080/colibri/stats works fine without any reference to jetty in sip-communicator.properties.

I used the “quick install” method listed at

My installation was on an AWS EC2.

I used the exact same steps as my previous install from a few months ago and the api wouldn’t work. When adding/removing this line at the sip-communicator.properties file, the api works/doesn’t work with only this single change.

From a software point of view, Jitsi-meet is an old and complicated software that has evolved very fast; there are tons of conditional in the code according to tons of configuration options and as such the final behaviour can sometimes be confusing when different settings are used. I can’t reproduce your problem on my instance (a quick install from 6 months ago, with some changes and kept updated)

You said that your installation ‘was on …’, Is it up-to-date now on last (unstable) version ? and did you see the problem on a vanilla quick install, or did you do some customizations before seeing this colibri interface problem ?

My previous install (from around 6 months ago) is hosted on AWS and still works without the jetty.host parameter in the config file

The new install I did yesterday was “vanilla” for videobridge. The only change I made was for jitsi-meet, where I reinstalled a slightly customized version with simple React/Html changes for jitsi-meet only.

I just cloned the repository into a server folder, built it, and pointed nginx to it. Something similar to this procedure, but without touching lib-jitsi-meet.

It was just after that that I actually went to enable the videobridge api and noticed the issue. But the only change in the videobridge folders were on sip-communicator.properties and config to enable the rest api. I woudn’t expect anything I did changing stuff in videobridge, but…

Private API works without the jetty.host line but it only listens the loopback IP (127.0.0.1) on the latest stable. Therefore it’s not accessable from the outside but accessable through the loopback.

jetty.host line changes only the binding IP.

Without org.jitsi.videobridge.rest.private.jetty.host=0.0.0.0

netstat -taunp | grep 8080

>>> tcp6  0  0 127.0.0.1:8080  :::*  LISTEN  459/java

With jetty.host

netstat -taunp | grep 8080

tcp6  0  0 :::8080  :::*  LISTEN  558/java