"Gateway" seems to confuse people... what should we call Janus?

[Lorenzo Miniero]

Hi there,

we've been calling Janus a WebRTC Gateway since day one, mostly because it was initially conceived as a gateway between heterogeneous technologies. It can still be used for this (and it IS used like this by many) but Janus is indeed much more than just that, now. Since many people seem to be confused by the term Gateway, which seems to lead them to think Janus is mostly a SIP-related WebRTC component, we were thinking of a new way to call it.

The simplest name change that comes to mind is "Janus WebRTC Server", which is nice but also a bit boring... Any better suggestion from you guys?? :-)

Surprise me!

Lorenzo

[Saúl Ibarra Corretgé]

"Janus: The WebRTC Universal Business Adapter" -
https://www.youtube.com/watch?v=AIOqOxI0K_I

On a more serious note: "Janus: The (Multi-Purpose) WebRTC Application
Server" could do.

--
Saúl Ibarra Corretgé
http://bettercallsaghul.com

[Nolan Darilek]

3-4 years ago, when I was looking for something that did what Janus does, I kept searching for "web rtc server" and not finding anything. I too struggled with what someone would call a thing that intercepted web RTC so it didn't have to go direct and added additional functionality, and "server" is all that came to mind.

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

[Gustavo Henrique]

I was also looking for a server-side intercept of WebRTC when I found Janus, and had to understand the "gateway" concept while learning WebRTC. Some name that contains "server" or "server-side" could help people that are searching for that.

[Амнон Исраэли]

Janus WebRTC Media Server

Janus WebRTC Media Router :)

[Mike]

I also at first didn't find Janus. I found Kurento first, but i didn't quite meet my needs.

[Olga Khylkouskaya]

Hi Mike, 

can you please explain what Kurento didn't provide for you. We were also looking at it before, but Janus is much easier with rtp.

[Lorenzo Miniero]

I don't know much about Kurento, if not that it's based on gstreamer. When we started, there were several good servers that were too "vertical" in their scope: we wanted something more flexible and easy enough to use for different use cases, and something we had an intimate knowledge of so that we could fix/extend it at will, so that's why we started working on one ourselves.

L.

[Mike]

Hi Olga!

Kurento does transcoding for each client involved and this quickly becomes a performance issue 

with one 2 many scenarios. And i don't need the filtering (and augmented reality) support which Kurento offers (it is great if you need it!).

And the other reason why I switched to Janus is because it's written in C and the API is so straight forward

that I had a working prototype within couple of hours.

[Olga Khylkouskaya]

Thank you Mike, those are definitely issues for us. We need real time as close as possible. Agree with Lorenzo about flexibility. We can do any necessary transformation or AR in ffmpeg or our server. All we needed is signaling handler and piping between ws, http and rtp.

[Carlos González Florido]

Hi all.

We have studied deeply Janus, Kurento and Freeswitch.

From Janus, we love the "lightness". It feels so speedy and reliable. It is very easy to build a service in a couple of days, but it comes with a price. You can only do what some of the plugins can do, and the way they are designed to work (unless of course you write your own plugin, but that is not exactly easy or quick). If you want to connect a SIP endpoint to a SFU conference, you are out of luck. If you have your own users database, or SIP stack, it is not easy to use the API, you have to "emulate" user registrations, fake SIP requests, etc., only to get a "plain" SDP. Each plugin has a quite different API. Under this circumstances, it is not easy to use any more (but, again, IT IS for a 'normal' use case).

With Kurento, it is quite the opposite. It has a clean, powerful "agnostic" API and you can build nearly everything, but you have to provide your own signalling (what is a big plus of us, but probably a problem for many) and think a bit what you want to achieve. The JS and Java APIs are very well documented, but it is not easy to know how to connect the pieces together. It also "feels" heavier and more inestable than Janus, and it still misses some basic options like being able to fix the external IP and avoid generating 40 ICE candidates for each call. (BTW, Kurento does not transcode everyhing!! In fact, you can connect any number of clients to any endpoint (webrtc or rtp) without transconding). Another big plus is that, when recording, the recorded file is playable immediately without any post-processing, and is seekable from WebRTC or HTTP (you can "jump" to any point in the file, even on WebRTC). Also, we are facing problems with Kurento and last Chrome (only on OSX, Windows and Linux are fine, also Firefox on OSX).

