Integrate VoIP with your existing network

As organisations increasingly recognise and require the benefits voice over Internet Protocol (VoIP) offers, they stop asking "Why?" and start asking "How?". A successful voice over IP implementation requires a keen understanding of how voice services will integrate with the existing network.

Organisations must know how voice and data traffic will coexist, what infrastructure additions will be required and whether major network re-designs will be necessary. This article takes a macroscopic look at how VoIP technology integrates with existing network infrastructure.

The first and foremost consideration with any VoIP implementation is the cumulative network infrastructure (switches, routers, firewalls and the like) to which you will add VoIP. If you currently run an IP network, or even a hybrid IP network, VoIP technology lets you pass voice traffic, encapsulated in IP packets, through your existing network hardware.

While the utilisation of existing infrastructure is a key VoIP benefit, you must allow for your current network's capabilities. You should know whether your switches can place voice and data networks into separate VLANs. You should also understand the Quality of Service (QoS) capabilities your switches and routers offer.

Along with your network hardware's supported features, a successful VoIP integration will depend on the hardware's physical capacity. Adding an additional traffic type to you existing network will increase network resource consumption. Bandwidth requirements will rise and with them memory and CPU utilisation. Minimum hardware requirements should be followed to ensure successful delivery of both voice and data traffic. For example, a 100Mb switched connection to the desktop is a common requirement. When your voice conversation depends on the underlying network's availability, you must ensure that traffic can be fully supported; otherwise, the voice communications quality will deteriorate as dropped packets cause choppy audio and speech delays. Data communications are resilient to delayed or lost packets, voice is not.

Before beginning a voice and data integration project, you should have accurate baseline data for the existing network's performance. Evaluate possible bottlenecks, network errors, and average bandwidth usage before putting phones on the network. This should be done before you begin evaluating a VoIP solution. Reliable baseline data will help you choose the VoIP implementation that provides the most bang for your buck.

Legacy telephony equipment

Unless you are deploying VoIP in a completely new environment, your VoIP solution will likely need to coexist, at least for a time, with your existing PBX or key switch telephone system. VoIP and traditional phones can coexist separately, allowing for a "flash" cutover -- where you move from the old system to VoIP on a scheduled date. If you prefer a staggered migration, you can run both systems simultaneously. While a staggered approach lets you test the VoIP waters before taking the plunge, it does require that you link your VoIP solution with your existing phone system.

How you link your VoIP solution and your existing phone system will depend on each system's specific characteristics, but you can smooth the process with a few common migration techniques. Many companies use a dial plan with non-overlapping phone numbers to simplify call routing. If your existing system uses 8XXX and your VoIP system uses 3XXX, both systems will know how to route specific calls.

You can also connect geographically distant legacy phone systems with VoIP technology over a WAN link. This allows you to test a VoIP solution and save on long distance costs. Some VoIP systems are merely "IP-enabled" PBX’s that natively perform this function.

A variety of PBX's and key systems exist, but almost any two systems can be made to communication with each other. You typically create the link by emulating either a station-side or a trunk-side connection. Either system can then translate the phone numbers to achieve interoperability. With large-scale VoIP rollouts this can be a critical process. It is also important to verify the signaling types supported by both the legacy and VoIP systems. Legacy phone system often include both a standalone voicemail system and a PBX. You should verify that your new VoIP solution will support your existing voicemail system. Voicemail systems use specific messaging protocols and not every VoIP system supports all the available protocols. Some VoIP solutions may require a new voicemail system and this condition may sway your choice of VoIP provider.

Public Switched Telephone Network (PSTN) connectivity Even if your entire enterprise is going completely VoIP, at some point you will need to reach the outside world. Small sites may only have a few business lines. Larger organisations may have one or many digital Primary Rate Interface (PRI) circuits. Unless you plan to change your outbound connection, you should choose a VoIP solution that works with your existing telephone circuit.

VoIP equipment is designed to work with commonly available telephone circuit types. You should search for an ideal solution that allows you simply unplug your exiting circuit from the PBX and connect it directly to the VoIP gateway. To ensure interoperability you should also confirm compatibility of signaling types, framing, and line coding.

In you plan to concurrently operate your legacy and VoIP systems, you will likely need separate Public Switched Telephone Network (PSTN) lines for each. It is unlikely both systems would be able to share the same local carrier lines. If you use a PRI circuit and are using Direct Inward Dial (DID), you can port the new phone number to the new PRI as you go. The approach allows some users to use the new system with their existing phone numbers and other users to operate on the old system as before.

Integrating VoIP with your existing network takes a significant amount of careful planning. You must ensure the existing network infrastructure can support the additional bandwidth and performance requirements. Ideally, the equipment should be able to logically separate voice and data networks, applying specific levels of service to each. Concurrently running your VoIP solution with your legacy phone system is a good way to test the VoIP waters.

This staggered approach will require linking the two systems and you should verify interoperability of PBX or key systems and voicemail prior to deployment. It is highly likely that you will also require additional PSTN connections while you simultaneously operate the two networks. While seamlessly integrating VoIP with your existing network can be a complex process, careful planning will help you reach the end goal of a IP-based telephony network that provides additional features and cost savings.

VOIP THE TECHCNOLOGY

The ability to transpose voice streams of analog data to digital, and back again, has gradually pushed its way out from the core of the telephone network to where it is today. Whereas codecs and digital links were only present between exchanges in the PSTN network, the development of services like ISDN have seen the A to D and D to A processes migrate right out into the PABX or Key Telephone System (KTS) of today. The main infrastructure of course has been under the control of the Telcos, or infrastructure providers, with users charged the relevant usage fees.

