Purpose and location
Register hardphones, render vendor-specific configuration and audit every secure fetch.
Open Organization → Devices & Provisioning. The available controls depend on the active edition, module entitlement, role and tenant scope.
Before you start
Use a tenant-scoped administrator unless the task genuinely requires platform access. Create plans, locations and roles before assigning them to people or endpoints.
Capture the current value or export the affected records before a bulk or routing change. This gives the operator a precise comparison point and makes a supported transaction undo easier to assess.
Step-by-step workflow
Complete the steps in order. Do not combine an initial configuration with unrelated cleanup; small, attributable changes are easier to test and reverse.
- Assign the hardphone to an extension with SIP credentials.
- Select the manufacturer, exact model and transport.
- Copy the one-time secure provisioning URL into the phone, DHCP option or approved vendor redirection service.
- Preview the rendered file and confirm a successful fetch in Provisioning history.
- Rotate the URL immediately if it may have leaked.
Field reference
Use the reference below while completing the form. Fields hidden by edition, module entitlement or role are intentionally unavailable to the signed-in user.
- Manufacturer and model
- Supported Yealink, Fanvil, Grandstream, Poly, Snom, Cisco MPP/SPA and Htek family profile, or a tenant custom template.
- MAC address
- Twelve hexadecimal characters used to bind the file to one registered endpoint.
- Transport
- UDP, TCP or TLS rendered into the selected vendor profile.
- VLAN / codecs / NTP / language
- Per-device settings that override template defaults.
- Secure provisioning URL
- Random 256-bit bootstrap credential shown only when created or rotated; only its digest is stored.
- Preview
- Tenant-admin-only view of the final vendor file before a physical device retrieves it.
- Provisioning history
- Timestamp, result, source IP and safe error summary for recent downloads.
- Custom template
- Tenant and model-specific override using the documented escaped variables.
Acceptance checks
A saved record is only the beginning of validation. Run every relevant check below and retain the call-session ID, time and result when telephony is involved.
- Factory-reset the device and confirm it downloads only the canonical MAC-specific filename over HTTPS.
- Verify registration, inbound/outbound audio, RFC 4733 DTMF and voicemail access.
- Rotate the provisioning URL and confirm the previous address returns 404.
- Record the tested hardware model and firmware version before declaring it certified.
Common mistakes and safe recovery
If a check fails, stop adding changes. Restore the previous value or use a supported transaction undo, regenerate PBX configuration, then repeat the smallest failing test.
- The provisioning URL contains a bootstrap secret and must not be placed in tickets, screenshots or ordinary email.
- A listed family profile provides registration compatibility; model/firmware certification still requires a physical-device acceptance test.
- Do not distribute third-party PBX template bodies as RelayPBX custom templates.
What to include in a support case
Provide the tenant, module and object name, local time with timezone, expected result, observed result and the most recent successful state. For a call problem, include the logical call-session ID and the redacted SIP/SDP text diagnostic before requesting PCAP.
Never paste passwords, private keys, raw license payloads or unredacted customer media into a ticket. Use the one-time diagnostic grant and attachment controls when support requests additional evidence.