If there's interest in this kind of stuff, I'm working on open-sourcing the core of a SaaS side project[0] I have. It's visual voicemail on steroids (cliché, sorry) and, like the linked article describes, accepts your forwarded call and handles the voicemail. Afterwards (and this was my original use-case), it can trigger a bunch of hooks to your favorite things — Dropbox, email, Slack, SMS, Zapier, what have you (and all right out of the box).
I built it because I was on Android and wanted to keep my moms voicemails. :)
This is interesting. Let me give you some potentially helpful context:
Some services require companies to have a public phone number. This doesn't need to be a real support phone number, but it shouldn't be completely unattended.
Your service would fit right into that, and if you (optionally) handled the purchase of the number itself (Twilio will do that), it would make it quite literally a 5 minute setup.
The only other thing I haven't found is a forwarding service, that would allow such companies to purchase a number in a particular country, to forward calls/sms to another arbitrary phone number (or an email/voicemail box). I'd certainly use that for myself as well.
I would be interested in seeing it if open sourced. I used YouMail in the past and their UI really bugged me, so I was playing around with the idea of building something more modern and self hosted.
This is super simple, and I like that using Twilio Studio makes it easy to expand and customise.
But for just the end goal, depending on use case specifics, another option is to use Twimlets which has the added bonus of the missing voicemail to email.
https://www.twilio.com/labs/twimlets
I've been thinking of building something a little bit more in depth, using Twilio Studio and Google Firebase, with proper dial-in voicemail retrieval, SMS notification, and maybe Sendgrid voicemail to email.
Does anyone has a ready-rolled Twilio Studio direct to Firebase example?
The only issue I have with Twilio is their charging. For voicemails, calls typically last less than 10 seconds, and often only a second (because they hang up and don't leave a message) - but as they charge per minute you are billed the full 60 seconds each call.
I built something similar as a side project but switched to Nexmo, purely because they charge per second. It was a fun thing to build and test.
Fun fact, if you're an enterprise customer you can demand full second rounding, or if you're mid market you can bring that down to 6 second rounding in many telco oriented places.
I would also recommend having a look at Anveo. They have a visual call flow handler that is less flexible than Twilio, but generally easier to understand and faster to make changes in. https://www.anveo.com/consumer/features.asp?code=ivrcallflow
Twilio has a great API and documentation etc. But I don't understand why we don't kill the old telephone system as soon as possible. And for anyone who has looked at how SMS actually works, it's a dumpster fire similar to XMPP but probably worse.
Twilio is pretty great but for this use case using Google Voice is a lot simpler (assuming its available in your country)
I recently did this for a firm that is fully remote now during pandemic. They had non voip line for main number. Set the office phone to FW to a GV number and put GV in DND so it goes straight to voicemail which was what they wanted. Then setup GV to send voicemail to email and gmail to forward to slack channel using the basic slack email integration app.
All in all very easy to setup in 20 min or less and get transcribed VM in slack channel with link to play the message as well.
I keep thinking of setting up something like this with Twilio as a backup... I don't trust GV to stay around forever... especially since it seems like they just stopped supporting voicemail transcription for a while (iirc over a month) and the settings and integrations seem to be left to die...
I haven't looked in a while, but running a Virtual PBX via Twilio or similar is really interesting to me... and something I'm surprised more aren't taking on, considering I've seen the amount of what providers for SIP support are charging.
The one feature that everyone seems to be missing with these tutorials is a simple tool to have people confirm that they would like to accept the forwarded call... I'm helping a mutual aid group and we have a list of people whose phones all ring simultaneously (meaning that inevitably someones voicemail answers first) and I have yet to find an easy way to implement a simple "Press any key to accept this call" where the first person to answer AND press any key gets the call...
>I have yet to find an easy way to implement a simple "Press any key to accept this call" where the first person to answer AND press any key gets the call
Would you be interested in a functions script that does this? I've got one kicking around I can share.
Kazoo [0] offers this as a config option on devices (which can represent SIP desk phones, soft phones, WebRTC endpoints, or call-forwarded cell phones): call_forward.require_keypress [1] There's a lot of re-inventing of telecom wheels required (if even possible) with TwiML (and clones).
I did this a while back, and got rid of the home phone. We had made the transition to VoIP in the early 2000s, and then migrated the number to Google, Anveo, and finally Twilio. I was tired of getting calls all day for various things and decided to make a Twilio Studio IVR. Now, I have text messages and certain calls (if someone vocalizes a choice or pushes a key) forwarded to mine or my wife's mobile.
Twilio really is a great provider. Sure they're expensive, and sure you have to pay to lease your number every month, but I've had so much fun with them.
For example I hooked I setup a simple "on-call" system by monitoring a specific Slack channel, and when emergency-messages were present, would dial and play a message to an engineer. Wonderfully reliable and worked really well.
Yes, but this is standard of any telecom provider, and Twilio is charging you for it because their underlying providers are charging them. Also inbound legs are generally an order of magnitude cheaper per minute for standard phone numbers.
Standard call:
- A places an outbound leg to C. A pays for this leg
- C receives an inbound leg from A. C pays for this leg
Forwarded call with B (your Twilio/some other telephony API provider number) in the middle:
- A places an outbound leg to B. A pays for this leg
- B receives an inbound leg from A. B pays for this leg.
- B places outbound leg to C. B pays for this leg
- C receives an inbound leg from B. C pays for this leg
In this scenario the two "sides" of the call could be going through completely different underlying telcos so there's no "Oh it's just forwarding!" The two different telcos don't really care about that. To them they're still each setting up 1 outbound & 1 inbound leg.
Although the billing structure is standard, Twilio is not considered a low cost provider for what they offer. They kind of rely on their customers being software people that need an API but don't know enough about telecom billing to demand better.
The value-add is real though, you would never want to go about this on your own. Companies like Twilio (and their competitors) gloss over the millions of rough edges that exist when working with a telco directly. It's just that the markup is very high for Twilio.
Are there alternatives that have as simple and well documented an interface for development... considering how much some of the SIP providers I've seen charge for SMBs, I think it kind of evens out depending on usage.
Pick up call - start recording - forward call to another line - collect recording & post it to S3, in no more than 100 lines, and that was before they had an SDK.
Yes--why wouldn't they? Your call is going through their network fully--this isn't a broker situation where their router connects the 2 endpoints directly.
I've been wondering, how hard would it be to set up a system like Apple's "hide my email" but for phone numbers, generating a new random phone number whenever I need to give it out?
Super easy and a bunch of apps do it, the problem here is that the numbers actually have a leasing cost if you want to hang on to them vs something like an email alias/front.
One possible way around this is to use phone number extensions, although I haven’t researched how well supported this might be across apps and the web.
Note that Twilio numbers (in the US, anyway) cannot receive SMS messages from short codes [1]. This means that you may not be able to receive SMS 2FA messages from your bank.
Like you mentioned, you can use call forwarding — there's even things like conditional call forwarding if you just want to forward your missed calls or things that go to voicemail. I did exactly this to build https://tinyvoicemail.com (which I'll be open-sourcing in the near future)
I built it because I was on Android and wanted to keep my moms voicemails. :)
[0] https://tinyvoicemail.com