The details worth asking about.

It lets a compatible communications operator deliver and maintain authorised service-related configuration on FreePBX 16 and 17. The module validates the response, applies configuration through FreePBX APIs and verifies the local result. It does not supply the carrier network or replace FreePBX.

A number alone is not a working telephone service. Its assignment, permitted use, routing and PBX configuration need to agree. DOMAINTAINS gives the PBX side a defined relationship with the operator-authorised service, while the operator remains responsible for the upstream service.

The repository targets FreePBX 16 and 17. The module requires PHP Sodium and HTTPS support. The independent operator examples require PHP 8.2+ and their own dependencies. Controlled live compatibility and upgrade acceptance remain necessary before operational use.

The public software is licensed under GNU GPL version 3 or later, as recorded by module.xml with the GPL text in the repository. You can inspect, modify and redistribute it subject to that licence. Software rights are not a promise of hosting, support or carrier service.

No. The administrator chooses a compatible HTTPS provisioning endpoint, and operators can implement the public contracts around their own infrastructure. FreePBX UK is a complementary integrated-service option, not a requirement for using the open-source technology.

No. Provider-neutral means the public interfaces do not hard-code a commercial provider or billing platform. A real operator must implement, configure and verify its adapters against the chosen infrastructure. The supplied fixtures are not production connectors.

You supply authoritative customer and service relationships, numbering, compatible provisioning, reachability and SIP edges, plus billing and operational controls. The independent BYOT reference demonstrates preparation, linking, activation, verification and recovery through replaceable interfaces.

No. Every result in the lab is synthetic and exists only to demonstrate searching and selection. It makes no carrier requests, takes no payment and neither allocates nor reserves a number. A real purchase must happen through a properly integrated operator.

No. The search uses OR: a result may match any one or more of the three patterns. Only subscriber digits after the selected area code are searched. Each pattern must contain 2 to 7 digits, fit the subscriber length and differ from the other active patterns.

Each search field has its own colour. When a number matches multiple fields, equal, sharply divided sections retain all of those colours. In this lab, matching digits also show their field colours, including overlapping occurrences. Text labels expose the matching fields without relying on colour alone.

The implementation keeps availability requests deliberate. One Search click checks at most six sequential positions. Find more explicitly searches further; See more and See less only change the local list. This limits unnecessary carrier traffic and leaves the customer in control.

No. Availability and scoped offer evidence do not create a carrier reservation. The operator must recheck availability and enforce real allocation and duplicate-operation protections. Any separate reservation service needs its own verified ownership and expiry guarantees.

Unowned objects cannot be silently changed or deleted. Exactly matching unowned configuration may be reused without becoming owned. DOMAINTAINS records verified objects in an ownership ledger and checks fingerprints before changing managed configuration. Conflicts stop the operation for review.

The PBX signs a request using its persistent identity, sends it to the configured HTTPS endpoint and validates the authorised response. Configuration is applied and verified locally before provisioned status is reported. Carrier readiness and call testing remain separate checks.

Provider-authorised incoming numbers initially use DOMAINTAINS Test. It answers with confirmation tones and hangs up. This is a local test destination, not a promise of an operational customer call flow or proof that the carrier has delivered a call.

It removes retained local activation authorisation only. Signing identity, endpoint, ownership, routing policy and PBX configuration remain. Calls may still work. It does not cancel a subscription, revoke carrier authorisation or request remote teardown.

Reactivate deliberately replaces valid retained authorisation after confirmation while preserving the signing identity. Ordinary Activate refuses a different token while retained state exists. Operator-side rotation and public-key recovery have their own authority requirements.

No. The separate operator-side integration requires authenticated customer access, current per-number authority, explicit confirmation and a real provider adapter. Submission is not registration. Only explicit authoritative carrier confirmation can establish registered status.

The emergency reference does not automatically change FreePBX Emergency Caller IDs. It also does not establish a general emergency dialling policy. The operator and PBX administrator must separately verify calling permissions, caller identity and emergency-service routing.

No. Activation tokens and signing keys relate to PBX service authorisation. Customer authentication, mutation permission and current resource ownership must be established independently through the operator platform. A browser account identifier cannot grant authority.

The operator does. The public contracts separate billing preflight, durable operation guards and reconciliation from allocation and activation. Search and checkout verification do not bill. Financial correctness must be proven in the actual commercial system.

Each picker has its own selection field, radio group and Refresh identity. Server checks bind evidence to customer, product and resource. At fulfilment, the receipt must match an independently verified immutable originating-item relationship, preventing same-account receipt swaps.

The production adapter must preserve the partial outcome durably and block blind retries. A local rollback cannot undo a remote carrier allocation. Recovery needs explicit operator review, idempotency protection and independent confirmation of what each system actually did.

The filesystem reference coordinates consumers sharing its local protection boundary. Separate hosts need a common availability gateway or separately verified distributed limiter. Every page, worker and scheduled job sharing carrier authority must be included.

No. Its public scope is authorised activation and reconciliation of its own service-related FreePBX configuration. It is not a remote shell, remote desktop or general PBX administration service. It does not automatically manage the FreePBX Firewall.

Inspect the public source and existing contracts, reproduce the issue with synthetic data and explain the expected authority boundary. Public repository issues and pull requests are the visible collaboration route. Do not publish tokens, keys, addresses, customer records or confidential vulnerability details. No response-time commitment is stated.

Read the milestone history, preserve protected keys and ownership stores, back up PBX and operator state consistently and rehearse restoration. Test upgrades on controlled FreePBX 16 and 17 systems before operational use. Do not use file deletion as a migration strategy.

No. It is a development milestone with local automated testing and independent development review. Real operator adapters, genuine number-search browser acceptance, controlled staging, live carrier and financial verification and final production approval remain outstanding.

Discuss service availability, support arrangements and commercial terms with your chosen operator. This site does not publish prices, service-level guarantees or a support response commitment. The FreePBX UK integrated-service proposition is separate from the public software and requires its own confirmed arrangements.

Only through a safe, explicit review. The interactive adoption command previews eligible exact native objects and asks for administrator confirmation. It does not resolve conflicting or ambiguous configuration by overwriting it. Existing objects do not become owned merely because they look compatible.

The public module contains an internal ownership-protected teardown primitive, but not a general remote teardown service or public teardown CLI action. Remote lifecycle delivery and selective teardown remain documented future work. Local Deactivate is not a substitute for service cancellation.