Janus JS lib not receiving any publisher change messages

769 views
Skip to first unread message

Robert Swain

unread,
Aug 22, 2017, 6:07:41 AM8/22/17
to meetecho-janus
I have written some client-side code using the Janus JS lib that attaches to the videoroom plugin, joins a room and publishes some audio/video to the room. Then another client attaches to the videoroom plugin, checks whether that room exists, if so lists its participants and joins as a listener, subscribing to the publisher's feed.

I'm now working on making things robust to various things that happen like disconnects, crashes, refreshes, etc.

The code I have seems to work fine with the subscriber disappearing, coming back again and re-listening. However, if the publisher just closes the page, I am surprised that the listener doesn't receive any event to say that the publisher left even after a few minutes. I am also surprised that if the publisher returns, them creating a new session and appearing like a new publisher even, and they publish to the same room, the listener doesn't receive any events about that new publisher either.

Does anyone have any idea what is wrong? I noticed that the videoroom example page code has one Janus client attached to the videoroom plugin that is potentially just a 'manager' as it is called in the code, if the user does not publish anything. Is that a necessary thing or just to allow other publishers to come and go while maintaining some kind of observer client?

Robert Swain

unread,
Aug 22, 2017, 7:25:25 AM8/22/17
to meetecho-janus
It really looks like the architecture of the JS lib is such that if one wants to receive any events about what is going on with the publishers, one has to join the room as a publisher regardless of whether one wants to publish a stream or not. If I do this, I see events. Why is this necessary?

Firas Abd Alrahman

unread,
Aug 22, 2017, 1:32:14 PM8/22/17
to Robert Swain, meetecho-janus
Hi Robert,
I hope I understood you well...
1 - You attach the VideoRoom plugin
2 - You join the room with join request.

Now you are able to receive events in onmessage callback.
you are not publisher or receiver, you are someone in the room, and you receive events.

' You need to be a publisher to receive events' 
Maybe you are confused with the fact that you do not get list of room participants (like audiobridge), you only get a list of publishers when someone publish.
So when someone publish, all joined participants will be notified with new publisher, but when someone joined the video room nothing happens in onmessage callback.

Maybe it is good to be notified about join event, but what you need is the publishers to view their cams, you have nothing to do with video room users who are not publishing...


Also, I closed the publisher page for test, room participants got unpublish event and then new publishers list received for all.
Joining the room again will surely create new session, you need to maintain that with application level help, 
For me I use list of logged in users from application layer, I set the display field when user join videoroom to be identifier that matches the application user ID, simple loop in videoroom publishers I can identify the users regardless his session ID change, then you can re-connect again.







On 22 August 2017 at 14:25, Robert Swain <robert...@gmail.com> wrote:
It really looks like the architecture of the JS lib is such that if one wants to receive any events about what is going on with the publishers, one has to join the room as a publisher regardless of whether one wants to publish a stream or not. If I do this, I see events. Why is this necessary?

--
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-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Eng. Firas Abd Alrahman
Khartoum, Sudan, Alriad, 60 St.
Mobile : +249126712777
Phone  : +249123334569
              

Mirko Brankovic

unread,
Aug 22, 2017, 4:17:58 PM8/22/17
to meetecho-janus
Yes i also came across this bug or a feature, but generally it was built to serve events only if you are publisher on the room.
So if you dont want to modify it for your needs, mayne you can overcome it with publishing and then muting the video/audio.
Or you can use event handler that will send room events to some socket where clients can pick that up and do something about it.

Firas Abd Alrahman

unread,
Aug 23, 2017, 4:23:59 AM8/23/17
to Mirko Brankovic, meetecho-janus
Mirko, I am not facing this bug/feature at all, I receive events without publishing, also I re-tested that when I read Robert message. joining the room is enough to receive publishers update.
I use latest Janus compile and latest janus.js versions by the way.

Mirko Brankovic

unread,
Aug 23, 2017, 4:42:40 AM8/23/17
to meetecho-janus
hmm,

Maybe then it was something that I tested long time ago, and who knows how I tested it.

