The Agent phones screen in the admin section of the console manages workstation endpoints — the phones that agents sign in at. An agent does not receive calls as an abstract identity; an agent receives calls at a device. This screen is where those devices exist as records. The screen body is shared: the contact-centre console and the voice-AI console render the same implementation, and each supplies only its own page chrome. What you see and edit here is therefore identical in both products.

​
What an agent phone endpoint is

An endpoint is a record for one place a call can be delivered to. It represents a seat’s telephony destination — a browser tab running the softphone, or a physical deskphone registered over SIP — independently of whoever happens to be sitting there. Endpoints are administrative objects. Creating one does not put anyone on shift and does not make the endpoint eligible for work on its own. It becomes eligible only once an agent binds to it (see Binding an endpoint to an agent at login).

​
How an endpoint differs from an agent identity

These are two separate records, and they are deliberately decoupled: The decoupling is what allows hot-desking: the same agent identity can bind to a different endpoint on a different day, and the same endpoint can be used by a different agent on the next shift. It is also why deleting an agent and deleting a phone are different operations with different consequences — removing an endpoint does not remove the person, and removing the person does not free up or reconfigure the device.

​
Browser softphone endpoints vs SIP deskphone endpoints

The two endpoint styles differ in how the call actually reaches the agent, and therefore in how the endpoint is addressed and authenticated. SIP deskphone. The device is reached at a SIP address-of-record. The leg is a SIP leg — the gateway stamps transport = sip on its traces for that leg, and SIP-side failures are visible in HEPv3 capture before any CallEvent is produced. Registration state lives with the device and the registrar, not with the agent identity. If a deskphone is unplugged, the endpoint record still exists and still looks assignable; the failure shows up as an unreachable destination at call time. Browser softphone. The device is a browser session, so there is no long-lived SIP credential on it. Instead your server mints a short-lived browser token for the session and the browser presents that token to the relay directly, over WebRTC / WebTransport. Never put a control-plane API key in the browser to make a softphone work — see Authentication for the token-minting pattern and why the key stays server-side. Browser legs also carry the WebRTC-specific diagnostics (ICE gathering, DTLS handshake, selected candidate type) described in Telephony Metrics, which is usually where you look first when a softphone agent reports one-way audio. Mixed fleets are normal. The distinction matters mainly when you debug: a deskphone problem is a SIP/registration problem, and a softphone problem is usually an ICE, TURN, or token-expiry problem.

​
Binding an endpoint to an agent at login

Binding happens at login, not on this screen. When an agent logs in, the login step binds that agent identity to a workstation endpoint for the duration of the session; work state transitions then apply to that pair. This screen’s job is to make sure the endpoint the agent is about to name already exists and points at the right device. The practical consequence is ordering. Provision or correct the endpoint first, then have the agent log in. An agent who is already logged in is bound to the endpoint as it was resolved at login time.

​
Before you edit or remove an endpoint

An endpoint can be bound to a live session, and a bound session can have a call up on it. Treat edit and delete as operations that can affect a person who is currently talking to a customer. Check first, in this order:
  1. Is anyone logged in at it? Look at the agent’s work state on the agent state screen. A logged-in agent is the signal that the endpoint is bound right now.
  2. Is there a call on it? An agent in a talking state is on a live leg. Wait for the wrap-up, or move the agent off the endpoint, rather than editing underneath them.
  3. For SIP endpoints, does the change require the device to re-register? Changes to how a deskphone is addressed are not picked up by a phone that is already registered with the old details.
The safe sequence for a change that affects addressing is: take the agent out of the ready pool, have them log out, make the change, have them log in again. For a decommission, do the same and remove the endpoint only once nothing is bound to it.
  • Agent state and the ready pool — work states, and the login step that binds an agent to a workstation
  • Authentication — API keys, relay tokens, and browser tokens for softphone sessions
  • Telemetry — traces (transport, call.sid), CDRs, and HEPv3 SIP capture for endpoint-level debugging
  • Telephony Metrics — the audio-quality and WebRTC numbers to read when one endpoint behaves worse than the rest of the fleet