CHAPTER 1

INTRODUCTION TO VoIP

IP telephony (IPT) offers a viable alternative to the legacy voice exchange, delivering improved
application integration, scalability, and multi-site management. It is precisely these features that
make this rapidly-maturing technology so attractive to organizations seeking to reduce costs,
increase productivity and improve customer relations. However, voice is critical to business, and
a major change to emerging technologies like IPT requires an understanding of a broad range of
technologies, careful planning and thoughtful implementation. This guide has been compiled to
help decision makers to understand the relevant technologies as they define their strategies.

Fig: 1.1 Network Layout of A small businesses VoIP

Following the introduction, we will review the typical components and features of an enterprise
telephony system. We then introduce voice over IP (VoIP), the underlying network

1
infrastructure, and then we address the various issues one must take into account when designing
the network to carry voice. We conclude by comparing these VoIP solutions to the traditional
centralized PBX, but before we do so, we describe advanced applications such as collaboration,
presence, customer relationship management and unified messaging.
There are many reasons to implement an IP-based voice communication system reduced long-
distance telephony charges; lower capital costs; lower management and administrative costs;
reduced complexity; improved integration of distributed business entities; and a greater ease with
which voice applications may be combined with other business systems.

2
 CHAPTER 2
IP ADDRESSES AND NAMES

2.1. IP (Internet Protocol):

Ethernet is the dominant LAN technology; it scales well and works over twisted pair, fiber optic
cable and even wireless. Why would we need anything more than just Ethernet? Let’s consider
some of the challenges of running just Ethernet:
•we tell applications running on computers how to find the addresses of other computers with
which they need to communicate.
•we communicate over very long distances, for example WAN connections spanning the globe.
•we deal with circumstances where economic constraints force us to use some other transmission
technology.
•we communicate with other organizations that do not necessarily want us to know the specific
addresses of machines on their internal networks.
•we should package information like emails or graphic-rich documents so that other machines
can download and display the information.

The protocol was needed that could provide an open interface between applications and the
various physical networks underneath (e.g.,, Ethernet on the LAN, Frame Relay, DSL and ISDN
in the WAN, etc..). There have been various proposed protocols including:

1. IP Internetworking Protocol – IETF standard

2. OSI Open Systems Interconnect – ITU standard
3. SNA Systems Network Architecture – IBM
4. DEC net – Digital Equipment Corporation
5. IPX Internet Packet exchange - Novell

The protocol removed the hierarchical structure and there was no single point of failure that
could bring down the nation’s communications. While this level of reliability was extremely
valuable, the true drivers for IP’s success were:
1. IP protocols are simple to understand and implement

3
2. The protocol specifications are freely available
3. Applications like the World Wide Web encouraged broad market adoption.
The IP community had an enthusiastic, open, and sharing philosophy that fundamentally drove
adoption through universities and beyond. Today, IP is used across the globe as the basis for the
Internet and the majority of enterprise networks .

2.2. IP Addresses:
IP addresses are used to identify devices connected to the network. The 32-bit addresses are
written as four decimal values (with each group capable of representing less than 256 values)
separate by a dot. The first groups of numbers identify the network upon which the machine is
located, and the other groups of numbers identify the specific machine within that subnet work.
Here is an example: [Link]

Fig: 2.1 IP Windows

4
When installing a computer, the network manager defines the machine’s address and the address
of the default gateway – the machine on the local network that provides connectivity to other
networks. In the early days of the Internet, this machine would be a computer with two network
interfaces and it would perform the task of forwarding packets between the two interfaces. Today
however, it is more likely to be a router. For use on machines connected directly to the Internet,
IP addresses are carefully allocated in blocks and managed by the owner of the addresses to
ensure that no two machines have the same address. However, within an enterprise the IETF has
allocated certain address ranges for internal machines only. The addresses of the internal
machines are protected by a firewall that provides Network Address Translation (NAT) that not
only protects the identity of internal machines, but also ensures that addresses belonging to one
enterprise do not conflict with similar addresses used by another enterprise.
Like telephone numbers, the numbers to the right of the address identify the specific machine or
device. When planning an IP voice implementation, a legacy voice manager should learn the
details of the addressing scheme used within the organization before connecting new IP devices
to the network. To make it easier for people to find services on their network and on the Internet,
a name-to-number translation service was introduced called the Domain Name System (DNS).
This global system allows one to type in a name like [Link] rather than its IP
address [Link] The DNS service simplifies things by allowing the end user to
memorize a website name instead of having to remember its IP address, which could change if
the Louvre were to change to a different service provider.
When you consider how you use phone numbers in your cell phone, you will recognize that here
too, you use people’s names rather than their numbers. Later we will show how this facility is
being introduced by the current generation of IP voice systems.

