Objective Systems offers several CSTA products. This post describes the various offerings and explains how they differ from each other.
First, what is CSTA? It stands for Computer Supported Telephony Applications. It's a set of standardized messages that can be passed back and forth between a computer and a PBX. There are three versions (called phases) of the CSTA messaging standards. You can find all kinds of information about CSTA here. In particular, the document ECMA-269 defines the messages in CSTA phase 3, the most recent phase. The document ECMA-217 defines the messages in CSTA phase 2, and the document ECMA-179 defines the messages in CSTA phase 1.
The first type of CSTA offerings are in a category that I'll call basic API kits. These kits consist of class definitions that are created by either ASN1C or XBinder against the ASN.1 or XML schema definitions for the CSTA (and ACSE in most cases) messages. The kits also contain samples that show how some of the CSTA or ACSE messages can be encoded and decoded. Most of the kits contain at least one test client sample, which is a console-mode program that lets the user choose what operations he wants to do against the target PBX.
Most of these basic API kits are available as an evaluation kit or a purchased standalone kit. Most evaluation kits require the presence of our ASN1C product. If you don't already have ASN1C, you can also obtain an evaluation version of that on the ASN1C product page that I provided a link to above. The evaluation kits contain mechanisms to build the ACSE and CSTA libraries that first generate the class definitions and then compile them. The evaluation period is 30 days.
A purchased standalone kit can be used without ASN1C being present. Standalone kits contain already-generated class definitions and the libraries that are built from them. The build mechanisms in a standalone kit just compile the class definitions; they don't generate them since ASN1C may not be present.
Some already prepared evaluation versions of basic API kits can be downloaded here. It's also possible for us to build evaluation and standalone kits for supported platforms other than those listed on the referenced page.
The second category of CSTA offerings I will call enhanced API kits. Currently there is only one product in this category: CSTADLL.
CSTADLL is for the Microsoft .Net platform. It consists of .Net class definitions generated by ASN1C against the ACSE ASN.1 specifications and the CSTA ASN.1 class definitions for all three CSTA phases, not just one phase. There are no build procedures included with CSTADLL; the class definitions are pre-packaged. The source code (in C#) for the generated class definitions is included. Besides the inclusion of class definitions for all three CSTA phases, CSTADLL includes the following additions:
- Simplified APIs for many common operations done with CSTA messaging. For instance, to tell the target PBX to make a call, you would use a MakeCall() method instead of encoding a MakeCall message yourself.
- Management of the TCP/IP session with the PBX.
- A logging mechanism so the traffic between the client and the PBX can be seen.
- Event handling that allows a user-defined callback method to be invoked when the PBX asynchronously sends an event message as part of a monitor operation.
- A console mode sample written in C# and a GUI sample written in Visual BASIC. Source code for both samples is included. There are also several smaller C# samples.
- Explicit support for several different common PBX models.