Every year, the Jitsi team gathers at FOSDEM, the Free and Open Source Developers European Meeting, and there are presentations about some technical aspects of the project.
So unfortunate that FOSDEM is happening right at the end of finals in Belgium when a lot of students are on holiday like me. I've had to miss 2 FOSDEMs so far, 3rd coming up :(
FWIW, the app does not depend on any Google Play services, so you could grab the apk from any of those mirrors and manually install it, and if you really want to, you could build it yourself, instructions are here: https://github.com/jitsi/jitsi-meet/blob/master/android/READ...
I recently buidling riot for F-Droid completely from source, which includes the jitsi-meet android library. So added the jitsi app should not be too complicated hopefully.
I looked at this for my project but we need to be able to do server side recording so we went with Janus gateway instead. It's a lean and mean c program that now supports plugins in rust. The one downside of jitsi is that it's a large java application. I can run Janus on a raspberry pi.
Yeah we tried jibri but the problem we had is it just doesn't scale compared to the Janus archive plugin. What jitsi needs is a server side peer that can connect to gstreamer to record and broadcast sessions
I think it is an important point that it is still using java. Java once the hero of portability is in my opionion just the hero of zero days and slow programs.
It also would not be the software to install on my grandmas pc because of the many important java updates which are needed. The automatic installation of a browser plugin i don't need and which makes it even more vulnerable.
I think if Android would not be using Java it would have died years ago.
On the other hand. Jitsi still great software. Open source and all.
> I think if Android would not be using Java it would have died years ago.
I think you're seriously underestimating the amount of enterprise software running on Java for decades now. Not only it's not going away, but the language itself and its ecosystem are evolving. Slowly, but in the domain of programming languages that are actually being widely used slow progress is a good thing.
Gonna second this - as much as I dislike Java there are a enormous number of very stable and mature projects in both the opensource and commercial/enterprise world. Many times there isn't even a alternative.
I'm no defensor of Java but PHP was never entrenched in Enterprise the way Java is. It's "good enough" for most business uses who treat software as a comodity and outsource to multiple vendors.
For Jitsi Meet, you don't have to install anything on a PC but a WebRTC capable browser. On iOS, you (still) need an app, although Safari is starting to support WebRTC natively.
Java on the server is a safe language. I agree that any browser plugin affects security and usability negatively, and the Java browser plugin was a nightmare.
I think you have not understood "C is the desert island language". Java is very much used for application because C++ is a nightmare, C is prehistoric, ...
Recently I have migrated a large application from RedHat 6 to RedHat 7. A lot of code in Ada, C++, Java (all using corba), many scripts in shell, Perl, Awk, make. Most of the code changes needed were in C++.
Most of the new applications here are developed in java or C#.
Modern C++ is a pleasure to work with, despite lacking a packaging ecosystem like Maven's. Though I agree it's way too easy to shoot oneself in the foot. Specially when dealing with large teams of not-so-great corporate developers.
We are a Java shop so jitsi was initially our first choice. However we also need to record and broadcast sessions and jibri was not robust enough. Setting up Janus was painful because we don't usually support non Java applications but Janus fit our needs more tightly because we are not a standard video conference app.
I'm not saying Java is bad we are a Java shop but if you look at resource usage Janus is incredibly tight and small. W do live broadcast with webrtc so jitsi wasn't really matched to our use case. Jitsi is a fantastic project but it's meant for group chat rather than media broadcast. Red5 was another thing we looked at but the open source plugin for webrtc was too unstable for us.
I'm using the archive video room and broadcast plugins, if not for the need for archives and broadcast we would have gone with jitsi because we are a Java house normally but because we need to have scalable archive recording Janus was the only fit besides rolling our own. It's been very light and stable. We also had good results with jitsi and would have u it but janus fit our requirements with broadcast and server side recording.
I don't know of a website that compares audio quality specifically, but I feel this still is the greatest impediment when it comes to ANY video or audio conference system. I get the impression that there is no system out there that allows for decent 'full duplex' audio, equivalent to a normal conversation where both sides might interrupt each other at times. I think this comes down to
a) background noise reduction
b) echo/feedback cancellation
c) input latency
I assume input latency may not be such a big issue anymore, with ultra low latency codecs (presumably) being widespread now.
Feedback cancellation is a problem if any side of the conversation is using speakers, rather than headphones. I guess chat services meet at the lowest common denominator, making fairly conservative assumptions and often cutting audio aggressively.
My personal list, best to worst, in respect to my requirements above:
I haven't tried Jitsi, and WhatsApp seems to work pretty well even for video calls, but I don't think it scales for normal use in a company. In my experience Zoom beats Hangouts and Skype every time.
Software aside, when some attendees will often be in the same location consider using https://www.owllabs.com/meeting-owl. It certainly improves the experience for the remote attendees.
I think zoom is the best for 1:1 and group chats after trying a number of such services. But there's still moments of dropped packets and confusion. You can't blame Zoom for every dropped packet, but what it doesn't do well is tell you when packets are dropped.
I wish video-chat services/clients would be totally up-front about the real-time quality of the connection. There are natural pauses in any conversation, and if you're always wondering whether the pause is natural or a result of a few dropped packets, it makes for a very un-natural conversation. This could be as simple as "last transmission received N ms ago" indicator or something, but I'm sure there are more clever solutions.
I don't think this is an "easy" problem to solve, but it's one that I think most video chat services seem to pretend doesn't exist. Or they implicitly blame outside factors ("we can't fix the network") rather than helping customers live with the realities of the internet ("we show you immediately and in real-time when the network isn't what you expect").
(I've not put Jitsi through its paces - would love to know how Jitsi handles the UX around dropped packets.)
Very granularly: simple tools like the Windows Task Manager Performance tab's Ethernet Throughput graph can provide enough of a clue that a network connection is suffering.
There are many utilities that show this info in useful form in the system tray; perhaps some would be able to superimpose it on top of the video conferencing software (like OnTopReplica).
I often have such OS-level tooling open during VC chats, but it's not natural to have to keep an eye on another tool, especially when you want the "last seen"/latency figure nearly instantaneously so you know the context for lack of signal (human vs machine).
This will be hard to do because it depends on your definition of quality. There are many factors that affect call quality and you can optimize for resillience against some while getting bitten by others. Lately I've noticed web browers being a bit on the aggressive side when setting up connections and that disturbs the flow of packets for some video/audio connections.
I work in the Cisco Spark team so I'm not unbiased when it comes to Skype but you might have a quality problem on your network connection (and the other participants' connections too) if you're seeing consistent audio issues. Real-time media (audio/video) is very sensitive to delay, jitter, congestion and all the network stuff that normally goes un-noticed with web browsing, and there are still plenty of cases that just can't be covered by error correction.
(This is where having the ability to fall back to PSTN to join a call comes in very handy: if I'm in a coffee shop with a crappy connection, there's a strong chance that my call will be of poor quality so I join with my cell phone instead.)
At my company https://voicefox.com, our bot attends a meeting on Google Meet, GoToMeeting and others. We connect to them meeting using Linux-based Chrome and capture the recording server side. From our experience so far, Google Meet (new hangouts version) has the best quality of video
I liked appear.in for smaller meetings, but when we got to 4+ clients it was really struggling, and my team at the time switched to google meet instead.
Anybody here who can explain whether this limitation is specific to appear.in, or whether it's an inevitable consequence of WebRTC's design? Do the audio streams get mixed client-side under WebRTC?
I use appear.in all the time for small meetings and love it. :)
WebRTC is inherently peer to peer (except the initial phase of signaling) so it (audio streams) can't be any other way. Conferences in WebRTC are just multiple peer to peer connections.
I love this project, and I really, really thought this would be the answer to give when people throw me a bewildered "what, you don't use skype?!"
Sadly, even just clicking a link seems to be too far out of many people's comfort zone, which is something that I find it very hard to wrap my head around...
I tried to love and promote Jitsi for a long time but the desktop client is just so darn 2000s Java-ish. Gradients, weird font-sizes, weird and few emoji. And no mobile clients...
Jitsi Meet on the other hand is pure bliss. The website could use a single-line explanation about what it is though. :D
Possible to access a "guide" of some sort. A person that knows jitsi, what it can do, how to mod it a little, and what would need to be done to change "settings a to something else"?
I need this, but after spending months trying to work with rocket chat only to find the few tweaks I need just can't be done (easily, and with a reason (to me) budget) - I gave up.
If I could pay someone $100 to walk me through it a bit, answer a few questions, and guide me to how to mod it to what I need, I'd jump.
I think the last time I looked at jiti there was like a mailing list or something suggested for contacting people(?) - I love email, and don't use fbook.. so that's great, but I just never took that step for whatever reason.
Sadly, one of those "chat with us" boxes on the side that just took you to a faq or offered to sign you up to the mail list might be good in that situation.
Would love to have this working on our servers with a few modifications.
Is there an auto answer option that also works with video calls? Skype recently updated all their clients and removed that option which is really useful for monitoring someone you care for (eg. kids, older relatives, pets).
I assume you talk about the Jitsi desktop client. TBH I don't know. I cannot find it on the UI either, sorry!
Something you can do is use Jitsi Meet (the WebRTC client) and have the monitored device permanently connected to a meeting room (protected by a password if you are using our public infra) and join the call whenever you want to see the other side.
The question is not if it is a video conferencing software. We have billions of these. The question is if it can deliver a solution on the old problem of sucking Voip connections, especially with multiple participants.
Used this recently as a Skype replacement and had no complaints. Similarly rocket.chat is a good free and open source Slack alternative that is worth looking into if you wish to host it yourself.
The company I don't think so. The products.. a bit more - not because they are bad products, but because they are enterprise products which comes with all the enterprise baggage that makes user experience range from meh to painful
It's no specific feature it's the fact that large enterprise requirements very often translate into a product that isn't very pleasant to use.
Jira allows for a very rigid, formalised process for everything to be built. Few companies resist the temptation, most go all in while chanting "compliance, compliance, COMPLIANCE!" and as a result you have an environment that is a pain to use, has too many mandatory fields everywhere, one allowed status transition workflow (or one per issue/content/whatever type)- it's bureaucracy as a service.
All that takes a lot of time to set up and makes changes within the organisation even harder, because you have one more thing that makes it rigid.
I feel like many people have strong opinions about Atlassian.
They are also a Java shop--which is something people also have strong opinions about.
At a previous job they switched from a hodgepodge of systems and centralized onto Jira and Confluence and I have longed for it at the places I've worked since. I do realize the cost and maintenance (configuring and customizing it to get the most out of it) requires a lot of upfront attention. My most recent job uses them and although I haven't used either heavily yet, I find the gui way more confusing and feel like the pages are almost comically slow and heavy.
Regarding the Java shop: here's a video of an Atlassian employee giving a talk on rxjs and redux-observable: https://www.youtube.com/watch?v=zk2bVBZhmcc None are specifically Atlassian's products, but it feels like their frontend is pretty normal (I would even say, advanced) and is quite dissociated from whatever Java they may be using on the backend.
Also, they started rolling out a different (React-based) frontend for Jira several months ago. Can't say that particularly improved Jira's performance, but still... I am not sure viewing them as just a Java shop is fair anymore.
I may not have been clear, Java was only really relevant for hosting onsite. Other comments in this thread mention competitors using other server-side languages that can be served from a RaspberryPi. The only way it'd slow down the client is if your server was poorly tuned or underpowered. In my own experience, managing Java applications have their own set of skills.
The client side bloat I've noticed are both in visual clutter and performance using the Atlassian hosted version...so I doubt it's related to Java (outside of maybe scaling issues?). I don't doubt they have a modern front-end. It feels like one of those hip, new, modern, chunky sites that take too long to load and I try not to revisit. I don't mean to knock on React or modern frameworks, they have their uses and fill needs, but the end result often isn't a pleasant experience. The version I remember using years ago was a bit slower than most static sites, but almost seemed boring and corporate in use (which is a compliment for something you rely on for your job).
I'd love to hear more about the APIs we need to improve. We are exploring using GraphQL for our next revision of APIs, and your experience would help us with that effort. If you're interested - we'd appreciate your feedback.
I haven't touched it in over a year now, but you might want to look at Bamboo. That product seemed rather stale and there's plenty of +1'd issues/requests on your jira.
One exceptionally bad example I remember is returning HTML for certain 404s even though caller requested json. It was for missing artifacts among others IIRC.
1) How easy is it to host this in your own infra, and can you do so 100% without proprietary bits?
2) It seems there is a "call a phone feature" built-in. Neat. Does that have any restrictions or can I use it worldwide to call my friends in other countries.
1) Add our repo, apt-get install jitsi-meet and you're done! We have 0 proprietary bits.
2) That feature requires that you deploy a service of your own to facilitate this. At this time, meet.jit.si provides this for free for 2 minutes, but if you deploy the service to your own infra you'll need to deploy jigasi and configure a VoIP provider yourself.
Anyone got experience with it as a skype replacement? If it has IM functionality and desktop sharing with voice chat and it works remotely well then I'd love to replace skype and webex.
I used it a number of years back. It seemed to be really buggy and not work most of the time. I really hope things have improved because a FOSS solution to teleconferencing would be dandy.
My recollection is similar, with usage starting ~3.5 years ago and ending ~18 months ago. Jitsi was slow, would often crash. But it seemed to be the best video-conferencing SIP client I could find that worked on enough platforms that I could use it and also guide my family through using it.
Their WebRTC site at https://meet.jit.si/ works incredibly well. It's the best I've seen, anonymous, with tons of videoconference functionalities and nice bandwidth tracking tools.
And being WebRTC, it needs no plugins on popular desktop webbrowsers. Sadly, mobile ones do not support WebRTC. But their app is open, and works very well.
Any experience using it on Wayland Linux? I guess there it wouldn't be so easy to grab other windows content without display manager support (which AFAIK does not yet exist and if is specific for the implementation Gnome, KDE, Enlightment, ...)
AFAIK (and I can be totally wrong here) screen grabbing is part of the Wayland protocol, but most (all?) compositors restrict which processes are allowed to use that API. For Sway (which is what I use), I've seen a separate config file for this. So it might be worth taking a look at the documentation for your compositor.
Both are hosted, this is a no go. Both are also proprietary, skype has just taught us why this is a bad idea. In addition, discord is an electron app, I'm going to avoid it as long as I can.
I will answer your question anyhow assuming that you honestly don't know: Electron Apps always desguise as whatever they want to be yet they are a fat Web browser, consume insane amounts of memeory for what they do, are all to often lagging when used. They open the door for script kiddies, and as backed by javascript offer for many great opportunities for extension at the cost of homogeneity and sometimes quality
I thought Jitsi was dead since jit.si started retiring user accounts, rendering communication with my parents through it impossible. How do you use it these days?
The page you link to <https://jitsi.org/downloads/> contains (mostly) instructions on how to install jitsi-meet on your server for a self-hosted WebRTC videoconferencing solution.
This does not include the older 'jitsi' named softphone / voip client, meaning there will be no jitsi command that can be executed.
Installation of jitsi-meet was straightforward for me, exactly as oulined on their page:
- first, add their repository to your apt sources.list
- then apt update && apt upgrade
- then apt install jitsi-meet
You should end up with a running web server hosting your own jitsi-meet instance.
I've installed it with a letsencrypt cert... you have to convert it to pkcs#12 with openssl and move it to /etc/jitsi/videobridge/ .
They are very lively, and do useful work.
This year, there will be a talk about Speech-to-Text in Jitsi Meet > https://fosdem.org/2018/schedule/event/jitsi/
Happening in Brussels, Belgium on 3 & 4 February 2018 ;)