Freeswitch has the best MCU module out there, by far. It also has PBX characteristics like DTMF detection, and the broader codec selection if you need transcoding (Kurento can only transcode mp4<->vp8). However, it also includes a signalling layer you have to emulate  (SIP and Verto) if you use your own. It does not have (and won't have) anything similar to a SFU.

We are writing a "meta" media server based on Janus, Kurento and Freeswitch (we may even add Jitsi in the future), because we think all three have advantages and disadvantages, and they are good for some cases and not so good for others:

• If you want a MCU (or video mixing), transcoding or PBX features, we use Freeswitch. Also for voice-only projects.
• If you want a standalone WebRTC Proxy or SIP <> WebRTC proxy, or a standalone SFU, go Janus
• If you need a more complex scenario (like SIP to SFU, or an SFU but you want to control the offer/answer process) or want video recording, we go Kurento.
• If you need to reuse the same WebRTC connection for different things, this is allowed only by Kurento and Freeswitch.

As I told Lorenzo, IMHO, Janus would be much more powerful if it offered the option to use and connect individual "elements" in the Kurento style: WebRTC endpoint, RTP endpoint, SFU, recorder and player, and not been only tied to specific plugins or behaviours. I'm sure the backend would support this, and you can do this writing a "special" plugin, but that is not easy for us (we are not C programmers). It would be then a lighter and more scalable alternative to Kurento for many more use cases.

[Miha Nedok]

Hello Carlos!

You havce very well put down about those 3.

My POV is somewhat a bit different because I am using Janus with my own plugin which I connect to my own backend system

for users sessions and media sessions and so on. Everything can be done with Janus in you plugin but the dev time can be 

a bit higher and steeper.

As for recording I agree, not just that the files from Kurento are playable instantly it's better for storage, that's why i was thinking

of creating a "mini recorder server" to which i would just forward the RTP packets and process them and spit them to the filesystem.

And again nice summary Carlos!

--
You received this message because you are subscribed to a topic in the Google Groups "meetecho-janus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meetecho-janus/r3f0_81mNR8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Olga Khylkouskaya]

Thank you Carlos, 

that's really a good answer! You saved me a lot of time :)

[Lorenzo Miniero]

Il giorno mercoledì 7 settembre 2016 20:37:18 UTC+2, Carlos González Florido ha scritto:

Hi all.

We have studied deeply Janus, Kurento and Freeswitch.

From Janus, we love the "lightness". It feels so speedy and reliable. It is very easy to build a service in a couple of days, but it comes with a price. You can only do what some of the plugins can do, and the way they are designed to work (unless of course you write your own plugin, but that is not exactly easy or quick). If you want to connect a SIP endpoint to a SFU conference, you are out of luck. If you have your own users database, or SIP stack, it is not easy to use the API, you have to "emulate" user registrations, fake SIP requests, etc., only to get a "plain" SDP. Each plugin has a quite different API. Under this circumstances, it is not easy to use any more (but, again, IT IS for a 'normal' use case).

That will change in the future, as Saùl and I have a plan to work on a plugin that would just give you the "plain" SDP, leaving the signalling details up to the developer.

 

With Kurento, it is quite the opposite. It has a clean, powerful "agnostic" API and you can build nearly everything, but you have to provide your own signalling (what is a big plus of us, but probably a problem for many) and think a bit what you want to achieve. The JS and Java APIs are very well documented, but it is not easy to know how to connect the pieces together. It also "feels" heavier and more inestable than Janus, and it still misses some basic options like being able to fix the external IP and avoid generating 40 ICE candidates for each call. (BTW, Kurento does not transcode everyhing!! In fact, you can connect any number of clients to any endpoint (webrtc or rtp) without transconding). Another big plus is that, when recording, the recorded file is playable immediately without any post-processing, and is seekable from WebRTC or HTTP (you can "jump" to any point in the file, even on WebRTC). Also, we are facing problems with Kurento and last Chrome (only on OSX, Windows and Linux are fine, also Firefox on OSX).

Freeswitch has the best MCU module out there, by far. It also has PBX characteristics like DTMF detection, and the broader codec selection if you need transcoding (Kurento can only transcode mp4<->vp8). However, it also includes a signalling layer you have to emulate  (SIP and Verto) if you use your own. It does not have (and won't have) anything similar to a SFU.

We are writing a "meta" media server based on Janus, Kurento and Freeswitch (we may even add Jitsi in the future), because we think all three have advantages and disadvantages, and they are good for some cases and not so good for others:

• If you want a MCU (or video mixing), transcoding or PBX features, we use Freeswitch. Also for voice-only projects.
• If you want a standalone WebRTC Proxy or SIP <> WebRTC proxy, or a standalone SFU, go Janus
• If you need a more complex scenario (like SIP to SFU, or an SFU but you want to control the offer/answer process) or want video recording, we go Kurento.
• If you need to reuse the same WebRTC connection for different things, this is allowed only by Kurento and Freeswitch.

As I told Lorenzo, IMHO, Janus would be much more powerful if it offered the option to use and connect individual "elements" in the Kurento style: WebRTC endpoint, RTP endpoint, SFU, recorder and player, and not been only tied to specific plugins or behaviours. I'm sure the backend would support this, and you can do this writing a "special" plugin, but that is not easy for us (we are not C programmers). It would be then a lighter and more scalable alternative to Kurento for many more use cases.

That would turn us into "Kurento lite". We're the developers of Janus ;-)

Jokes apart, partial chaining is in our minds sometimes, but we have no schedule or immediate plan to do anything in our direction. I believe our architecture is clear/clean enough as it is.

L.

[Carlos González Florido]

That's the thing, the architecture is more then enough clear an clean. It's a pity it cannot be used in a more flexible way easily ;-)

[Chad Furman]

Kurento is unstable.  It's research-quality software, and it's not maintained.  Moreover, it was recently bought up and the devs are going to be moved into other projects.  Kurento will become abandonware.  Don't use it :(

[Khaled]

How about "Janus WebRTC Exchange"? 

in short it could be called like JaWREx or Jawrex.

just my thought.  :)

// khaled

[Horsetopus]

Here's my contribution:

Janus: WebRTC hub, to reflect the server/centralised/broadcasting aspect.

Janus: WebRTC toolkit, to reflect that it does more (record, replay, convert).

Finding something that matches both aspects of Janus... is much harder, Janus: WebRTC versatile hub or something?

On Monday, September 5, 2016 at 4:49:33 PM UTC+2, Lorenzo Miniero wrote:

[max]

what's about WebRTC Session Controller ?

在 2016年9月5日星期一 UTC+8下午10:49:33，Lorenzo Miniero写道：

[Tomasz L]

Janus Webrtc Media Server

[Saqlain Gardezi]

I think it should be called  "Janus Server for WebRTC"


Saqlain

[Concept Instinct]

Pls how can I contact you to discuss a project. Thanks