2.3. Allocating and Managing Addresses

Given that each device has to have its own IP address, does this mean that you must manually
assign an IP address to every phone you install on your network? Fortunately, the answer to this
question is “no.”An automatic address allocation system was developed to ease the
administrative overhead associated with IP address allocation: Dynamic Host Configuration
Protocol (DHCP).The DHCP protocol resides on a server and manages a pool of IP addresses.

5
DHCP keeps track of which addresses are currently in use and which are available for allocation.
IP addresses can be leased from an address range for devices that conform to certain criteria.
For example, an Ethernet MAC address range and leasing can be time-bound to handle
applications such as shared desks for mobile employees.

6
 CHAPTER 3
WAN INFRASTRUCTURE

3.1. Wireless LANs:

In the USA, wireless premises for voice has remained vendor specific, which contrasts with
Europe where regulated spectrum was established and a standard approach has been widely
adopted – ETSI’s DECT. The challenge with wireless has always been cost. The cost of
providing full building coverage and possibly campus-wide roaming has been prohibitive;
establishing the necessary access points or base-stations has been too expensive. This situation is
changing with the broad adoption of Wi-Fi networks based on IEEE 802.11, the wireless
Ethernet standard. Broad market adoption has helped to drive access point prices down and many
enterprises are intrigued by the potential to provide employees a single mobile device for
applications as well as voice. There are, however, some challenges that should be considered
when planning a wireless implementation:
1. QoS – Delays for Enterprise voice should not exceed 150ms. Given that Wi-Fi is a contention
protocol (like the original shared Ethernet), when a particular access point is heavily used, voice
quality will suffer.
IEEE 802.11e is expected to be ratified in Sept 2004 and addresses wireless quality issues.
2. Reliability – Except for 802.11a, which specifies the 5GHz band, the 802.11 standards use the
2.4 GHz band and suffer from interference with other wireless devices.
3. Security – Voice can be slowed down by data encryption.
A voice-specific encryption standard has been developed: IEEE 802.11i
4. Standards – There are multiple signaling standards (802.11a, 11b and 11g), which should be
compared based on distance, capacity and frequency interference.
5. Handsets – Running voice through PDAs may be desirable, but ultimately, users will still need
wireless phones for the foreseeable future. The number of suppliers is still relatively limited.
6. Coverage - Establishing coverage throughout a building is no trivial task and should be carried
out by experienced wireless network designers.

7
 Fig: 3.1 WLAN

IP was designed to function independently over lower topology layers (i.e., closer to the physical
layer in the OSI model), the options for interconnecting IP devices over the wide area network
are almost limitless.
Here’s what you will have to deal with in today’s market:
1. T-1 and fractional T-1
2. ISDN
3. Frame Relay
4. ATM
5. xDSL
6. Cable
7. Wireless Local Loop technology such as 802.11 and LMDS
8. SONET
9. Wide Area Ethernet (delivered by metropolitan area networks)

Previously you may also have had to manage an access router with a rack of modems, but this
service has been replaced by the combination of service providers and Virtual Private Network
(VPN) technology. Enterprises will typically connect their LAN to the WAN using a router. The

8
router combines IP routing intelligence with knowledge of the appropriate lower level network
signaling used on the WAN. Such devices range from low-end access devices for connecting
home users to large enterprise routers with redundant links for failover and load balancing.

9
 CHAPTER 4
ROUTERS AND ROUTING

In the telephony world, conversations are carried out over circuits – end to end connections
between the caller and collie. All the work of determining how to route the call is done during
call setup. Once the circuit is in place, no further route decisions are required (assuming there are
no catastrophic problems on the network).Data networks, however, do not work like this. Packets
are forwarded and forgotten so that each intermediary router between the source and the
destination:
1. Reads the destination address of the packet
2. Checks which route to use
3. Forwards the packet to the interface associated with that route
4. And forgets it.
The primary function of a router is to route packets along the best path across a network. Each
router maintains a route table, essentially a roadmap of the network which is kept up to date by
exchanging information with other routers about the status of each link and the status of the
network.

Fig: 4.1 Routing technology

10
When an incoming packet is received, a router identifies the destination address, checks the route
tables to determine the best route, and then forwards the packet to the next router along the path.
A router should be connected to multiple forwarding paths so that if one path fails, packets will
be re-routed around the failed connection.
Due to their strategic location in the network (at the LAN/WAN boundary), routers are
frequently used to prioritize and filter traffic. Note that WAN links are shared resources and
therefore suffer from similar contention problems inherent with the early Ethernet. This can
cause serious problems for real-time voice communications.
QoS will be discussed in the following section:
Routers are also used to act as a firewall, filtering packets to protect the network from unwanted
attempts to gain access to the network. Firewalls use techniques similar to traffic prioritization;
that is, they identify and filter traffic based on source or destination address, protocol type, or IP
port numbers. Port and socket numbers, in particular, may indicate application functions such as
telnet or file transfer protocol (FTP), and because these applications can be used to break into a
corporate network, identifying these types of traffic before the traffic enters the network can
offer valuable protection. There are literally hundreds of well-known techniques for breaking
into a network, such as IP spoofing, Denial of Service attacks, or SYN floods. In all cases, the
router or firewall must be capable of identifying and filtering these types of traffic. Use of traffic
prioritization or firewall technology could become an issue when transporting voice over the
network due to the additional processing required for these functions. However, the newest
generation of routers and stand-alone firewall devices has become much more powerful, making
use of custom ASICs to simultaneously classify, queue, filter, and forward packets with minimal
latency.

11
 CHAPTER 5
THE REAL TIME PROTOCOL (RTP)

During a conversation, the human mind can make sense of imperfect sound in which small
(barely perceptible) bits of audio are missing – Audio CDs and the pointillism technique in
painting show how the mind is capable of putting together a complete picture from fragments.
But if a communication system has to stop processing to ask for a packet to be retransmitted,
then the delay can cause a serious degradation in the perceived quality of the conversation. In
fact, for real-time communications it actually makes more sense to discard the missing packet
rather than re-request it.
RTP is a protocol designed specifically to handle the needs of real-time communication. Among
the fields defined for an RTP message format are:
• Sequence Number: Incremented for each RTP packet
• Time-Stamp: Used to record the sample rate and therefore playback rate
One can take a variety of different approaches (in a voice over IP implementation) to handling a
lost packet during a conversation. For example, one approach might be to simply replay the
sounds from the previous packet, discard the missing packet, and then play the next one when it
arrives. Another aspect of real-time communications is that in order to achieve higher quality
sound, the sampling rate must be increased, and this leads to smaller packet sizes. The smaller
packet sizes have the benefit of avoiding the increased processing latency caused by large packet
sizes, but the small packets cause a new inefficiency—namely packet headers end up taking up
as much bandwidth as the payload (i.e., the actual sound being transmitted). RTP provides a
solution by using header compression. So RTP doesn’t handle the voice signaling nor does it
define the format to be used for the transporting the voice packets, but it provides important
solutions to the challenges of real-time voice communications. Problems of latency (perceptible
delays between talker and listener) and jitter (a gradual loss of synchronization between the two
endpoints) can still appear. However, given the speed and reliability of most enterprise LANs,
such problems are rarely seen for conversations at a single site and tend to be crop up in WAN
communications. Careful planning should be taken to ensure the WAN is correctly sized for the
needs of the organization, and care should be taken to verify that appropriate jitter buffers have
been set. We discuss this more in the following section on voice quality.

12
 CHAPTER 6
VOIP – TECHNOLOGIES AND STANDARDS

6.1. Working of VoIP

To understand what makes up a typical VoIP system, let’s begin by looking at what goes on
while two parties are talking to each other. Imagine yourself holding a traditional analog
telephone. When you speak, your voice excites the airwaves, literally creating a wave pattern in
the air – an analog signal. This sound wave is picked up by the microphone in the telephone
handset, and the handset replicates the analog signal as electrical impulses. The signal is sampled
and converted to a numerical representation of the wave pattern – ending up as a series of 1’s and
0’s. The resulting digital signal can then be compressed if desired. Thus far, the process
described is exactly the same for a digital telephone connected via a line interface on a legacy
PBX. But that’s where the similarity ends.
6.2. VoIP Components
Having established the process for voice communications across any data network, the next
challenge is to provide sophisticated call control (call set up, tear down, etc.) capabilities.
Various component of VoIP shown in fig 6.1.

