Convert Figma logo to code with AI

meetecho logojanus-gateway

Janus WebRTC Server

8,183
2,470
8,183
28

Top Related Projects

Cutting Edge WebRTC Video Conferencing

11,263

coturn TURN server project

OpenVidu Platform main repository

12,311

Simple peer-to-peer with WebRTC.

Quick Overview

Janus-gateway is an open-source WebRTC server designed for building and deploying scalable WebRTC applications. It provides a flexible plugin architecture, allowing developers to create custom functionalities while handling the core WebRTC protocols and media routing.

Pros

  • Highly scalable and performant, capable of handling numerous concurrent WebRTC sessions
  • Flexible plugin architecture for easy customization and extension of functionality
  • Supports various WebRTC use cases, including video conferencing, streaming, and SIP integration
  • Active community and regular updates

Cons

  • Steep learning curve for beginners due to its complex architecture
  • Limited documentation for advanced use cases and troubleshooting
  • Requires significant server resources for large-scale deployments
  • Some users report occasional stability issues in high-load scenarios

Code Examples

  1. Creating a new Janus session:
var janus = new Janus({
    server: 'https://janus.example.com/janus',
    success: function() {
        // Connected to Janus
        console.log("Janus session created successfully");
    },
    error: function(error) {
        console.error("Error creating Janus session:", error);
    }
});
  1. Attaching to a plugin:
var pluginHandle;
janus.attach({
    plugin: "janus.plugin.videoroom",
    success: function(handle) {
        pluginHandle = handle;
        console.log("Plugin attached successfully");
    },
    error: function(error) {
        console.error("Error attaching to plugin:", error);
    }
});
  1. Joining a video room:
var register = {
    request: "join",
    room: 1234,
    ptype: "publisher",
    display: "User123"
};
pluginHandle.send({
    message: register,
    success: function() {
        console.log("Joined the video room successfully");
    }
});

Getting Started

To get started with Janus-gateway:

  1. Clone the repository:

    git clone https://github.com/meetecho/janus-gateway.git
    
  2. Install dependencies:

    sudo apt-get install libmicrohttpd-dev libjansson-dev \
        libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev \
        libopus-dev libogg-dev libcurl4-openssl-dev liblua5.3-dev \
        libconfig-dev pkg-config gengetopt libtool automake
    
  3. Build and install:

    ./autogen.sh
    ./configure --prefix=/opt/janus
    make
    sudo make install
    
  4. Configure and run Janus:

    cd /opt/janus/etc/janus
    cp janus.jcfg.sample janus.jcfg
    /opt/janus/bin/janus
    

For more detailed instructions and configuration options, refer to the official documentation.

Competitor Comparisons

Cutting Edge WebRTC Video Conferencing

Pros of mediasoup

  • Built on modern WebRTC standards, offering better performance and scalability
  • Designed for flexibility, allowing easier integration into existing applications
  • Supports multiple programming languages through its client-side libraries

Cons of mediasoup

  • Steeper learning curve due to its modular architecture
  • Less out-of-the-box functionality compared to Janus Gateway
  • Requires more setup and configuration for basic use cases

Code Comparison

mediasoup (JavaScript):

const mediasoup = require('mediasoup');
const worker = await mediasoup.createWorker();
const router = await worker.createRouter({ mediaCodecs });
const transport = await router.createWebRtcTransport(webRtcTransportOptions);

Janus Gateway (C):

janus_plugin *create(void) {
    janus_plugin *plugin = (janus_plugin *)calloc(1, sizeof(janus_plugin));
    plugin->init = janus_echotest_init;
    plugin->destroy = janus_echotest_destroy;
    plugin->handle_message = janus_echotest_handle_message;
    return plugin;
}

Both projects are powerful WebRTC solutions, but they cater to different needs. mediasoup offers more flexibility and modern features, while Janus Gateway provides a more comprehensive out-of-the-box solution with a wider range of plugins. The choice between them depends on specific project requirements and development preferences.

11,263

coturn TURN server project

Pros of coturn

  • Specialized TURN server with extensive STUN support
  • Lightweight and efficient, focusing solely on NAT traversal
  • Widely adopted and battle-tested in production environments

Cons of coturn

  • Limited to STUN/TURN functionality, not a full WebRTC solution
  • Requires additional components for complete WebRTC implementation
  • Less feature-rich compared to Janus for media handling

Code comparison

coturn (simple TURN server configuration):

listening-port=3478
listening-ip=0.0.0.0
relay-ip=0.0.0.0
realm=example.com

