Closed jsdir closed 5 years ago
Just checking for the presence of RTCRtpSender.replaceTrack
will not work. There are browsers (e.g., some older versions of Chrome that are probably still around) that had the method, but it didn't do anything: in that case, the feature would just fail.
We can modify the check we have so that if it's Safari, we use replaceTrack as well. I'd like to be sure all versions of Safari supported this, though: do you know if they only added it later on?
Eventually decided to change the code to use replaceTrack in Safari too.
Improved the check, as I wasn't 100% sure replaceTrack was available in all Safari instances or only TP. Please let me know if you have feedback or you can verify this introduces regressions (can't check myself, sorry).
Using
media.replaceAudio
ormedia.replaceVideo
is failing on iOS Safari since none of the conditions required for usingRTCRtpSender.replaceTrack
(Firefox or Chrome >= 72) are met.Instead, iOS Safari defaults to the following logic, which causes the RTCPeerConnection to send a second track for that media type without removing the first track.
https://github.com/meetecho/janus-gateway/blob/6075610ff3bbad37a79c432030b1d669907521fb/html/janus.js#L1560-L1561
This caused to gateway to fail with the following messages, which I figured to mean that the gateway expects only one track of each media type:
I've modified
janus.js
to check for the presence ofRTCRtpSender.replaceTrack
instead of the browser versions, and that seems to fix device switching on iOS Safari.Does it make more sense in cases like these to directly check for the availability of the API on the browser instead of using conditionals requiring specific browser types and versions?