Fig: 6.1 Various component of VoIP

13
 The act of setting up, tearing down and routing calls requires intelligence that goes beyond the
simple transmission issues we have covered so far. A lot of effort has been put into standardizing
these rules so that IP voice systems can accomplish call processing in the same predictable
manner web servers deliver information to web browsers anywhere in the world. We will hold
our discussion of standards for a later section and, for now, focus on the functionality required.

Soft switch: To set up a call, the system must to act on signals from the calling phone. One way
to accomplish this is with specialized call processing software that tracks and manages call
progress, and handles conversion between the addressing schemes used on a data network (IP
addresses) and telephone numbers. Think of this device as an automated operator, handling all
the tasks the switchboard operator used to handle. In fig 6.2, block diagram of soft switch is
shown. The working of soft switch can be described as follow:

Fig: 6.2 Soft switch

14
Telephone Call Server/Soft Switch I’ve gone off hook OK, here’s your dial tone.
Here’s the phone OK, I’m routing this; number I dialed here’s some progress info I’ve just put
this OK, I’ll remember that call for caller on hold you; here’s another dial tone I’ve replaced OK,
I’ll store the call detail the receiver record and terminate the call.
These examples – which are typical of signals that might be sent between a telephone and a call
server –show how a call server can perform the same functions as those of a PBX. So if the call
server or soft switch can manage call set up, call routing and call tear down - does that mean we
now have a fully functional IP-based alternative to the PBX.

Gateways: Not quite. We are still missing an important interface with the legacy PBX.
Specifically, we need a gateway between the IP world and the legacy circuit switched world. The
gateway accomplishes this with three components:
1. Trunk or line interface on one side.
2. VoIP transmission capability on the other side.
3. In between, the gateway must have the necessary logic to convert between the two media
formats and ask the call server for help setting up the call.
In practice, it often makes sense to combine the functionality of call processing and gateway into
single network elements – but for the purposes of this discussion, they are being treated as
separate components.
IP Phones: While a complete system with a soft switch and specialized media gateways can
potentially support existing analog handsets, in practice, most implementations only support IP
phones. Phones can either be hardware devices that plug into the Ethernet network (and look just
like a normal legacy telephone) or soft- phones that run on the user’s PC.
IP phones actually provide the functionality of a single user gateway, converting the analog
speech pattern into digitized voice packets which are then sent over the IP network.
Here some of the characteristics you should consider when selecting IP phones:
1. Signaling standard is used.
2. The phone provide a second Ethernet port so that a PC can use the same uplink as the phone
(offering savings on cabling cost).
3. The phone support Power over Ethernet so it would work without interruption during a power
outage.

15
4. The phone provide a mechanism to classify traffic so that voice can be prioritized through the
network.
5. The phone provide easy access to advanced features through an intuitive interface.
6. The phone is easy to install and configure.
7. The phone deliver good sound quality.
As a mature market, differentiation was critical for the legacy PBX vendors and over time, the
phone or handsets became the focal point for vendor competition.
Specialist phones were developed:
• Operator consoles
• Administrative assistants
• Key systems
• Conference phones
• And a range of phones for the different hierarchical levels within an organization.
Today’s IP phones have software hooks for customization and are far more flexible than their
legacy counterparts. Even the simplest of telephone designs can be extended with applications
that reside on the user’s PC. Today’s IP phone provides an intuitive interface with access to
application-rich features and is also capable of leveraging recent improvements in sound quality
to provide a better experience for users and the people with whom they communicate.
The Complete System: Using these components:
1. Soft switch or media gateway controller
2. Gateways
3. IP Phones.
We have the necessary components to build a complete system. Let’s review how these
components work during a call:
• A phone transmits state changes (off hook, on hook, etc.) to the call server or soft switch.
• The soft switch sets up calls, finds routes, keeps track of everyone’s state.
• The soft switch automatically converts between telephone numbers and IP addresses.
• Once a call route is established, the soft switch gets out of the way so that the path for the voice
stream is independent of the soft switch. (This is important because it prevents delay from being
introduced into the conversation).

16
• If the call is leaving the IP network and being routed to the PSTN or a legacy PBX, a gateway
converts the IP packets back into the appropriate media stream for the trunk.
• If the call is being sent to another IP device, the call may be managed by multiple soft switches.
But eventually, the VoIP packets reach the called party’s phone and are converted back into
voice.
Having reviewed the functional elements that need to be provided by an enterprise-class IP voice
communications system, we will now look at some of the frameworks and standards available.

17
 CHAPTER 7
SESSION INITIATION PROTOCOL (SIP)

SIP has emerged as a lightweight and extensible alternative to H.323. SIP defines standard
objects/components and a limited message hierarchy for communicating between these elements.
SIP Components:
1. SIP User Agent Clients (UACs)
2. SIP Location Server – track which IP address a client is currently using
3. SIP Proxy Servers – forwards requests to other servers on behalf of SIP clients.
Redirect Servers – communicates the target address of the called party to the calling party. The
SIP protocol defines a set of basic messages to signal events:
SIP Messages
1. Invite – to join a session/call
2. Ack – to accept this invitation
3. Options – determine the capabilities of a server
4. Register – Register with a server
5. Cancel – cancels a previously issued request
6. Bye – to end a call

18
Developed by the Internet Engineering Task Force (IETF), SIP focuses on session initiation,
modification and termination – leaving the session and connection details to be negotiated by the
end systems. SIP uses a simple text-based command structure, with HTTP syntax and URL
addressing. Thus, it is well suited for Internet and web-based applications where, for example,
phone calls and web pages work together in customer call centers environments.
Where terminals are concerned, SIP’s emphasis – like H.323 – is still on end-point intelligence,
and this has some significant implications for the cost of telephone handsets. However, SIP’s key
advantage is that it offers a well-defined mechanism for device-to-device signaling beyond the
handset itself. Specifically, SIP is well architected for communications between multiple proxy
and location servers. This part of the SIP specification makes it very scalable and manageable.
SIP is also the basis for SIMPLE, which is one of the two standards currently being proposed for
instant messaging and presence. A voice system based on SIP will therefore be better able to
integrate presence and telephony and will be able to deliver a richer suite of applications. For
these reasons, we expect SIP signaling to be one of the requirements of next generation IP voice
communications systems.

7.1. MGCP/MEGACO/H.248
There are two other standards worth mentioning: MCGP and closely related MEGACO. Unlike
SIP and H.323, MGCP assumes that edge systems are unintelligent gateways and, therefore, the
gateway controller handles all aspects that go beyond media conversion. Central management of
less intelligent gateway devices is a reality in some business telephony implementations today.
Reduced cost IP phones can act as simple gateway devices (analog-to-IP converters) and the
intelligence of call control can be handled by the gateway controller.
When MGCP was initially introduced for standardization to the IETF, the name was changed to
MEGACO and an agreement was reached with the ITU to work on a parallel standards activity:
H.248. The key difference between MEGACO and H.248 is that H.248 mandates the support of
H.323 (see below). To simplify things and reduce costs, vendors have been implementing
systems that use the original MGCP signaling proposal.

19
7.2. ITU H.323
The earliest VoIP standard was the ITU’s H.323 standard, which evolved from H.320—the
standard for video-conferencing. H.323 defines a set of standards to facilitate multimedia
conferencing over packet-based networks. As such, it offers a complete suite of protocols for
audio, video and data conferencing. The H.323 standard contains the following modules:
Terminals: Telephones (software or hardware)
Gateway: Translates between packet and telephony media streams
Gatekeeper: Performs address translation, admission control and bandwidth management
MCUs: Multi-point Conferencing Units, support multi-party conferences for voice and video.
In addition to IP voice communications, H.323 supports collaborative applications, such as white
boarding and video-conferencing. This has important implications for IT organizations:
1. Protocol stacks are large and therefore expensive to develop.
2. End points must accommodate more than just basic telephony signaling to be compliant.
Since its original introduction in the mid 1990’s H.323 has provided an important foundation for
the VoIP community but has since lost ground to the more recent SIP and MGCP protocols.
H.323 is an umbrella standard that groups multiple sub standards together into a single
specification. Because the actual standards documents are cross-referenced with each other, it
can be quite challenging to a new reader. The list below is intended to clarify roles and
responsibilities of some of the main H.323 components:
G.711 Codec: Pulse code modulation (PCM) of voice frequencies
G.723.1 Codec: Dual rate speech coder for multimedia communications transmitting at 5.3 and
6.3 Kbit/s
G.729a Codec: Coding of speech at 8 Kbit/s using Conjugate-Structure Algebraic-Code-Excited
Linear-Prediction (CS-ACELP) H.225.0 Call signaling protocols and media stream packetization
for packet based multimedia communication systems
H.245 Control protocol for multimedia communication
H.323 Packet-based multimedia communications systems
H.248 ITU equivalent of IETF MEGACO
H.450 Generic functional protocol for the support of supplementary services in H.323
Consider this example of the many technologies at work in a H.323 call. First, when a user picks
up the phone and dials, an H.323-enabled phone uses H.245 to negotiate a channel and exchange

