Basic Cluster Operation

The most basic cluster would consist of one DjangoPBX, one FreeSWITCH, one AMQP Message Broker and one File Store. In most cases, more than one FreeSWITCH will be required, and many orgainisations choose to use separate database servers coupled with DjangoPBX replicas. The typical cluster diagram shows this kind of deployment.

So how does a cluster work?

For any given domain (customer) we have two DNS records (CNAMEs are fine), for example cust1.djangopbx.com and portal-cust1.djangopbx.com.

cust1.djangopbx.com points to the IP address of the FreeSWITCH that will be home for this domain (SIP Realm). portal-cust1.djangopbx.com points to the IP address of the DjangoPBX server. We will refer to this domain as “cust1”.

When cust1 makes a call, the FreeSWITCH fetches the dialplan from DjangoPBX or an available replica and the call is routed. During the call, FreeSWITCH sends events about the call to the AMQP Message Broker (RabbitMQ) server, including the final CDR record, and DjangoPBX collects these from the AMQP Message Broker. If DjangoPBX is not available or too busy, the AMQP Message Broker will store the data until an instance of DjangoPBX becomes available to receive it.

If the call was recorded, FreeSWITCH would send the recording, via http_cache (non blocking), to the File Store; a message is also sent via the AMQP Message Broker back to DjangoPBX containing the name and location of the recording.

If a customer logs in to portal-cust1.djangopbx.com, they can view their CDR records and voicemails etc. and, if they click the button to listen to a call recording, DjangoPBX fetches the recording from the file store.

The file store isn’t really much more than a standard chrooted SFTP server, but it does also run a very small amount of Django framework code to allow FreeSWITCH to send call recordings via an HTTP PUT.