|This is not a Wikipedia article: It is an individual user's work-in-progress page, and may be incomplete and/or unreliable. For guidance on developing this draft, see Wikipedia:So you made a userspace draft.|
|Operating system||Microsoft Windows|
Go Connect is a software product that allows monitoring and control of telephone systems. It is produced by Mondago Ltd and generally distributed by other software developers as part of a larger solution. Go Connect must be installed and run on a Windows platform though client applications can run on other platforms including Mac, Unix and Android. Go Connect's main purpose is to present developers with a simple and consistent method of connecting to a large range of makes of telephone systems. The alternative is for developers to write specific drivers for each type of telephone system. Thus, Go Connect is often considered to be a protocol conversion layer, converting the telephone systems native language into a more open standards such as TAPI.
Go Connect provides the following functions:
|Protocol conversion||Go Connect processes the data from telephone systems and can represent it in a variety of formats for developers to use|
|Directory integration||Go Connect synchronizes the list of devices with the telephone system internal directory and provides this data through a common interface for developers.|
|Error correction||Go Connect refines the data that comes from the telephone system and uses "snapshot-ing" techniques to verify that calls are still in progress.|
|Call continuity||Some telephone systems do not naturally provide data that can be used to associate the various legs of a call (ie during transfers). Go Connect can artificially correlate these calls to allow developers to track them better.|
|Missing functions||Some telephone systems do not naturally support less common functions such as "Blind Transfer". Go Connect artificially makes these functions by performing the equivalent steps. For instance, Blind Transfer would be replaced with a "Consultation Transfer followed by Transfer on Ringing".|
|Call history||Go Connect can record historic data of calls to save developers from having to do this themselves.|
|Clustering||Go Connect can connection to multiple telephone systems simultaneously (both of the same and different makes) and present the information looking like a single telephone system.|
|Simplified configuration||Generally, Go Connect downloads and maintains relevant information, including telephone system configuration, from telephone system and thus needs a minimum of configuration settings. Often it only requires the IP address of the telephone system.|
|Reduced licensing costs||Go Connect typically connects to the telephone system using the manufacturers preferred (ie proprietary) interface which is normally cheaper to license than any open standards interface that they may also offer.|
Go Connect uses a Service Oriented Architecture (SOA) design, where each component performs a single purpose and many of the components can be replaced through "abstraction". For instance, the equipment driver that connects to an Avaya telephone system can be replaced by, say, the Cisco equipment driver and it will function to the same specification. The chart below shows the server-side components
The server side components have the following uses:
|UC Server||UC Server is the main call handling engine. It also provides marshalled access to the underlying SQL Server database.||Access to UC Server is through either direct IP connection or through the UC Client library. The UC Client library provides access to all functionality and is used by all internal components, so it is the recommend interface. Direct IP access should be for circumstances where the UC Client library is not practical, such as under Java or non-Windows platforms.|
|HttpServer||Http Server provides pages and other functionality over a HTTP or HTTPS channel.||The Http Server extends the API functionality over more channels, such as HTTP and HTTPS. There is presently no support for SOAP/WSDL but developers can provide their own web pages and/or graphics to complement or replace existing ones.|
|Telephony Server||The Telephony Server provides interoperability with one or more telephone systems by loading the relevant equipment drivers.||One instance of the Telephony Server service is created and run for each configured telephone system. The product documentation says that a maximum of 30 telephone systems can be configured per server.|
|Equipment Drivers||These are per-telephone system drivers that provide the same abstract functionality||The equipment drivers are DLL files that are loaded into their respective Telephone Server process.|
Go Connect can connect to several types of telephone system. The list is shown in the table below. Often a license is required on the telephone system to permit connection, though this may actually vary by geographic region as some manufacturers subsidize technologies such as computer telephony in geographic areas where they are not popular.
|Aastra||800||Open CSTA 100 license|
|Aastra||MX One||CSTA license|
|Alcatel||Omni PCX Enterprise (OXE) Alcatel 4400||TAPI licenses|
|Alcatel||OmniPCX Office (OXO)||3rd Party TAPI license|
|Avaya||Communication Manager||TSAPI licenses (basic)|
|Avaya||Definity||TSAPI licenses (basic)|
|Avaya||IP Office||3rd Party TAPI license|
|BT||Versatility||Broadband Plus and Click-to-dial licenses|
|Cisco||Call Manager Express|
|Cisco||Unified Call Manager|
|LG||IPECS||3rd Party TAPI license|
|LG||ipLDK||3rd Party TAPI license|
|LG||LDK||LAN Card and 3rd Party TAPI license|
|Mitel||3000||Broadband Plus and Click-to-dial licenses|
|Mitel||3300||MiTAI server 'license to use'|
|Mitel||Axxess (InterTel)||PAL resources|
|NEC||SL1100||3rd Party TAPI license|
|NEC||SV8100||3rd Party TAPI license|
|NEC||XN120 (Topaz)||Applications Enablement Services card|
|Nortel||BCM||Available LAN CTE license|
|Samsung||SCM Express||CSTA license|
|ShoreTel||ShoreGear||TAPI Application Server license|
|Siemens||Hipath 4000||CA 4000 server|
|Siemens||Open Office (HOOME)||Available CSTA License|
|Toshiba||CIX||Available CSTA License|
|Toshiba||CTX||Available CSTA License|
Go Connect does not use exactly the same call model as any of the telephone systems that it connects to. Of existing models, it most closely resembles the CSTA model, but it is has some key differences. See "differences from the CSTA model" below.
Calls and Connections
It is easiest to begin by explaining the difference between a "call" and a "connection". A "call" is a communication attempt between two or more parties (one might be voice processing). It begins when the "caller" initiates the process by "calling" their intended target (the "called" party). The call may or may not connect with the intended target. The original caller may leave and be replaced, but the call will continue until all parties (initial or subsequent) have left. For external calls, this will be typically associated with a call record, such as might appear on a bill.
During the course of a call, several parties may become involved. For an outbound call, this would start with an extension making the call and then include the trunk or line over which the call is made. The trunk represents the external party to the call. For an inbound call, again the trunk represents the external party. However, this time, the incoming call may ring several extensions simultaneously, thus involving several devices.
Simply put, a "connection" represents the amount of time that a call is with a particular device. Typically, during this period, the owner of the device can interact with the call. It may be that throughout the life of a call it "appears" several times at the same extension (such as with call queuing). This is counted as multiple connections.
Most application developers are interested in connections. This is because, generally speaking, to interact with a call you have to specify a device at which it appears. For instance, to "answer" a call then you have to specify a location (ie a connection) to answer it at.
Connections thus follow the pattern: They appear at a device with an initial state; over time, they can change state; after a period, they disappear.
An example of this would be:
|A connection starts ringing at extension 100||State=Ringing|
|Extension 100 answers the call||State=Connected|
|Extension 100 hangs up||(Connection disappears)|
In API terms, state changes are called updates or "Connection.Update", and when the connection disappears then it is called a remove or a "Connection.Remove".
Calls follow a similar Update/Remove pattern but they don't contain information about participating devices. This information is stored on the calls' related connections.
While a call is in progress, the information on the call (ie Start, Caller, Called, Duration, etc) is persisted. Any related connections that may join have access to this original information. Thus even when a call is transferred many times, then even late-joining connections still have access to the original start time of the call (thus it's total duration) plus the original caller and called parties.
When a call finally ends (ie there are no more connections) then a record of the entire calls and its connections exists. This is written to the database as CallHistory and ConnectionHistory records for future use. It is also available for Call Management and Call Recording applications to use for statistical analysis and matching purposes.
Differences from the CSTA model
The CSTA model is generally considered to be an excellent design. However, several of the telephone systems that Go Connect supports cannot produce an output that satisfies its needs. Also, it is predominantly designed as a Third Party API (see earlier for explanation) and as such, doesn't lend itself well to being extended into a client layer.
As the chart below demonstrates, many of the connection states have a one-to-one relation with their CSTA counterparts, though they are often renamed to be more descriptive (ie ServiceInit becomes Dialtone). The Delivered message is split into Ringback and Ringing depending on context. Also, the Failed message is split into Disconnected and Busy. This is because several phone systems do not consider the call ended when it is in a Busy state. Instead they may allow a Camp-On which transitions to Ringback.
Connections can disappear (ie be cleared) at any stage.
|1||These states are viewed from the Connection perspective, ie one end of the call.|
|2||Internal calls can transition from Busy to Ringback when camping on.|
|3||Calls can disappear (be deleted) from any state.|
|4||Calls that enter a Conferenced state don’t re-enter a Connected state when returning to two participants.|
|5||NetworkReached is for calls to external destinations only.|
|6||Some platforms do not offer a Dialing call state, so it is implemented artificially.|
|7||Calls to implement ‘features’ will often go from a Dialtone to Disconnected call state.|
- see Go Connect Developers Reference, p4
- "Supported telephone systems". mondago.com.
- see Go Connect Developers Reference, p6-10