20
capabilities. Then, H.225.0 handles call signaling and call set-up, and finally, a component called
the RAS (registration/admission/status) channel signals the gatekeeper that coordinates the calls
within a zone. In addition, if the destination is on or over the PSTN, a gateway must be used to
translate H.323 packets to circuit-switched telephony.
Although technically transmitting voice over packets has been feasible for decades, H.323 has
served an important role in establishing an early framework for how this might be achieved.
Since its first release,
H.323 has been constantly enhanced. However, it is still generally perceived to be overly
complex and “too heavy” with functionality that is not required for IP voice communications [4].

21
 CHAPTER 8
CODECS

A codec is a device that converts sound from an analog format to a digital/numerical

representation in the form of 1’s and 0’s (which is why the term itself is an acronym for
coder/decoder). Codec’s may also handle compression and decompression. There are many
codec options available, and the choice often involves a tradeoff between voice quality,
processing speed, and data size. Below are some examples of codec’s. Each codec is listed with
the associated data stream produced, compression delay, and quality of the voice stream as
measured by mean opinion score (MOS), an open test where a variety of listeners judge the
quality of the voice sample on a scale of 1 (low) to 5 (high).
Compression Method Bit rate (kbps) Delay MOS Wideband 128 1 4.8
Linear (no compression) 4.5
G.711 64 0.75 4.1
G.723.1 5.3 or 6.3 30 3.65
G.726 32 1 3.85
G.728 16 3 to 5 3.61
G.729a 8 10 3.27
Determining which codec option is best for your company depends on your requirements. For
example, G.711 provides excellent voice quality and would likely be useful for call center or
sales environments. In contrast,
G.729a might be preferable for WAN voicemail, where bit rate is more important than voice
quality.
Today the codec war has more or less died down with vendors selecting and licensing the codec
they feel best serves their purposes (cost and technical). Part of the reason for this issue dying
down is that network capacity has grown to such an extent that network performance is no longer
the bottleneck (particularly on the LAN). Vendors have taken advantage of this situation by
introducing systems that make use of wideband codecs that significantly improve voice quality
without affecting either throughput or cost. Systems that support wideband codecs actually
improve voice quality beyond what was achievable with the digital PBX.

22
Another codec issue to bear in mind is that of transcoding. Let’s imagine two parties talking –
one on a GSM or other cellular phone and the other using an IP telephone system. The call has to
transit a gateway. If the IP telephony party is using one of the typical VoIP codecs, let’s say
G.729a, then to successfully communicate with the other party we need to decode the G.729a
stream, transmit to the PSTN, which recodes the stream with a GSM full-rate or half-rate code.
Each time we code or decode we introduce at least 12 milliseconds of delay (but often as high as
50-100 ms) – and this kind of transcoding should be avoided as it will impact overall end-to-end
delay as described in earlier sections. Systems from a single vendor are designed to make the
correct codec decision at call set-up but network designers must be diligent. As the telco/service
provider market evolves the enterprise system will likely be required to interact with the service
provider’s equipment.

Fig: 8.1 Table shows the different Codec information and respective Bandwidth calculation

8.1. IP Standard
When selecting an IP voice system, you should select a vendor which has clearly committed to
certain standards.

