Beyond SIP: How Cloud Softphone Unlocks BroadSoft XSI for Operators

Cloud Softphone by Acrobits is built on a universal SIP foundation. If your backend speaks SIP, the app registers, makes calls, and handles messages. That is by design. Operators running Asterisk, FreeSWITCH, Kamailio, or any number of open-source or proprietary Class 4/5 softswitches can deploy a branded softphone without backend changes.

SIP Is the Floor, Not the Ceiling

But SIP is foundational by design. The protocol was built to set up and tear down sessions, and it does that universally well. Everything beyond that (presence, call logs, voicemail, enterprise directory, feature management) lives outside the SIP dialog, in supplementary services layers that each vendor implements differently.

That is where backend-specific integrations matter. And that is also where operators frequently run into what we at Acrobits call the "quirks layer."

Every Platform Has Its Quirks

BroadSoft (now Cisco BroadWorks), Metaswitch (now under Alianza), and NetSapiens each built their advanced telephony features on top of SIP using proprietary mechanisms. The SIP call still works the same way. But the moment you need anything richer, you are dealing with platform-specific behavior.

Metaswitch historically relied on a combination of SIP events and its own provisioning APIs to expose features like call queues and shared lines. With the platform's ownership now under Alianza and the MaX UC client's future uncertain, operators are increasingly looking for a softphone that can abstract that layer without being tied to a single vendor stack. (We covered that shift in Alianza Acquired Metaswitch: What Operators Need to Know.)

NetSapiens uses its own REST-based SNAPsolution API for provisioning and feature control alongside SIP. Handling conference bridges, call recordings, and portal integration requires speaking that API natively. Pure SIP clients leave most of it inaccessible.

BroadSoft / BroadWorks is arguably the most widely deployed carrier-grade telephony platform in the world, particularly among CLECs, MSOs, and large ISPs. It ships with a powerful supplementary services interface called XSI (the Xtended Services Interface), and supporting it properly is what separates a capable BroadWorks softphone from a generic VoIP dialer.

Cloud Softphone supports all three platforms, with native XSI integration being the deepest and most feature-complete of the three.

What Is BroadSoft XSI?

XSI (Xtended Services Interface) is a RESTful HTTP API exposed by BroadWorks that sits alongside the SIP layer and provides programmatic access to the platform's advanced call services.

Think of it as the management and feature-control plane for a BroadWorks subscriber: separate from the call signaling plane (SIP), but tightly coupled to it.

XSI-Actions handles on-demand feature execution and account management. Through XSI-Actions, a client can:

• retrieve directories
• access call history
• manage voicemail
• read or modify call service settings like Call Forwarding and Do Not Disturb

The protocol returns structured XML responses that a client can parse, cache, and present natively. In plain terms: the app reads and changes call features and account data in-app, without ever sending the subscriber to a self-care web portal.

Cloud Softphone's BroadWorks integration is designed from the ground up as a plug-and-play replacement for UC-One, the original mobile and desktop client provided by BroadWorks. Operators who have UC-One deployed today can migrate subscribers to a white-labeled Cloud Softphone app with minimal reconfiguration on the BroadWorks side.

The Provisioning Proxy: How It All Fits Together

Before getting into individual features, it helps to understand the architecture. Cloud Softphone's BroadWorks integration does not have the app talk directly to XSI for all operations. Instead, it routes through the Acrobits Provisioning Proxy, a transformation and orchestration layer that sits between the Cloud Softphone clients and the BroadWorks platform.

The Proxy retrieves data on behalf of the Cloud Softphone app (including SIP device parameters, contacts, call history, and voicemail) and returns it in a normalized format the client can consume directly.

This matters for two reasons:

• It shields the client from XSI's verbosity and versioning nuances.
• Complex provisioning logic (device profile matching, credential resolution, tenant identification) happens server-side, not on the device.

For an operator, that is the difference between fixing provisioning once on the server and chasing it across thousands of devices already in the field.

Alongside the Provisioning Proxy, the Acrobits stack includes SIPIS (for maintaining SIP registration while the mobile app is in the background) and the Push Notification Mediator (for delivering incoming call alerts via APNs and FCM). These components work together to ensure Cloud Softphone behaves like a native carrier-grade client, not a generic SIP app that drops calls when backgrounded.

What Cloud Softphone Actually Does with XSI

1. Full SIP Provisioning

The provisioning flow begins with XSI. When a subscriber launches Cloud Softphone for the first time and authenticates, the Provisioning Proxy uses their credentials to query the BroadWorks XSI-Actions API and walk through a multi-step process:

It retrieves the list of access devices associated with the user, identifies the device entry that matches the platform being provisioned (mobile or desktop), and downloads the corresponding device profile XML. Cloud Softphone ships with separate device profiles for mobile (Business Communicator – Mobile) and desktop (Business Communicator – PC), mirroring the UC-One profile structure BroadWorks operators already have configured.

