A call kept going through a network cut and back. Restarts move calls first, and browser and app calls now reconnect too.
Last time we wrote that a call carries on when its server fails. Since then we have worked on everything around that moment: the planned restarts, the network that drops out and comes back, and the calls that used to slip through.
A cable pulled, and plugged back in
On our two test servers we took a call from outside on a desk phone, then cut one server's network in the middle of it.
| What happened | Result |
|---|---|
| The other server took the call | Both people kept talking |
| The caller was parked and picked up again | On the server still running |
| The network came back | The call moved home, still going |
A server that loses its network and comes back no longer fights for calls it has already handed on.
Restarts that drop nothing
Restarting or updating a server now hands its calls to another first. Upgrading one server at a time no longer means waiting for a quiet moment.
More of each call carried on
| Before | Now |
|---|---|
| Browser and app calls lost with their server | They reconnect by themselves |
| A recording stopped at the failure | It goes on, as one recording |
| A call that could not be saved was simply gone | The people on it are rung back and put together |
| A queue caller cut off started again | Their place is kept for a few minutes |
The walls, checked again
With several servers sharing the work, we went over every business's separation again, the way an attacker would. Nothing let one business see another's calls, recordings or messages. The gaps we found at the edges are closed.
The honest part
The network cut and the move home were seen on real machines with real desk phones. Browser and app calls, recordings and ring-backs have run in our own testing, not yet on hardware. All of it is in testing. Until you have tried it yourself, keep a standby you trust.