[jitsi-users] How Jitsi Videobridge implements adding of new conference participants dynamically and how it handles RTCP?


#1

Hi,

1) I'm wondering about how Jitsi Videobridge implements the dynamic adding of new conference participants.

Specifically, when a new participant joins, it starts receiving RTP video streams from other participants. But since it eventually receives one of these existing translated/relayed streams not from the very beginning, it has not received any keyframe yet. Hence it cannot properly decode and display video from this stream.

What happens in this case? I suspect that this participant somehow indicates to the sender (to the videobridge? or to the real originator of this RTP stream, i.e. to another participant) over RTCP that it would like to received a keyframe. the sender reacts to it by sending a keyframe ahead of usual schedule and this keyframe is then translated/relayed by the bridge to all other participants. Is it a correct understanding? Or may be a different mechanism is used? I'd like to understand exactly, how this situation is handled.

2) More generally, I'd like to understand how RTCP is handled by the Jitsi video bridge. From the docs I got the impression that each channel on the bridge gets two ports assigned - one for RTP, one for RTCP (btw, does the bridge use different RTCP ports for all participants or the same one? Source code gives an impression that some sort of multiplexing is used either on the bridge or on the media stream originator side). Audio and video streams use their own channels. What happens when participant sends RTCP packets? Are they sent to the bridge or directly to other participants? If they are sent to the bridge, what happens with them? Does the bridge simply relay/translate them towards proper participants (originators of the RTP stream)? Or does it create new RTCP packets based on the incoming ones and then sent them towards proper participants (originators of the RTP stream)? Or may be it does something else?

3) Is there a way for a web client to trigger resending of a keyframe by means of WebRTC APIs?
The following commit (https://github.com/jitsi/jitmeet/commit/cc6653dc2fa5a77e51cec73633402065a99e7dbd) gives an impression that basically calling setRemoteDescription with the same/existing remote description like in the code below should do the trick. Is it correct? If this is the case, it is standard compliant or Chrome specific?

pc.setRemoteDescription(
pc.remoteDescription,
function () {
pc.createAnswer(
function (modifiedAnswer) {
pc.setLocalDescription(modifiedAnswer, .. );
...
},
);
},
);

Thanks,
Leo


#2

Hi,

Just a small ping. May be someone could answer this question?

Or is it a wrong mailing list to ask this question? If this is the case, I apologize. What would be the right mailing list to ask this question then?

Thanks,
Leo


#3

Hello,

Sorry for the late reply.

Hi,

1) I'm wondering about how Jitsi Videobridge implements the dynamic
adding of new conference participants.

Specifically, when a new participant joins, it starts receiving RTP
video streams from other participants. But since it eventually receives
one of these existing translated/relayed streams not from the very
beginning, it has not received any keyframe yet. Hence it cannot
properly decode and display video from this stream.

What happens in this case? I suspect that this participant somehow
indicates to the sender (to the videobridge? or to the real originator
of this RTP stream, i.e. to another participant) over RTCP that it would
like to received a keyframe. the sender reacts to it by sending a
keyframe ahead of usual schedule and this keyframe is then
translated/relayed by the bridge to all other participants. Is it a
correct understanding?

I believe that it is.

The participants are generally not aware of the videobridge -- from
their point of view they just send RTCP messages to other participants.

Or may be a different mechanism is used? I'd like
to understand exactly, how this situation is handled.
2) More generally, I'd like to understand how RTCP is handled by the
Jitsi video bridge. From the docs I got the impression that each channel
on the bridge gets two ports assigned - one for RTP, one for RTCP (btw,
does the bridge use different RTCP ports for all participants or the
same one?

Currently jitsi-videobridge uses separate ports for each participant.
One for RTP and one for RTCP.

Source code gives an impression that some sort of multiplexing
is used either on the bridge or on the media stream originator side).
Audio and video streams use their own channels. What happens when
participant sends RTCP packets? Are they sent to the bridge or directly
to other participants?

As above -- participants think they send RTCP to each other, but RTCP
goes through the bridge.

If they are sent to the bridge, what happens with
them? Does the bridge simply relay/translate them towards proper
participants (originators of the RTP stream)?

Something like this. Currently, Sender Reports and Receiver Reports are
sent to everyone. Feedback messages are only send to the intended
destination.

Or does it create new RTCP
packets based on the incoming ones and then sent them towards proper
participants (originators of the RTP stream)? Or may be it does
something else?

3) Is there a way for a web client to trigger resending of a keyframe by
means of WebRTC APIs?
The following commit
(https://github.com/jitsi/jitmeet/commit/cc6653dc2fa5a77e51cec73633402065a99e7dbd)
gives an impression that basically calling setRemoteDescription with the
same/existing remote description like in the code below should do the
trick. Is it correct? If this is the case, it is standard compliant or
Chrome specific?

That's what happens in jitmeet: new participants are announced over XMPP and
this triggers setRemoteDescription and a keyframe. But if I understand
correctly this is going away:
https://github.com/jitsi/jitmeet/issues/51

I hope that helps a bit.

Regards,
Boris

ยทยทยท

On 19/03/14 22:34, Leo Romanoff wrote: