Libre video chat applications
Hey, is jitsi-meet different to jitsi? If so, why is it not available in the Parabola repos? Is there a freedom concern with it?
With the coronavirus-related lockdown we are going through, I am seeing some pressure from members of my family to start using Zoom for multi-person video calls. I see this as a good opportunity to encourage them to try a free-software alternative. I haven't used jitsi before, but my impression is that jitsi-meet is simpler to get up-and-running, whereas jitsi requires users to sign up with another third-party service (e.g. XMPP, etc.). So, I think jitsi-meet would be easier for them to migrate to and for me to explain to them.
Otherwise are there any other libre Zoom alternatives anyone would recommend, which would be easy to set up for someone using Windows (i.e. my Mum - sorry, she's not a free-software convert!)?
I tried jitsi-meet in Iceweasel on my Chromebook, with the media.peerconnection.enabled setting set to true, but I still got the same issue as before. The session ends immediately if I click on the 'settings' button in the menu.
It should be kept in mind that only 1:1 calls are end-to-end encrypted in Jitsi Meet, and conferences are not . But the work is in progress on that . So for now if it's not desirable to let third party see the conversation unencrypted, then self-hosting of the instance is the way to go.
grizzlyuser Ok, thanks for the info on that. I would consider self-hosting, but I'm not willing to put the time in to set it up if I can't even get meet.jit.si working for myself in a browser first.
I posted an issue report on the Jitsi Meet page and they directed me to http://test.webrtc.org. I ran the tests there and they fail with icecat/weasel on both of my machines. In icecat on my x86 desktop, it can't find the microphone and it's failing network and connectivity. I'm using ALSA direct, not Pulseaudio, so perhaps that may be causing an issue with the mic? Although, audio output works in icecat and I know the camera/mic works with other programs.
the last i knew, jitsi-meet is working with the current iceweasel - are people still having trouble with it ?
i suppose it could make a difference depending on if you are using pulse, ALSA, or JACK
bill-auger I was trying it in icecat on x86, but I will install iceweasel and see if it is any better. On that system I am using OpenRC and direct to ALSA, no Pulse.
In the support ticket I had raised with Jitsi Meet, they recommended trying http://test.webrtc.org, to see if the browser-integrated webrtc is working correctly. I tried it with icecat and it didn't seem to be detecting the mic for my webcam. So, that might suggest a compatibility issue with ALSA (although audio output works fine with it in icecat).
webrtc is probably disabled in icecat v60 - when icecat v68 is
released, we will try to get that working too
RE: Libre video chat applications - laust - 3 months ago -
1. The packages on the Arch repos are out of date.
2. A possible issue with it not working with OpenRC.
The latter would probably be a deal-breaker for me, as I don't like systemd. I might have to investigate a different libre chat option instead.
freemor you said it worked for you. Are you using systemd?
I experience erratic behaviour as well with systemd as with openrc, so I doubt that would be the only cause. By erratic, I mean that some messages don't go through like you describe. But sometimes, a bunch of pending messages finds its way and is delivered at the same time.
RE: Libre video chat applications - freemor - 3 months ago -
Just to add some data points.
I just had a very successful, hour long Video chat on Jami. The friend I usually Tox with was willing to give Jami a go.
My machine core i5 on fiber
Remote end recent macbook on cable modem
Results crystal clear audio over the entire chat
Some transient minor video artifacting during the call but cleared up quickly each time and certainly wasn't anything I'd consider an issue
Was so clear on the Mac end that we'll be switching to Jami.
This was with the current Jami in the repo. Didn't use it for text chat. That is definitely broken in the version in the repo.
That said my wife has been unable to use Jami with a bandwidth constrained friend (rural Satellite based internet)
jami is an arch package - so we would need to try to reproduce
the chat problem on an arch system, and post a bug report if that
one behaves the same
will jami route through a VM or NATs easily? - i cant remember
send me your jami ID if you like; and i will try to restore mine
if that would help
i think jami is the program we should recommend, and as a SIP
phone also - i remember you had trouble using SIP with jami - it
came up recently on the jami mailing list - the developer made it
clear that they intend to fully support standard SIP; and
explained that in fact, the jami protocol is essentially SIP
tunneled through the special p2p E2E layer
RE: Libre video chat applications - freemor - 2 months ago -
Jami transits NAT ok as neither I not the other participant did anything to forward ports in our routers and I have UPNP turned off in my router.
VM may be an issue as that usually involves another IP change and thus would equal double NAT or worse. Also VM may muss with accelerated rendering (poor video performance) or introduce weird packet jitter etc.
If we recommend it as a general SIP client (it definitely has SIP support) we'd probably need a couple of set-up examples on the Wiki as
I have tried several times to set it up to use my linphone account with out much success. So in some cases like that we'd need to provide
information on the right way to set it up. (Possibly involving contacting the Jami folks to figure that out)
I'll email you my Jami ID/tox IDs/etc for testing purposes. I don't keep Jami up 24/7 as I am usually not in X11 I do have a 24/7 Tox instance (via toxic) and also usually have XMPP/IRC (via finch).
I have several SIP accounts I'll see if I can find the time to test Jami with those.
RE: Libre video chat applications - freemor - 2 months ago -
Scratch that. Just tried to launch Jami and it looks like recent updates to aom and libavcodec have broken ringd and then jami Running jami doesn't give useful details but trying to manually launch /usr/lib/ring/dring --help it throws:
usr/lib/ring/dring: error while loading shared libraries: libaom.so.2: cannot open shared object file: No such file or directory If you try and cheat and ln -s /usr/lib/libaom.so.0 /usr/lib/libaom.so.2 It Then throws:
/usr/lib/ring/dring: symbol lookup error: /usr/lib/libavcodec.so.58: undefined symbol: aom_codec_control So it looks like Jami needs to be sorted out upstream before we can do any further testing. This info should probably be pushed upstream and I'm pretty sure this means that Jami is broken on Arch too.
Never mind seems my last pacman -Suy must have caught things right between libavcodec updating and aom updating so I had new libavcodec but old aom.
a fresh pacman -Suy pulled in the new aom and we're back in business.