[PSA] Releasing Janode, a node.js adapter for Janus

[Alessandro Toppi]

Hello Janusers !

We have just released Janode, a node.js signalling adapter for Janus.

Check out the code on github and let us know what you think :-)

[august black]

Hi Alessandro,

This seems really cool.

Can you explain a bit on how you imagine it being used?

Is it supposed to replace the janus.js  in the browser?

Is it supposed to act as middleware between the browser/janus.js and the server-side Janus?

both?

thanks -August

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/bbe2a6c1-cd2a-4678-9062-e4a054a2a0dcn%40googlegroups.com.

[Alessandro Toppi]

Hi,

Janode was born as an adapter to be used in application servers, e.g. we adopted it to:

- create stress testing frameworks for janus (orchestrating signalling for test clients)

- create layers that could translate specific signalling protocol to the Janus API (w.g. whip to janus api)

- wrap janus instances in scalable virtual event platforms

Said this, it works in browsers too but it's (still?) not intended to replace janus.js.

If you are interested in janode, don't lose my talk at CommCon 2021 (https://2021.commcon.xyz/)

[august black]

Hi Alessandro,

That all sounds great.  I also look forward to your talk.  I hope it will be recorded.

When you say "wrap janus instances in scalable virtual event platforms",  do you intend janode to be a front-end to Janus for the app communication layer?

You say it works in the browser but is not (yet) meant to replace janus.js

Would you mind explaining what are the parts that are missing for it to replace janus.js?

Is it a cross-browser compatibility layer and/or other things that are missing?

I would love to see a more contemporary api.  I'm happy to contribute if needed.

Please excuse the peanut-gallery style comment, but the thing I see making the janus.js weird in the browser is the Janus-side differentiation between sync and async messages.  Both are async in the colloquial sense of the term, but Janus async messages mean that you have these global event handlers for only certain kinds of messages where you send the message on one channel, but have to observe on another (global) channel.

  

I wonder why all network messages aren't "sync" in Janus. By that I just mean that the "id" that is sent in the message is later returned when done.

It would be much cleaner IMO to have all message be in the style of:

plugHandle.send({...})

   .then(() => {...})

   .catch(errHandle) 

When I look at the C code (for the audio plugin at least), there doesn't seem to be a reason for that differentiation.  The reply for messages could all include the initial "id" that is sent.

I'm guessing this is maybe a remnant of http polling only communication.

best -August.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/f7d583e9-cc02-40a9-86a4-c392a7055285n%40googlegroups.com.

[Lorenzo Miniero]

You say it works in the browser but is not (yet) meant to replace janus.js

Would you mind explaining what are the parts that are missing for it to replace janus.js?

No parts missing, we're simply not going to do it, at least not anytime soon. Our main focus remains the server side, not the demos, and updating those to use Janode would take an awful lot of time we can't spare.

L.

[Alessandro Toppi]

Il giorno sabato 4 dicembre 2021 alle 18:53:52 UTC+1 augus...@gmail.com ha scritto:

Hi Alessandro,

That all sounds great.  I also look forward to your talk.  I hope it will be recorded.

It'll be available on YT.

 

When you say "wrap janus instances in scalable virtual event platforms",  do you intend janode to be a front-end to Janus for the app communication layer?

I mean it is used as front-end for multiple interfaces: in the case of Meetecho VEP there are at least 3 interfaces:
1) one to serve the public clients with a Socket.io server
2) one to serve private internal requests via HTTP (e.g. room setup and allocation of resources)
3) one to update a distributed status via ETCD

Those all services need janode in some way, since the whole application is basically controlling the janus instance, letting it communicate with clients, managers and distributed status.
More on that in the upcoming commcon talk

  

You say it works in the browser but is not (yet) meant to replace janus.js

Would you mind explaining what are the parts that are missing for it to replace janus.js?

Is it a cross-browser compatibility layer and/or other things that are missing?

I would love to see a more contemporary api.  I'm happy to contribute if needed.

Well it is not meant to replace janus.js for a number of reasons:
1) Since it does not deal with W3C PeerConnections and Media Stream APIs, conceptually it could not replace janus.js. Instead janus.js should be HUGELY refactored to use janode for the communication with Janus and the plugins. As Lorenzo pointed out, that is an enormous effort.

2) Janus.js is used (mainly by Lorenzo) to quickly prototype and test new features. Adding janode to the janus development cycle implies that a new feature must be added on both janode and janus in order to be tested.
3) Many APIs are sill missing (and also the whole multistream support). Contribution on that is  very welcome of course.

Said this, you can still use it in the browsers if you want and I'm showing a demo at commcon.

You just need to bundle the core + needed plugins script and use it in your web app. There is an example on the janode repo for echotest.

 

Please excuse the peanut-gallery style comment, but the thing I see making the janus.js weird in the browser is the Janus-side differentiation between sync and async messages.  Both are async in the colloquial sense of the term, but Janus async messages mean that you have these global event handlers for only certain kinds of messages where you send the message on one channel, but have to observe on another (global) channel.

  

I wonder why all network messages aren't "sync" in Janus. By that I just mean that the "id" that is sent in the message is later returned when done.

It would be much cleaner IMO to have all message be in the style of:

plugHandle.send({...})

   .then(() => {...})

   .catch(errHandle) 

That is one of the purposes of janode, hiding the complexities of the janus API.
Every API in janode (both core and plugins) is a promise that resolves when the closing event is received. Take a look at the examples on the repo. 

 

When I look at the C code (for the audio plugin at least), there doesn't seem to be a reason for that differentiation.  The reply for messages could all include the initial "id" that is sent.

I'm guessing this is maybe a remnant of http polling only communication.

That difference is pretty confusing sometimes and also the janus API is not coherent in some requests and events.
That is another concept of janode: streamline the API and adding what is missing in order to facilitate the job for developers using janus.

One of the reason for having async requests is not to stop the thread-pool that is handling messages from clients.

[Alessandro Toppi]

Here is the YouTube link to the talk

https://youtu.be/CeZzIedQA6s