A single TeleQuick Voice node runs everything — signalling, media, routing, and agent state — and it runs fine that way. But one node is one failure domain: if that host dies, everything on it dies with it. High availability is opt-in. You turn it on by running two or more engine nodes and enabling the replicated control plane that keeps them in agreement. Below two nodes there is nothing to fail over to, so a single node is never truly HA no matter what you configure. When HA is off, there is zero overhead — the control plane runs in single-node mode and never touches the network for consensus. You opt in only when you deploy more than one node.
HA covers the control plane — membership, call/session ownership, and routing — and that failover is shipped and exercised. Media continuity across a mid-call node loss is more nuanced; read What survives a failure before you design around seamless mid-call survival.

​
How it works

Every node runs the same engine. What makes a set of nodes a cluster is a replicated control plane — a single authoritative, replayable log of cluster state that every node holds a copy of:

Membership

Which nodes are alive and in the cluster right now. Nodes heartbeat each other for liveness; a node that stops heartbeating is declared down.

Ownership

Which node currently owns each call, session, and agent registration. Every live entity has exactly one owning node at a time.

Routing

Where new calls and control verbs should land — trunk bindings, agent availability, and queue/skill assignments — so any node can steer a request to the node that owns the target.
The log is replicated across the nodes themselves — there is no external coordinator to stand up or babysit. You do not deploy a separate consensus service, quorum store, or lock manager alongside the engine; the cluster reaches agreement internally over the same secured transport it already uses. That keeps the operational surface to just “run N engine nodes.”

​
Boot snapshot for fast recovery

Replaying the full history of a long-lived cluster from the beginning would make a restarting node slow to rejoin. Instead, the control plane periodically writes a boot snapshot — a compacted point-in-time image of membership, ownership, and routing. A node that (re)starts loads the latest snapshot and then replays only the tail of the log after it, so it catches up to current cluster state in seconds rather than reprocessing everything. This is what makes rolling restarts and node replacement quick.

​
No single point of failure

Because the log and its snapshot live on every node, there is no one host whose loss stops the cluster from making progress. Lose a node and the survivors still hold the authoritative state; they re-elect ownership for whatever the dead node held and keep accepting new work. There is no primary database, no leader-only store, and no coordinator process whose death is fatal.

​
What happens on a node failure

1

The node stops heartbeating

Its peers miss its heartbeats past the liveness deadline and mark it down in the replicated membership state.
2

Ownership is reassigned

Everything the dead node owned — call/session ownership and agent registrations — is re-owned by surviving nodes through the control plane. No operator action is required.
3

Routing moves to survivors

New calls, control verbs, and agent traffic that would have targeted the dead node are steered to the nodes that now own the work. Trunk and relay bindings converge on the survivors.
4

The node rejoins cleanly

When the host comes back, it loads the latest boot snapshot, replays the log tail, and re-enters the cluster — then it can take a share of ownership again.

​
What survives a failure

Be precise about what “highly available” buys you, because control-plane failover and media continuity are different guarantees.

Shipped: control-plane failover

Membership, ownership, and routing move to surviving nodes automatically. The cluster keeps accepting and routing new calls through the failure, agent state and registrations are preserved in the replicated log, and control verbs (including the CSTA CTI surface) continue to resolve against the survivors.

Best-effort: media on the failed node

Calls whose media was terminating on the node that died lose that RTP path when the node goes. The control plane recovers ownership and routing, but audio in flight on the dead host is not teleported to a survivor mid-stream. Reconnecting clients and new legs land on healthy nodes.
A hard node loss is not seamless for a call whose media was terminating on the failed node — plan your SLAs accordingly. What is guaranteed today is that the cluster stays available — new calls, routing, and agent/CTI control keep working through a node failure, and calls not pinned to the dead node are unaffected. Calls actively terminating media on the lost node are dropped and must reconnect.

​
Deploy for HA

1

Run two or more engine nodes

A minimum of two nodes — more for headroom, so a single failure still leaves enough capacity. Each node is a full engine; there are no special-role hosts.
2

Front them with a relay or anycast

Put the nodes behind relay.telequick.dev (or an anycast address) so clients reach a single stable endpoint and are steered to a live node. Signalling and media land on whichever node the relay directs them to; the control plane sorts out ownership from there.
3

Enable the replicated control plane

Turn on cluster mode so the nodes form the replicated log and begin heartbeating. This is the opt-in piece — it does nothing on a single node and only engages once peers are present.
4

Verify failover before you rely on it

Drain or kill a node and confirm new calls still route, agents stay registered, and CTI verbs resolve. Then bring the node back and confirm it rejoins from its boot snapshot.
HA is an add-on to any self-managed deployment — it pairs with self-hosted / on-prem. On managed cloud the multi-node cluster is operated for you; you don’t configure it.

Deployment models

Managed cloud, self-hosted, and hybrid — and which planes you run.

On-prem quickstart

Stand up the engine and control plane in your own environment.

CSTA CTI

Third-party call control that resolves against the same clustered nodes.

Voice architecture

The end-to-end signalling, media, and runtime path.