I’m involved in the maintenance of a Call Control Client for BroadWorks, Attaché, and a Provisioning Library for BroadWorks, Alpaca. This makes me very interested in changes BroadSoft makes to their interfaces.
At present, BroadSoft supports a number of interfaces:
- OCI-P for Provisioning
- OCI-C for Call Control
- XSI for Call Control
- Other interfaces for Call Center Reporting
OCI-P Here Forever
When the eXtended Services Interface (XSI) was announced, some speculated this would the Interface To Own All Interfaces for call control and for provisioning. But according to a highly placed source within BroadSoft’s Montreal development team, XSI is not intended to replace OCI-P. For new provisioning platforms built today, OCI-P is the protocol to use.
XSI, not OCI-C, for Client Applications
In 2007 when we began work on Attaché, OCI-C was the only viable option for call control. Since then, the XSI was built and enhanced to support what we needed to do for live call control and basic call status reporting. But currently, the BroadWorks Assistant Enterprise toolbar clients still use OCI-C for call control. So which is the blessed client-facing interface: XSI, or OCI-C?
In the future, OCI-C may not be an option for BroadWorks call control. All new Call Control applications should be built for XSI. And existing applications will need to be migrated to XSI.
XSP as the Interworking Agent
The XSP currently faces the Internet, and accepts connections from client devices. It interworks between XSI on the client side to OCI-C and OCI-P on the BroadWorks core side. As of now, in some cases, the XSP has to rewrite the entire message even for a minor change between XSI and OCI-C/OCI-P. According to my source, future versions of messages in XSI will be revised slightly to better align directly with the OCI-C and OCI-P.
You can expect a few changes to XSI as this occurs. But this is not surprising for a relatively new protocol for a complex application-layer protocol.