[jitsi-dev] Value for the 'label' source-specific SDP media attribute in Jitsi Meet


#1

Hi,

in Jitsi-Hammer, I had a bug where if it was creating a second fake user, the video for both fake users wouldn't be displayed correctly (by that I mean the video of the second user wasn't displayed, and the video of the first one would freeze like hell).

I've fixed the bug by not using the same code Jitsi use to generate the value of the 'label' attribute, because at first, I used the same code as the one in the method "getLabel" of the class "CallPeerMediaHandler", where it just return "mediaType.toString()", ie "audio", "video" etc... (I was told that the value of the 'label' attribute didn't really matters, but it seems like it do matter for Jitsi Meet).
Instead, like msLabel, I generate a random UUID, and it seems to fix the problem.

So I was wandering why in the first place in Jitsi, you doesn't generate an random UUID for the label : Jitsi Meet seems to do so, why not Jitsi?

In the comment of the function, you mention the RFC 5576, but this RFC doesn't mentions the label attribute (nor msid, or mslabel).

Thanks for your attention.

Cheers,

Thomas Kuntz.


#2

hey Thomas,

I can try to shed some light on the webrtc side at least. RFC 5576 is a framework that can be extended. IIRC mslabel (and possibly label) are "old" interim versions of what is currently described in http://tools.ietf.org/html/draft-ietf-mmusic-msid-06 -- and it's safe not to include them in the request you send (once we get Emil to agree on merging https://github.com/jitsi/jitsi-meet/pull/75 at least).

The value in the msid correlates to the id (or label) attribute of the mediastream the webrtc api gives you in the onaddstream. If that value is not unique, different SSRCs will be mixed into one mediastream which would explain the effects you describe above.

Makes sense? :slight_smile:

···

Am 08.07.2014 18:13, schrieb Thomas Kuntz:

Hi,

in Jitsi-Hammer, I had a bug where if it was creating a second fake
user, the video for both fake users wouldn't be displayed correctly (by
that I mean the video of the second user wasn't displayed, and the video
of the first one would freeze like hell).

I've fixed the bug by not using the same code Jitsi use to generate the
value of the 'label' attribute, because at first, I used the same code
as the one in the method "getLabel" of the class "CallPeerMediaHandler",
where it just return "mediaType.toString()", ie "audio", "video" etc...
(I was told that the value of the 'label' attribute didn't really
matters, but it seems like it do matter for Jitsi Meet).
Instead, like msLabel, I generate a random UUID, and it seems to fix the
problem.

So I was wandering why in the first place in Jitsi, you doesn't generate
an random UUID for the label : Jitsi Meet seems to do so, why not Jitsi?

In the comment of the function, you mention the RFC 5576, but this RFC
doesn't mentions the label attribute (nor msid, or mslabel).


#3

На 8.07.2014 19:13, Thomas Kuntz написа:

So I was wandering why in the first place in Jitsi, you doesn't generate an random UUID for the label : Jitsi Meet seems to do so, why not Jitsi?

I'm not aware of that label being taken into account for the purposes of media playback in libjitsi/Jitsi so I presume Philipp's explanation about WebRTC gives you an answer why libjitsi/Jitsi and Jitsi Meet differ with respect to the generation of that label.


#4

Hey Philipp,

thanks for your explanation, it does make sense.
I send this email because I was curious about this behavior, and because if ultimately we wanted to let Jitsi connect to Jitsi Meet conference, I thought that maybe it would have been a problem to not use UUID for the label.

But it seems like I was worried for nothing (I'll continue to send UUID for the label with the hammer, better safe than sorry).

Thanks !

Thomas Kuntz.

Le 08/07/2014 20:13, Philipp Hancke a �crit :

···

Am 08.07.2014 18:13, schrieb Thomas Kuntz:

Hi,

in Jitsi-Hammer, I had a bug where if it was creating a second fake
user, the video for both fake users wouldn't be displayed correctly (by
that I mean the video of the second user wasn't displayed, and the video
of the first one would freeze like hell).

I've fixed the bug by not using the same code Jitsi use to generate the
value of the 'label' attribute, because at first, I used the same code
as the one in the method "getLabel" of the class "CallPeerMediaHandler",
where it just return "mediaType.toString()", ie "audio", "video" etc...
(I was told that the value of the 'label' attribute didn't really
matters, but it seems like it do matter for Jitsi Meet).
Instead, like msLabel, I generate a random UUID, and it seems to fix the
problem.

So I was wandering why in the first place in Jitsi, you doesn't generate
an random UUID for the label : Jitsi Meet seems to do so, why not Jitsi?

In the comment of the function, you mention the RFC 5576, but this RFC
doesn't mentions the label attribute (nor msid, or mslabel).

hey Thomas,

I can try to shed some light on the webrtc side at least. RFC 5576 is a framework that can be extended. IIRC mslabel
(and possibly label) are "old" interim versions of what is currently described in
http://tools.ietf.org/html/draft-ietf-mmusic-msid-06 -- and it's safe not to include them in the request you send (once
we get Emil to agree on merging https://github.com/jitsi/jitsi-meet/pull/75 at least).

The value in the msid correlates to the id (or label) attribute of the mediastream the webrtc api gives you in the
onaddstream. If that value is not unique, different SSRCs will be mixed into one mediastream which would explain the
effects you describe above.

Makes sense? :slight_smile: