Is someone working on Safari compatibility?

From hints in this forum and in GitHub issues it seems like someone is working on adding Safari compatibility.

Is there a public branch where this work is being done? Any info on the scope of work that is needed to support this (just lib-jitsi-meet or will it require changes to jitsi-videobridge also?). Any hint of when it might be ready?

Is there a way to assist this effort?


We are currently working on improving the Unified Plan usage, for Firefox and Safari will also come at some point, but @jallamsetty can give more details on that.

Hey there ! Yes, we are working on adding Safari support. There is no public branch right now, I am hoping to merge it soon in the next 1-2 weeks. The work being done now is all in lib-jitsi-meet. We are seeing some issues with simulcast though, like Safari not receiving the higher resolution simulcast streams from the videobridge. We might have to make changes to the videobridge if we determine that the problem is on the bridge side. We are hoping to wrap up these changes by March end. Hope this helps !


Thanks for the update (and for the work you are doing) @jallamsetty and @damencho!

I too have been tasked to work on safari compatibility. I’ll start from scratch if I have to, but I’d love it if you could share what work you’ve done thus far or even hints about where to start and what to look out for.

Hi @jallamsetty, is there any update on this? I want to use Jitsi for a site I’m putting together for some non-technical users who may be using Safari and less likely to install Chrome.

Maybe I could try my hand at adding Safari video support to lib-jitsi-meet if that would help.

Great! The code is on GitHub, so you can fork and then work on it. (But I suspect it’s a very much non-trivial thing to do.)

We have wrapped up Safari support work, it should be out in the next release.



1 Like

Thanks @jallamsetty!

1 Like

We just had a lively testing sesh on this PR:

Takeaways for me: Safari streams will technically be able to work in the upcoming release, but there are a bunch of problems with how Jitsi Meet works that mean it’s not quite ready for prime time.

In the test we ran with @jallamsetty, on Safari in large-video view, we didn’t see the thumbnail tiles showing video, but clicking on them to pin did show the video streaming in both from an iPhone and a Chrome browser participant. (Chrome was able to show both feeds without any issues.) In Safari the little filmstrip tiles and the thumbnail tiles didn’t show correctly, and on iPhone none of the videos were able to render and play. (Sometimes you could see a single still frame or a play button that launched a fullscreen video of the camera feed, but showing them inside

It’s unclear whether mobile Safari will be able to show the videos at all, although I’d like to run some tests outside of the Meet app to be certain.

The PR referenced above was for the getting the signaling to work on Safari which defaulted to Unified plan starting 12.1.1. That was a major roadblock which has been fixed. We know about the issue with the thumbnails and the tile view, someone else from the team will be working on that.

Safari mobile is not supported yet and that is something we will work on soon.

Hi I’m continuing the PR discussion
did a fresh install from master on a fresh server, seeing the same issues.
Safari joins > others > safari gets signalling issues > gets broken.

[Error] 2020-04-12T12:27:58.216Z – "[conference.js]" – "CONFERENCE FAILED:" – 
[Error] 2020-04-12T12:27:58.230Z – "[modules/xmpp/JingleSessionPC.js]" – "addRemoteStream failed:" – InvalidAccessError: Failed to set remote offer sdp: The order of m-lines in subsequent offer doesn't match order from previous offer/answer. InvalidAccessError: Failed to set remote offer sdp: The order of m-lines in subsequent offer doesn't match order from previous offer/answer.
s (lib-jitsi-meet.min.js:10:26346)
(anonymous function) (lib-jitsi-meet.min.js:1:204107)

test server
Safari version: 13.0.5 (also happens on newer Safari for iPad)

Have the same issue. I describe cases below.
Case 1:

  1. Chrome in conference.
  2. Safari 13 joins the conference, there is user’s permission request
  3. User allow, m-lines error in console, no TRACK_ADDED in chrome’s console, so no audio from safari on the chrome’s side.

Case 2:

  1. Chrome in conference.
  2. Safari 13 already has a permission for microphone, and it joins to conference.
  3. No m-lines error in console, TRACK_ADDED fired in in chrome’s console, audio work fine.

Case 3:

  1. Safari 13 joins the conference as the first user.
  2. Permission request -> allow.
  3. Chrome joins the conference
  4. m-line error in console, TRACK_ADDED fired in chrome’s console, but not fired in safari’s console, so chrome hear safari, but safari does not hear chrome.

Seems, that everything works on safari only if you got a permissions previously.

1 Like

I took a look at your setup and I noticed that you are using sctp datachannels for the bridge channel. Is there a reason why you are going with that instead of the websockets ? I don’t think this is root cause for the problems you are facing but I am trying to understand the differences between your installation and that of where it runs perfectly fine. Also, did you take the latest jitsi-meet as well ? There is one change in jitsi-meet other than the lib-jitsi-meet changes.

the setup is from the nightly build of jitsi-meet I used that because previously you mentioned it’s specific to my setup. my hunch the issue is more related to Safari 13 signalling as @ashitikov is experiencing the same thing. what safari version are you using ?

@pilosof, do you reproduce the issue on ? If you cannot reproduce it there I would assume that it has something to do with your setup or something that you are doing differently in your setup that is exposing a bug in our code.
@ashitikov, are you sure you have the latest code ? Are you getting the prompt from the browser for using the camera ?

I am using completely custom UI with lib-jitsi-meet inside. I think the most difference of the permission workflow is that my UI use createLocalTracks separately for audio and video and can do that after joining to conference.

Cannot reproduce this on I guess because original UI first do createLocalTracks for both audio and video, and only then add it to conference.

I am using the latest docker-jitsi-meet with patches for websocket support and the latest lib-jitsi-meet.
I could provide some logs if you could support such custom environment :slight_smile:

  1. re not using websockets this is jitsi-meet current default, (fresh debian server with a fresh jitsi-meet install)
  2. “my” setup is jitsi-meet default setup not changing anything see 1.
  3. it works on your servers but not on anyone else who uses your distributed setup…