
Janus WebRTC Server - simonpure
https://janus.conf.meetecho.com/
======
folkhack
Having to look into this professionally for local/remote streaming solutions
and came across this paper in the last couple of weeks which has been a _huge_
help to understanding my use case:

[http://lup.lub.lu.se/luur/download?func=downloadFile&recordO...](http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8995044&fileOId=8995045)

One of the most useful/interesting use cases to me is the ability to have a
PTP encrypted stream without having to go through weird IoT PKI hoops.

Ninja edit: If anyone has experience with Janus and/or WebRTC on edge devices
I would very much like to talk as I could _really_ use a solid consultant in
this realm.

~~~
Sean-Der
I do WebRTC on Edge/IoT devices (mostly MIPS/ARM devices running Linux).
Customers are mostly teleoperations (robotics) and security cameras.

Most customers run an MCU/SFU on a server, but then just a WebRTC client on
the device. We do simulcast on the device to an SFU, and then distribute from
there. Happy to answer questions here or directly.

I don't want to be disrespectful and sell other stuff on this thread though. I
like seeing people realize how great Janus is :) don't want to distract from
that conversation!

~~~
folkhack
I'm concerned in targeting things like Janus etc to the MIPS architecture for
streaming over WebRTC because typically I only see MIPS on legacy devices in
my world. How does MIPS handle this stuff?

PS: I know that Amazon has a product in the space and we're vetting AWS as our
cloud provider due to it's diverse product offering. I've been looking at
opensource solutions due to vendor lock-in but would love to hear if you have
any experience with the Amazon offering!

~~~
kdkeyser
MIPS is still alive in the IP camera world. There exist very cheap SoC's (e.g.
the Ingenic T20 -
[http://www.ingenic.com.cn/en/?product/id/14.html](http://www.ingenic.com.cn/en/?product/id/14.html)
), tailored towards making cheap network camera's (~ €20 retail price for the
full camera). I guess at that price point, the ARM license fee does become
visible in the bill of materials.

