CTI Computer Telephony Integration

This section of our technical library presents information and documentation relating to Computer Telephony and Computer Telephony Integration software and products. Computer Telephony Integration CTI software is a rich set of phone software library routines that enable application programs to control your phone system. This comprehensive CTI software lets you increase employee productivity, enhance customer service and reduce costs by combining the capabilities of our PACER phone system with the custom functionality of your Windows, Unix or Web applications. Data collected by your phone ACD (Automatic Call Distribution) or IVR (Interactive Voice Response) systems can be passed to your existing PC, Unix or Web applications through our phone software. The PACER predictive dialer can automatically call your customers and pass only connected calls to your agents. With our computer telephony software, your telephone and computer work together to provide cost-saving benefits.

BY Mike Matthews, head of product marketing, Aculab

What does a developer need to consider before creating IP telephony solutions while keeping the total cost of an enterprise solution in mind?

The first consideration is the customer that the developer is targeting their application for. Depending on the company culture and current communications infrastructure, different aspects of the total solution become more critical — majoring on either a feature or a cost basis. A developer needs to ask questions and tease out the answers from their prospective marketplace, as the responses to these questions will affect not only the cost and features to be implemented but also the best enabling technology option. This article works through a number of these qualification questions and proposes the best way forward – always keeping an eye on cost and ROI.

VoIP enables the transport of voice along with data and other media over a single IP based network. Taking this into account provides some indication as to the many applications that are now emerging because suddenly the solution provider’s palette contains more than just voice or just data — it consists of multiple communication methods.

This article will focus on how to create a solution depending on the enterprise’s situation, and there are many considerations. Initially the key aspect is to understand how much the customer is planning to change their existing architecture. Will the customer maintain legacy equipment and cabling while adding on a new VoIP service? Alternatively, is the customer looking to move completely to a converged IP infrastructure using a single network?

‘IP Ready’ Architechture

If we look into this first scenario, there are still some architectural aspects to settle:

• Is the legacy equipment ‘IP ready’? A number of platforms may not have IP connectivity today, but can have a circuit board added that will introduce support. Computer telephony (CT)-based platforms are the likeliest candidate for this situation as they are the most flexible solutions in the market.
• Is the legacy equipment upgradeable? One possibility here is to add an external gateway box to introduce a VoIP capability to the premises.

All IP Solution

If the legacy equipment is ‘IP ready’ — we touched on this in 1.) above — the good news is that well specified CT platforms can be VoIP enabled with the addition of a circuit board and appropriate software. The better news still is that by enhancing the existing platform the original investment is retained. And the stunningly good news is that a single CT platform can now connect not just to the WAN in order to consolidate traffic and save money, but also at the desktop, users can start using their new VoIP services.

This alternative is starting to sound interesting, so what other points do designers have to consider?

In creating this ‘well specified CT platform’ careful thought around the programming model needs to be made and most designs today are modular with the need to support multiple threads. A great asset to designers is being able to select additional CT hardware that supports more and different features like VoIP, yet easily fits into an existing application architecture as the way it is programmed — via the API — and is consistent across all CT product types.

A Twist In The Tale

So far we have been talking around hardware-based solutions and this is logical from the starting point of most businesses and indeed communications solutions of today. A more recent innovation — suitable for applications like an auto attendant that fronts and distributes businesses’ phone calls — is to use host based media processing (HMP).

The HMP technique uses no dedicated specialist CT hardware and simply takes advantage of the improved processing power that is increasingly available. The connection to a communications platform running HMP will usually be via the standard network interface card (NIC) making the hardware line up a familiar one for the IT staff.

Small enterprise businesses, say less than 100 users, in an IP only situation could well benefit from a HMP-based solution. So how does the developer factor this into their equation? The same sort of programming issues need to be considered when looking at software instead of hardware — is the programming interface consistent with any existing application? This last point starts to become really important when we take a step back to look at the bigger picture for many enterprise businesses.

The most common model is one where there is at least one site with large capacity requirements — usually the head office. There are then a series of satellite offices serving customers’ needs around the geography being covered. Historically this has been a challenge to hardware-based solutions with few ‘high end’ solutions scaling down very cost effectively. With both HMP and CT hardware products that employ consistent APIs in the tool bag, the developer now has a great opportunity to develop a single robust application that can be deployed in small to large installations. Some distinct benefits of this approach start to come through; support of the solution becomes more straightforward from front-line IT staff back through to the designer, and training of the end users becomes easier as each work station can be implemented in a consistent manner.

While these points illustrate distinct benefits we can see from a qualitative position, it becomes a harder challenge to perform the quantitative analysis. This is often the point where expert help in the form of consultancy is sought.

The Letter Q Is A Good Reminder

Having touched on a couple of the q words recently, we should take a few sentences to remember one of the early perceived issues with VoIP — speech quality and QoS. When traditional calls come over the circuit switched telephone network they use a full 64kbits/s bandwidth and employ a standard coder identified as G.711. The vast majority of early IP equipment has been sending and receiving traffic using this traditional high quality voice scheme.

There are alternatives that usually become considered when bandwidth is a more scarce resource than usual, say in an expensive connection with high call demand. The main alternative that is widely deployed is a compression scheme called G.729, which lowers the bandwidth down to 8kbps, yet retains highly intelligible speech. It is important to check that the proposed components for the design encompass key codec support along with the latency management referenced earlier. The good news for the designer is that there is widespread support for this technology making interoperability of IP-based solutions a basic expectation these days. The only negative item to report is one of cost associated with some compression schemes. G.711 is free while the others do carry a licence fee to a small number of companies involved in the original intellectual property development.

So in terms of checking out the solution’s ROI, we need to ensure that only what you need is specified and this cost is another driver behind why G.711 has remained the default scheme of choice.

Summary

Time to bring together a checklist that can help improve the return on investment when designing a VoIP solution for the enterprise:

• Check the customer’s intentions — is this going to be an ‘IP ready’ architecture or an all IP solution?
• Consider both hardware and software components in the solution mix — this could help manage cost and complexity.
• Ensure the programming interface is consistently implemented across the vendor’s product range (hardware and software) to minimize time to market and ongoing application maintenance.
• Make sure both major protocols are supported and will evolve: H.323 and SIP.
• Check the specifications for QoS — pay attention to the support of standards like TIPHON.