Textroom plugin

[Lorenzo Miniero]

Hi all,

I've just published a new PR that introduces a new plugin, called "Text Room": https://github.com/meetecho/janus-gateway/pull/560

This plugin, as the title suggests, allows you to implement text-based communication rooms that use data channels. Basically, you create a single PeerConnection with Janus, and on that single PC you can manage (as in create/join/leave/destroy) multiple rooms at the same time. Within the context of those rooms, you can send and and receive either public messages (to/from the whole room) or private ones (to/from one or more participants). A simple web demo shows how this can be used for a very basic feature, that is a chatroom.

The main aim of the plugin is not to be used only for that (although I guess people might find it useful for the purpose) but actually to allow, in the future, WebRTC users to interact with third party applications that are not WebRTC compliant. One idea, for instance, would be to allow external applications to inject messages in these rooms, addressed at the whole room or individual participants. At the moment, the only external communication that is implemented is the ability to forward messages addressed to the room, to an external HTTP backend via HTTP POST. That's basically a proof of concept, and is not meant to be more than that for now. Hopefully with more feedback from you guys we'll have better ideas on what to do and how.

Feedback welcome!

Lorenzo

[Wilbert Jackson]

How do I get the new text plugin?

Thanks

Wilbert Jackson

[Lorenzo Miniero]

I've linked the PR.

L.

[Wilbert Jackson]

When trying to compile the text plugin source I get the error shown below. I did a make about a week ago without any problems. I am running Ubuntu 14.0.4 and I did an: aptitude remove libmicrohttpd-dev libjansson-dev libnice-dev \

libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev \

libopus-dev libogg-dev pkg-config gengetopt libtool automake and an aptitude install libmicrohttpd-dev libjansson-dev libnice-dev \

libssl-dev libsrtp-dev libsofia-sip-ua-dev libglib2.0-dev \

libopus-dev libogg-dev pkg-config gengetopt libtool automake to make sure I had the correct packages.

Thanks

Wilbert Jackson

configure: error: Package requirements (

                    glib-2.0 >= 2.32

                    nice

                    jansson

                    libssl >= 1.0.1

                    libcrypto

                    sofia-sip-ua

                  ) were not met:

No package 'glib-2.0' found

No package 'nice' found

No package 'libssl' found

No package 'libcrypto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you

installed software in a non-standard prefix.

Alternatively, you may set the environment variables JANUS_CFLAGS

and JANUS_LIBS to avoid the need to call pkg-config.

See the pkg-config man page for more details.

make: *** [config.status] Error 1

On Friday, June 10, 2016 at 12:53:52 PM UTC-4, Lorenzo Miniero wrote:

[Lorenzo Miniero]

"aptitude remove" uninstalled those libraries... :-)

L.

[Wilbert Jackson]

Yes, but I did reinstall them

[Lorenzo Miniero]

Looks like an issue in your setup. That PR changes very little in the configure process.

L.

[Janus_SFU]

Hi Lorenzo,

Thanks a lot for the textroom plugin.It is working very well with videoroom plugin.

Regards

[Lorenzo Miniero]

I've just merged the feature, so now it's in master. You can find a demo along the others:

https://janus.conf.meetecho.com/textroomtest

L.

[Josh Dickson]

Wonderful work on this! Using this in tandem with the audio bridge is actually quite attractive, where you are then limited to 2 up streams and 2 down streams no matter how many connections there are. Unfortunately it looks like the dynamic room creation is not available just yet? Looks like that section of the file guide is TBA and I get 415 Unknown request 'exists' when trying it out.

I'm going to assume this is coming eventually and just not done yet? Any idea when it might be on the schedule? Understand you already have plenty to do, and very much look forward to using this whenever it happens to get done. Thanks!

[Lorenzo Miniero]

Il giorno sabato 16 luglio 2016 20:09:16 UTC+2, Josh Dickson ha scritto:

Wonderful work on this! Using this in tandem with the audio bridge is actually quite attractive, where you are then limited to 2 up streams and 2 down streams no matter how many connections there are. Unfortunately it looks like the dynamic room creation is not available just yet? Looks like that section of the file guide is TBA and I get 415 Unknown request 'exists' when trying it out.

I'm going to assume this is coming eventually and just not done yet? Any idea when it might be on the schedule? Understand you already have plenty to do, and very much look forward to using this whenever it happens to get done. Thanks!

Dynamic room creation does work. Make sure you're sending these requests on the data channel, and not to the plugin via Janus API.

