AnyRoom – A self-hosted, Twilio-based system for temporary conference calls | Hacker News Reader

AnyRoom – A self-hosted, Twilio-based system for temporary conference calls

anyroom.io

110 pointsthenrich9927 comments

I love this because it's a great example of a hybrid world where customizable open source solutions and commercial hosted SaaS APIs go together hand in hand.

Absolutely. There's one more I just posted https://news.ycombinator.com/item?id=14446337

Jitsi Meet works great for us.

Integrated with the company VOIP system = bliss

Happy to answer questions!

How does Jitsi Meet compare to https://talky.io/ concerning stability, UX, ease of use etc?

How does the integration with your VoIP system work?

The Jigasi daemon connects to our VoIP server and has its own extension. You can either call a VoIP extension from inside the Jitsi conference, or route an incoming call to a specific Jitsi conference.

This means that our existing Polycom-based conference room setups can be bridged with Jitsi Meet with no effort. Our work-from-home people can just dial the physical conference room from a Jitsi Meet conference.

https://github.com/jitsi/jigasi

Appear.in or even something simple built with WebRTC on a heroku dyno or Firebase for signalling would get the work done for free.

You can use this argument for almost any SaaS and it simply does not make a sense.

They have competitors but maybe they are better with marketing, fault tolerance and so forth ? Considering conferencing takes time, free might get more expensive.

Jitsi Meet :)

always had bad results for appear.in while conferencing (1to1 works ok)

Too many layers of oxymorons for my taste. Open Source. Twilio. Plans and pricing.

I'm yet to see a solid, usable and mature FOSS WebRTC implementation, hubl.in is a good candidate though.

What's your opinion on https://inthelocus.com/ ? They got screen sharing without plugins. Most WebRTC-ish implementations don't have this but apparently whitelisting by Mozilla/Google is necessary to do that, so FOSS is not possible at all for screen sharing?

Aww, that means "in the toilet" in German.

Anyways, that is not FOSS. And worse, they mention patents on their developments.

When I click "Share screen" I get "Screen sharing in Chrome requires installing and enabling our small extension." which attempts to install their plugin[1]. This is the same as every other WebRTC screen sharing I've used.

[1] https://chrome.google.com/webstore/detail/locus-screen-shari...

Ok, then it only works in Firefox without plugin installation. :/

Firefox had this "Firefox Hello" but only one-on-call. Sadly they discountined it.

The descriptions are slim and there's no screenshots of the product in use, why would someone click 'Go' on a paid plan after seeing barely any information?

They don't do a great job of explaining that it's solely "dial up audio conferencing" via Twilio. Once you have that context, it's more clear.

Though they could bubble up some of the specs/features from Twilio (https://www.twilio.com/voice/conference)

Written in Go, source is here: https://github.com/thenrich/rooms

Nice! I would love to see something similar with support for a landline, though. Open source telephone infrastructure is an underexplored field.

I am not sure what protocol is being promoted here. If this is based on some random thing they cooked up themselves then they are part of the problem...

As far as I can tell these are old school phone-in conference rooms, so there's no protocol to speak of. You set it up using the system and then call the conference room from any phone.

Any guidance on the use-case of using this compared to Uberconference?

This is just old fashioned telephone conferencing. Dial a number, enter a conference code. Uberconference has screen sharing, dial-out vs dial-in, etc.

The open source part of this seems nice, as opposed to figuring it out yourself with Twilio. They have it all packaged to run on Google App Engine. Though the timing isn't great now that Twilio supports their own "serverless hosting" via AWS Lambda. They should probably offer an option to deploy it that way as well.

This isn't earth shaking to me, but there are companies that still do a fair amount of plain old telephone conferences, and overpay for it.

We've also had a lot of issues with some other conference tools, especially with different software stacks/plugins etc..., so having a quickfire backup solution that we can get to in minutes is useful (esp. compared to "mobile phone on speaker" in an empty corner of the office we've had to resort to in the past), even if it just voice.

(Creator here)

Yes, this is plain telephone conferencing and the landing page could definitely do a better job explaining that.

API Gateway + Lambda might still be an upcoming deployment option for this. App Engine was chosen as the initial deployment target because some of the additional features that will be added are cheaper / free for low volume usage when compared to AWS. This already requires Twilio, so releasing this initially for App Engine seems to resonate better.

I was talking about "Twilio Functions". It's new. It happens to use AWS Lambda under the covers, but they don't mention that. You don't need an AWS account.

It's this: https://www.twilio.com/blog/2017/05/introducing-twilio-funct...

Reply on news.ycombinator.com