How can a videoroom subscriber know a publisher stopped transmitting?

General
1

Hi,

I’m using the videoroom plugin with one publisher transmitting to Janus with a fixed ID feed and then having multiple subscribers view that feed.

If the publisher looses internet or stops streaming for any reason, is there a way for the subscriber to know?

Currently using the janus.js, if I stop the publisher, the subscriber seems to get callbacks for the track being muted and then another onremotetrack callback where “on” is false. However, these seem to fire during sdp negotiation as well (if I understand correctly)

I would like the subscriber to be able to poll janus in a loop if the stream goes down so that it can auto-recover.

thanks for any tips.

2

When using Janus 1.x the subscriber handles will always get a new JSEP with inactive m-lines when a publisher disconnects. That in turn will trigger the callbacks you mentioned in janus.js.

Applications might discover that a publisher left in different ways:

  1. Use a “companion” publisher handle for any subscriber that will never publish any feed but will be leveraged to receive events related to the room (e.g. user left/joined).
  2. If you are using an application server with a dedicated signalling channel, let the server join the room with a “manager” handle and then forwards events to the subscribers sessions on the dedicated signalling channel.
3

Thanks @atoppi for the reply.

If I understand you correctly, there is no sure-fire way for the client subscriber (alone) to recognize that a publisher stopped streaming from the janus.js callbacks?

Is that right? If the client receives a JSEP with inactive m-lines, it could just mean a renegotiation of some sort, correct? I imagine the rtc peer iceConnectionState could indicate disconnect, but that would also only be temporary (ie its not a final state and can be renegotiated)?

One needs an out-of-band signal with either a publisher connection to the videoroom or a separate application server signal altogether?

How about the streaming server? Can a client know if a mounted live rtp stream (a forward from the video room) into the streaming server has stopped? I imagine the same applies, one would have to create a publisher connection to the videoroom to receive join/leave events if the rtp_forward goes down?

thanks for the reply and for all you do with janus -August

4

There is no explicit signalling towards the subscriber, but it’s still feasible (see next comment),

Inactive m-lines always trigger a renegotiation (as Lorenzo pointed out, that is true if autoaupdate is true, true by default) and mean that those streams are not available anymore. Theoretically a subscriber could infer a publisher’s disconnection by keeping the history of attached and updated events and comparing them. E.g. if attached has this streams list:

[
  {
    "type": "audio",
    "active": true,
    "mindex": 0,
    "mid": "0",
    "ready": false,
    "send": true,
    "feed_id": 2103101764684917,
    "feed_display": "atoppi",
    "feed_mid": "0",
    "codec": "opus"
  },
  {
    "type": "video",
    "active": true,
    "mindex": 1,
    "mid": "1",
    "ready": false,
    "send": true,
    "feed_id": 2103101764684917,
    "feed_display": "atoppi",
    "feed_mid": "1",
    "codec": "vp8"
  }
]

and is followed by this updated event:

[
  {
    "type": "audio",
    "active": false,
    "mindex": 0,
    "mid": "0",
    "ready": false,
    "send": true
  },
  {
    "type": "video",
    "active": false,
    "mindex": 1,
    "mid": "1",
    "ready": false,
    "send": true
  }
]

a subscriber could infer that atoppi (that was allocated to mid 0 and mid 1) is now unavailable. However this is just a “media” perspective and a guess made from that (media not available, hence publisher disconnected), not an explicit signalling event (the publisher went away and his session is over). I don’t know how your application works, that might work for you maybe.
Not sure why you are mentioning iceConnectionState. A subscriber only knows his iceConnectionState, and that will always be “connected” if the Peer Connection is healthy.

That would be a more robust approach.
Attach a “phantom” publisher handle for every subscriber (like we do in our demos when setting subscriber-mode=yes), or use a manager handle in an AS that listens for room events and forward them out of band.

That is even a more complicated problem. The mountpoint is just a socket receiving packets. The source of that stream is unknown to the mp subscribers. You need a “monitoring” point in your architecture to notify streaming users that the origin went away.

5

Not always. That depends on whether autoupdate for subscribers is true or not. It’s true by default but it can be overridden, e.g., when you want to manually switch sources instead of renegotiating.

6

Thanks @atoppi and @lorenzo for the replies.

It sounds like the robust approach is to connect to the videoroom as a “companion” publisher and receive events for join/leave.

What’s kind of cool about the streaming plugin is that at least experimentally, it seems that clients of the streaming plugin will stay connected to a live mountpoint and keep picking up the stream even if the videoroom publisher->rtp_forward->streamingPlugin goes down and then back up again. For my one-to-many broadcast application that is great.

7

Notice that you also have the option to use event handlers for being notified about anything that happens in Janus, including plugin events. It was mostly conceived for monitoring and stats collection, but it can be used for what you need to as well, I guess.

8

thanks @lorenzo

How does one connect to the event handler? That sounds generally useful for all situations.