|
@@ -2028,7 +2028,21 @@ TraceablePeerConnection.prototype.replaceTrack = function(oldTrack, newTrack) {
|
2028
|
2028
|
// the client is using the p2p connection. Transceiver direction is updated when media is resumed on
|
2029
|
2029
|
// this connection again.
|
2030
|
2030
|
if (transceiver && mediaActive) {
|
2031
|
|
- transceiver.direction = newTrack ? MediaDirection.SENDRECV : MediaDirection.RECVONLY;
|
|
2031
|
+ // In the scenario where we remove the oldTrack (oldTrack is not null and newTrack is null) on FF
|
|
2032
|
+ // if we change the direction to RECVONLY, create answer will generate SDP with only 1 receive
|
|
2033
|
+ // only ssrc instead of keeping all 6 ssrcs that we currently have. Stopping the screen sharing
|
|
2034
|
+ // and then starting it again will trigger 2 rounds of source-remove and source-add replacing
|
|
2035
|
+ // the 6 ssrcs for the screen sharing with 1 receive only ssrc and then removing the receive
|
|
2036
|
+ // only ssrc and adding the same 6 ssrcs. On the remote participant's side the same ssrcs will
|
|
2037
|
+ // be reused on a new m-line and if the remote participant is FF due to
|
|
2038
|
+ // https://bugzilla.mozilla.org/show_bug.cgi?id=1768729 the video stream won't be rendered.
|
|
2039
|
+ // That's why we need keep the direction to SENDRECV for FF.
|
|
2040
|
+ //
|
|
2041
|
+ // NOTE: If we return back to the approach of not removing the track for FF and instead using the
|
|
2042
|
+ // enabled property for mute or stopping screensharing we may need to change the direction to
|
|
2043
|
+ // RECVONLY if FF still sends the media even though the enabled flag is set to false.
|
|
2044
|
+ transceiver.direction
|
|
2045
|
+ = newTrack || browser.isFirefox() ? MediaDirection.SENDRECV : MediaDirection.RECVONLY;
|
2032
|
2046
|
} else if (transceiver) {
|
2033
|
2047
|
transceiver.direction = MediaDirection.INACTIVE;
|
2034
|
2048
|
}
|