I have two custom lib-jitsi-meet based clients which are joining a channel, both of which have no AudioContext, so lib-jitsi-meet is not getting audio level data correctly.
The channelLastN has been set to -1, and I have even tried making sure -1 is sent via the data channel via BridgeChannel.js.
I still see lastN messages coming in from the bridge. When I first publish my stream, the remote client sees:
2020-05-27T17:21:36.750Z [modules/RTC/BridgeChannel.js] <RTCDataChannel.channel.onmessage>: Channel new last-n event: [ 'd8c09767' ] {
colibriClass: 'LastNEndpointsChangeEvent',
lastNEndpoints: [ 'd8c09767' ],
endpointsEnteringLastN: [ 'd8c09767' ],
conferenceEndpoints: []
}
Everything streams, and looks normal, but suddenly I get on the receiving client a lastN:
2020-05-27T17:21:44.200Z [modules/RTC/BridgeChannel.js] <RTCDataChannel.channel.onmessage>: Channel new last-n event: [] {
colibriClass: 'LastNEndpointsChangeEvent',
lastNEndpoints: [],
endpointsEnteringLastN: [],
conferenceEndpoints: [ 'd8c09767' ]
}
And as a result the track is removed:
2020-05-27T17:21:44.200Z [modules/connectivity/ParticipantConnectionStatus.js] <ParticipantConnectionStatusHandler.figureOutConnectionStatus>: Figure out conn status for d8c09767, is video muted: false is active(jvb): true video track frozen: false p2p mode: false is in last N: false currentStatus => newStatus: active => active
2020-05-27T17:21:56.282Z [modules/RTC/TraceablePeerConnection.js] <TraceablePeerConnection../modules/RTC/TraceablePeerConnection.js.TraceablePeerConnection.removeRemoteTracks>: TPC[1,p2p:false] removed remote tracks for d8c09767 count: 1
2020-05-27T17:21:56.282Z [modules/RTC/RTC.js] <RTC.removeRemoteTracks>: Removed remote tracks for d8c09767 count: 1
Why am I still getting these lastN messages from the bridge when it has been set to disabled?
Is there some mechanism to fully disable lastN?