Managing Devices

The Devices page lets you manage every phone on the account — deskphones, DECT base stations, and the wireless handsets paired with those bases. Deskphones are PoE-wired or Wi-Fi desk phones; DECT systems are a base station plus a fleet of cordless handsets.

Viewing Devices

Navigate to Devices from the sidebar. The table shows every device on the selected account with its name, type, hardware identifier (MAC address for deskphones and bases; IPEI for handsets), vendor, model, status, location, and the user it is assigned to.

A device you haven't named shows the name of the user it is assigned to, and follows that user if you reassign the device or rename the user. Give the device a name only when you want it called something else — clear the name to go back to the user's.

DECT handsets are listed underneath their paired base in the table — indented and grouped — so a base and its handsets stay visually together. A handset that has been stocked but not yet paired with a base appears as a top-level row.

Ordered hardware

Hardware ordered with the account that hasn't been delivered yet appears at the bottom of the table — one row per unit, each with an ordered badge showing the vendor and model. There is no device to configure yet; once a unit ships and registers, that same row becomes a regular device row.

You can decide ahead of time who each ordered phone or handset is for and which site it goes to. Pick its user and location right in the row (or open its detail page) — the same way you configure a delivered device — and both are applied automatically when the device arrives and registers. Base stations can be staged for a location but not assigned to a user (they serve all users at a site); handsets are assigned to a user but inherit their location from the base they pair with.

Ordered, shipped and received

The Status column follows hardware from order to desk. Units still on order show Ordered, with the order date underneath (a draft or a requested order shows that instead). Once the distributor ships a phone, it becomes a regular device row marked Shipped, with the ship date underneath. It counts as received when it is plugged in and fetches its configuration, at which point the usual readiness status takes over. Shipped is also a status filter.

Handsets that arrive without an IPEI

A handset shipped in a kit with its base (for example the M53 in an M253) arrives without its IPEI: the distributor records only the base. Its row is highlighted and shows Enter IPEI in the Hardware ID column. Read the IPEI off the handset's label or the kit's box and enter it there. IPEI needed is also a status filter, and these handsets count as needing setup.

Setting up devices from the table

You can set each device's user and location straight from the table, for delivered devices and hardware still in transit alike. A phone set up before it ships arrives ready to use. The user picker hides people who already have a phone, and Create user inside the picker opens the same form as New user on the Users page, prefilled with what you typed, and then assigns the phone to that person. Admin only access isn't offered there, since an admin without phone service can't be assigned a phone. Picking someone else for a delivered phone moves it to them; choose Unassigned to free it. Base stations take a location but no user, and handsets take their location from their base. A handset that hasn't been paired yet offers a base picker instead. Phones shared by several users are managed from their detail page.

Use the Needs setup status filter to list only what still lacks a user, a location or a base, and the order filter to narrow the table to one or more hardware orders (or to devices Added manually).

Searching and filtering

A filter strip above the table lets you narrow the list:

• Search — type any part of a name, MAC address, IPEI, model, vendor, or an assigned user's name or email.
• Type — show only deskphones, bases, or handsets.
• Location — show devices at one or more physical sites (or "Unassigned"). Handsets are matched by the location of their paired base.
• Status — show devices in a specific provisioning state.

Filters and search compose, and the result is preserved as you move through the table.

Bulk-assigning a button template

Use the checkbox column to apply one button template to several visible phones:

1. Select individual deskphones or DECT handsets, or use the header checkbox to select all eligible phones in the current filtered view.
2. Click Assign template in the selection bar.
3. Choose a template and click Apply.

DECT bases and hardware that has not arrived cannot be selected because neither has programmable keys to configure. Changing search or filters clears selections that are no longer visible, so the action only affects the phones shown as selected.

Updates run in small batches. If some phones cannot be updated, the dialog lists each failed phone and its error, keeps those phones selected, and offers Retry failed devices. Successful phones are removed from the selection.

For automatic assignment on phones added later, set the account default button template.

Provisioning

Phones added here are configured automatically — no per-device data entry. See Phone Provisioning for the overview, including what to do if a phone won't register.

The provisioning token and URL live on the Account Settings page under the collapsible Provisioning section. See Account Settings for details.

Adding a Device

1. Click Add Device in the top-right corner.

2. Choose the type of device you want to add:

   • Deskphone — PoE-wired or Wi-Fi desk phones.
   • DECT Base — Wireless system with a base station and cordless handsets.
   • DECT Handset — A cordless handset that pairs with a DECT base station.

3. For deskphones and DECT bases, enter the MAC Address (format: 00:04:13:XX:XX:XX).

   For DECT handsets, enter the IPEI and pick the DECT Base to pair it with. You can leave the base picker blank to stock an unpaired handset and pair it later from the handset's detail page.

