Twilio releases open source video conferencing apps for iOS, Android and web
twilio.com
twilio.com
I'm seeing discussion below about fully open-source solutions (Jitsi Meet) vs. fully proprietary solutions (Zoom). What's interesting about using Twilio is that it is a programmable solution.
Case in point: I am building a webpage where people can log-in to a virtual office, so that people working from home don't feel so lonely. I have certain requirements, such as:
- All audio is muted
- Participants are arranged in a grid
- Room is persistent (no need for an "owner")
Accomplishing this with either Jitsi or Zoom may have been impossible, because while they are configurable they are not programmable.Now, Twilio isn't the only Video platform on the market (see TokBox, etc), but I think comparing this to Jitsi/Zoom/Hangouts is like comparing apples to oranges.
There are blocks for WebRTC, RTP, RTSP input (not output), and others. You can also apply computer vision to the video, with OpenCV filters. There is a "Composite" filter that places N streams in a grid. And users are expected to write their own fancy "blocks" if needed, so the option is there too.
Only important matter would be to see if the currently existing blocks are already providing the features you need, or new ones would have to be created.
Some technology from the Kurento project was acquired by Twillio [2], so it's possible (but not sure, I don't really know, maybe the parent commenter knows) that their media services might be based or inspired on Kurento.
Full disclosure I currently work for the Kurento project as the main developer, at Universidad Rey Juan Carlos.
[2]: https://www.kurento.org/blog/whats-next-kurento-and-elasticr...
EDIT -- I wrote "under the radar" which is exactly the opposite of what I meant to say :-) now fixed
Where I think it does play in is that while Zoom is probably making a lot of sales right now, they are probably starting to regret their start-up friendly pricing model now that they have to fund large engineering efforts to keep up with demand. I imagine Zoom prices will go up while Twilio APIs will stay fairly consistent. There may be some cool start-ups that get built on top of this as well.
No, but I bet a lot of places are (like the big enterprise shop I'm in) both scaling out their existing solutions for things like conferencing and VDI that were initially chosen to support more limited use and starting to consider long-term solutions to support more comprehensive at-need remote work.
[0] https://developer.webex.com/docs/platform-introduction
[1] https://github.com/webex/webex-ios-sdk-example-buddies
[2] https://marketplace.zoom.us/docs/sdk/native-sdks/preface/int...
At best, they have no incentive to fix your issues / provide missing documentation.
At worst, you're seen as sabotaging revenue from their productized offerings.
I've seen very few companies that can successfully be a product and a platform company at the same time.
https://github.com/crtr0/twilio-video-app-react
You can try it out at:
https://video-app-7758-dev.twil.io?passcode=7020447758
Just enter your name and the room "HN".
Media connection failed or Media activity ceased
Error Code: 53405
Was that an error on the webpage or in the JS console?
I'm about 300% unsurprised that this uses JavaScript- correct me if I'm wrong- I don't think there's really a way to do this without it, if we aren't supposed to be using Flash anymore, either.
I spent some time looking at the Jitsi Meet source to confirm this assertion:
https://github.com/jitsi/jitsi-meet/
It was quite clear that trying to use that code to execute my use case above would have been a very large waste of time, and quite possibly (given the lack of docs) a futile exercise.
These are the React features supported, including chat/conference,etc https://github.com/jitsi/jitsi-meet/tree/master/react/featur...
https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/API....
Hats off to anyone who can rapidly go from those docs to a deployed and working app. I was able to modify the repo linked in the parent to suit my needs in roughly 2-3 hours, much of which was install/setup.
Still it feels like a bit of a letdown to see protocols meant to open up communication (RTC) being wrapped in a per minute charge.
Kickstarting innovation would be even more possible if charges only kicked in after a high enough threshold.
Again, big fan of Twilio and what they did to abstract away telephone hardware.
Has worked out of the box on Ubuntu 18.04 for the last four months with screen recording, as host, as attendee, background replacement, chat, seminar mode, etc.
Yesterday I found one issue, the whiteboard share collab mode doesn't work but the app continues to function fine.
FYI: Get rid of unity if you're using that. It'll crash on it's own, not zoom. I'm using i3wm as a tile manager and everything just works as expected.
If you are comfortable with a more proprietary stack, then Google Hangouts / Zoom / others are likely to provide a better supported user experience.
If you would prefer a more libre end-to-end experience then Jitsi Meet may be an attractive alternative.
Do you have a reference/quote for that, out of interest?
In the past it seems like he's been skeptical[0] of providing user data to third-party services.
[0] - https://www.theguardian.com/technology/2008/sep/29/cloud.com...
Additionally, https://www.gnu.org/philosophy/javascript-trap.html makes no mention of proprietary backends being harmful to user freedom, only obfuscated (unauditable) frontend code.
OK, but the later essay https://www.gnu.org/philosophy/who-does-that-server-really-s... does.
The proprietary backend is providing a network service, the question is: to what degree is that service being used as a software substitute?
----
My own opinions on RMS' opinions:
The essay I linked is from 2010; don't get too hung up on specific examples, things have changed since then. The Facebook of 2010 was fairly usable as a dumb service without being a software substitute. It was possible to consume your news feed via RSS, and perform your own sorting of it (for example).
That said, I do think that RMS has taken a rather naive view of which services are pure services, and which services are software substitutes. I can see how many things can reasonably be conceptualized as a pure service... but also, they could be replaced by software. If you could use software as a service substitute, then surely the service is a software substitute. And part of this changes over time, as people figure out how to replace more things with software. (Based on personal (mailing list?) communication regarding DDG vs YaCy vs Searx as the default search engines in FSF-endorsed distros)
It should also be said that RMS refines his views change over time, and that he often doesn't do a good job of acknowledging that they've changed, instead doing a sort of "I've always had this wisdom" thing. Years ago, he had a bit about how people would ask him about "free hardware", and that his answer was that the concept of free hardware didn't make much sense, as you can't copy a piece of hardware the way that you can a piece of software, and that having the source files for hardware wasn't very important. Then a few years later, consumer 3D printing and home manufacturing started to take off, but he held on to his old position. Then a few years later, he came around, and he had a bit in a talk at LibrePlanet about how free hardware was obviously important. So don't give old statements by him too much weight--his views change in response to new information and developments (as they should).
It'd be great to learn more about that call for a FOSS Google Docs client if you can share a hyperlink.
> likely to provide a better supported user experience.
Yeah, about that: https://arstechnica.com/gadgets/2019/01/the-great-google-han...
[0] https://cloud.google.com/blog/products/g-suite/helping-busin...
My experience with Google software is the exact opposite. The never-ending parade of new products, SDK versions, grand rewrites, non-existent support, and cancelations has served to remind me of one thing: that I am the product.
Twilio, PortSIP, and Abto are currently implemented as demo backends.
With that said, Twilio has a very easy to use API and if usage cost isn't as big of a deal to you as development time is, it's an easy decision to utilize what they offer.
https://docs.daily.co/docs
Our focus has been on doing as much as possible to make video calls reliable, and helping developers get started with video as quickly as possible.Twilio is a great company. Jitsi is a great open source project. As always, there's room for different approaches to solving hard problems, for different customers. We've found that the biggest pain point for lots of developers are that 1) building out a full video call UI is non-trivial, and 2) handling all the failure cases possible in real-world calls is non-trivial. So we try to solve those two problems.
I love this stuff (this is the third time I've built a video tech stack, in my career), and I'm happy to answer any questions about WebRTC, building live video into applications, and give you (relatively) non-biased advice about tools/approaches for your particular goals.
I'm currently a Twilio customer using their Network Traversal Service.
Businesses aren't charities but man does this feel cynical to anyone else? Twilio is not a bad investment for any business, in my opinon -- they make very complicated things very simple and offer a lot of value. This feels like OSS-washing though, and I feel like I'm a mark -- "use our awesome open source stuff so we can pull you into our ecosystem".
Does Twilio still use Zoom for internal voice & video employee collaboration?
I worked there for a few years and left Twilio not long ago. I always thought it was super strange how Twilio doesn’t dog food any of its own service.
Some examples: - Twilio Flex isn’t used for support desk - Slack is massively used at Twilio vs Twilio Chat - Zoom is massively used vs Twilio video - employees don’t text yet SMS is your core business
And more
With a TURN server from Xirsys[2], I have had live drone video recording as well as barely a second of latency. I disabled peer2peer video because I do not want a 4G connection to broadcast to multiple viewers.
The reason I have not used twilio(even though I evaluated its offerings) is that they do not provide on premises hosting and my potential customers are not normally interested in not having on premises hosting.
[1] https://janus.conf.meetecho.com/ [2] https://xirsys.com [3] https://github.com/ptsneves/janus-gateway-android
The basic thing is that if you are doing a basic demo without business logic you can easily pick up a Janus video room demo and set Xirsys as your ice server in the Java script file. After that, start front end work, to get to your demo goal. Of course if you know Janus you probably are already doing this. :)
For the android part, if any, you can pick the library that i quoted before.
My biggest difficulty, that almost made me give up was realizing that my reverse proxy internet facing machine needed to have the ports open necessary for webrtc. Otherwise you get extremely weird results in the ice candidate gathering stage, or sessions that take very long to start. Even weirder, the turn server does not work without it, which my limited understanding at the time did not even consider it. It may sound obvious in retrospective but the debugging results were just misleading.
With that problem solved i just programmed a small library in C# that sets up private video rooms per user group. Also programmed a system that gathers the mjr files after a live video session and makes it available in a gallery as webm files(tried mp4 for ios safari but never got them working)
The system design is glued together by a docker compose file which has containers for: asp.net core server, Janus, mjr transcoder, ngingx reverse proxy, and mysql database.
Sorry if this is not much detail, but I am a one man show and I dedicate the time apart from my family to this project and day time job, and I am really trying to be laser focused to release it commercially. Also, I work in an Eastern European country so my resources to hire out help, are more constrained. When I have a minimal viable product I will try to get it to the Show HN and hopefully work on the growth and scaling.
The camera of the phone is not used nor is the phone flying. Actually the phone is connected to a remote control. See [1].
The role of the phone is not only as a viewer of the live video being captured by the drone, but also as a 4G internet point and a hardware video encoder, that pumps the live video to my platform.
The bottom mentions that peer-to-peer room pricing is even lower, $0.18/hr for a two-person meeting, but I'm not sure when that's used.
With Jitsi I can self-host. In my view, that makes Jitsi better from a privacy perspective.
Potentially, one could make a fork that can use either one’s own backend or Twillio’s, while Twillio’s own can only use Twillio’s.
I'd be interested in giving it a go. If anyone else is, just leave a comment on this issue. https://github.com/ethanwillis/oss-twilio-video-backend/issu...
However if people do want to contribute early on I'd welcome that :)
It's not going to work 100%, as the Twilio API can do stuff that Jitsi doesn't (e.g. the choice of video being transferred p2p or via the server).
But if you're going to do that, then you're using Jitsi mainly for media transcoding/multiplexing. So maybe it would be easier to use that code in Jitsi directly and write a new API layer, rather than writing a shim above the existing API.
I've never done it so I don't know, but I thought the whole point was that it's peer-to-peer. I know there is some kind of "discovery" layer required, but this doesn't seem complex enough to warrant a SaaS.
Most open-source WebRTC implementations I've seen use a list of semi-public STUN/TURN servers, notably including Google's, which I believe are explicitly for dev/testing purposes.
In addition to this "discovery layer" - and possibly handling reconnections - I imagine it's non-trivial to provide video/audio transport, compression, etc.
I'd love it if it were simpler to use WebRTC, truly peer-to-peer, in the vein of how early Skype used to work. Unfortunately, from what I've learned so far, there are still technical hurdles to self-host such a service.
https://en.wikipedia.org/wiki/STUN
https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...
If you have video chat with 10 people, then you have peer connections with 10 people. Each person will have connections with 10 other people, resulting in 10x10=100 connections.
With a streaming server, you would just need 1 connection to a server that would give you 10 media streams.
With a streaming server, you can also do recording and stuff.
- OSS client and server
- E2E encryption
- migration to IETF MLS protocol for E2EE messaging
MLS is a stepping stone to moving away from siloed messengers to interoperable services.^^^ sounds like they did a one-off.
> We build open source video apps so you don't have to
^^^ sounds like they're now in the business of doing this for steady revenue, which I don't think is true.