Presence & Busy-Lamp: Knowing Who's Available Before You Dial
Presence looks trivial — “is this person on a call?” — until you try to make it consistent. Is an agent ‘busy’ because of a live call, a wrap-up state, or a DND toggle? Does a colleague on another PBX node see the same thing? And does the state survive a restart?
RustPBX treats presence as platform state, not a desk-local guess.
Three Kinds of “Unavailable”
It helps to separate them, because they have different owners:
| State | Owned by | Consumers |
|---|---|---|
| Registration — is there a reachable device? | Locator registry | Routing, dialing |
| Dialogue — is the extension on a call? | Call state | BLF lamps, transfer target lists |
| Presence — does the person want calls? | The person (idle / busy / away / DND) | Queues, colleagues, consoles |
A desk that merges all three into one green/red dot will eventually be wrong in a meeting. RustPBX exposes each and lets clients decide.
Presence as Shared State
Presence is stored centrally (identity, status, note, activity) and synchronized across cluster nodes alongside locator events. Concretely:
- An extension publishes its state (idle / busy / away with an optional note)
- The PBX stores it and fans it out to peers
- Consoles, desks, and routing all read the same record
This is why CC’s “agents online” count, the desk’s availability badge, and a colleague’s BLF lamp agree with each other: they’re all reading platform state, not polling each desk.
Where Presence Actually Changes Behavior
Presence isn’t just a lamp:
- ACD — agents marked not-ready are excluded from dispatch; breaks are presence transitions
- Screen-pop — the agent’s displayed state rides events so supervisors see ring/wrap-up transitions
- Transfer target lists — the desk can grey out colleagues who are busy, before the transfer attempt
- Messaging integrations — CRM presence widgets consume the same states
BLF at the Signaling Level
Busy-lamp works because dialog state is observable per extension: a subscription is answered with the current state and then updated on each transition (ringing, talking, held). The CC desk uses the internal event stream; SIP phones use the standard dialog package. Either way, the source of truth is the call registry, so a call that starts on one node lights the lamp on another.
Cluster Notes
- Presence events are part of the always-on cluster event hub — even single-node deployments dispatch them internally, so addons behave identically in both modes.
- Node failures mark affected identities appropriately rather than leaving stale “available” lamps.
- Presence is memory + DB backed, so a restart doesn’t leave everyone looking permanently busy.
More in Extension Management and Cluster Deployment.