Janus (WebRTC gateway plugin initialization):

janus_plugin *create(void) {
    static janus_plugin janus_echotest_plugin = {
        .init = janus_echotest_init,
        .destroy = janus_echotest_destroy,
        .handle_message = janus_echotest_handle_message,
        // ...
    };
    return &janus_echotest_plugin;
}

Summary

coturn is a specialized STUN/TURN server, ideal for NAT traversal in WebRTC applications. It's lightweight and efficient but limited in scope. Janus is a full-featured WebRTC gateway with broader capabilities, including media handling and plugin support. Choose coturn for dedicated TURN functionality or Janus for a more comprehensive WebRTC solution.

OpenVidu Platform main repository

Pros of OpenVidu

  • Easier to set up and use, with a higher-level API and abstraction
  • Provides a complete WebRTC solution with server and client components
  • Offers additional features like recording and screen sharing out-of-the-box

Cons of OpenVidu

  • Less flexible and customizable compared to Janus Gateway
  • May have higher resource requirements due to additional features
  • Limited support for non-WebRTC protocols

Code Comparison

OpenVidu (JavaScript):

var OV = new OpenVidu();
var session = OV.initSession();
session.connect(token)
    .then(() => console.log("Connected"))
    .catch(error => console.error(error));

Janus Gateway (JavaScript):

var janus = new Janus({
    server: "wss://janus.example.com",
    success: function() {
        // Attach to plugin
    },
    error: function(error) {
        console.error(error);
    }
});

Both projects aim to provide WebRTC solutions, but OpenVidu focuses on ease of use and a complete package, while Janus Gateway offers more flexibility and lower-level control. OpenVidu is better suited for developers who want a quick setup and don't need extensive customization, while Janus Gateway is ideal for those who require fine-grained control over their WebRTC implementation.

12,311

Simple peer-to-peer with WebRTC.

Pros of PeerJS

  • Simpler to set up and use for basic peer-to-peer connections
  • Lightweight and focused on WebRTC peer-to-peer communication
  • Better suited for small to medium-scale applications

Cons of PeerJS

  • Less feature-rich compared to Janus Gateway
  • Limited scalability for large-scale deployments
  • Lacks advanced media processing capabilities

Code Comparison

PeerJS:

const peer = new Peer();
peer.on('open', (id) => {
  console.log('My peer ID is: ' + id);
});

Janus Gateway:

var janus = new Janus({
  server: 'https://janus.example.com/janus',
  success: function() {
    // Connected to Janus
  }
});

Summary

PeerJS is a lightweight library focused on simplifying WebRTC peer-to-peer connections, making it ideal for small to medium-scale applications. It offers a straightforward API and is easier to set up compared to Janus Gateway.

Janus Gateway, on the other hand, is a more comprehensive WebRTC server with advanced features like media processing, recording, and support for various protocols. It's better suited for large-scale deployments and complex use cases.

While PeerJS excels in simplicity and ease of use, Janus Gateway provides more robust features and scalability for enterprise-level applications. The choice between the two depends on the specific requirements of your project and the scale of your WebRTC implementation.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Janus WebRTC Server

License: GPL v3 janus-ci Coverity Scan Build Status Fuzzing Status

Janus 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: do NOT trust repos that provide .exe builds of Janus, they are not official and will not be supported.

For some online demos and documentations, make sure you pay the project website a visit!

Note well: this is the main branch for the multistream version of Janus, which is the new version. If you want to check the legacy version of Janus instead (i.e., 0.x, a.k.a. "legacy") click here instead.

If you have questions on Janus, or wish to discuss Janus with us and other users, please join our Community. If you encounter bugs, please submit an issue on GitHub: make sure you read the guidelines before opening an issue or a pull request, though.

Dependencies

To install it, you'll need to satisfy the following dependencies:

These are optional dependencies, depending on which features you're interested in:

  • usrsctp (only needed if you are interested in Data Channels)
  • libmicrohttpd (at least v0.9.59; only needed if you are interested in REST support for the Janus API)
  • libwebsockets (at least v4.x suggested; only needed if you are interested in WebSockets support for the Janus API)
  • cmake (only needed if you are interested in WebSockets and/or BoringSSL support, as they make use of it)
  • rabbitmq-c (only needed if you are interested in RabbitMQ support for the Janus API or events)
  • paho.mqtt.c (only needed if you are interested in MQTT support for the Janus API or events)
  • nanomsg (only needed if you are interested in Nanomsg support for the Janus API)
  • libcurl (only needed if you are interested in the TURN REST API support)