~~~
exikyut
Incidentally the Allwinner F1C100s used in this business card
([https://www.thirtythreeforty.net/posts/2019/12/my-
business-c...](https://www.thirtythreeforty.net/posts/2019/12/my-business-
card-runs-linux/),
[https://news.ycombinator.com/item?id=21871026](https://news.ycombinator.com/item?id=21871026))
contains an ARM9 series core clocked at 900MHz alongside 32MB of on-die DDR1,
is designed for dashcam-type applications (SDIO, LCD, USB2 OTG, no PHY) and
the author of the linked article was able to buy them for $1.42 each.

I've long been curious about MIPS from a hobbyist/tinkerer/maker perspective
and would be very interested to know what silicon I might select at a similar
price point.

------
j1elo
I'll chime in to comment that WebRTC, as complex as it is, is of course
usually just one part of the equation, and arguably a small one.

You'll have to correctly deploy your servers, a TURN server to aid with ICE
(NAT/Firewall traversal), and configure it all appropriately in both server
and client browser applications. It is surprising how many people have
problems with getting ICE, STUN and TURN servers, to work correctly,
understandably because it is a complex topic.

Then once you have the basics of streaming media over the network, and your
application developed (think video-based customer support, education
conference, any stuff for which WebRTC is a good choice), there are still a
myriad of things to worry about for a production-grade service: user
permissions, autoscaling, metrics gathering, dynamic distribution of all the
video streams through multiple media servers in order to accomodate for
varying loads, etc.

While developing Kurento, I also work with the team that makes OpenVidu, a
project that builds _upon_ Kurento and aims to provide an all-in-one solution
to all these problems, and handles all complexity of WebRTC for you.

Have a look at it if you need more than just the basics offered by media
servers such as Janus, Jitsi, mediasoup, or Kurento itself:

[https://openvidu.io/](https://openvidu.io/)

------
VWWHFSfQ
For those that are interested in Janus and WebRTC in general, I highly
recommend reading Lorenzo Miniero's (creator of Janus) Ph.D thesis [1] on the
project and the state-of-the-art of WebRTC. It's brilliant and enlightening.
The Janus project is a really marvel of engineering.

[1]
[http://www.fedoa.unina.it/10403/1/miniero_lorenzo_27.pdf](http://www.fedoa.unina.it/10403/1/miniero_lorenzo_27.pdf)
(PDF)

~~~
lminiero
I didn't know anyone else apart from me and and my tutor had read my Ph.D
Thesis... :-) Glad you found it informative! Janus was indeed born during my
research efforts there.

------
spicyramen
Janus is amazing, very easy to use. I used to develop MCU/voice control
Systems but unfortunately for large companies you really need a dedicated team
to manage this Infrastructure. (scheduling, video/voice quality issues, among
other things) good if you have the resources to do it

------
greatjack613
Newbie here,

Can someone explain why webrtc needs a server and how Janus fulfills this
role?

As far as I understand webrtc is meant to be peer to peer with minimal server
signaling, so what role does a WebRTC server play?

~~~
Sean-Der
These are the big points I see for servers, I am sure there are more though!

* Less resource usage for users

If you do mesh signaling every user connect with each other via P2P. This
means if you have a 4 person conference call everyone needs to upload their
video 3 times. If you have a media server each user uploads only once, and
then the server distributes the video. This means a lot less CPU and network
usage for each user.

* P2P Connections reveal details about the user

If users are connecting directly to each other they are able to figure out
details like their public IP. If you route everything through a server you can
anonymize more things.

* Protocol Bridging

People want to view RTSP/RTMP/$X via WebRTC. A media server is the only way to
make it happen.

* Less variability to deal with

When doing P2P connections you will deal with a lot more variables. It will be
harder to figure out which user's internet is causing issue, or debug
encode/decode issues. A few times running a SFU has come really in handy
because I was able to debug something that would have been impossible when
just doing P2P.

------
bigmanwalter
Just finished setting up a Janus server while building a web application in
the education space which needed video chat and the ability to record the
videos.

Absolute dream to work with! Thank you Lorenzo and the rest of the Janus team.
Hopefully we'll get the chance to make it down to Janus Conf!

If anyone is looking for help adding it to their app hit me up!

------
jtchang
I am currently working on a project to solve my own needs around this. If
anyone wants to collaborate or chat about it please e-mail me. I've done some
work around the Xiaomi cameras with the custom firmware so love to talk to
others about what they want to see.

~~~
kdkeyser
I hacked together a proof of concept of using Janus to wrap the H264 RTSP
stream of the Xiaomi Dafang into a WebRTC stream without transcoding, giving
close to real-time streaming of the ip camera to browsers without needing a
plug-in.

Currently, Janus and Nginx (https/auth) run on a cheap VPS, and a device in
the NAT network of the ip camera creates a Wireguard tunnel to get the RTSP
stream to the VPS without needing to open/forward ports on the NAT.

Ideally, more of the components could run on the camera itself, but I haven't
gotten to cross compile anything to the MIPS cpu of the Xiaomi camera. Will
contact you so we can chat.

------
bbeausej
We use Janus as a WebRTC SFU for projects in the education/gaming sector. Its
general purpose approach to WebRTC has been a good foundation to help us build
custom solutions.

~~~
carlsborg
What turn servers do you use?

~~~
mboehm
Answering for myself, not for bbeausej. We are currently using coturn. It is
quite easy to setup, you have to dig a little into the configuration parameter
and that's it - I would recommend it.

Oh well, you probably should use the rest api for generating credentials on
the fly and think about scaling (depending on your needs).

~~~
carlsborg
What percentage of sessions do you see going through turn?

------
mboehm
We started our journey with Janus about three months ago and I can just fully
recommend it. It is an amazing well-written piece of software which is just as
flexible and integrative as developers wish. E.g. Slack used Janus, at least
in 2016 [0]. It is important to understand: Janus offers the ingredients for
building great WebRTC applications (examples [1]), whereas Jitsi is more like
a ready-to-go solution and got much more attentation as Janus did.

Lorenzo and his colleagues are doing a really great job.

In the space of SFU/MFU, one really needs to decide beforehand what kind of
solution is suitable for which requirement. I have chosen Janus because we
could integrate it by 100% in our software. For example, I was also looking
into Jitsi. But compared to Janus it feeled so much more complicated and not
suited for that specific job.

However, it is important to point out, that this is no a ready-to-go solution.
There is a long list of things you will have to dig into:

\- ICE (a way to connect if you switch between WIFI and LAN or to punch a hole
into your fw) [2]

\- Cross-browser compatibility (Thank you iOS [4])

\- TURN/STUN (Which matrix of udp/tcp and ports is needed for Hole Punching?),
I recommend coturn.

\- Scalability: How many clients are planned? In my experience, CPU and
bandwith are bottlenecks, we went with horizontal scaling

\- How do you gonna test your WebRTC application? So far great results with
[https://testrtc.com](https://testrtc.com), but you probably also could
accomplish a lot with Selenium.

\- Simulcast/Bitrate or Unified Plan (Use available bandwith and adapt on-the-
fly) [3][5]

But once you got it running, it is an amazing feeling. We are in 2020 and it
is possible for an SMB to offer video conferencing to customers via a web-
browser using your own infrastructure while being compliant to GPDR and other
stuff.

[0] [https://webrtchacks.com/slack-webrtc-
slacking/](https://webrtchacks.com/slack-webrtc-slacking/)

[1]
[https://janus.conf.meetecho.com/demos.html](https://janus.conf.meetecho.com/demos.html)

[2] [https://webrtcglossary.com/ice/](https://webrtcglossary.com/ice/)

[3] [https://webrtcbydralex.com/index.php/2018/03/14/extending-
ja...](https://webrtcbydralex.com/index.php/2018/03/14/extending-janus-webrtc-
bandwidth-management/)

[4] [https://webrtchacks.com/guide-to-safari-
webrtc/](https://webrtchacks.com/guide-to-safari-webrtc/)

[5] [https://www.callstats.io/blog/what-is-unified-plan-and-
how-w...](https://www.callstats.io/blog/what-is-unified-plan-and-how-will-it-
affect-your-webrtc-development)

------
xmichael99
I checked out the project on github, and I was a little surprised to see no
mention of jsmpeg.com as over on that project the number one question and
issue is the lack of a quality web socket server. Long story short, anyone try
this or think it would fit with jsmpeg?

~~~
lminiero
Janus only supports WebRTC, and WebRTC doesn't support MPEG out of the box (to
be more precise, it's not in the codecs list any endpoint supports). Besides,
streaming happens over WebRTC, not WebSockets: we only use WS as one of the
alternative "transport" protocols for the Janus API, so just signalling.

------
nerdbaggy
We use Janus for a few hundred clients all spread out over a few instances. It
works great for us. We tried kurento and it was just soooo hard and complex to
setup. The Janus JS client library is pretty good and makes it really really
easy

------
tomasyany
How hard is to use Janus for a media server in the SFU paradigm? Or where
could I find a good example?

We currently use Kurento for the easiness of usage + the Java client, but we
have been wondering about other solutions like Janus.

~~~
VWWHFSfQ
You might check out Mozilla's SFU plugin [1] for Janus that powers Mozilla
Hubs [2]

[1] [https://github.com/mozilla/janus-plugin-
sfu](https://github.com/mozilla/janus-plugin-sfu)

[2] [https://hubs.mozilla.com/#/](https://hubs.mozilla.com/#/)

------
xvector
Why use C over Rust or Golang? It sounds like a security disaster waiting to
happen?

~~~
ibc
Yeah please, let the author know your preferred programming language so he'll
rewrite the whole software.

~~~
xvector
I wasn’t aware that the software had a history behind it, my bad.

------
amelius
Does anyone have a link which explains WebRTC technology in a concise way?

~~~
Sean-Der
I really want to write a book on this eventually, but I haven't found a good
single resource myself :( I have done some talks trying to explain WebRTC.
Happy to answer any questions

* Slides - [https://pion.github.io/talks/2018-11-28-seattle-video-tech.h...](https://pion.github.io/talks/2018-11-28-seattle-video-tech.html)

* Video - [https://www.youtube.com/watch?v=FdgoOrJH8ok&feature=youtu.be...](https://www.youtube.com/watch?v=FdgoOrJH8ok&feature=youtu.be&t=989)

* Video - [https://www.youtube.com/watch?v=ezZYd5NsxE4](https://www.youtube.com/watch?v=ezZYd5NsxE4)

\------

But when I teach others I try to break it down into a few unique chunks.

* ICE - Establishing P2P Communication

* DTLS/SRTP - Securing Communication

* SCTP - Sending binary data over UDP and handling loss

* RTP/RTCP - Sending media data over UDP and handling loss

------
dang
We changed the URL from [https://github.com/meetecho/janus-
gateway](https://github.com/meetecho/janus-gateway) to the project homepage,
which is generally preferred when a project is being discussed for the first
time on HN. Especially if it also links to its GitHub page or other
repository.

I found previous submissions, but no comments except
[https://news.ycombinator.com/item?id=22610510](https://news.ycombinator.com/item?id=22610510).

~~~
Uninen
Well, at least the GitHub page stays up under the traffic.