4. Optionally enter a Name to help you recognize the device later (e.g., "Reception", "Conference room", "John's phone").

5. Optionally enter the Model (e.g., "D815" for deskphones, "M58" for a DECT handset).

6. For deskphones and DECT bases, choose the Location — the physical site the device lives at. This determines the dispatch address used when the device places an emergency call. It defaults to the account's main location (shown with its full address) so a single-site account is correct without any extra step; change it if this device lives at a different site. For DECT systems, the base's location is shared by every handset paired with it. See E911 Dispatch Addresses for the full picture.

7. Click the submit button to register the device.

Devices can be renamed, moved between locations, or repaired with a different base later from their detail page.

DECT Limitations

DECT handsets are cordless phones built around a single radio link to their base station, and that design imposes a few limits a wired deskphone doesn't have. Plan for these when you decide whether DECT is the right fit:

• User presence is base-local, not system-wide. A DECT handset shows the busy/idle status of another user only when that user's handset pairs to the same base station. Within one base, busy-lamp keys work as expected; they can't watch a user on a different base or on a deskphone.
• Call parking has no occupied-slot indicator. A parked call can't show up as a quiet "occupied" lamp on a handset. The call can still be parked and retrieved from any handset, but there's no glanceable way to see which park slots are in use.

DECT is still the right choice where running Ethernet isn't practical and Wi-Fi coverage is unreliable — it trades system-wide presence for mobility and easy deployment. Where you need system-level busy-lamp keys (watching users on other bases or deskphones) or parking indicators, choose a wired or Wi-Fi deskphone instead.

Is My Phone Working?

Every device tells you where it is on the path from "in the box" to "in service" — no phone-system expertise needed.

The setup checklist

While a phone is being set up, its detail page opens with a Device setup checklist:

1. Phone retrieved its configuration — the phone has fetched its configuration from DialStack.
2. Online — the phone is reachable right now: it's powered on, on the network, and holding a live connection to DialStack.
3. Ready to call — the phone belongs to a user and that user's line is live, so it can make and receive calls.
4. First call made — the phone has placed or received a call, proving its connection to the phone network works.

Step titles reflect their state — a step that hasn't happened yet reads as pending ("Not online yet"), never as a fact. The current step shows a one-line hint for what to do next — plug the phone in, check the network, assign a user, or make a test call.

Online is not the same as ready to call. A phone can be reachable before anyone is assigned to it — it's on the network and healthy, it just can't place calls yet. Assigning a user is what unlocks calling, and you can do it at any point: before the phone is plugged in, or long after. The checklist points it out only when it's the thing standing between you and a working phone.

The checklist updates live, so you can watch a phone come up while you're standing next to it.

After the first call

Once a phone has carried a call, the checklist is replaced by a compact status: "Phone is working" (or "Phone is offline") with the evidence underneath — online since when, the last call, and the last time it fetched its settings. A working phone stays quiet; if it ever drops offline, the problem — and what to check — shows up right there.

In the devices table

The table's status badge gives you the same signal at a glance:

• Setting up — the device is still onboarding.
• Online / Offline — the device has proven itself with a call; the badge now tracks live reachability.

A device that needs attention

Occasionally a phone's registration with its manufacturer fails, and the phone needs support's help before it can fetch its configuration from DialStack on its own. In the table the phone carries an amber row and a warning icon, and a banner on its detail page says what is blocking it:

• Registered to another provider: the phone is already registered to another company in the manufacturer's provisioning directory, which is common for phones bought secondhand or carried over from a previous provider. Support is having it released.
• Serial number mismatch: the manufacturer says the serial number on file does not belong to this phone. Correct it as described below.
• Waiting on manufacturer: support is handling it, and nothing is needed from you.
• Registration rejected: contact support.

Support needs the phone's serial number to have it released. Open the phone's detail page and enter the serial number in the banner, then click Save. You can find it on the label on the back or bottom of the phone, usually marked SN or S/N. It is made of letters, numbers, and dashes. Once it is saved, the banner confirms it was received, and you can click Edit to correct it. The serial number then also appears in the phone's device details.

Support takes it from there and has the phone released and transferred to your account. The banner clears on its own once that is done. It usually takes a business day or two, because it depends on the manufacturer.

In the meantime the phone stays in your device list and keeps its user assignment, so nothing is lost. The phone cannot be removed while it is in this state. If you need it taken off the account, contact support.

Reloading Device Configuration