Anyway, i didn't use it to only join, without publishing.

Thanks 
--
Regards,
Mirko

Robert Swain

unread,
Aug 23, 2017, 5:25:52 AM8/23/17
to meetecho-janus, robert...@gmail.com
On Tuesday, 22 August 2017 19:32:14 UTC+2, Firas Abd Alrahman wrote:
I hope I understood you well...
1 - You attach the VideoRoom plugin
2 - You join the room with join request.

Yes, but note that the join request requires you to state whether you are a publisher or a listener. https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_videoroom.c#L278

Now you are able to receive events in onmessage callback.

Yes, some types of messages are received.
 
you are not publisher or receiver, you are someone in the room, and you receive events.

That is not correct, as noted above. You have to state whether you are a publisher or a listener when you join the room.

' You need to be a publisher to receive events' 
Maybe you are confused with the fact that you do not get list of room participants (like audiobridge), you only get a list of publishers when someone publish.

No, I'm not confused. I only want to know what streams are being published and if they change I want to know what is no longer being published or what new streams have been published.
 
So when someone publish, all joined participants will be notified with new publisher, but when someone joined the video room nothing happens in onmessage callback.

This is precisely what I am not observing. People joined to the room as listeners are not notified via a message about changes in published streams. However, it seems that publishers are notified.

Maybe it is good to be notified about join event, but what you need is the publishers to view their cams, you have nothing to do with video room users who are not publishing...

That is correct. I only want to know what streams are being published.

Also, I closed the publisher page for test, room participants got unpublish event and then new publishers list received for all.
Joining the room again will surely create new session, you need to maintain that with application level help, 
For me I use list of logged in users from application layer, I set the display field when user join videoroom to be identifier that matches the application user ID, simple loop in videoroom publishers I can identify the users regardless his session ID change, then you can re-connect again.

Yes, but first I want to know if a new published stream has appeared. If no new published stream appears, either the publisher could be experiencing some temporary networking issue and may recover, or they're just gone. Either way I want to wait to see if they send more media and it would be nice if there were some event indicating that there is no more media coming from the publisher for that stream as far as Janus is concerned.

If a new stream is published and it is published by the same user (according to the 'display' value) then I can switch to that stream, for my use case.

Lorenzo Miniero

unread,
Aug 23, 2017, 9:11:01 AM8/23/17
to meetecho-janus, robert...@gmail.com
The confusion may derive by the need to join as "publisher". That's not really publisher, but more "participant" as a concept. We called it "publisher" because that's the handle you use to publish your own media, if you want to (you can very much join as "publisher" and never really publish anything). Listeners don't get events, as otherwise you'd get the same info over and over on all your handles (possibly many of them, in a crowded room), which would be a mess. Just create a handle to receive events, and you'll be fine. As an alternative, create such a listener on the server side (e.g., some kind of room manager) and push events to users yourself.

L.

Firas Abd Alrahman

unread,
Aug 23, 2017, 11:48:22 AM8/23/17
to meetecho-janus
Hi,
"ptype": "publisher" does not mean you are publishing or your media being streamed,

Let's say that's mean you want to publish but you have the option to do that or not.
now listener does not mean you are joining a room as listener to receive events, it means you are connecting to someone's feed in this room actually.

So you can join as publisher, then receive events, if you want to publish your own cam, another call should happen.
check the example (publishOwnFeed(true);)


We have three user types
1 - Room user with type 'publisher' but not publishing, no event triggered here, you are not listed in publishers list, you are a potential publisher, or maybe listener as you are receiving list of users who decided to publish later and you may subscribe.


2 -Video publisher user, after joining he offered his video with media vdeosend:true https://github.com/meetecho/janus-gateway/blob/master/html/videoroomtest.js#L365


3 - Subscriber: after he joined as publisher, he received the publishers list filed with type-2 users, and he subscribed to their feeds.
createoffer in scenario 2  and 3 does not receive events.
only scenario 1 will receive events about scenario 2.

I already confused with publisher in join request until I noticed that there is three scenario you need to consider, but I found that flexible.
Reply all
Reply to author
Forward
0 new messages