Case Study: Unified Provisioning Across Multiple Device Vendors

Provisioning crossed device, account, and voice systems

The client's billing and service-management platform remained the source of truth for companies, accounts, credentials, service status, and telephone numbers. The new provisioning application owned device assignments and coordinated the work needed to turn those records into usable physical-device and softphone configurations.

Yealink, Poly, and Grandstream devices each required their own configuration tree. Softphones followed a separate external provisioning path. Every customer also had to be assigned to one high-availability SIP service instance so that all of its endpoints received configuration for the same stable voice endpoint.

Billing, provisioning and PBX responsibilities had to remain separate

• Vendor-specific templates had to remain explicit and maintainable as device families and firmware requirements changed.
• Company, account, credential, and telephone-number changes had to reach the provisioning application reliably from the existing billing environment.
• SIP password corrections and configuration retrieval had to use the PBX's supported SOAP interface.
• Customer-selected BLF layouts had to feed back into device configuration and support remote reprovisioning.
• Reconciliation had to identify differences across billing, provisioning, support, and PBX records.

A dedicated application coordinated each provisioning path

We developed the provisioning application from scratch using PHP and Lua. Separate template trees generated HTTPS configuration for Yealink, Poly, and Grandstream devices, including SIP credentials, telephone numbers, the assigned SIP service endpoint, codecs, firmware settings, and BLF keys. Softphones were provisioned through an established external platform rather than forced through the physical-device workflow.

The billing environment wrote account changes into an intermediary data store. Database triggers placed company names, account details, credentials, and telephone numbers into a processing queue. The application checked that queue every second, retried failed records, and removed each item only after successful processing.

SOAP integration corrected SIP and PBX passwords, retrieved PBX configuration, and supplied data for reconciliation. Reports compared records across the provisioning application and the billing, support, and voice platforms so staff could find customers, accounts, numbers, or configuration that had not synchronised correctly.

A self-service component within the provisioning codebase allowed customers to manage BLF keys and remotely reprovision their devices. The customer access proxy injected that component into the existing portal, keeping the configuration logic in the provisioning application while making it available through the portal customers already used.

A common provisioning path for thousands of endpoints

In production for more than seven years, the application supported thousands of physical devices and softphones. Staff assigned each customer to one high-availability SIP service instance, and every device assigned to that customer was then provisioned against the corresponding stable endpoint.

Physical devices retrieved their vendor-specific configuration over HTTPS, while softphone provisioning remained behind its existing external interface. Staff did not need to configure each physical-device vendor separately, and supported PBX operations and reconciliation remained available from the same provisioning environment.

SIP registration itself did not depend on the provisioning application remaining available. Kamailio passed registrations through to the existing PBX, while a separate integration hook used registration activity to initialise the corresponding real-time session. This kept provisioning and session initialisation connected without moving core registration handling into the provisioning application.

The provisioning application evolved with the surrounding network

The initial provisioning application also coordinated mobile subscriber operations through the client's existing network platform, including IMSI association, service barring, and diagnostic queries. That integration was later decommissioned when the underlying vendor platform was retired.

Over the same period, the provisioning application gained softphone provisioning, customer-managed BLF configuration, remote reprovisioning, reconciliation reporting, and assignment to the client's high-availability SIP services. Keeping those responsibilities behind defined templates and interfaces allowed it to evolve without replacing the billing or voice systems around it.

Related case study:

• High-Availability SIP Infrastructure for a Live Voice Service explains how the assigned SIP services handled endpoint registration, call routing, media, failover, and real-time session behaviour.

---

Client names and identifying details have been withheld to protect confidentiality.