Go Connect

Go Connect

Developer(s)	Mondago
Development status	Active
Written in	.Net
Operating system	Microsoft Windows
Type	Computer Telephony
License	Proprietary
Website	http://www.mondago.com/goconnect

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 ,^[1] and therefore more generally known by other names. Go Connect must be installed and run on a Windows platform though client applications can run on other platforms including Mac OS, 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.

Software Purpose

Go Connect provides the following functions:

Logical Structure

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:^[2]

The server side components have the following uses:

Telephone Systems

Go Connect can connect to several types of telephone system.^[3] 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.

Call Model

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^[4] the CSTA model, but it 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 (i.e. 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:

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 (i.e. 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 (i.e. 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 (i.e. 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 (i.e. be cleared) at any stage.

Notes

References

External links

• Go Connect on Mondago's web site