User:Socnet/Go connect

Go Connect

Developer(s)	Mondago
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. 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.

Software Purpose

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.

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

The server side components have the following uses:

Name	Purpose	Notes
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.

Telephone Systems

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.

Manufacturer	Model	Requirements
3Com	NBX
3CX	Phone system
Aastra	800	Open CSTA 100 license
Aastra	Intelligate/OIP	OIP Server
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
Broadsoft	Broadworks
Broadsoft	M6
BT	Quantum
BT	Versatility	Broadband Plus and Click-to-dial licenses
Cisco	Call Manager Express
Cisco	UC500
Cisco	Unified Call Manager
IP Cortex	PBX
IPFX	IPFX
LG	IPECS	3rd Party TAPI license
LG	ipLDK	3rd Party TAPI license
LG	LDK	LAN Card and 3rd Party TAPI license
M5	M5
Mitel	3000	Broadband Plus and Click-to-dial licenses
Mitel	3300	MiTAI server 'license to use'
Mitel	Axxess (InterTel)	PAL resources
Mitel	CS5000 (interTel)
NEC	Aspire
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
Panasonic	KX-NCP
Panasonic	KX-TDA	Network card
Panasonic	KX-TDE	Network card
Panasonic	NS1000	CSTA license
Samsung	OfficeServ	TAPI license
Samsung	SCM Express	CSTA license
ShoreTel	ShoreGear	TAPI Application Server license
Siemens	8000	CSTA license
Siemens	Hipath 3000
Siemens	Hipath 4000	CA 4000 server
Siemens	Open Office (HOOME)	Available CSTA License
Snom	One
SpliceCom	Maximiser
Tekelec	Tekelec
Toshiba	CIX	Available CSTA License
Toshiba	CTX	Available CSTA License

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 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.

Notes

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.

External links

• Go Connect on Mondago's web site