Two front doors, a pool of voice servers and a hot-standby management platform. Lose a part and the next call finds another way. Break any of them yourself, right on this page.
This is the shape of the platform: phones, two front doors, a pool of voice servers, and a management platform with a hot standby. Press any box to take it down, and read what happens to your calls.
A diagram of a ProjectPBX cluster. Desk phones, the browser phone and the Android app connect through two front doors to three voice servers. A management platform with a hot standby supplies configuration. Press any part to take it down. The panel then says whether new calls still connect, whether changes are applied, and why. Calls already in progress on a failed part end. Buttons run common scenarios or play a guided tour.
Your people
Front doors different hosts
Voice servers health-checked
Management one shared address
New calls spread across three voice servers. Edits reach every phone in about ten seconds.
Calls connectChanges apply
Phones use the backup front door their company is given, on another host.
Calls connectChanges apply
Health-aware routing sends the next call to a healthy server.
Calls connectChanges wait
Last-known-good keeps working phones calling. Changes apply once it is back.
Calls connectChanges in about 20 s
The hot standby takes over, behind the same address.
Calls connectChanges apply
Both servers serve the company until the old one is empty.
A call already in progress on a failed front door or voice server ends, and the very next call connects on another.
Health-aware routing and last-known-good need no setup, and 4voice keeps the hot standby in step. The one choice that is yours is encrypted desk phones, which you set per company.
Calls only go to voice servers that are healthy. One drops out and the very next call lands on another, with no one touching anything.
Front doors hide the voice servers, relay media and get phones through NAT. Each company gets a primary and a backup, on different hosts.
Front doors keep every company's route, encrypted-phone mode and call-rate cap. Voice servers keep their directory and dialplan. Working phones keep calling.
A live copy of the management database waits on a second server behind the same address. One command moves it into place in about twenty seconds.
Both servers serve the company during the move. Front doors flip routing, phones re-register, the old server drains, and voicemail boxes follow.
Watch itEvery call that crosses the front doors is scored from 1 to 5. A score under 3.5, or loss above 5 percent, raises a flag.
Score a callAvailable per company as Off, Offered or Required: SIP over TLS with the certificate and its name checked, and SRTP audio.
Try the modesThe call path runs on FreeSWITCH, Kamailio, rtpengine and PostgreSQL, tied together by a Python management platform.
See the stackEvery front door and every voice server keeps the last good copy of what it needs, saved to disk for up to 24 hours. A restart in the middle of an outage keeps it too.
Every company's route, its encrypted-phone mode and its call-rate cap.
Each server's agent keeps the last good directory and dialplan.
Records of calls that end during the outage are kept and re-sent once management is back.
With the management platform blocked for 3 min 12 s, calls through both front doors kept connecting.
A streaming replica of the management database sits on a second server behind one shared address. Switch over or fail over with a single command, and watch the clock.
Never a second primary.
After a failover it fences itself.
New calls keep connecting the whole time. Edits go live once the standby answers.
19 s and 20 s without a management platform, nothing lost, and a test call through each front door.
A real-time clock counts the twenty seconds of a standby takeover. New calls keep connecting the whole time. Changes wait until the standby is in place, and then they go live again. Press Run the drill to watch it, or read the final state shown by default.
Moving a company to another voice server runs in four phases, and at every one of them the company has a server to call through. Drag the slider and watch it happen.
A slider from 0 to 100 moves a company between two voice servers in four phases: overlap, cutover, drain and finalize. Twelve phones re-register from the old server to the new one, three calls finish on the old server, and the move finalizes only when the old server is empty.
12phones registered
3calls in progress
Voicemail boxes here
0phones registered
0calls in progress
Waiting to receive them
Both servers serve the company. Nothing has moved yet, and nothing has to: every phone still has a home.
A monitor measures every call that crosses the front doors and scores it from 1 to 5 (MOS). When quality slips, a flag goes up before anyone has to complain.
Browser phone and trunk legs are scored from the voice server's own measurements, so there is nothing for a phone to configure.
A score under 3.5, or packet loss above 5 percent, raises an alert in our monitoring.
With chat alerts on, poor calls are posted to Slack or Google Chat, as an add-on.
Call quality scores show the average per day and per extension, as an add-on.
A call setup ladder from a phone through a front door to a voice server, then the audio, then the hang-up. Two sliders, packet loss and one-way delay, change the call's score on a scale from 1 to 5. A score below 3.5, or loss above 5 percent, raises a flag.
Quality is healthy. No flag.
Set it per company: Off, Offered or Required. Phones use SIP over TLS with the certificate and its name checked, and SRTP audio, ending at the front door.
Standard SIP over UDP, until you are ready to encrypt.
Phones are provisioned for TLS while UDP still works, so you move across at your own pace.
Front doors accept only TLS from the company's phones.
Audio is encrypted with DTLS-SRTP.
Set it per company
Phones are provisioned for SIP over TLS, with the certificate and its name checked, and SRTP audio. The front door still accepts UDP from the company while phones move across.
A short list of conditions raises a flag in our monitoring, a public status page tells you the rest, and your data is copied off-site on a schedule.
The call path runs on FreeSWITCH, Kamailio, rtpengine and PostgreSQL, tied together by a Python management platform. Transcription and voices run on our own servers.
Each one is live in ProjectPBX today. Open any of them for the full detail.
Tell us the outage that keeps you up at night. We will show you ProjectPBX running and talk through how it would go.
