Live data from Hacker News

Janus WebRTC Server

janus.conf.meetecho.com

11–20 of 65 posts

Re: Janus WebRTC Server

#11

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... 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 anyon…

Out of curiousity: What is an edge device? An IP camera? Depending on the professional grade of your use case, you could directly talk to meetecho, as they are the original developers and offer consultancy around Janus.

Re: Janus WebRTC Server

#12

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.

Have you looked at mediasoup?

Re: Janus WebRTC Server

#13
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?

Re: Janus WebRTC Server

#14
post #6

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

WebRTC is the good old RTP, on steroids.

It standardizes a set of conventions that web browsers could follow to a) solve the issue of NAT traversal (i.e. opening ports in consumer routers and firewalls), b) send video and audio (and possibly also arbitrary data), directly between web browsers, and c) possibly adapt the video quality to the conditions of the network, in an autonomous and automatic way.

That's the bird's-eye view of it.

Some keywords to expand on this: "a)" is done with the ICE protocol, "b)" is done with plain old SRTP, and "c)" is done with algorithms called REMB or Transport-CC.

Re: Janus WebRTC Server

#15
post #4

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.

What turn servers do you use?

We use coturn as the TURN solution and talk to the Janus API via websockets (we found it much better then REST if the msg rate is high)

Re: Janus WebRTC Server

#16
post #3

We changed the URL from 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 .

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

Re: Janus WebRTC Server

#17
post #10

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... 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 anyon…

If you are interested in cross-compiling the WebRTC implementation so it runs directly from within edge devices, Janus might be one of the best options out there. Kurento offers a variety of features apart from WebRTC, but it is more intended to be cloud-deployed as an independent media server, you could think of it as a "proxy/bridge" that distributes media between producers (like RTSP cameras) and consumers (WebRTC…

I've been vetting solutions in the space and I think I have a need for both...

I'm having a hard time figuring out direct streaming from device on your local LAN without having to go out/back-in through the public internet with a hard requirement of an encrypted "point-to-point" communication (ie: can't listen into streams) which is browser trusted + the ability to ship that out to a "proxy/bridge" media server solution like you describe.

I've looked at EvoStream and Wowza as licensed solutions and I am super interested in the ability to use something like Kurento with ideally self-signed certificates to a cloud-deployed/redundant media bridge that then in-turn broadcasts to the remote clients who are consuming via the public internet.

The OpenCV tie-in with Kurento would be of great interest to me as well. That could be a game changer for what I'm currently embarking on!

Would a hybrid approach make sense to you as you're definitely an expert in this space? (ie: using Janus on-edge and Kurento in the cloud at the same time)

PS: I apologize if my questions/communication is rough... I'm two weeks into a nightmare trying to sort all of this out so I'm still coming up-to-speed on the technical details of WebRTC + secure streaming!

Re: Janus WebRTC Server

#18
post #11

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... 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 anyon…

Out of curiousity: What is an edge device? An IP camera? Depending on the professional grade of your use case, you could directly talk to meetecho, as they are the original developers and offer consultancy around Janus.

IP cameras mostly, some remote-audio stuff - I think that may be a logical next step for me so I'm going to bring that up to leadership tomorrow.

Re: Janus WebRTC Server

#19
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/

Re: Janus WebRTC Server

#20
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, 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/

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

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

[3] https://webrtcbydralex.com/index.php/2018/03/14/extending-ja...

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

[5] https://www.callstats.io/blog/what-is-unified-plan-and-how-w...

Post reply on HN