Case Study: Unified Access and Real-Time Integration Across Telecoms Platforms

Customer access, staff access, and call control had different constraints

The client is a UK business communications provider operating across mobile and fixed-line services. Customer accounts originated in its billing and service-provisioning environment. Customer registration then activated the existing account for use across the self-service, support, and PBX portals.

Staff worked with a different set of systems. Provisioning, PBX administration, support, and other operational backends each had their own access requirements. Staff needed one SSO entry point across those systems and one password reset propagated to the backends, while some technical and network-operations staff still required direct access.

The Windows desktop call-control application presented a separate constraint. Some users needed access to the application from different locations while an existing desktop instance remained active, but the backend permitted only one session per user. For example, a user could leave it logged in at the office and then be unable to use it from home. A stuck session could cause the same lockout, and recovery could otherwise require restarting the wider real-time services cluster.

Account activation, staff SSO and call control had to span several platforms

• Customer registration had to activate an existing account and establish consistent credentials across several systems.
• Credential synchronisation could not depend on a vendor process that did not consistently preserve password encoding across the connected systems.
• Staff needed SSO across administrative backends, with password resets initiated and propagated from one place.
• The desktop application needed to support multiple active instances for a user, even though the backend allowed only one session per user.
• Real-time events and commands had to reach each active desktop-application instance to support incoming-call alerts, transfers, and other call controls. The same event path also had to connect with the high-availability SIP service.
• Presence events had to pass between the backend PBX and SIP service, where they could be translated into Busy Lamp Field state for VoIP devices.
• The established applications and their core responsibilities needed to remain in place.

Three services handled the missing access and session functions

Rather than modify the vendor applications, we placed three focused Node.js services at their integration boundaries. Each service handled one access or session requirement while the underlying platforms retained responsibility for billing, provisioning, support, PBX administration, and call handling. HAProxy provided load balancing and TLS termination where required.

Customer access and SSO. The customer access proxy handled registration and activation of accounts created in the billing and service-provisioning environment. The existing synchronisation path did not consistently preserve password encoding, so our process applied the customer's credentials directly through the supported interfaces of the provisioning, support, and PBX systems. After signing in, customers received automatic access to support and could open the PBX portal in one action using the same account.

Staff access and SSO. The staff access proxy provided one authenticated entry point into the administrative backends and created the required backend sessions without separate staff logins. Staff could reset a password in one place and have the change propagated to the systems behind it.

Real-time application access. The gateway maintained one upstream CometD session for a user and multiplexed it across that user's active desktop-application instances. Someone who had left the application running at the office could therefore open it from home without first closing the office session.

The gateway relayed messages between the backend PBX, each active desktop application, and the client's high-availability SIP service. Incoming-call events and presence updates travelled towards the applications and SIP service; transfer and other call-control commands travelled back towards the backend. An MQTT connection joined the gateway to a real-time translation component within the SIP service stack.

The gateway did not interpret the call or presence messages. The translation component in the SIP service retained presence received from both sides and converted relevant events into SIP call-control and BLF behaviour. This boundary kept session transport separate from the telephony logic needed to act on each message.

FreeSWITCH and the translation component also detected when a hold or transfer operation did not receive the expected response. The translation component could re-establish the affected user's real-time session through the gateway without restarting the wider services cluster. The user could then repeat the operation.

Consistent access without platform replacement

Customers could activate accounts created in billing and service provisioning, then use the same credentials for automatic support access and one-action PBX portal login. Staff had one SSO entry point and one password-reset path, while direct backend access remained available for specified technical and network-operations roles. Users who needed the desktop application on multiple computers could run concurrent instances against the original single-session backend.

Because credentials were applied directly to the provisioning, support, and PBX systems, customer access did not rely on the vendor synchronisation path completing successfully. Per-user session recovery restored the real-time connection used for call controls without requiring an operator to restart the complete services cluster.

Keeping access, session transport, and telephony translation separate limited the effect of changes in any one integration path. It also made the maintenance requirement explicit: authentication adapters, synchronisation rules, backend interfaces, and message mappings had to be kept in step as the connected platforms evolved.

The services evolved as connected systems changed

Over several years, the services were extended as customer journeys, staff systems and call-control requirements changed. Backend routes and SSO behaviour stayed in the access proxies; the real-time event gateway continued to handle multi-instance use and CometD transport; and the linked SIP service retained SIP call control, presence translation and BLF behaviour.

This kept compatibility work outside the vendor applications while preserving a clear boundary between access, message transport, and telephony behaviour.

Related case study:

• High-Availability SIP Infrastructure for a Live Voice Service explains how the SIP service handled automatic failover, endpoint registration, transfers, media, and the events relayed by this gateway.

---

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