Fork me on GitHub
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
Frequently Asked Questions

This page contains a list of FAQ as gathered on the meetecho-janus Google group and the Issues page on GitHub. It obviously also includes things we're being asked all the time in general! If your question is not listed here or not available anywhere in this documentation, feel free to refer to the group for generic help, or to the Issues page for bugs in the implementation.

  1. What is Janus?
    Janus is an open source WebRTC gateway written by Meetecho, conceived as modular and, as much as possible, general purpose. It acts as a WebRTC endpoint browsers can interact with, and different modules can determine what should be done with the media. This means that you can do SIP, videoconferencing, streaming and tons of other stuff using the same box! And if what you need is not there, you can always write your own module and expand Janus.

  2. What is Meetecho?
    Meetecho is a startup founded by a few researchers, post-docs and Ph.Ds coming from the Universty of Napoli Federico II. We've been working on real-time multimedia applications over the Internet for years, and at one point we decided to try and make products out of our research efforts. Our web conferencing platform and Janus is part of those efforts.

  3. Now that we're at it, how is Meetecho pronounced??
    We're being asked that a lot! We've heard so many variants and different pronounciations of the name that we could make a book out of it! When we chose the name, we wanted it to sound like this, which means awesome! in Italian. The extra H was a mistake on our side, as obviously echo is pronouced differently than eco! Long story short, it doesn't really matter how you pronounce it: just do it and help us be famous! :-)

  4. Why is Janus called like that?
    Quoting Wikipedia: "In ancient Roman religion and myth, Janus (Latin: Ianus, pronounced [ˈiaː.nus]) is the god of beginnings and transitions, and thereby of gates, doors, passages, endings and time. He is usually depicted as having two faces, since he looks to the future and to the past." Considering the general purpose nature of our gateway, where one face always looks at the future (WebRTC) and the other at the past (whatever the modules allows you to do, be it legacy stuff or not), Janus looked like the perfect name for it! And besides, we're Italian, Ancient Rome was awesome and mythology rules... ;-)

  5. Is the license AGPL or GPL? Do you provide alternative license mechanisms as well?
    First, a word of update: we recently switched from AGPLv3 to GPLv3, so if AGPL was your concern, we hope this simple choice managed to change your mind on whether considering trying Janus or not!

    That said, we initially chose AGPL for a simple reason: we wanted our work to be open source, and we wanted interested people to play with it and contribute back whatever improvement they could provide to the core. This is not always the case with open source software, which is sometimes just seen as free stuff you can exploit without helping back, and AGPL looked like the easiest way to do that. We've been made aware that this license mechanism is not very appreciated around, especially because of some interpretations about it that could affect the way proprietary stuff is deployed. We obviously cared about these concerns, and that's what eventually lead to pick GPLv3 as a license, which should make it easier for Janus to be integrated in heterogeneous scenarios.

    Apart from that, we're obviously also willing to discuss different licensing agreements with interested parties, including commercial ones. Sponsored development can also be considered, so if you're interested in more details just contact us.

  6. On what OS can I install Janus?
    At the moment only Linux is supported. While a more cross-platform approach has been considered, there are no plans to work in that direction in the near future, as we're mostly interested in adding new features and improving/enhancing what's already there.

  7. I've launched Janus, how do I try the demos?
    The demos are available in the html folder in the project. That said, the integrated web server in Janus does not serve static files as well, so you'll have to make them available using a different webserver. Details about how to deploy Janus are provided in Deploying Janus.

  8. Are Data Channels supported?
    Yes they are! Starting from version 0.0.3 of Janus, we added a first experimental support to Data Channels, that can as such be used in plugins that choose to support them. Right now, they are only handled in the Echo Test plugin, but this will be added to other plugins as well, if not just to showcase what can be done with them.

    Please notice that right now we only support text data: we're currently working on binary streams as well, so we hope support for those will be available soon.

  9. I don't care about Data Channels, do I have to compile usrsctp anyway?
    Support for Data Channels is optional. If you don't care about them, but only about audio and/or video, pass the –disable-data-channels option to the configure script. If you already attempted an install previously, issue a make clean before compiling again, or you might encounter issues with pre-existing symbols.

  10. I can't install usrsctp, I'm getting errors about dereferencing pointers?
    Apparently recent compilers are stricter with respect to some code syntaxes, and this seems to be affecting the way usrsctp is written as of now. Some users managed to fix this issue by passing an export before the bootstrap and configure steps in the usrsctp compilation:

      export CFLAGS="-fno-strict-aliasing" ./boostrap
      export CFLAGS="-fno-strict-aliasing" ./configure --prefix=/usr
      make && make install
    
    Another solution seems to be removing all the -O2 occurrences in the generated configure script.

  11. Can I use Janus as a gateway to my Freeswitch/Kamailio/Asterisk/other SIP infrastructure?
    Of course! One of the modules we provide out of the box is a SIP gateway plugin based on the Sofia-SIP library stack. These plugin allows a web user to register at a SIP proxy/server either as an authenticated user or as a guest, and start or receive calls from other SIP users, including other web users exploiting the same plugin. Janus will take care of all the WebRTC-related stuff (ICE, DTLS, SRTP), which means that on the SIP side it will be plain RTP only, much easier and lighter to handle for legacy implementations. This has so far only been tested with Kamailio and Asterisk but, since a well known and reliable stack like Sofia is being used for the purpose, it should work fine with other implementations as well.

    Please notice that there's definitely room for improvement in this module (e.g., video support is a bit flaky right now), so let us know if you encounter any problems with it!

  12. Can I use existng SIP stacks (e.g., JsSIP) with Janus?
    Janus uses a custom JSON-based protocol for all the communication between web users and plugins in the gateway, so no, that's not possible right now. The SIP plugin in Janus only exposes some very high level information to web users (e.g., registration failed/succeeded, incoming call, decline, hangup, etc.), without delving in any SIP-related detail, which is instead completely demanded to the server-side plugin itself. This ensures that web users can take advantage of SIP functionality in an easy way, without having to worry about the details and complexity of SIP within JavaScript.

  13. Does Janus support transcoding?
    Janus is a simple intermediary between WebRTC users and server-side plugins providing application logic, so no, it doesn't provide any transcoding functionality per-se. If transcoding is needed, this is supposed to be implemented within plugins themselves. That said, none of the plugins we provide out-of the box does transcoding, since we wanted the implementation to be lightweight and besides there are several existing tools and third-party implementations that could be leveraged for the purpose.

  14. Does Janus support recording?
    See above: no recording functionality is provided by Janus itself, as that's something that should be done by plugins as part of their application logic. That said, unlike transcoding some of the plugins do implement some sort of recording feature. Specifically, the Audio Bridge plugin allows for a recording of the mixed audio room to an uncompressed WAV file; the Voice Mail plugin, instead, allows for the recording of audio frames provided by a web user to an .opus file, for the purpose of archiving. The same functionality could be easily migrated to other plugins, and work is being done to do the same for video as well (something that we have ready, but currently introduces too many dependencies that we'd rather avoid).

  15. Can I use WebSockets instead of plain HTTP to interact with Janus?
    Since version 0.0.4, you can! At first we chose a REST-based plain HTTP communication for a simple reason: we noticed that there were some scenarios (e.g., client firewalls) where websockets wouldn't work, even though WebRTC did. To improve the chances of success in the communication, we then chose this simpler approach with respect to signalling. Besides, plain HTTP is much easier to proxy and/or place behind frontends like Apache HTTPD or nginx than WebSockets, another aspect that played a decisive role in our decision, as we were also very interested in making the integration of Janus in heterogeneous environments as easy as possible. That said, WebSockets also provide substantial benefits when compared to plain HTTP, and definitely make life easier to server side integrators as well, e.g., in terms of overhead and use of resources. For this reason, we added an optional (meaning you can skip it if you want) support for WebSockets that uses the same API already available in HTTP, as documented in the WebSockets Interface.
    Note
    Please beware that support for WebSockets is still highly experimental, so handle that with care!

  16. Can I use RabbitMQ instead of HTTP/WebSockets to interact with Janus?
    Since version 0.0.6, you can! This is a feature that several developers asked for, especially those that are interested in wrapping the Janus API on the server side, and implement the communication on the client side their own way. Specificaly, Janus now supports RabbitMQ based messaging as an alternative "transport" for API requests, responses and notifications, meaning it can be used with or without HTTP and WebSockets, depending on your requirements. To implement a pseudo-bidirectional channel using RabbitMQ, Janus makes use of two different queues: one to receive messages, and another one to send responses and notifications. Since this support is in its early stages, right now you can only have a single "application" talking to a specific Janus instance using RabbitMQ messaging, meaning that Janus won't implement multiple queues to handle multiple concurrent "application servers" taking advantage of its features. Support for this is planned, though (e.g., through some kind of negotiation to create queues on the fly). If you're going to use the same RabbitMQ server for handling multiple Janus instances from the same application or different ones, make sure you configure different queues for each of them (e.g., from-janus-1/to-janus-1 and from-janus-2/to-janus-2), or otherwise in case of "conflicts" more instances will end making use of the same queues and messages will get lost.
    Just as with WebSockets, the Janus API usage when involving RabbitMQ is exactly the same as the one for HTTP and WebSockets, as documented in RabbitMQ interface.
    Note
    Please beware that support for RabbitMQ is still highly experimental, so handle that with care!

  17. Can I use Janus with node.js or other frameworks?
    Not out of the box, but since interaction with Janus can be completely HTTP/WebSockets based, this can be abstracted in several different way. With respect to node.js, NICTA recently released a module called rtc-janus that allows you to interact with a Janus instance from a node.js application, so give that a try!

  18. Is there any benchmark on Janus performances?
    Benchmarking Janus is not an easy task, especially if we consider its general purpose nature. In fact, Janus by itself does not much more than negotiating WebRTC PeerConnections and relaying frames around, while most of the application login is in the modules. As you can imagine, different modules may have very different requirements and impact on the performances. For instance, the Echo Test is probably much lighter than the Video MCU, even if they're handling the same number of users. This means that such a benchmarking does not have much sense unless you contextualise the scenarios.

    For this reason, we and some Janus adopters have recently tried to do some benchmarking taking a specific plugin as a reference, that is the Video MCU: in fact, the Video MCU is one of the most popular modules in Janus, and by itself it does represent a good test bed considering its many-to-many communication pattern. You can find some details and considerations in a recent post on our Google group.

    You can find more results in a publication we made at the All-Web real-time Systems (AWeS 2015) workshop.

  19. I want to write my own plugin, where do I start?
    Great! There's an API you can refer to, documented in Plugin API. Since you'll want your web users to interact with it, make also sure you study the JavaScript API as well, especially the parts that talk about how to send/receive messages and negotiate WebRTC PeerConnections. The existing plugins are also an excellent way to start to get comfortable with the API: a good starting point may be the Echo Test plugin, which is a very simple and barebone implementation that simply bounces back whatever it is sent, and also involves some rough application logic to determine its behaviour (e.g., messages coming from web users that selectively enable or disable video). If you need any help with this, feel free to contact us: we're excited to see who will make available the first third-party Janus plugin!

  20. I'm using the Video MCU and, when several users are handled, I get a "Too many open files" errors and Janus crashes
    As all applications on Linux environments, Janus is bound to the constraints imposed by the OS and/or the user. One of these constraints is related to how many file descriptors the application, or all the applications, can open. On several distributions this number is, by default, quite low, which can cause the issue you experienced. This value, together with others, can be modified, per-user or for all users, using the ulimit application. For a simple and quick way to handle this refer to the guide provided by the MongoDB developers: http://docs.mongodb.org/manual/reference/ulimit/

  21. When I enable the HTTPS web server in Janus, the CPU goes crazy
    As discussed in a recent post on our Google group, this is caused by an occasional problem within libmicrohttpd, the library we use to implement an embedded web server in Janus. This is not deterministic, as the high CPU usage does happen on some distributions (e.g., Ubuntu 12.04), while it doesn't on others (e.g., Ubuntu 14.04). Anyway, this only can happen if you enable HTTPS support within Janus itself: you can still have a safe HTTPS usage with Janus if you deploy it behind a frontend (e.g., Apache HTTPD) that takes care of this on its behalf. Refer to the Deploying Janus section for more details about this.

  22. I enabled TURN in the Janus configuration, but my clients behind a firewall can't connect
    As explained in the janus.cfg documentation, the TURN settings you configure there refer to Janus itself, not the clients that make use of its services. This means that, whether you configure a static TURN server and the related credentials, or the REST API client stack to retrieve them dynamically, you're asking Janus to gather relay candidates for ITSELF. This is only useful if you know that your Janus instance will not be deployed on a public address (as it usually will) but will instead potentially sit behind a restrictive component like a firewall, or if you simply want to limit the number of open ports and so force all media traffic to go through the TURN server port alone.

    If you want your clients to gather relay candidates, instead, this needs to be done on the client side (e.g., in JavaScript, if your clients are web applications). If you're using our JavaScript API check the echotest.js code, which has a commented portion that explains how to provide one or more TURN servers to make use of. If you're handling the WebRTC-related stuff on your own and are contacting Janus some other way, please refer to the related way of specifying STUN and TURN servers instead.

  23. Can you implement a feature I want?
    We're constantly working on new features and on improving what's already there, and we do love feedback from users. That said, we're a small team and we do have to pay our bills, so we always have to reserve our resources wisely. If there's a feature you'd like to see implemented, tell us on our Google group, and discuss it with other users: it may be on our schedule, or someone else may be already working on it to contribute it back to the project. You may even want to try and build it yourself and help us make Janus even better! If you really need something that isn't there, you may also want to consider a sponsored development or contact us for consulting.