23
Each of the standards described below has experienced a significant level of adoption in today’s
market:
1. H.323, with its roots in ISDN-based video-conferencing, has served its purpose of helping to
transition the industry to IP telephony. Today, however, its circuit switched heritage makes
H.323 complex to implement, resource intensive, and difficult to scale. Vendors and service
providers are now de-emphasizing H.323’s role in their IP voice communications strategies.
2. SIP is ideal for IP voice and will play an important role for next generation service providers
and distributed enterprise architectures. SIP suffers from some of the limitations of H.323 in that
it has become a collection of IETF specifications, some of which are still under definition. The
other similarity with H.323 is that SIP defines intelligent end points and vendors have found this
approach to be more costly and less reliable.
3. In contrast to SIP, the MGCP/MEGACO standards both centralize the control of simple
telephones. This is popular in environments where both cost and control are important issues,
which is certainly the case in the enterprise environment where the PC can be used to augment
features and functionality.
Moving forward, the market will likely support multiple standards for IP voice communications,
with certain standards optimized for specific areas – such as carrier markets or communication
with end point devices.
But as we have previously mentioned the current trend towards delivering presence along with
instant messaging using SIP as the transport make it a strong contender for the delivery of
application-rich voice systems over time.

24
 CHAPTER 9

DEPLOYMENT ISSUES

Having described the fundamentals of VoIP and the underlying IP infrastructure, we now turn to
some of the deployment issues that need to be addressed.
9.1. Legacy Integration
In most cases, enterprises have legacy PBX systems and the migration to IP voice
communications will be carried out in steps. This may be for financial reasons, as the PBX asset
depreciates over a seven- or even ten-year period and a large number of legacy PBXs were sold
in the lead up to Y2K. Equally important, the logistics involved in deploying simultaneous multi-
site cutovers can be daunting. Thus, though it may only be a temporary requirement, it is
important that the new IP-PBX can interact with various types of the legacy system.
9.2. Basic Connectivity
The easiest way to connect two PBXs is to use a digital trunk like T-1 or E-1. By linking an IP-
PBX to a legacy system, we can begin the process of configuring the legacy system to deliver
extension-to-extension dialing between the two systems. If the IP-PBX has been designed with
ease of deployment in mind, then setting up the extension-to-extension mappings will be a matter
of a few minutes on the IP-PBX side.
After verifying that we can dial extensions between each system, we should verify that other
features are implemented correctly. Caller ID, for example, can be forwarded from one voice
system to another so that the identity
of a caller can be displayed on the handset. Over the years, the legacy vendors have pushed
proprietary solutions for delivering these features but, in fact, standards like ISDN-PRI and
QSIG will provide the necessary signaling and are implemented in most PBXs and IP-PBXs[4].
The final decision concerning connectivity will be which system owns the trunk connection to
the public telephone network. Clearly there are three options for the location of the trunk
connection:
• Legacy PBX owns the PSTN trunk
• IP-PBX owns the PSTN trunk
• Both systems have a trunk connection

25
The approach selected will depend on budget as much as anything else. If the line card used for
the PSTN connection is to be employed to link the legacy system to the IP-PBX, then clearly an
additional line card will have to be purchased for the legacy system. However, most
organizations would prefer to purchase equipment that will work even after the legacy switch has
been decommissioned, and this implies that any additional line cards should be purchased for the
IP-PBX, which would act as a trunk gateway.

9.3. Voicemail Integration

You must decide how the IP-PBX will interact with the legacy voicemail system. There are two
approaches to address this requirement Keep them Separate: the legacy PBX and the IP-PBX
each have their own separate voicemail systems.
Voicemails may be passed between the two systems using AMIS or VPIM
Host Voicemail on a Single System: either the legacy voicemail system is preserved for all users,
or all users move to the voicemail system provided by the IP-PBX.
SMDI is the appropriate protocol for this scenario. First we will look at the two protocols
available for interconnecting separate voicemail systems:
1. Audio Messaging Interchange Specification (AMIS) – Mimics the DTMF signals of the
handset to forward voicemails between two AMIS-compliant systems over trunks between the
two systems. Of the two approaches, AMIS is simpler to implement on the legacy system and
requires significantly lower investment.
2. Voice Profile for Internet Messaging (VPIM) – provides a standard Multipurpose Internet
Mail Extensions (MIME) encoding so that voicemails can be sent as multimedia emails over
LAN/WAN data connections.
While VPIM is the more modern of the standards, it is often sold as an add-on feature and
therefore requires considerable investment to implement.
When migrating to IP voice, you may need to make decisions regarding which system houses
companywide voicemail storage. No matter which system is finally selected, the message-
waiting lamps of the alternate system (IP-PBX or Legacy PBX) will need to be activated and
deactivated. In other words, the handsets of the IP-PBX will light up when a voicemail arrives
even though that voicemail gets stored on the legacy voicemail system. Similarly the legacy

