# Agent phones (workstation endpoints)

> What a workstation endpoint is, how it differs from an agent identity, how browser softphones and SIP deskphones are addressed, and what to check before you change one.

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](#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:

| | Agent identity | Workstation endpoint |
| --- | --- | --- |
| Represents | A person who does work | A device that can ring |
| Carries | Work state, skills, queue membership | Its telephony address |
| Managed on | The agent state / roster screens | This screen |
| Lifetime | Follows the person's employment | Follows the hardware or the browser deployment |

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](/concepts/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](/glossary/metrics#webrtc-specific-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.

## Related

- [Agent state and the ready pool](/modalities/voice/transport-telephony/agent-state) —
  work states, and the `login` step that binds an agent to a workstation
- [Authentication](/concepts/authentication) — API keys, relay tokens, and
  browser tokens for softphone sessions
- [Telemetry](/platform/telemetry) — traces (`transport`, `call.sid`), CDRs,
  and HEPv3 SIP capture for endpoint-level debugging
- [Telephony Metrics](/glossary/metrics) — the audio-quality and WebRTC
  numbers to read when one endpoint behaves worse than the rest of the fleet