The perfect Janus server stack

411 views
Skip to first unread message

Ancor Gonzalez Sosa

unread,
Nov 24, 2015, 2:17:40 AM11/24/15
to meetecho-janus
Once in a while we see in this group or in the issues section of github reports about Janus instability. For some people, using a concrete commit of BoringSSL improves things. Others have reported problems with libnice and quite some people have some mechanism in place to periodically restart Janus. So, in general stability seems to depend a lot of the operating system and the libraries stack.

I was wondering if somebody (Lorenzo?) with a completely stable Janus (no openSSL errors, no libnice errors, no need to restart, etc.) could describe their whole stack: version of operating system, concrete version of every involved library (which rpm or even if installed manually) so somebody can create a container with the same setup.

I general, I dislike the idea of containers for production environments but in this case I think the idea is worth a try.

Thanks.

Lorenzo Miniero

unread,
Nov 24, 2015, 4:31:45 AM11/24/15
to meetecho-janus
I'll leave it to others to share their experience with Janus, as somebody already did in some more or less recent posts (Pierce also shared his own approach to building Janus in their environment on github), so I'll just give my two cents here.


We have no secret recipe: we do make use of containers but that's just a commodity, we still build Janus as I believe everybody else does. Ubuntu 14.10 (or later? can't recall, I don't handle that part) servers, libsrtp compiled manually, whatever libnice is available, and lately we switched to BoringSSL ourselves as well.

We only experienced the infamous OpenSSL alert bug twice in two years and it appeared to be completely random, so considering most people feel more comfortable with BoringSSL we decided to give it a try as well. I think it was Pierce that found out that BoringSSL didn't suffer from the same issue as in that fork they improved some thread-safe mechanisms internally in the library, but I'm not such an expert in OpenSSL to say that it was indeed the case. We're already trying to be as thread-safe as possible within the core, so I'm not sure what else we might do to fix the plain OpenSSL usage (if it's something we can do at the application level and that does not need internal fixing, I mean); feedback and, more importantly, help in that direction would be cool, as I can't tackle everything by myself.

As to libnice, things have greatly improved in the latest (see, post modular-transports) Janus revision, as we fixed some TCP-related leaks that were lingering there, and that I believe could affect performances in the long run (or more precisely, those leaks are not a problem anymore when you don't enable ICE-TCP, when you do they're still there but it's a known issue that will be solved in the upcoming libnice 0.1.14 revision so not a Janus issue). Besides, we also took care of what prevented recent libnice versions to be used effectively (the "spinning threads" issue), and so there's no costraint on using a specific version there either. If you're already using the latest version (0.1.0) with the latest libnice available in your distro you should have noticed some improvements.

Not sure how many people out there are using data channels as extensively as you do, so I can't share any specific feedback on this. We do use it in part for chat only in some setups where we don't want any messaging infrastructure: when I say chat, though, I mean text messages only, so no base64-encoded data and the like.


Hope that helped, looking forward to more comments from the community,
Lorenzo


 
Thanks.

Ancor Gonzalez Sosa

unread,
Dec 4, 2015, 2:37:44 AM12/4/15
to meetecho-janus
El martes, 24 de noviembre de 2015, 10:31:45 (UTC+1), Lorenzo Miniero escribió:

Hope that helped, looking forward to more comments from the community,

With current revisions of Janus finally fixing the openSSL errors, I now feel confident to list my setup in this (still short) list of "perfect" setups.

I'm running Janus on a SUSE Enterprise Linux Server 12 using the packages from this repository
https://build.opensuse.org/project/show/home:mlin7442:hackweek11

Everything from RPM packages, nothing compiled in the host.

The same repository should work nicely for openSUSE 13.1, 13.2 and Tumbleweed. In fact, my development machine is an openSUSE Tumbleweed with these packages. Everything works.

Cheers.

Lorenzo Miniero

unread,
Dec 4, 2015, 2:45:59 AM12/4/15
to Ancor Gonzalez Sosa, meetecho-janus

Good to know we're not just suited for small/medium teams with a hand on the reboot button anymore ;-)

L.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pierce Lopez

unread,
Dec 9, 2015, 8:25:03 PM12/9/15
to meetecho-janus
On Friday, December 4, 2015 at 2:37:44 AM UTC-5, Ancor Gonzalez Sosa wrote:
With current revisions of Janus finally fixing the openSSL errors, I now feel confident to list my setup in this (still short) list of "perfect" setups.

I'm running Janus on a SUSE Enterprise Linux Server 12 using the packages from this repository
https://build.opensuse.org/project/show/home:mlin7442:hackweek11

Everything from RPM packages, nothing compiled in the host.

The same repository should work nicely for openSUSE 13.1, 13.2 and Tumbleweed. In fact, my development machine is an openSUSE Tumbleweed with these packages. Everything works.

I'll go ahead and post my own janus+libs build script here so more people may find it - https://gist.github.com/ploxiln/a78867604cde1c6b7e0e
I've used it on ubuntu-14.04 and debian-8, in both docker containers and full servers, and I expect it works with later ubuntu releases as well.

All custom-built libraries (including openssl or boringssl) are installed to /opt/janus-gateway/ by default (as well as janus itself). You can adjust that in a variable at the top of the script, and there are a few more variables there which you should review.

By default this script disables all plugins/transports except for echotest, videoroom, http, and websockets. You can adjust that at the top of the script, but other modules may have more dependencies which the script as-is does not provide. Anyway it should be a good starting point; I hope it helps people get started building and customizing janus in a reliable way :)

Kaplan

unread,
Nov 1, 2016, 11:32:27 AM11/1/16
to meetecho-janus, pie...@samsungaccelerator.com
thanks for sharing this, it just helped me a lot!
Reply all
Reply to author
Forward
0 new messages