26
phones should indicate the availability of voicemail on telephone handsets connected to the PBX
even though the actual voicemail resides, this time, on the IP-PBX system.
Simplified Message Desk Interface (SMDI) is a protocol developed for serial connections (TIA-
232 cables) between voicemail systems and PBXs. The protocol signals the availability of
voicemail for a specific extension to the management interface of the legacy PBX. The legacy
PBX uses this information to signal to the handset that it should light its message-waiting lamp.
When the message has been played, the lamp is switched off using the same mechanism. For
some PBXs, an additional external interface may be required.

9.4. SUPPORTING VOICE QUALITY (QoS) IN THE NETWORK:

Voice quality is based on users’ experiences and expectations.
In general, today’s business telephony networks have virtually no noise, echo, or delay. In IP
voice communications networks, noise and echo problems can be easily addressed, but delay can
still be a problem.
The ITU specifies an acceptable delay of not more than300ms round trip or 150ms one way.
Delays over ¼ of a second (250ms) are noticeable and unacceptable. In the US, the acceptable
delays in the PSTN are below 100ms. Cellular phones cannot deliver this level of delay quality,
but users accept the delay in exchange for improved mobility. There are several sources of
latency in transmitting voice over IP networks. The first source of delay comes from encoding
analog voice into a digital data stream. Stream, processing delay, and voice quality rating. Once
the voice stream has been digitized, it must be packetized and transmitted onto the network. And
this is the second place where latency can be added to the overall delay. Voice is typically
sampled in 20ms intervals, but this is not a given, and transmission is dependent both on line
speed and the packet size resulting from the sample rate. For example transmitting a 64 byte
packet onto 56 Kbps line takes 8ms, (formula:64 bytes x 8 bits/byte = 512 bits / 56,000bps
=.0008 seconds). Transmitting a 64 byte packet onto a 10 mbps LAN takes only 51
microseconds. In today’s world of wire-speed switched LAN infrastructures, transmission delays
introduced by switches and routers are negligible. Delays are likely to occur at the WAN access
point where line speeds are low and the potential for congestion is high. To ensure voice quality,
you first need to determine that there is sufficient bandwidth. As packet sizes get smaller and

27
compression techniques improve, the packet header portion takes up the majority of what is
transmitted.
As you consider how you will prioritize voice traffic over your network we recommend you give
some thought not only to which of the approaches is the more sophisticated but also how easily
will you be able to manage the scheme. In general, the simpler approach will be the least costly.
Looking deeper into the IP header, routers may also prioritize packets based on protocol type,
such as time sensitive protocols like SNA or SDLC. In addition, the IP header contains a Type of
Service (TOS) field that indicates priority or handling characteristics (e.g., high priority, low
loss, low delay).
In private WANs where there is a dedicated leased line, prioritizing voice over data at the access
point is all that is required. In public or shared wide area networks (Internet, VPNs), voice traffic
must be prioritized throughout the shared network space. Rather than have routers classify and
prioritize packets at every hop, the IETF is developing several standards to identify and prioritize
different types of traffic.

9.5. Reliability
For both a legacy PBX and a next generation IP voice communications system, the issue of
reliability is dependent on the system’s ability to ensure access to dial tone, voicemail,
administrative functions, and value-added applications.
The most important considerations will be:
• The dial tone and call processing done.
• The operating system use this device (Windows NT or embedded real-time).
• The cost of protecting this device from failure.

28
 CONCLUSION

VoIP systems today cannot only match the features of legacy PBXs, but they have been built
with today’s communications environment in mind. When most of the legacy PBX architectures
were launched, the Internet was irrelevant to mainstream business activity. Today, however, the
Internet is a crucial tool in facilitating business, and IP forms the foundation for many of the
applications and systems that continue to drive our productivity to new levels. IP telephony is
inherently designed to leverage the Internet phenomenon, providing a distributed
communications infrastructure that businesses will use to both scale and simplify their activities
simultaneously.

29
 REFERENCES

1. Lawrence Harte “Introduction To IP Telephony Technology”; june2001; PP: 153-177.

2. Bill Stuckey “VoIP Made Easy “; august 2004; PP: 189-230.
3. Daniel Collins “Carrier Grade voice over IP”; 2003; PP: 184-215.
4. Ted Wallingford “Switching to VoIP”; 2005; PP: 44-59.

30