It then fetches the user's profile to extract display name, group membership, and user ID, the values that get injected into the final account configuration delivered to the app.

Authentication for device profile downloads supports both Digest and Basic authentication, controlled by the useDigestAuth setting in the BroadSoft configuration.

This zero-touch provisioning means end users enter credentials once. Everything else (SIP server address, transport settings, auth credentials, feature flags) is resolved automatically.

2. Enterprise and Group Directory

Cloud Softphone synchronizes contacts from the BroadWorks enterprise and group directories using XSI-Actions:

/com.broadsoft.xsi-actions/v2.0/user/{userId}/directories/Enterprise
/com.broadsoft.xsi-actions/v2.0/user/{userId}/directories/Group

Both endpoints are queried using tenant-level credentials. The returned directory entries (name, extension, full DID, group membership) are merged into the app's contact search, so users get real-time lookups against the full organizational directory without maintaining a separate contact list.

The groupId field from directory entries also serves as a network identifier for on-net contact detection, enabling features like in-app messaging through the Acrobits Linkup platform.

3. BLF (Busy Lamp Field) Monitoring

The app monitors the presence status of contacts defined in the BroadWorks monitoredUserList for each subscriber. The Provisioning Proxy queries the BLF service endpoint:

/com.broadsoft.xsi-actions/v2.0/user/{userId}/services/BusyLampField

When a monitored list URI is present, Cloud Softphone creates a single SIP Resource-List subscription to that URI, receiving consolidated BLF state updates for all monitored users in one subscription. This is operationally efficient: rather than maintaining individual SIP presence subscriptions per contact, the BroadWorks Resource-List model consolidates them, and Cloud Softphone handles it correctly.

Monitored users are also surfaced as quick-dial entries in the app.

4. Call History and Voicemail

The Provisioning Proxy integrates with BroadWorks call history and voicemail through XSI-Actions.

For call history, the integration retrieves direction and result (answered vs. missed). Call duration is not included in the synchronized data, and call recordings are not supported through this integration path.

For voicemail, the integration is significantly richer. Cloud Softphone retrieves and displays caller information, message duration, and a download link for each voicemail, enabling true visual voicemail where users see a list of messages and play them inline without dialing a voicemail portal.

Users can also mark messages read or unread and delete them (when deletion is enabled on the platform). Voicemail transcription is not currently supported.

5. Call Feature Management

This is one of the most operationally impactful parts of the XSI integration. Cloud Softphone exposes a set of BroadWorks call features directly in the app's account settings screen, synchronized in near real-time. Changes made in the app are applied to the BroadWorks platform immediately, not stored locally.

The synchronization uses a combination of SIP as-feature-event subscriptions (for receiving state updates) and XSI-Actions API calls (for applying changes). The supported features are:

• Do Not Disturb (DND): toggle on/off
• Call Forwarding: Always, Busy, No Answer, and Not Reachable, with configurable forwarding destinations
• BroadWorks Anywhere (Mobility): manage mobile identity settings
• Anonymous Call Rejection: toggle on/off
• Automatic Callback: enable/disable
• Remote Office: configure remote office number
• Calling Line ID: manage outbound caller ID presentation

This means a subscriber who needs to quickly enable Call Forwarding before stepping into a meeting can do so from their phone, and the change takes effect on the BroadWorks platform immediately: no web portal, no IT ticket.

What BroadWorks Operators Need to Configure for XSI

To set up the integration, operators provide three things: the BroadWorks XSI API URL (the XSP or ADP base URL), device profile names for mobile and desktop (matching the device types configured in BroadWorks), and the device profile file names (mobile-config.xml for mobile, config.xml for desktop). Two test accounts are all that is needed to validate the integration end-to-end.

All of this is configured once in the Cloud Softphone Provider Portal. Every subscriber provisioned under that configuration receives the XSI integration automatically. At scale (across thousands of subscribers), this matters: there is no per-device configuration, no manual credential entry, and no dependency on end users understanding how BroadWorks provisioning works.

Why This Matters for BroadWorks Operators

BroadWorks is a significant investment in licensing, integration work, network architecture, and operational processes. The value of that investment is only as visible to subscribers as the client software they use to access it.

A generic SIP softphone throws away most of that value. Users see calls. They do not see enterprise directory integration, visual voicemail, server-synchronized call history, or in-app feature management. They cannot toggle Do Not Disturb from their phone or update Call Forwarding without logging into a web portal.

Cloud Softphone with native XSI integration exposes that value in the client layer, where users actually experience it. It does so under the operator's own brand, distributed through the operator's own App Store and Play Store accounts, with full provisioning automation through the Acrobits platform.

For operators evaluating softphone clients for a BroadWorks deployment, the question is not whether to use XSI. BroadWorks is built around it; the features are there. The question is which softphone client actually implements XSI correctly, at the right depth, and can be deployed at scale without burdening operations teams with per-device configuration work.

That is exactly what Cloud Softphone was built to do.