Adding stream in Firefox doesn't trigger source-add in chrome


#1

I’m running into an issue where I am not receiving a ‘source-add’ event on a chrome client when I have added a stream in Firefox.

From looking at the SDP on firefox’s side i can see that firefox changes the a=recvonly line for the video to be a=sendrecv for it’s local description and that additional information around the msid is added to the SDP. I can see that an outgoing IQ message is sent to jicofo

<jingle xmlns="urn:xmpp:jingle:1" sid="5l7f0f031ia0f" action="source-add"> <content creator="initiator" name="video" senders="both"> <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="video" ssrc="3375410633"> <source xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" ssrc="3375410633"> <parameter xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" name="cname" value="{c3ee0171-91ea-9e49-98ef-377ff27cc5b0}"/> <parameter xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" name="msid" value="{2fcf3738-ef09-714e-bcb9-c0085a247404} {8b4f4cb7-935a-374f-98ec-14f6e375d57e}"/> </source> </description> </content> </jingle>

however Chrome does not receive the ‘source-add’ message. I’m wondering if anyone else has encountered this and if so how they got around it.

it’s worth mentioning that this scenario is when both are in a meeting not sharing and firefox tries to share.


#2

We had identified a problem like that with Firefox. So the scenario we saw it is that if you join Firefox participant with video muted (recvonly stream is created) and then you try to turn on video(sdp changes to sendrecv) the bridge does not start sending it. This is a problem in the bridge and we didn’t had time to fix it.

Which jitsi-meet are you running, the source-add part was fixed 2 months ago https://github.com/jitsi/lib-jitsi-meet/commit/98acf1336df7a6fe6fc27c16c829ef607ec20ceb?

For the same scenario with audio, there was also a problem in Firefox, but it was fixed in Firefox 62: https://bugzilla.mozilla.org/show_bug.cgi?id=1472321


#3

Damian, any ideas on where the issue might be in the videobridge? We have seen this behavior in Firefox 62. This is using a custom client. We did get it working by filtering the recvonly source out of the jingle session-accept message and only signaling it when a real stream is added but we see issues with chrome sending a stream to firefox when firefox has no stream (recvonly). The MST is sometimes muted when Firefox receives it and becomes unmuted when the videobridge receives the next keyframe. Weirdly also the stream sometimes freezes when a keyframe comes in or sporadically. I do see some frame corruption warnings in the JVB logs when the stream is initially added by chrome. This is with JVB build 1066.

I noticed that lib-jitsi-meet has senders=“both” in the session-accept when the SDP has a=recvonly. What is that supposed to do?


#4

For the video problem in jvb we need to ask @gpolitis when he is back from vacation :slight_smile: he has more detailed info there. Do your client use jicofo, does it handle the source-add, source-remove from there?


#5

Our client does use jicofo and it doesn’t handle the source-remove source-add when adding a stream from Firefox. We have to work around that in the client either by mimicing what lib-jitsi-meet does with removing and re-adding the source or by not signaling the recvonly source initially.

When will @gpolitis be back from vacation?


#6

We will be back next week, I will talk with him and will let you know.


#7

Hi @damencho @gpolitis I was going to start looking into this issue. Any information that you may have on the issue would be greatly appreciated. Thanks.


#8

So the fix for source-add source-remove is https://github.com/jitsi/lib-jitsi-meet/commit/98acf1336df7a6fe6fc27c16c829ef607ec20ceb
Other than that I would ask @gpolitis to give more details about the bug in the bridge.