Each device row exposes a reload icon (the circular arrow next to the row's actions). Clicking it asks the device to fetch and apply its latest configuration without rebooting — active calls keep going and the device stays registered.

Use this after changing settings that affect a specific device (name, line keys). Routine clicks on the admin UI do not need it. Assignment changes don't need it either: when you assign a user to a device, remove one, or move a user between devices, the affected device reloads automatically if it is registered.

• Deskphones and DECT base stations — Clicking the icon triggers the reload directly on the device.
• DECT handsets — Handsets do not reload on their own. Clicking the icon opens a dialog explaining that the reload is performed on the paired base, which then fans the update out to every handset registered with it. Confirming the dialog reloads the base. A handset that is not paired with a base cannot be reloaded.

Device Detail Page

Click any device row to open its detail page. The header carries the device's name with an inline edit affordance — click the pencil to rename in place. An unnamed device shows its user's name as a placeholder; clearing the name returns to it.

Below the header are two cards:

• Device Info — type, hardware identifier (MAC or IPEI), vendor, model, status, firmware version, last-provisioned timestamp, current IP address, and (for bases) max handsets and multicell role. Most fields are read-only and reflect what the device reports during provisioning. The exception is a DECT handset's model: handsets never provision (the base fetches config and pushes it over DECT), so the handset can't report its model — set it here from the dropdown. This is required before you can bind a button template (see below). A Resync button in the card header pushes a configuration reload to the device — the same operation as the row-level icon in the devices table, surfaced here for when you're working on this specific device. The device reloads to apply the latest configuration, which briefly interrupts any active call; for a DECT handset it confirms the reload on the paired base.
• Configuration — inline pickers for the fields you control:
  • Location — the device's E911 dispatch address. For deskphones and bases this is editable directly. For DECT handsets it is read-only and shows the value inherited from the paired base.
  • Paired base (handsets only) — move the handset to a different DECT base on the account, or unpair it entirely. The handset record stays so you can re-pair it later.
  • User — the user this phone is assigned to. The picker shows everyone on the account; selecting a user assigns the device to them.
  • Advanced (deskphones and bases) — a collapsed section for settings most accounts never touch. It holds SIP Transport, which controls how the device's call signaling reaches the platform. Leave it on Inherit (default) unless you've been advised otherwise — the platform default applies automatically and is right for almost every network. Choosing UDP, TCP or TLS overrides the transport for this one device. Handsets follow their base, so this section isn't shown on a handset. On Snom and Yealink deskphones it also holds Ring Group Calls: choose Ring silently to have calls that come through a ring group show on screen and flash the light without ringing out loud, while every other call rings as usual. Ring normally keeps them audible even if silent ringing was turned on for the whole account, and Inherit (default) follows the account.

One device per user

A user can only have one phone assigned at a time. If you pick a user who is already assigned to another device, the admin shows a confirmation dialog noting which device they're on. Confirming reassigns the user to this device and releases the old one. Cancelling leaves both assignments untouched.

Programmable buttons

Deskphones and DECT handsets carry a Buttons card where you bind a reusable button template — speed dials, call parking, voicemail, and do-not-disturb. The Effective buttons table shows exactly what the phone will provision after the template and any per-device overrides are merged, along with whether each button is supported by the model. You can add per-device overrides, suppress individual template buttons for this phone, and restore them later — all without changing the shared template. Templates are managed from the account's Settings view; per-device tweaks live here on the device.

Some rows are badged Phone default. A few phone models have no other way to reach a function at all — the Snom D800 desk phones (D810WB, D812, D815W, D815WB), for example, have no do-not-disturb hard key and no do-not-disturb softkey, so the only place DND can live is a programmable key. On those models, if neither the template nor an override provides that button, the Effective buttons table adds one automatically, just after the template's last button. It is not part of the template, so it appears on that model only and disappears the moment you provide your own. Treat it like any other row: place an override at its position to replace it, or suppress it to remove it. Because it sits one slot past the template's last button, adding buttons to the template moves it along too — a suppression stays with the position, not with the button, so it will not follow.

DECT bases do not carry their own Buttons card — a base has no assigned user and renders no buttons of its own. Buttons live on each paired handset, so bind templates on the handset's detail page instead.

If the device's model isn't in our capability matrix yet, the card shows a "Button management not available" message instead of an empty table — the phone still provisions, just without programmable-key configuration from the admin. For a DECT handset, this usually just means the model hasn't been set: set it in the Device Info card and the Buttons card will appear.

Removing a Device

From the devices table, hover a row and click the trash icon to delete the device. Deleting a DECT base keeps its handsets: they become unpaired top-level rows in the table, with their user assignments intact, and can be paired with another base later from each handset's detail page. A handset stays out of service until it is re-paired. Deleting a deskphone does not affect the users that were assigned to it — the user simply has no phone until you assign them a new one.