[Rjevski]

On the other hand, I'm not sure Asterisk has a future.

It's quite a legacy application and is not easily scalable nor made highly available.

The world is also moving to hosted communications (Twilio, etc) so there is less and less need for a local PBX, thus less demand for Asterisk.

[kimi]

You can scale Asterisk up quite a bit (we have customers with clusters of 50+ boxes) and every telecom uses it some way or the other.

[Rjevski]

How do you share state between them?

[spditner]

The state you tend to store is in the application side, so it still backs onto things like SQL databases in the end. You'd put another service in front of your Asterisk instances like OpenSIPS or Kamailio to distribute load.

[Rjevski]

Seems like a huge hack. What we really need is some kind of etcd for telecoms, where you just configure it and they replicate and share state automatically.

[florent42]

It's not a hack. Think of Asterisk as if it was an http server + backend code. How do you scale?

You scale horizontally using proxies (kamailio dispatchers), (what you would call "reverse proxies in the http world), and use external storage / database / logic.

[dvtrn]

SIP? This sounds like exactly what SIP does. Or at least a function of what it exposes

[gerdesj]

Asterisk is just another daemon. You could use etcd for it or Puppet or whatever to create config on the fly. On FreePBX you generally use MySQL/MariaDB.

[kimi]

Lots of ways. Usually externally, through a database. An Asterisk box processes and forwards calls - you can hook into a "master controller" that decides what is to be done.

[florent42]

> The world is also moving to hosted communications (Twilio, etc) so there is less and less need for a local PBX, thus less demand for Asterisk.

Correct, but don't forget many hosted communications services use asterisk internally.

Twilio did use Asterisk in the past, although I believe they have switched to something else.

[Rjevski]

I believe they built their own, exactly for the reasons I outlined above.