LastN

[emcho]

Jitsi Videobridge now has a LastN feature that allows it to only forward the video for the last N active speakers. This is a mandatory feature for large scale conferences.

[fippo]

Can you show me some examples for LastN? How does the focus signal it?

[lyubomir]

In order to support LastN, two new attributes have been introduced in the channel element:

(1) The channel attribute endpoint specifies the identity of the conference participant who is streaming on that channel to Jitsi Videobridge. It is an opaque string as far as Jitsi Videobridge is concerned and is optional. For example, Jitsi uses the JID of the conference participant. For example, the following (schematic depiction of an) IQ tells Jitsi Videobridge that the audio streamed on c1 and the video streamed on c2 are coming from the same conference participant/endpoint p1@jit.si/resource:

<conference>
    <content name="audio">
        <channel endpoint="p1@jit.si/resource" id="c1" />
    </content>
    <content name="video">
        <channel endpoint="p1@jit.si/resource" id="c2" />
    </content>
</conference>

(2) The channel attribute last-n on a video channel specifies the maximum number of last active in the sense of audible audio endpoints/conference participants whose video is to be transmitted through the channel from Jitsi Videobridge. It is a positive number and is optional. For example, the following (schematic depiction of an) IQ tells Jitsi Videobridge that at most 8 videos of actively speaking conference participants are to be sent by Jitsi Videobridge on the video channel c2 i.e. to the endpoint p1@jit.si/resource

<conference>
    <content name="audio">
        <channel endpoint="p1@jit.si/resource" id="c1" />
    </content>
    <content name="video">
        <channel endpoint="p1@jit.si/resource" id="c2" last-n="8" />
    </content>
</conference>

As common with Jitsi Videobridge, the two new channel attributes endpoint and last-n may be specified at any time i.e. either during the allocation of a new channel or as an update to an existing channel.

[fippo]

Let's discuss this at fosdem. The plan at the RTP stream layer is not clear to me since the webrtc API doesn't give me clear indications that a stream is not progressing anymore. Well, getstats, but...

[emcho]

I guess that would require further signalling from the bridge ... and then the focus. @fippo would an RTCP bye help? Would that destroy the stream? If not, we have to send this from bridge->focus->participant

[emcho]

We discussed this today. Definitely doable. Would require a moderate amount of signalling from the bridge, to tell the application about the currently dominating speaker.

[emcho]

This is proving out to be our currently biggest performance bottleneck so we'd need to think about it in the short term. Since an SCTP implementation does not look as something easily achievable, we may have to resort to bridge->focus->participant signalling.

[emcho]

This would require active speaker detection and SCTP support at the bridge so March might be a bit optimistic. April sounds fine though. @bgrozev and @paweldomas are the likely victims here ;)

[hristoterezov]

Already implemented.

[markreg]

How are stream changes signaled to lastN endpoints?

[bgrozev]

Through data channels. See here.