This article discusses the installation of Janus on a Redhat Enterprise Linux 7 server. The installation process is long and complicated due to the dependencies required for Janus and their lack of inclusion in Yum repositories.
The steps below require come code compiling. The process is simple but may be scary for those who’ve never done it. Compiling code has a side effect hindering the use of Yum. Yum (as a system) only knows about packages installed with yum (and rpm) and therefore cannot see what you’ve compiled and installed manually.
The reason i’ve documented this process is because it was difficult. A client requested that we install Janus on their application server which runs Redhat Enterprise Linux 7. In hindsight i would recommend a dedicated Ubuntu server for this role (the media server, not the web sever).
Janus is a WebRTC server described as “Janus is an open source, general purpose, WebRTC server designed and developed by [Meetecho](http://www.meetecho.com). This version of the server is tailored for Linux systems, although it can be compiled for, and installed on, MacOS machines as well. Windows is not supported, but if that’s a requirement, Janus is known to work in the “Windows Subsystem for Linux” on Windows 10.”
I strongly recommend taking a backup of the system before following the steps in this article. Even better would be to do this on a test system and then on a production system (still with backups or a snapshot that can be reverted to). I’ve sourced CentOS packages to fill the gaps in what Redhat doesn’t supply.
TIP: This biggest sticking point for me was the “libsrtp, libsrtp-devel” software. See below for the section on installing them. It was a matter of doing things in the right order. If what i’ve done doesn’t work for you, try in different ways with different commands such as “yum” versus “rpm -ihv” versus “rpm -Uhv”.
It helps to have EPEL configured.
yum install epel-release
Install as much as possible using the following Yum command. Several of the packages listed in the command below wont be found.
Throughout this process i have sourced dependencies from “https://pkgs.org/”. The versions that i’ve noted below will obviously change over time so consider the date of this article and the versions available.
The documentation at “https://janus.conf.meetecho.com/docs/README.html” gives guidance on the installation process but not specific to Redhat (or CentOS, etc) and includes content not included here. Consider reading that article if you get stuck.
The following sections start with the name of the dependencies being installed (in bold).
Package: sofia-sip-devel wget -O sofia-sip-1.12.11.tar.gz https://downloads.sourceforge.net/project/sofia-sip/sofia-sip/1.12.11/sofia-sip-1.12.11.tar.gz?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fsofia-sip%2Ffiles%2Flatest%2Fdownload&ts=1540078563
tar -xzf sofia-sip-1.12.11.tar.gz
cd sofia-sip-1.12.11
./configure; make; make install
anus is an open source, general purpose, WebRTC server designed and developed by Meetecho. This version of the server is tailored for Linux systems, although it can be compiled for, and installed on, MacOS machines as well. Windows is not supported, but if that’s a requirement, Janus is known to work in the “Windows Subsystem for Linux” on Windows 10.
For some online demos and documentations, make sure you pay the project website a visit!
To discuss Janus with us and other users, there’s a Google Group called meetecho-janus that you can use. If you encounter bugs, though, please submit an issue on github instead.
Dependencies
To install it, you’ll need to satisfy the following dependencies:
All of those libraries are usually available on most of the most common distributions. Installing these libraries on a recent Fedora, for instance, is very simple:
Note: please notice that libopus may not be available out of the box on Ubuntu or Debian, unless you’re using a recent version (e.g., Ubuntu 14.04 LTS). In that case, you’ll have to install it manually.
While libnice is typically available in most distros as a package, the version available out of the box in Ubuntu is known to cause problems. As such, we always recommend manually compiling and installing the master version of libnice. Installation of libnice master is quite straightforward:
git clone https://gitlab.freedesktop.org/libnice/libnice
cd libnice
./autogen.sh
./configure --prefix=/usr
make && sudo make install
Note: Make sure you remove the distro version first, or you’ll cause conflicts between the installations. In case you want to keep both for some reason, for custom installations of libnice you can also run pkg-config --cflags --libs nice to make sure Janus can find the right installation. If that fails, you may need to set the PKG_CONFIG_PATH environment variable prior to compiling Janus, e.g., export PKG_CONFIG_PATH=/path/to/libnice/lib/pkgconfig
In case you’re interested in compiling the sample Event Handler plugin, you’ll need to install the development version of libcurl as well (usually libcurl-devel on Fedora/CentOS, libcurl4-openssl-dev on Ubuntu/Debian).
If your distro ships a pre-1.5 version of libsrtp, you’ll have to uninstall that version and install 1.5.x, 1.6.x or 2.x manually. In fact, 1.4.x is known to cause several issues with WebRTC. Installation of version 1.5.4 is quite straightforward:
wget https://github.com/cisco/libsrtp/archive/v1.5.4.tar.gz
tar xfv v1.5.4.tar.gz
cd libsrtp-1.5.4
./configure --prefix=/usr --enable-openssl
make shared_library && sudo make install
The instructions for version 2.x are practically the same. Notice that the following steps are for version 2.2.0, but there may be more recent versions available:
wget https://github.com/cisco/libsrtp/archive/v2.2.0.tar.gz
tar xfv v2.2.0.tar.gz
cd libsrtp-2.2.0
./configure --prefix=/usr --enable-openssl
make shared_library && sudo make install
The Janus configure script autodetects which one you have installed and links to the correct library automatically, choosing 2.x if both are installed. If you want 1.5 or 1.6 to be picked, pass --disable-libsrtp2 when configuring Janus to force it to use the older version instead.
Note: when installing libsrtp, no matter which version, you may need to pass --libdir=/usr/lib64 to the configure script if you’re installing on a x86_64 distribution.
If you want to make use of BoringSSL instead of OpenSSL (e.g., because you want to take advantage of --enable-dtls-settimeout), you’ll have to manually install it to a specific location. Use the following steps:
git clone https://boringssl.googlesource.com/boringssl
cd boringssl
# Don't barf on errors
sed -i s/" -Werror"//g CMakeLists.txt
# Build
mkdir -p build
cd build
cmake -DCMAKE_CXX_FLAGS="-lrt" ..
make
cd ..
# Install
sudo mkdir -p /opt/boringssl
sudo cp -R include /opt/boringssl/
sudo mkdir -p /opt/boringssl/lib
sudo cp build/ssl/libssl.a /opt/boringssl/lib/
sudo cp build/crypto/libcrypto.a /opt/boringssl/lib/
Once the library is installed, you’ll have to pass an additional --enable-boringssl flag to the configure script, as by default Janus will be built assuming OpenSSL will be used. By default, Janus expects BoringSSL to be installed in /opt/boringssl — if it’s installed in another location, pass the path to the configure script as such: --enable-boringssl=/path/to/boringssl If you were using OpenSSL and want to switch to BoringSSL, make sure you also do a make clean in the Janus folder before compiling with the new BoringSSL support. If you enabled BoringSSL support and also want Janus to detect and react to DTLS timeouts with faster retransmissions, then pass --enable-dtls-settimeout to the configure script too.
For what concerns usrsctp, which is needed for Data Channels support, it is usually not available in repositories, so if you’re interested in them (support is optional) you’ll have to install it manually. It is a pretty easy and standard process:
git clone https://github.com/sctplab/usrsctp
cd usrsctp
./bootstrap
./configure --prefix=/usr && make && sudo make install
Note: you may need to pass --libdir=/usr/lib64 to the configure script if you’re installing on a x86_64 distribution.
The same applies for libwebsockets, which is needed for the optional WebSockets support. If you’re interested in supporting WebSockets to control Janus, as an alternative (or replacement) to the default plain HTTP REST API, you’ll have to install it manually:
git clone https://libwebsockets.org/repo/libwebsockets
cd libwebsockets
# If you want the stable version of libwebsockets, uncomment the next line
# git checkout v2.4-stable
mkdir build
cd build
# See https://github.com/meetecho/janus-gateway/issues/732 re: LWS_MAX_SMP
cmake -DLWS_MAX_SMP=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" ..
make && sudo make install
Note: if libwebsockets.org is unreachable for any reason, replace the first line with this:
The same applies for Eclipse Paho MQTT C client library, which is needed for the optional MQTT support. If you’re interested in integrating MQTT channels as an alternative (or replacement) to HTTP and/or WebSockets to control Janus, or as a carrier of Janus Events, you can install the latest version with the following steps:
git clone https://github.com/eclipse/paho.mqtt.c.git
cd paho.mqtt.c
make && sudo make install
Note: you may want to set up a different install path for the library, to achieve that, replace the last command by ‘sudo prefix=/usr make install’.
In case you’re interested in Nanomsg support, you’ll need to install the related C library. It is usually available as an easily installable package in pretty much all repositories. The following is an example on how to install it on Ubuntu:
aptitude install libnanomsg-dev
Finally, the same can be said for rabbitmq-c as well, which is needed for the optional RabbitMQ support. In fact, several different versions of the library can be found, and the versions usually available in most distribution repositories are not up-do-date with respect to the current state of the development. As such, if you’re interested in integrating RabbitMQ queues as an alternative (or replacement) to HTTP and/or WebSockets to control Janus, you can install the latest version with the following steps:
git clone https://github.com/alanxz/rabbitmq-c
cd rabbitmq-c
git submodule init
git submodule update
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..
make && sudo make install
Note: you may need to pass --libdir=/usr/lib64 to the configure script if you’re installing on a x86_64 distribution.
To conclude, should you be interested in building the Janus documentation as well, you’ll need some additional tools too:
Once you have installed all the dependencies, get the code:
git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
Then just use:
sh autogen.sh
to generate the configure file. After that, configure and compile as usual to start the whole compilation process:
./configure --prefix=/opt/janus
make
make install
Since Janus requires configuration files for both the core and its modules in order to work, you’ll probably also want to install the default configuration files to use, which you can do this way:
make configs
Remember to only do this once, or otherwise a subsequent make configs will overwrite any configuration file you may have modified in themeanwhile.
If you’ve installed the above libraries but are not interested, for instance, in Data Channels, WebSockets, MQTT and/or RabbitMQ, you can disable them when configuring:
There are configuration flags for pretty much all external modules and many of the features, so you may want to issue a ./configure --help to dig through the available options. A summary of what’s going to be built will always appear after you do a configure, allowing you to double check if what you need and don’t need is there.
If Doxygen and graphviz are available, the process can also build the documentation for you. By default the compilation process will not try to build the documentation, so if you instead prefer to build it, use the --enable-docs configuration option:
./configure --enable-docs
You can also selectively enable/disable other features (e.g., specific plugins you don’t care about, or whether or not you want to build the recordings post-processor). Use the –help option when configuring for more info.
Building on MacOS
While most of the above instructions will work when compiling Janus on MacOS as well, there are a few aspects to highlight when doing that.
First of all, you can use brew to install most of the dependencies:
For what concerns libwebsockets, though, make sure that the installed version is higher than 2.4.1, or you might encounter the problems described in this post. If brew doesn’t provide a more recent version, you’ll have to install the library manually.
Notice that you may need to provide a custom prefix and PKG_CONFIG_PATH when configuring Janus as well, e.g.:
Everything else works exactly the same way as on Linux.
Configure and start
To start the server, you can use the janus executable. There are several things you can configure, either in a configuration file:
<installdir>/etc/janus/janus.jcfg
or on the command line:
<installdir>/bin/janus --help
janus 0.7.5
Usage: janus [OPTIONS]...
-h, --help Print help and exit
-V, --version Print version and exit
-b, --daemon Launch Janus in background as a daemon
(default=off)
-p, --pid-file=path Open the specified PID file when starting Janus
(default=none)
-N, --disable-stdout Disable stdout based logging (default=off)
-L, --log-file=path Log to the specified file (default=stdout only)
-H --cwd-path Working directory for Janus daemon process
(default=/)
-i, --interface=ipaddress Interface to use (will be the public IP)
-P, --plugins-folder=path Plugins folder (default=./plugins)
-C, --config=filename Configuration file to use
-F, --configs-folder=path Configuration files folder (default=./conf)
-c, --cert-pem=filename DTLS certificate
-k, --cert-key=filename DTLS certificate key
-K, --cert-pwd=text DTLS certificate key passphrase (if needed)
-S, --stun-server=filename STUN server(:port) to use, if needed (e.g.,
Janus behind NAT, default=none)
-1, --nat-1-1=ip Public IP to put in all host candidates,
assuming a 1:1 NAT is in place (e.g., Amazon
EC2 instances, default=none)
-E, --ice-enforce-list=list Comma-separated list of the only interfaces to
use for ICE gathering; partial strings are
supported (e.g., eth0 or eno1,wlan0,
default=none)
-X, --ice-ignore-list=list Comma-separated list of interfaces or IP
addresses to ignore for ICE gathering;
partial strings are supported (e.g.,
vmnet8,192.168.0.1,10.0.0.1 or
vmnet,192.168., default=vmnet)
-6, --ipv6-candidates Whether to enable IPv6 candidates or not
(experimental) (default=off)
-l, --libnice-debug Whether to enable libnice debugging or not
(default=off)
-f, --full-trickle Do full-trickle instead of half-trickle
(default=off)
-I, --ice-lite Whether to enable the ICE Lite mode or not
(default=off)
-T, --ice-tcp Whether to enable ICE-TCP or not (warning: only
works with ICE Lite)
(default=off)
-R, --rfc-4588 Whether to enable RFC4588 retransmissions
support or not (default=off)
-q, --max-nack-queue=number Maximum size of the NACK queue (in ms) per user
for retransmissions
-t, --no-media-timer=number Time (in s) that should pass with no media
(audio or video) being received before Janus
notifies you about this
-W, --slowlink-threshold=number
Number of lost packets (per s) that should
trigger a 'slowlink' Janus API event to users
-r, --rtp-port-range=min-max Port range to use for RTP/RTCP (only available
if the installed libnice supports it)
-B, --twcc-period=number How often (in ms) to send TWCC feedback back to
senders, if negotiated (default=1s)
-n, --server-name=name Public name of this Janus instance
(default=MyJanusInstance)
-s, --session-timeout=number Session timeout value, in seconds (default=60)
-m, --reclaim-session-timeout=number
Reclaim session timeout value, in seconds
(default=0)
-d, --debug-level=1-7 Debug/logging level (0=disable debugging,
7=maximum debug level; default=4)
-D, --debug-timestamps Enable debug/logging timestamps (default=off)
-o, --disable-colors Disable color in the logging (default=off)
-M, --debug-locks Enable debugging of locks/mutexes (very
verbose!) (default=off)
-a, --apisecret=randomstring API secret all requests need to pass in order
to be accepted by Janus (useful when wrapping
Janus API requests in a server, none by
default)
-A, --token-auth Enable token-based authentication for all
requests (default=off)
-e, --event-handlers Enable event handlers (default=off)
Options passed through the command line have the precedence on those specified in the configuration file. To start the server, simply run:
<installdir>/bin/janus
This will start the server, and have it look at the configuration file.
Make sure you have a look at all of the configuration files, to tailor Janus to your specific needs: each configuration file is documented, so it shouldn’t be hard to make changes according to your requirements. The repo comes with some defaults (assuming you issues make configs after installing the server) that tend to make sense for generic deployments, and also includes some sample configurations for all the plugins (e.g., web servers to listen on, conference rooms to create, streaming mountpoints to make available at startup, etc.).
To test whether it’s working correctly, you can use the demos provided with this package in the html folder: these are exactly the same demos available online on the project website. Just copy the file it contains in a webserver, or use a userspace webserver to serve the files in the html folder (e.g., with php or python), and open the index.html page in either Chrome or Firefox. A list of demo pages exploiting the different plugins will be available. Remember to edit the transport/port details in the demo JavaScript files if you changed any transport-related configuration from its defaults. Besides, the demos refer to the pre-configured plugin resources, so if you add some new resources (e.g., a new videoconference) you may have to tweak the demo pages to actually use them.
Janus is a WebRTC Server developed by Meetecho conceived to be a general purpose one. As such, it doesn’t provide any functionality per se other than implementing the means to set up a WebRTC media communication with a browser, exchanging JSON messages with it, and relaying RTP/RTCP and messages between browsers and the server-side application logic they’re attached to. Any specific feature/application is provided by server side plugins, that browsers can then contact via Janus to take advantage of the functionality they provide. Example of such plugins can be implementations of applications like echo tests, conference bridges, media recorders, SIP gateways and the like.
The reason for this is simple: we wanted something that would have a small footprint (hence a C implementation) and that we could only equip with what was really needed(hence pluggable modules). That is, something that would allow us to deploy either a full-fledged WebRTC gateway on the cloud, or a small nettop/box to handle a specific use case.