fix: Missed "cname" attribute in SDP jingle

[mnasyrov]

Added cname attribute to SDP jingle.

The missed cname causes receiving PeerConnection's track without a media stream in not-latest Chromium-based browsers.

[saghul]

Ping @jallamsetty1

[saghul]

Jenkins please test this please.

[jitsi-jenkins]

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

[paweldomas]

I don't think we want cnames to be advertised. Aren't we filtering that in jicofo already? See jitsi/jicofo@1681586

[paweldomas]

Uncaught TypeError: Cannot destructure property 'id' of 'undefined' as it is undefined.
    at Object.Yt.isReactNative.getStreamID (lib-jitsi-meet.min.js:2)
    at Function.getStreamID (lib-jitsi-meet.min.js:2)
    at Xo._remoteTrackAdded (lib-jitsi-meet.min.js:2)
    at Xo._usesUnifiedPlan.onTrack (lib-jitsi-meet.min.js:2)
    at RTCPeerConnection.s (lib-jitsi-meet.min.js:2)

What is this stack trace? Are you running custom lib-jitsi-meet?
Cname is not meant to be a stream ID

[jallamsetty1]

@mnasyrov, Can you please give us an example of where this breaks ? Jicofo doesn't advertise cnames anymore as msid is the only param that needs to be set on the browser in the a:ssrc line and that value corresponds with the stream id. All browsers have already dropped generation of the cnames in the local description.

[paweldomas]

There must be something wrong because it goes through the react native flow on the browser according to the stack

[jallamsetty1]

Just read through the original issue. @mnasyrov Can you please grab the remote description that is being set on the peerconnection before the track event is fired ?

[paweldomas]

It is also important to see if 'isReactNative' flows are not activated, because this has many different consequences in different places of the app.

[mnasyrov]

@paweldomas
It is not isReactNative flow. There is the simple getStreamID() function which is pointed by the stack trace:

@jallamsetty1
Here is the remote description:

• set_remote_description-pre_transform.txt
• set_remote_description-post_transform.txt

[paweldomas]

@mnasyrov then what is this part of the stack:

Object.Yt.isReactNative.getStreamID ([REMOVED]/main.34a3d636.js:257:385988)

The thing is that the getStreamID can be defined different way for each platform:

lib-jitsi-meet/modules/RTC/RTCUtils.js

Line 351 in ad1f06d

this.getStreamID = function({ id }) {

From the stack it still looks like it may be going through the RN flow, so can you debug this part?

[jallamsetty1]

@mnasyrov, Are you using an older version of Jicofo on your deployment ? This doesn't fix the issue with latest JIcofo as it appears that latest Jicofo doesn't propagate the cname to the other endpoints even if the client adds this param in the source signaling.

[mnasyrov]

@jallamsetty1 jicofo 6173 is used

[mnasyrov]

@paweldomas This is. because of a js compressor, here is a screenshot with the formatted code:

[mnasyrov]

@jallamsetty1

This doesn't fix the issue with latest JIcofo as it appears that latest Jicofo doesn't propagate the cname to the other endpoints even if the client adds this param in the source signaling.

Could you say the number of the latest Jicofo which will not work with the fix?

[jallamsetty1]

@jallamsetty1

This doesn't fix the issue with latest JIcofo as it appears that latest Jicofo doesn't propagate the cname to the other endpoints even if the client adds this param in the source signaling.

Could you say the number of the latest Jicofo which will not work with the fix?

jitsi/jicofo@1681586 is the commit that changed the behavior in Jicofo, so 6433 looks like. Thanks for providing me the remote descriptions being set on the client, I don't see anything wrong with them.
Will you be able to share a link where I can reproduce this issue ?

[mnasyrov]

@jallamsetty1

jitsi/jicofo@1681586 is the commit that changed the behavior in Jicofo, so 6433 looks like.

Thank you for the details.

Will you be able to share a link where I can reproduce this issue ?

Please open a conference with two people at https://meet.jit.si in Chromium 79:

[agustinbranaf]

@mnasyrov interested in finding a solution to this since we use chromium in our App, did you ever find a fix/workaround to this issue?

[paweldomas]

@mnasyrov interested in finding a solution to this since we use chromium in our App, did you ever find a fix/workaround to this issue?

You should be able to use Chromium just fine, but with a reasonably latest version. I don't know which one exactly.

[mnasyrov]

@mnasyrov interested in finding a solution to this since we use chromium in our App, did you ever find a fix/workaround to this issue?

We use a custom lib-jitsi patched by this PR locally with a previous version of Jicofo. Soon, I hope, we'll update requirements for client browsers, and discard this fix as well.