TMCnet
ITEXPO begins in:   New Coverage :  Asterisk  |  Fax Software  |  SIP Phones  |  Small Cells
 

Feature Article
January 2005


The Question Of Return On Investment Of VoIP

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:

  1. 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.
  2. Is the legacy equipment upgradeable? One possibility here is to add an external gateway box to introduce a VoIP capability to the premises.

When reviewing these architectural variations we have to remember what the customer is trying to achieve. If it is to consolidate traditional TDM network trunks and data networking links to a single IP WAN connection then the options suggested by either a) or b) will do the job and the ROI calculations can be easily made. In many respects this is the easy part of the equation, as we haven’t started looking at productivity benefits of VoIP — just simple ‘like for like’ cost comparisons. The big technical check to be made at this point is ensuring that the proposed equipment supports the two VoIP protocols present in the market today: H.323 and SIP. Also worth checking is the commitment of the supplier to evolve the protocol support over time as enhancements are made.

When looking to the WAN service providers, it is usual to have a service level agreement (SLA) to specify a quality of service (QoS) to be achieved. This last point leads to consideration of the specification of any VoIP hardware introduced to the architecture. It is important to consider latency performance and ensure it meets a recognised standard such as the ETSI TIPHON rating.

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.

Finally, don’t be afraid to discuss your thoughts and concerns with vendors of VoIP technologies. A wealth of experience already exists and working closely with vendors makes good business sense.

Mike Matthews is head of product marketing at Aculab. Aculab enables developers and systems integrators to produce a variety of high-performance communications solutions. For more information, please visit the company online at www.aculab.com.

[ Return To The January 2005 Of Contents ]



Today @ TMC
Upcoming Events
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
Austin, Texas
MSPWorld
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Austin, Texas
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center
Austin, Texas