Product capability

Service activation

Authorise the relationship before applying the configuration.

The operational problem

Installing a module is only preparation. A working operator relationship must define which service this PBX is entitled to use.

The service lifecycle / conceptual illustration

A number. A service.
A verified relationship.

Each transition has an authority. No single component owns the entire telephone service.

Illustrative number / no live operation020 7946 0123Offer observed

Operator / number provider

Availability is not allocation.

A customer finds a number through the operator availability interface. The offer is scoped evidence, not an allocation or a reservation.

Read the implementation guide ↗

Discover: Offer observed. A customer finds a number through the operator availability interface. The offer is scoped evidence, not an allocation or a reservation. Availability is not allocation.

Assign: Service relationship verified. The operator verifies the actual order, customer entitlement and number assignment. Allocation and activation must be confirmed by its real provider integration. An accepted order is not proof of carrier readiness.

Authorise: PBX entitlement validated. The PBX signs a fresh activation claim. The provider checks current entitlement and returns configuration authorised for that PBX service. Installing a module does not authorise a service.

Apply: Local state pending. Validated authorisation is retained as pending. DOMAINTAINS applies only permitted changes, with ownership and fingerprint checks protecting existing objects. An attempted write is not a verified result.

Verify: Locally provisioned. The resulting native configuration is inspected before provisioned status is recorded. Carrier routing, live calls and emergency confirmation need separate verification. Local success is not a call test.

Maintain: Refresh and reconcile. Activate with retained authorisation obtains a fresh provider response. Matching owned configuration can be reconciled; unexpected administrator changes fail closed. Drift is a conflict, not permission to overwrite.

Unlink: Local authorisation removed. Confirmed Deactivate removes retained activation authorisation. Identity, endpoint, ownership and existing PBX configuration remain. The operator handles upstream withdrawal separately. Local unlink is not cancellation or teardown.

A practical example

A provider refresh changes a channel limit

The module requests fresh authorisation using its retained identity. It validates the new entitlement, records it as pending and reconciles a matching owned trunk. If the provider rejects the request, the previous known-good state is retained.

Prepare the service

Obtain a token privately from a compatible operator. Confirm the correct PBX identity, endpoint and explicit routing policy. Do not place the token in shell arguments, URLs, tickets or logs. The CLI prompts without displaying it; the administrator interface uses a password field and CSRF protection.

Sign, validate, apply, verify

The module creates or reuses its persistent signing identity and sends an Ed25519-signed claim over HTTPS. The response must match the local service and pass validation. Authorised configuration is retained as pending before local reconciliation. Only complete local verification allows provisioned status.

Check the result

Assigned incoming numbers initially use DOMAINTAINS Test, which answers with confirmation tones and hangs up. A locally provisioned result does not prove upstream routing, working outbound calls or emergency registration. Those need separate controlled operator checks.

Read the technical guide All product capabilities