A couple of plugins depend on a few more libraries (you only need to install the ones for the plugins you need):

  • Sofia-SIP (only needed for the SIP plugin)
  • libopus (only needed for the AudioBridge plugin)
  • libogg (needed for the recordings post-processor, and optionally AudioBridge and Streaming plugins)
  • libcurl (only needed if you are interested in RTSP support in the Streaming plugin or in the sample Event Handler plugin)
  • Lua (only needed for the Lua plugin)
  • Duktape (only needed for the Duktape plugin)

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:

yum install libmicrohttpd-devel jansson-devel \
   openssl-devel libsrtp-devel sofia-sip-devel glib2-devel \
   opus-devel libogg-devel libcurl-devel pkgconfig \
   libconfig-devel libtool autoconf automake

Notice that you may have to yum install epel-release as well if you're attempting an installation on a CentOS machine instead.

On Ubuntu or Debian, it would require something like this:

apt install libmicrohttpd-dev libjansson-dev \
	libssl-dev libsofia-sip-ua-dev libglib2.0-dev \
	libopus-dev libogg-dev libcurl4-openssl-dev liblua5.3-dev \
	libconfig-dev pkg-config libtool automake
  • Note: please notice that libopus may not be available out of the box on your distro. 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. To build libnice, you need Python 3, Meson and Ninja:

git clone https://gitlab.freedesktop.org/libnice/libnice
cd libnice
meson --prefix=/usr build && ninja -C build && sudo ninja -C build 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. While 1.5.x is supported, we recommend installing 2.x instead. 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

Notice that the --enable-openssl part is important, as it's needed for AES-GCM support. As an alternative, you can also pass --enable-nss to have libsrtp use NSS instead of OpenSSL. A failure to configure libsrtp with either might cause undefined references when starting Janus, as we'd be trying to use methods that aren't there.

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 (which is NOT recommended), 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 --disable-programs --disable-inet --disable-inet6
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 v4.3-stable
mkdir build
cd build
# See https://github.com/meetecho/janus-gateway/issues/732 re: LWS_MAX_SMP
# See https://github.com/meetecho/janus-gateway/issues/2476 re: LWS_WITHOUT_EXTENSIONS
cmake -DLWS_MAX_SMP=1 -DLWS_WITHOUT_EXTENSIONS=0 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_C_FLAGS="-fpic" ..
make && sudo make install

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:

On Fedora:

yum install doxygen graphviz

On Ubuntu/Debian:

aptitude install doxygen graphviz

Compile

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 the meanwhile.

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:

./configure --disable-websockets --disable-data-channels --disable-rabbitmq --disable-mqtt

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 FreeBSD

  • Note: rtp_forward of streams only works streaming to IPv6, because of #2051 and thus the feature is not supported on FreeBSD at the moment.

When building on FreeBSD you can install the depencencies from ports or packages, here only pkg method is used. You also need to use gmake instead of make, since it is a GNU makefile. ./configure can be run without arguments since the default prefix is /usr/local which is your default LOCALBASE. Note that the configure.ac is coded to use openssl in base. If you wish to use openssl from ports or any other ssl you must change configure.ac accordingly.

pkg install libsrtp2 libusrsctp jansson libnice libmicrohttpd libwebsockets curl opus sofia-sip libogg jansson libnice libconfig \
    libtool gmake autoconf autoconf-wrapper glib

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:

brew install jansson libnice openssl srtp libusrsctp libmicrohttpd \
	libwebsockets cmake rabbitmq-c sofia-sip opus libogg curl glib \
	libconfig pkg-config autoconf automake libtool

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.:

./configure --prefix=/usr/local/janus PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig

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

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=address:port
                              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)
-2, --keep-private-host       When nat-1-1 is used (e.g., Amazon EC2
                              instances), don't remove the private host,
                              but keep both to simulate STUN  (default=off)
-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)
-O, --ipv6-link-local         Whether IPv6 link-local candidates should be
                              gathered as well  (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)
-Q, --min-nack-queue=number   Minimum size of the NACK queue (in ms) per user
                              for retransmissions, no matter the RTT
-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
                              (default=0, feature disabled)
-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=200ms)
-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)
-w, --no-webrtc-encryption    Disable WebRTC encryption, so no DTLS or SRTP
                              (only for debugging!)  (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.

Documentation

Janus is thoroughly documented. You can find the current documentation, automatically generated with Doxygen, on the project website.

Help us!

Any thought, feedback or (hopefully not!) insult is welcome!

Developed by @meetecho