High Availability Class 5 Switch/PBX
This page currently captures my company's attempt at building a high availability Class 5 PBX using FreeSWITCH.
Class 5 - Defined - people always throw telecom terms around:
What is a Class 5 Switch
A Class 5 switch is a phone switch that provides end-subscriber features. This includes features like call routing, IVRs, voice mail, voice mail to email, call forwarding, ACDs, call recording, etc. This presents a unique challenge, in that there are many more stateful services provided by the switch that need care and feeding.
Here are my current plans:
- Dual SBCs on the front end, running HA Linux (Just Heartbeat, Configs are VERY static). No shared state. These machines are stateless, except for checking the load of the clustered machines on the back end. A Python script that uses the Twisted SIP library, and the Twisted FreeSWITCH Socket interface.
- To allow a simpler User Agent (Device) configs and still have high availibility
- These SBCs bypass all media, have no user directory, and one SIP profile facing the User Agents. (I Think - TBD)
- N+1 Clustered FreeSWITCH Media servers on the back end
- These also handle registration, so a shared ODBC Sofia registration DB is required
- Media Servers do all the dirty work - transcoding, dialplan, CDRs, as a normal PBX would.
- Clustering is via a possibly custom ESL mod in the SBC that queries each server and checks the ratio of current calls to MAX_CALLS and routes the session to the server doing the least work. Any server failing to respond gets no traffic sent to it.
- This could also be round robin for simplicity. Statistically, load should get distributed as call volume increases. N+1 Load should be managed such that any one server causes no impact. After the second failure, there may be some performance impact but it should be negligible.
- Clustered MySQL
- Stores lots of things. Each Back End Media Switch is also a data node in the MySQL Cluster
- Front End SBCs are also MySQL Load Balancers, and one is the Cluster Manager.
- Sofia Registrations
- Configs are still regular XML. One node gets updated, then pushes its config to the others via rsync. This is to allow a UI like Blue.Box or FusionPBX to unknowingly manage a cluster of FS servers.
Links to crap I don't want to forget
- 2 servers, Super Micro Mini Boxes with Quad Core Xeons, single 500 GB HD, Dual GB Lan
- Centos 5.5
- MySQL Cluster