Note: I AM NOT AN EXPERT, DEVELOPER OR IN ANY WAY AFFILIATED WITH 2600HZ
I am a huge fan of 2600hz’s Kazoo. An open source, scalable, multi-tenant VoIP solution. They cover their costs by selling commercial solutions and many “apps” for the service are gated behind their paid services. But this hasn’t stopped many others out there from using the 2600hz Kazoo platform to build a viable commercial telecommunications solution for their customers.
If you’re thinking about using Kazoo to build your telecommunications infrastructure, I will be writing several guides based on my experience with the Open Source solution. Running your own VoIP infrastructure requires knowledge of the SIP protocol, databases, networking and network communication, security, telecommunications law and more.
If you are considering deploying infrastructure for 1000+ users, you will need your own in-house experts or, I would recommend, engage the developers for their paid products over at 2600hz.com
Why choose 2600hz Kazoo
I had been traditionally re-selling white-labeled VoIP solutions. Like FastGoodCheap indicates you always want things fast, good and cheap. Now pick two.
So wanting to start selling VoIP services, I picked something that was ready made and cheap so that I could compete, which meant white-labeling. Although the service we re-sold was not that bad, I had no control. So one day, when a database issue at the provider caused an issue, all my new customers had broken phone systems for over 48 hours.
And so, I started to look for solutions to increase control over the system and mitigate outages. I looked in to Asterisk, FusionPBX, 3CX and other solutions that were better known to me, but what I didn’t want to do, is have to create a server per customer, so Multi-Tenancy was a massive requirement.
Stumbling along Kazoo which had just hit version 3.0, it touted a lot of features I wanted. It had Multi-Tenancy, it had scalability, it has high availability and it used well known Open Source projects as it’s base. Knowing that Kazoo would make use of Kamailio, Freeswitch, RabbitMQ, CouchDB and other projects I knew gave me confidence in the project.
Components
As mentioned above 2600hz Kazoo makes use of existing open-source and community driven projects and instead, programs the “glue” that holds it all together. It provides the configurations and the PBX applications that turn this from a series of disjointed services in to a fully working telecommunications platform. A run down of these are;
- Freeswitch to handle call media
- Kamailio to handle SIP messaging, load balancing, etc
- RabbitMQ to handle the message bus
- BigCouch or CouchDB to store documents and configuration
- HAProxy to failover and load balance your TCP services
- Kazoo MonsterUI for a Frontend User Interface
- Kazoo Applications to provide functionality like authentication, presence, websockets, a REST API, callflows, call rating and more
Design Considerations
As should be obvious, spending more time in planning your new infrastructure will save you countless, hundreds of hours down the track and there are many caveats and pitfalls if you don’t pay attention. The documentation has a pretty good guide and outlines a 7 server per-zone setup. What if you are only servicing 200 users and 7 servers across two zones (for redundancy) seems excessive to you. So you have a choice;
- Single Server (1 server)
- Single Zone (7+ servers)
- Multiple Zones (14+ servers)
I will go in to more detail in future posts, but my immediate advise would be this;
Single Server Considerations
Keep your database on a separate server regardless.
This does mean two servers, but if you opt to CouchDB (for easier future expansion) instead of Couchbase, I experienced issues with erlang versions causing crashes.
Prepare to expand
One server will work fine, but obviously, you have no redundancy and if you are selling VoIP services, your customers will not accept ANY downtime. At some point, you will also hit a limit of users before the performance of your server starts to tank.
Multiple Server Considerations
Keep your Media and SBC servers separate
Do not install these roles on the same server. Once you start dealing with more than one media or SBC server, you will find that the IP for your SBC/Media server can only be on the Authoritative ACL and you won’t be able to add it again to the Trusted ACL. This will result in attended call transfers failing with a MANDATORY IE MISSING error.
Encrypt your traffic
If you are dealing with multiple datacenters and communications are travelling over the public internet, encrypt your communications. Unless you take extra steps, your message bus and database communication will all be plain.