L. 

[Josh Dickson]

Aha. I misunderstood the documentation for that. Thank you!

[Josh Dickson]

Real problem was that I thought an 'exists' command was available. Our event flow when joining a (video/audio) room is always check exist -> if no, create -> join room that will now always exist. I see 'list', but our rooms are all private so you couldn't sniff out other calls taking place on the same server that you're on. Seems best course of action is try to create and let Janus send an error if already existing?

[Lorenzo Miniero]

Since I'm such a nice guy I added a new "exists" request for you ;-P

https://github.com/meetecho/janus-gateway/commit/f88b08a4d5afc111a95916cd0eb224dbe64abc63

L.

[Josh Dickson]

Haha you have to be the best open source project maintainer I’ve ever seen. Ti ringrazio tanto!! (Hopefully that makes sense!)

--
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/2EcoJajOzmU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lorenzo Miniero]

It does make sense, thanks!

L.

[Josh Dickson]

Have been trying this out.

We seem to run into issues when pushing the events to occur too quickly. I'm curious if it might be smart to have an option to cache multiple messages into a single event. Perhaps a config specifying a cache time, i.e. 50ms, that would ensure at most 20 messages are sent to a listener per second, rather than (potentially) hundreds. Seems as though there would be a dramatic savings in overhead from doing this. Looking at the code and seeing if I remember enough C to get it done!

[Lorenzo Miniero]

That's a good idea, and something to definitely look into. If you can come up with something like this and can share a PR that would be cool. I'm abroad until next week so no time to do that myself ATM.

L.

[Josh Dickson]

Will definitely be looking into this. One thing I'm worried about, is that it seems as though the CPU likes to keep ticking up. Here's a test instance's cloud watch monitoring chart over time. During the low points, nothing is happening - there's no calls or rooms on the server. I'm a little concerned that it looks like it's continuing to creep upward... is that something to worry about? This is very recent Janus, running an audio bridge & text room during periods of activity. 

[Josh Dickson]

Oops... that chart would be here: http://imgur.com/Si3zDvj

[Lorenzo Miniero]

Please open a new post, as this one here is only supposed to notify people about the new plugin.

L.

[Josh Dickson]

This is really a great start. 

One point I would bring up is how all messages are acknowledged by the server. I think in principle this makes sense - but from a usability standpoint I think it's a lot of unnecessary overhead for little gain. For example, the real time data API co's (PubNub, Pusher) have not approached things this way. Using their APIs, you assume that if the connection is up and you are not seeing any error messages the event was successfully received by the server. The real point of value here is not whether the server saw your message, but whether it was actually delivered, which pretty much everyone has decided should not belong in their core API (i.e. if you want it, have receivers emit an ack event and monitor receipt of all acks to ensure deliverability IF you really need it). I would definitely be up for a, let's call it 'UDP mode' where we don't ack, but I would actually suggest that default is no-ack.

I'd also bring up the fact that the standard API route for the other providers is to not emit broadcast events that a client sends back to themselves. In addition to the above issue, this results in a lot of overhead whenever you send a broadcast message (i.e. client A emits a broadcast event, they then get back a 'success' event for send and then sees the event itself again). Again, I would support the default being what we would see from other API providers, though there are absolutely times where the full broadcast makes sense - perhaps they could be separate events?

[Also, I don't intend to bring up the other service provider's APIs as though those are 100% correct, but in a lot of programming with them, I find that those are almost always what you want from an implementation perspective.]

[Lorenzo Miniero]

Good points, thanks for sharing your thoughts on best current practices. Not sure yet how to proceed. I guess we can add a "noack" kind of property to outgoing messages, which if enabled doesn't send a success back to the user. A similar property might be added to not be included in a broadcast message we send. I'd keep the defaults to what we have right now, though, as disabling them makes assumptions not everyone might have.

L.

[Josh Dickson]

Yeah if you’d like to keep the current API structured this way that is more than fine - a different event type for a no-ack message makes sense as well, rather than a room-wide setting. So I would +1 either of those.

[Saqlain Gardezi]

I have seen the demo for creating a single room with id 1234. How can I create multiple rooms. Is there any documentation for that? Kindly send the link. Thanks.

[Lorenzo Miniero]

The TextRoom API is not currently documented. Anyway, it's similar to other plugins so it's just a "create" with some additional stuff. Check the plugin code for the accepted arguments for a "create".

L.