Hot-desking
Hot-desking (also called extension mobility or shared-device login) lets several agents share the same physical desk phone across rotating shifts. When an agent signs in, the phone becomes their extension: inbound calls to their number ring that phone, and outbound calls from it carry their caller ID. When they sign out, the phone returns to the shared pool until the next agent signs in. Retail floors, clinics, manufacturing lines, and hybrid offices typically have more agents than desks. Provisioning one SIP credential per person on a phone nobody owns leaves devices mis-assigned; hot-desking replaces that with a transient user-to-device binding that follows the person.What hot-desking solves
- Shared physical devices — one desk phone serves the morning shift, the evening shift, and a weekend roster without re-provisioning.
- Personal call routing on shared hardware — the agent’s extension, caller ID, and queue membership attach to the device for the duration of the session, anywhere they sit.
- A clean fallback identity — a signed-out phone keeps its shared-pool SIP credential, so it never dangles without inbound routing. Calls to the pool arrive on the device’s default inbound rule.
Sign in / sign out workflow
Orbit enforces one active session per device and one per user — the same “follow me” semantics as RingCentral Hot Desking or Cisco Extension Mobility.- The agent opens Voice → Hot-desking in the dashboard and enters the
device’s SIP username (the shared credential provisioned for that
phone), optionally with a friendly label such as
Floor 5 — Desk 2. - They can optionally set an end-of-shift time. Orbit signs them out automatically when it passes — treat it as a backstop, not a guarantee.
- On sign-in, any prior session involving either party is released atomically: signing in to a phone someone else is using signs them out, and signing in at a second phone signs the agent out of the first.
- Signing in to the same phone twice is a no-op — the existing session is re-confirmed rather than duplicated.
API reference
Five REST endpoints back the dashboard page, mounted at/api/v1/voice/hot-desking. Authenticate with an API key or the dashboard
session; sign-in, sign-out, list, and me accept the owner, admin,
developer, and agent roles, while the revoke endpoint is restricted to
owner and admin. Paths in the SDK samples are relative to /api/v1.
Sign in
POST /api/v1/voice/hot-desking/sign-in binds the calling user to a shared
desk phone. Send the phone’s SIP credential username; optionally add a
human-readable label and an end-of-shift expiry (ISO-8601, at most 24 hours
ahead).
201 opens a
new session, while 200 returns the existing session when you were already
signed in to that device — data.displaced is null in that case.
Sign out
POST /api/v1/voice/hot-desking/sign-out releases the caller’s active
session and returns the released row. Repeating it returns 410 — never
404 when you had a prior session — carrying when it actually ended and
why (data.details.prior).
List active sessions and check your own
GET /api/v1/voice/hot-desking returns the organization’s active sessions
(newest first, capped at 200) — the board behind Voice → Hot-desking.
GET /api/v1/voice/hot-desking/me returns only the caller’s active
session, or data: null when they are not signed in anywhere.
Force-release a session (admin)
POST /api/v1/voice/hot-desking/:id/revoke force-releases any active
session in the organization — the API behind the revoke action on the
dashboard. Owner or admin role required. Repeating it returns 410 with
the same details.prior shape as sign-out.
Error shapes
Errors return the standard envelope with adetails object where the
endpoint has context to share. Branch on the status code.
Configure a hot-desk device
- Provision a shared SIP credential for the phone (for example
acme-shared-5F-2) under Voice → SIP credentials. This is the pool identity the phone holds while signed out. - Register the device on that credential and confirm it appears as registered.
- Label the phone physically with its SIP username so agents can type it at sign-in without guessing.
- Agents sign in from Voice → Hot-desking. Admins see every active session there, with signed-in duration and a revoke action per row.
Desk reservations are a related but separate feature: a reserved window
blocks double-booking, and signing in during your window claims the desk
automatically. No-show bookings release themselves.
How sign-out interacts with queues, wallboards, and emergency calling
Queue membership. Signing out releases the user-to-device binding; it does not alter the agent’s queue assignments. If no other device is bound to that agent, inbound queue calls to them find no registered endpoint and fall through to the queue’s no-answer path (next agent, voicemail, or overflow) exactly as with any offline agent. See Voice call lifecycle for how those fallbacks resolve. Wallboards and SLOs. A signed-out, unassigned device contributes no agent presence. Agents-away metrics treat it like any offline endpoint — the device itself is not counted as an idle agent. Emergency calling. Orbit does not route emergency calls, and hot-desking does not change that: a call to 911 / 112 / 999 / 000 from a hot-desk device is rejected pre-flight regardless of who is signed in. Because the binding is transient, the physical location of the phone at call time cannot be assumed from the signed-in user. Post the limitation at the shared desk and point agents to a mobile or landline phone for emergencies. Full detail: Emergency calling.Session rules
- One session per user, one per device. A new sign-in displaces the overlapping prior session — there is never a concurrent double-bind.
- Optional auto-sign-out. Set an end-of-shift expiry at sign-in (up to 24 hours ahead). When it passes, the session releases itself and the device returns to the shared pool.
- Housekeeping. Sessions record the sign-in IP, time, and a release
reason (
signed_out,displaced_by_new_session,revoked, or expiry), and every transition lands in the audit log with the actor, device, and timestamps — enough to reconstruct who sat where, when. - Concurrent sign-in races are safe: if two sign-ins collide for the same device or user, one wins and the other is asked to retry.