VoIP Developer

Both service providers and enterprise customers face a similar dilemma they hear the great reasons for moving to VoIP, but are mindful of the thousands, if not millions, of dollars invested in their current equipment. Should they trash that equipment (or, perhaps, sell it on eBay these days) in favour of new VoIP solutions, or is there a pain free way of seamlessly adding a VoIP capability to it. After all, this is the equipment that their people know how to use and maintain and its probably paid for! How easy is it to VoIP-enable existing TDM telephony equipment? This article explains the principles and practice of gateways and advises those considering this kind of solution.

Hi, how have you been? Are you fully recovered from the explosive information on Next Generation VoIP hardware last month? If you didnt see it, do feel free to check out my other articles.

So now lets begin by looking at the challenge that VoIP gateways can address, as outlined above.

You know the story. Telecoms managers and others in enterprises and service providers are hearing about the great savings that can be made by using VoIP instead of traditional connections like the good old T1. They are prepared to acknowledge that the combination of their existing equipment (a PBX, for example) and the T1 connections have been reliable over a long period of time but they like the idea of those compelling savings theyve heard can be made by using VoIP. Not only that, but IP connectivity can deliver things like mobility, presence and triple play (voice, video and data) too.

Choices, choices

What are they going to do? Well, they could contact their trusty PBX vendor to find out if they can VoIP-enable their existing PBX this will probably involve an upgrade or exchange of both hardware and firmware.

Whilst this is a realistic option, there are two questions that it would pay to have in mind when considering this avenue:

1. Will this provide real value for money, given that the PBX vendor knows that you have little or no choice of suppliers for this upgrade and they may, therefore, inflate the price accordingly?

2. Is the hardware (e.g. a new card) you need to connect to VoIP going to replace an existing card in the system (say, a line card) and are you happy with that scenario as it may reduce the capacity of the PBX?

[Note: Prepare to hear predictions of doom and/or gloom from your legacy equipment vendor if you decide to do anything other than buy more equipment from them.]

The other option is to use a gateway. This is an external solution that connects to the legacy equipment (PBX, etc.) on one side and to the IP network on the other. Its job is to convert call control and audio from the traditional format provided by the PBX (e.g., Q.931 call control, m-law speech) to packet based information for the IP network (e.g., SIP for call control, G.729A speech) and vice versa. Below is a diagram to illustrate this:

Figure 1: Gateway positioning and functionality (Note: SIP and Q.931 merely serve as examples)

Now let us be clear that a gateway, in and of itself, is NOT going to provide the mobility, presence and triple play functionality I mentioned earlier these require a native IP solution rather that some legacy equipment VoIP-enabled by the addition of a gateway. So, although these new features (presence, etc.) are good reasons to consider VoIP, they will no longer feature in our thinking as we are here to consider VoIP-enabling existing equipment.

This, parenthetically (if you are wondering what that last word means click it VoIP stuff and free English vocabulary tuition only with David Duffett!), brings us to the interesting issue of timing. If your existing equipment is coming to the end of its useful life, then you will probably be best to move to a new, all VoIP, solution thus there will be no need for a gateway. If, however, you need to quickly connect to IP in order to take advantage of the cost savings on calls then a gateway solution is for you.

Having come to the conclusion that a VoIP gateway is the best way forward, the next thing to think about is the environment we are going to put the gateway into.

What call control protocol does the gateway need to support on the traditional telephony (PBX) side Q.931, T1RB, NI2, etc. and how about the IP side H.323 or SIP? And then theres the codecs G.711, G.722, G.723.1, G.729 (A&B), etc.

Will it be any or all of the above? These factors will help decide what kind of gateway is best for a given application. Practically, many approaches are possible from individual specifically designed chips (ICs) for you to build with, through IP telephony cards for you to program solutions with, all the way to turn-key appliances that are totally stand-alone and ready to perform once the appropriate connections have been made.

Clever or stupid?

Another consideration is whether any other functionality or intelligence could be valuably co-located with the gateway.

VoIP could well be the cheapest option for long distance and international calls, but is it the best value for local calls wouldnt it be great if there was enough intelligence in the gateway to recognise local calls and route them through a trusty T1 connection to your local telco, while directing other traffic to your VoIP provider? This, in case you have never come across it, is least cost routing, or LCR. Would you like to see a neat picture showing the gateway as a least cost router between the IP network and a number of traditional PSTN connections? You would? OK then, here it is:

Figure 2: Gateway acting as least cost router between an IP provider and three traditional telephony connections

So your gateway could be an LCR device too. And theres more how about address translation, CLI/DDI authentication or producing billing information. All of these things (and even more) could be delivered by the gatewaying device if required.

Take a step back

You can see that, like most situations, a detailed definition of the full requirements is the single biggest step towards a suitable solution.

These requirements may include future variations. For instance, if your current requirement is for a gateway between SIP and T1RB, you could probably buy a fairly cheap box to fulfil this function. When, later on, you need to connect to an NI2 trunk or H.323 on the VoIP side you could find that your cheap box cannot be adapted to do that. Whereas, if you knew that an NI2 connection was likely to be needed later on, you could have obtained a more flexible gateway solution. Remember you get what you pay for!

This is only one example of a future requirement and there are plenty more where that came from (the future) so please fully evaluate your requirements before making that purchasing decision.

Were nearly done

At the end of the day these four questions are key:

1. Why do you want to use VoIP (cost, new features, etc.)?

2. How quickly do you want to make the transition?

3. What additional functionality do you need?

4. What changes could be needed in the future?

Put together, these questions will help you decide whether a gateway solution is best (rather than an all new VoIP solution) and, if so, what kind of gateway solution would match your need.

If you would like to see one of my live presentations, or just say Hello, I will be speaking at the following conferences:

VoIP Developer, San Francisco
Tuesday - 08/02/05, 2:30-3:30pm
Wednesday, 08/03/05, 4:30-4:50pm

See you next time.

David Duffett
[email protected] 

David Duffett, TMCnet's columnist for "The Voice of IP," is a Chartered Engineer and has been in the Telecoms sector for over 14 years with experience spanning air traffic control communications, wireless local loop, mobile networks and computer telephony. At Aculab for 5 years, David has global responsibility for customer training through the Aculab Academy.