With the recent and rapid development of the Internet, as an interactive and mass data carrying network, voice over internet protocol (VoIP) is poised to enhance if not supplant a fair proportion of the traffic of the Telcos mentioned above. The primary reason for this of course is economic: in that once the investment is made in hardware and access to the internet in its "Broadband" form is established the cost of voice communications to anywhere in the world with similar equipment is basically just data cost.

DIGITAL STREAMS

In today’s digital telephone systems the analog voice channel is digitised, usually at the handset, for switching by the system itself. This offers the immediate benefits of digital re signal quality etc. If the CO interface is ISDN the voice data continues in digital form with relevant signaling, if PSTN the data is converted back to analog prior to this point. If the interface is a VoIP channel the digital data is divided up into packets for transmission over the internet according to the relevant protocol.

PROTOCLS

The power of the internet today is primarily due to the development of the many protocols in use. Since the internet is such a complex array of devices and services there has to be sets of rules for behaviour and structures of these sets to maintain orderly operation. These rules and structures are called protocols and they have been developed according to the needs of the relevant services involved. Protocols are often refered to as "stacks" - this is due to the onion like layers of lesser protocols that go to make up a major protocol according to the OSI model (refer to a networking text if you want to go further here).

For Voice over IP there are three main protocols that have been developed: H.323, MGCP, and SIP.

H.323 was developed by the ITU (International Telecommunications Union) and is a telephony centric protocol that has components for telephony networks as well as internets and has an extensive stack to cope with all aspects of telephony or video transport.

MGCP (Managed Gateway Control Protocol) is a protocol that uses a central controlling agent (or computer) in the supervision of the communication between two end point devices (media gateways or MG). MGCP currently uses H.323 as a subset in its operations. With MGCP the MGC (Media Gateway Controller) assumes most of the control duties of the connection, and as such can handle more complex connections. Since MGCP exerts a higher degree of control it is considered to generate more reliable networks. With MGCP each entity (device) wishing to use a network must be registered with the MGC, or Call Agent, of that network.

SIP (Session Initiation Protocol) was developed by the IETF (Internet Engineering Task Force) in response to what they considered was the rigidity of H.323. Whereas with H.323 an MGC controls the media gateways throughout a connection, with SIP the media gateways themselves do most of the controlling of the connection with reference only to a SIP server or proxy for the relevant address they wish to connect with initially. H.323 is an entire protocol suite, SIP is a single module designed to interwork well with existing internet applications. For example SIP defines telephone numbers as URL's, so that web pages can contain them. The inference to be drawn from all this is that H.323 (&MGCP) is here now and reliable but with its rigidity has some limits; SIP is considered the up and coming lad, more relevant to the internet, but requires a lot more smarts in the MG interface and as such may suffer from interwork problems until equipment/application standards become more developed and widespread.

Comparison of H.323 and SIPItem H.323 SIP

Designed by ITU IETF

Compatibility (PSTN) Yes Largely

Compatibility (Internet) No Yes

Architecture Monolithic Modular

Completeness Full protocol stack SIP just handles setup

Parameter Negotiation Yes Yes

Call Signalling Q.931 over TCP SIP over TCP or UDP

Message Format Binary ASCII

Media Transport RTP/RTCP RTP/RTCP

Multiparty Calls Yes Yes

Multimedia Conferences Yes No

Addressing Host or Teleph No. URL

Call Termination Explicit or TCP release Explicit or Timeout

Instant Messaging No Yes

Encryption No Yes

Size of Standards 1400 pages 250 pages

Implementation Large and complex Moderate

Status Widely deployed Up and coming

VOIP CALLS WITH MGCP EXAMPLE

VoIP Call Sequence

The sequence below is only approximate as the actual protocol and process is more complex than this.

1. Person A at Company A wishes to call Company B lifts receiver and selects VoIP trunk, MG allocates bandwidth

2. MG (VIU card in Hybrex GX) knows Call Agent (MGC) address and signals request for service to Call Agent

3. Call Agent receives request via internet on designated port.

4. Call Agent acknowledges request from 203.75.168.168 (Company A) and

5. Call Agent instructs MG at Company A to serve dial tone and waits for addressing.

6. Person A enters desired number (the extension number of desired port at Company B) which is transmitted to call agent.

7. Call Agent establishes a connection with Company B whose address (203.75.188.188) it knows from its database, and instructs MG there - Setup to port (No.dialled). From 203.75.168.168

8. System at Company B rings relevant extension and returns an Alert message to the Call Agent which is passed back to Company A that dialled extension is ringing at 203.75.188.188

9. When extension at Company B is answered a Connect message is sent back to the calling party (Company A ) and a channel is established between the two - first to negotiate codecs/rates etc (using RTCP), then the data flows (using RTP) and the call is in progress. At this point the Call Agent is not part of the data stream but oversees call progress, tearing down the connection when the call is finished, or re-assigning if either party wishes to make further calls.

A point to note - this whole process happens pretty quickly these days

QUALITY OF SERVICE

Although the transport protocol used is RTP (Real Time Transport protocol) which is optimised for real time data such as audio. The data is still packetised and the nature of the internet is such that different packets may take different paths through the net. Different paths mean different transit times with the possibility of arriving to late to be used (RTP is not re-transmitted) or being dropped (disappearing) along the way; particularly if a particular route is congested. Events such as this affect the speech quality of the connection. Better quality of service, or QoS guarantees

are provided by some ISP/vendors, albeit at a price!. But bandwidth rollout continues apace and improvements over the already generally good service available continue.