Routing Actual Calls With Erlang

Chat / Discussions
,
1

Hi everyone. I’m new to Erlang, and would love to use the language in a way similar to how it was originally designed. For what it’s worth, I’m also looking for professional help with this, where I can pick your brain along the way to better understand Erlang on a deep level.

Anyways, currently in my organization there is a large demand for efficiently routing calls. By efficiently, I mean in a cost effective way primarily. Some platforms exist to track and route incoming calls, but they are all very expensive (4 cents per minute or more) which would add up to tens of thousands of dollars per month in usage fees.

Erlang seems to be the perfect language for this, however with modern VOIP services, it seems like it can only get as close as one degree of separation away, not actually in the trenches.

What I mean by this is, I can run cowboy on a linux server running Erlang, and that code can decide where a call should go, but it seems like we will ALWAYS need some other third party such as Twilio, Bandwidth.com etc to maintain PSTN connection, number management, etc.

I don’t like this as, in the case of twilio, a large percentage of the app could be built within one of their pre-existing services, such as Studio…

We would greatly prefer a standalone, on-prem service that does not require companies like this to operate, apart from the original purchasing/porting of numbers perhaps.

Is still still possible these days? Or could Erlang only become a glorified shot caller from a distance (ie, responding back to Twilio incoming call requests with a REST response telling twilio where to send the call/what to do).

Thanks!

2

Erlang/OTP (Open Telephony Platform) certainly is a great choice for your problem space. Your “degree of separation” concern appears to come down to available signaling stacks. OTP includes the DIAMETER protocol which is used systemically in 3GPP EPC and IMS. Third party signaling stacks are also available for many other protocols. Which one you need depends on the network equipment you want to interface with. If you want to build a VoIP router you will need SIP. There are a few Erlang SIP stacks available.

3

Re-implementing telecom services yourself is not a productive use of
time, IMO.

Leverage open source projects like Kamailio or FreeSWITCH (or projects
that try to ease the management of those like FreePBX).

You are still going to have to interop with the broader telecom world,
which means paying carriers for phone numbers and minutes.

You can check out KAZOO, a telecom platform I’ve been working on the
last 15 years at 2600Hz (now Ooma) in Erlang. Depending on your actual
needs, KAZOO may be fuller featured, but we have an app within KAZOO
called Pivot to route new calls to your web app and you return the call
logic we should execute on your behalf (same mechanism as Twilio).

You’re not wrong that Erlang is a good choice but delving into the
bowels of telecom is not a weekend hackathon project :slight_smile: What you save in
not paying usage rates, you will more than spend in time and effort (and
tears when you see how different providers can implement the SIP RFCs in
interesting ways.

Ethan via Erlang Forums writes:

2 Likes
4

The owned number would be VOIP, but it would be receiving inbound calls from all over. Other voips, cell phones, landlines, etc.

5

Very fair! This is how I actually feel but, at the same time, it kind of makes Erlang look like a party trick language more than anything, especially in the world of AWS/‘Serverless’. If it can all be handled there, then why branch out and bring Erlang into the mix at all?

6

Bandwidth/Twilio + FreeSwitch + Erlang looks cool. The core reason why I’m even considering Erlang is because I believe it would be ideal to stream and transcribe call audio simultaneously for each phone call.

Call comes in > route determined > connection made and transcription begins.

Any advice you have would be greatly appreciated!

1 Like
7

Don’t? :slight_smile:

More constructively, its a tradeoff of your time.

FreeSWITCH can stream RTP but you have to know how to setup the media
bugs in FS to do it. You have to know how dialplans work, manage
registrations (so now you have accounts to manage, SIP
username/passwords, etc), configure ACLs to allow traffic, and more.

FreeSWITCH has mod_erlang_event so you can at least get some control in
native Erlang terms (we also have mod_kazoo which provides similar
DistErl functionality but tailored for how we manage FreeSWITCH
instances in KAZOO).

Are you trying to optimize this prematurely? It feels like you have a
lot of unknown unknowns to discover still and spinning your wheels
learning how to manage FreeSWITCH/telephony in general.

That said, if you are mostly looking to learn and are okay with the
likely stumbling about as you navigate the telephony ecosystem, it is
“fun” to do.

You could also look at SignalWire - the FreeSWITCH team’s response to
Twilio. It may be high-level enough for you to validate your idea
without requiring lots of mental investment in the underlying tools and
protocols. Those are always lurking for if/when you need more control.

Ethan via Erlang Forums writes:

2 Likes