Skip to main content

​
Extension identity: one user endpoint spanning voice, SMS, and appearance

An extension in Devotel Orbit is a user endpoint identity — one object that a person answers calls on, texts from, and appears on colleagues’ phones as. It is deliberately not any of the neighbouring concepts: a DID is a rentable number with its own lifecycle (Number lifecycle), an agent presence state is a routing eligibility flag (Agent presence lifecycle), and the UCaaS/CCaaS/CPaaS split is about which product tier you deploy (UCaaS, CCaaS, and CPaaS). The extension is the identity those constructs point at. Three guides each cover one facet of it — Extensions and desk phones, Extension SMS, Shared Line Appearance — and this page is the model that ties those facets together.

​
What an extension is

An extension is a SIP identity — a label, a derived SIP username, a password, and an optional short extension number — created under Voice → Extensions. It usually resolves to one DID as its caller-ID identity and inbound destination, and it is the identity that many devices register against: the browser softphone, a desktop or mobile app, a zero-touch-provisioned desk phone, or all three at once. The extension answers every inbound call placed to its DID or its short extension number, and whichever of its devices holds the latest registration picks up. The identity is stable even as its facets change. Rotating the password, re-provisioning the desk phone, or removing a member from a shared line does not create a second object — the extension survives, and every binding re-points at it. That is why the answer to “what rings when someone dials Mina?” is always the extension, never the device.

​
The bindings

One extension fans out to several bindings, and each binding is optional — the object is valid with any subset:
  • Desk-phone registrations — a Polycom, Yealink, Cisco, or Grandstream handset pairs to the extension and REGISTERs over its identity. The extension’s Live status card shows the current binding (Registered / Not registered / Disabled) with the last REGISTER’s timestamp and source IP, and can Force unregister it. End-to-end provisioning is in Extensions and desk phones.
  • SIP credentials — the username and password that authenticate each REGISTER. The plaintext is returned exactly once at creation; rotation replaces the password while the username — the identity everything else keys on — stays stable. Full lifecycle: SIP credential lifecycle; how registration proofs are verified: SIP digest verification.
  • The from_extension send-side role — on POST /api/v1/messages/sms, naming from_extension resolves the extension to its DID identity and sends from that DID. It is a sibling of from, not of a sender pool, and is mutually exclusive with sender_pool_id (both on one request → 422). Full precedence chain: Sender resolution.
  • An SMS thread identity — every SMS that names the extension’s DID as sender or recipient rolls into that extension’s per-peer inbox at Voice → Extension SMS, with unread badges and mark-read per peer.

​
Inbound SMS to an extension

Inbound (MO) messages addressed to the extension’s DID land in the extension’s own thread roll-up rather than in the organization’s shared inbox. The GET /threads roll-up groups inbound messages by peer, counts only the inbound direction as unread, and refuses any from number that is not an active DID the organization owns (403 on all four extension-SMS endpoints). Inbound MO rules — tenant-level matchers that route incoming messages to a webhook, queue, inbox, or SMS menu — still fire alongside the extension thread. How the inbound rule surface differs from sender resolution is covered in How routing picks a sender; the extension thread is an additional destination for messages that also matched a rule, not a replacement for rules.

​
Shared-line appearance

Shared Line Appearance (SLA) mirrors one extension onto a roster of devices: an inbound call to the line — via a DID routed to it or an internal dial to its primaryExtension — rings every member at once, the first to answer owns the call, and a colleague with grab permission can move it onto their own device. A member’s private or outbound call never lights the shared busy indicator, so the lamp is accurate. This is the deskphone-replacement pattern for reception and executive-assistant deployments — not a queue and not a ring group. Field-by-field semantics (roster caps, canGrab, grab dedup, DID routing to the line) stay in Shared Line Appearance (SLA); the concept-level rule here is that the line’s identity is an extension, and every member of the roster is an extension or a user id bound to one.

​
Presence interplay

Extension registration state and agent presence are two separate facts that interact at routing time:
  • Registration state — whether a device currently holds a binding on the extension (Registered / Not registered / Disabled). Governs whether a SIP fork would reach a live endpoint at all.
  • Agent presence — the available / busy / wrapup / paused / offline eligibility flag that ACD dispatch and the omnichannel capacity ledger check before any ring (Agent presence lifecycle). Mediated per queue membership, with audit history.
An available agent with no registered device still does not ring — presence qualifies the person for eligibility, registration makes a device answerable. The softphone toggle that flips presence (login, pause codes, logout) never alters the SIP binding, and re-REGISTERing a desk phone never touches the agent’s queue memberships. Keep both healthy, and check presence first: dispatch consults it before it ever asks the SIP edge about registrations.

​
Worked example: a front-desk receptionist

Mina runs a three-person front desk. The shipped setup, end to end:
  1. Create the extension. Under Voice → Extensions, create reception-desk-1 with extension number 201, and save the one-time password (Extensions and desk phones).
  2. Register three desk phones. Under Voice → Desk phones, register the three Polycom handsets (single dialog or CSV bulk import) and pair each to reception-desk-1. All three REGISTER over the same identity; the extension’s Live status card shows the binding.
  3. Wire the SMS inbox. Voice → Extension SMS opens the per-peer thread list for the reception DID — first text of the morning lands in reception-desk-1’s inbox, with unread badges on inbound only (Extension SMS).
  4. Add the shared line. Create a shared line with primaryExtension: "201" and add each colleague’s own extension as a member with canGrab: true. The main inbound DID routes to the line, so all colleagues see Mina’s busy lamp and can grab her answered call (Shared Line Appearance).
  5. Presence for the queue. If Mina also staffs an ACD queue, her softphone presence toggle decides dispatch eligibility — completely independent of which of the three phones is registered. The queue rings her extension; the phones answer.
One extension object carried four facets there: SIP identity, desk-phone registrations, SMS thread, and the shared line’s primaryExtension. No DID lifecycle step, no presence eligibility change, and no UCaaS-tier decision was involved.

​
See also