A little more complicated than that :). So Here's a brief overview of what we're doing and why we're doing it this way. Asterisk doesn't scale without a lot o

A little more complicated than that :). So Here's a brief overview of what we're doing and why we're doing it this way. Asterisk doesn't scale without a lot of cruft and it's not accessible. At the high end of the market there's only gigantic switches from companies like Cisco/Alcatel etc; and those are $$$. So we see a market space inbetween cheapo asterisk and high-end cisco. The crux of what we're doing is a lot of work in AMQP (RabbitMQ) to disintermediate the underlying infrastructure from the services. The point is that we don't ultimately want to care what underlying components you run on your network, only that you have components that can be consumed. Think of it as TelecomSDN from a management perspective and a distributed switch from an infrastructure perspective. The stack as we distribute it today is: * Kamailio (Border Controller) * RabbitMQ (AMQP messaging bus) * FreeSWITCH (Open-source switch) * BigCouch (Distributed database with Dynamo Quorum to help deal with Network Partitions) That's the gist of it; all on CentOS and all open-source. We may close source some modules as we go forward, but right now just about everything is open. Using a few clicks in AWS you can run an infrastructure capable of competing against AT&T. There's a lot of telecom infrastructure that exists which can route calls. There aren't a lot of telecom infrastructures that have built-in fault tolerance and linear scaling. EDIT: I should note that we've developed custom modules for both Kamailio and FreeSWITCH for our use case. We had to write a multi-threading module for Erlang for FreeSWITCH, as an example.