1

Chapter 1: INTRODUCTION

We did our project with iPhonica LLC. We were assigned to their VoIP (Voice
over IP) team spear headed by Mr. Iftikhar Rathore, Vice President Engineering
at iPhonica LLC.

1.1 VoIP Overview

1.1.1 History

Availability of a telephone and access to a low-cost, high quality worldwide

network is considered to be essential in modern society. Anything that would
jeopardize this is usually treated with suspicion. There is however, a Paradigm
shift beginning to occur since more and more communications is in digital form
and transported via packet networks such as IP, ATM cells and Frame Relay
frames. Since Data traffic is growing much faster than telephone traffic, there has
been considerable interest in transporting voice over data networks (as opposed
to the more traditional data over voice networks).

1.1.2 What is VoIP?

Support for Voice communications using the Internet Protocol (IP), which is
usually just called "Voice over IP" or VoIP, has become especially attractive
given the low cost, flat-rate pricing of the public Internet. In fact, toll quality
telephony over IP has now become one of the key steps leading to the
convergence of the voice, video, and data communications industries. The
feasibility of carrying voice and signaling messages over the Internet has already
been demonstrated but delivering high-quality commercial products, establishing
public services, and convincing users to buy into the vision are just beginning.

VoIP can be defined as the ability to make telephone calls (i.e., to do everything
we can do today with the PSTN) and to send facsimiles over IP-based data
networks with suitable quality of service (QoS) and a much superior cost/benefit.
Equipment producers see VoIP as a new opportunity to innovate and compete.
The challenge for them. For Internet service providers, the possibility of
introducing usage-based pricing and increasing their traffic volumes is very
attractive. Users are seeking new types of integrated voice/data applications as
well as cost benefits.

1.1.3 Applications and Benefits of VoIP

Voice communications remains a basic form of interaction for all of us. The
immediate goal of VoIP service providers is to reproduce existing telephone
capabilities at a significantly lower "total cost of operation" and to offer a
technically competitive alternative to the PSTN. It is the combination of VoIP with
point-of-service applications that shows great promise for the longer term.
 2

The first measure of success for VoIP is the cost savings for long distance calls
as long as there are no additional constraints imposed on the end user. VoIP
provides a competitive threat to the providers of traditional telephone service
that, at the very least, will simulate improvements in cost and function throughout
the industry.

VoIP is applied to almost any voice communications requirement, ranging from a

simple inter-office intercom to complex multi-point teleconferencing/shared
screen environments. The quality of voice reproduction is tailored according to
the application. Customer calls may need to be of higher quality than internal
corporate calls. Hence, VoIP equipment has the flexibility to cater to a wide range
of configurations and environments and the ability to blend traditional telephony
with VoIP.

Some examples of VoIP applications:

 PSTN Gateways.
 Internet-aware Telephones.
 Inter-office trunking over the corporate intranet.
 Remote access from a branch (or home) office.
 Voice calls from a Mobile PC via the intranet.
 Internet call center access.

Generally the benefits of technology can be divided into the following four
categories:

 Cost reduction
 Simplification
 Consolidation
 Advanced applications

1.1.4 IP Network Support for Voice

A key requirement for successful VoIP deployment is the availability of an

underlying IP based network that is capable of supporting real-time telephone
and facsimile.

Most of today's data network equipment e.g. Routers, LAN switched, ATM
switches, Network interface cards, PBX's etc support voice traffic. Furthermore,
VoIP-specific equipment is either integrated into these devices or work
compatibly with them. Three different techniques are used to improve network
quality of service.

 Controlled networking environment

 Management tools
 3

 Control protocols and mechanism

Real time voice traffic can be carried over IP networks in three different ways:

1. Voice Trunks can replace the analog or digital circuits that are serving as
voice trunks (such as private links between company owned PBXs) or
PSTN-access trunks (links between a PBX and the carrier). Voice packets
are transferred between pre-defined IP addresses, thereby eliminating the
need for phone number to IP address conversions. Fallback to the PSTN
(or other private voice circuits) is always an option.

2. PC-to-PC Voice can be provided for multimedia PCs (i.e. PCs with a
microphone and sound system) operating over an IP-based network
without connecting to the PSTN. PC applications and IP-enabled
telephones can communicate using point-to-point or multipoint sessions (a
form of Internet ham radio).

3. Telephony (any phone-to-phone) communications appears like a normal

telephone to the caller but may actually consist of various forms of voice
over packet network., all interconnected to the PSTN. Gateway
functionality is required when interconnecting to the PSTN or when
interfacing the standard telephone to a data network. Also IP-enabled
telephones connect directly.

VoIP networks also include IP-based PBXs which emulate the functions of a
traditional PBX. This allows both standard telephones and multimedia PCs to
connect to either the PSTN or the Internet, providing a seamless migration path
to VoIP.

Some of the functions that are required for a VoIP system include:

 Fault Management
 Accounting/Billing
 Configuration
 Addressing/Directories
 Authentication/Encryption

1.1.5 Protocols being used for VoIP

Voice over IP is increasing in importance. There are a number of protocols being

used each being an advancement from the last, each trying to increase QoS
(Quality of Service). A few of them are listed with their short definitive summaries
below:
 4

1.1.5.1 H323

The H.323 standard provides a foundation for audio, video, and data
communications across IP-based networks, including the Internet. H.323 is an
umbrella recommendation from the International Telecommunications Union
(ITU) that sets standards for multimedia communications over Local Area
Networks (LANs) that do not provide a guaranteed Quality of Service (QoS).
These networks dominate today’s corporate desktops and include packet-
switched TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network
technologies. Therefore, the H.323 standards are important building blocks for a
broad new range of collaborative, LAN-based applications for multimedia
communications. It includes parts of H.225.0 - RAS, Q.931, H.245 RTP/RTCP
and audio/video codecs, such as the audio codecs (G.711, G.723.1, G.728, etc.)
and video codecs (H.261, H.263) that compress and decompress media streams.
Media streams are transported on RTP/RTCP. RTP carries the actual media and
RTCP carries status and control information. The signalling is transported reliably
over TCP.

1.1.5.2 Megaco

The Media Gateway Control Protocol, (Megaco) is a result of joint efforts of the
IETF and the ITU-T Study Group 16. The protocol definition of this protocol is
common text with ITU-T Recommendation H.248.

The Megaco protocol is used between elements of a physically decomposed

multimedia gateway. There are no functional differences from a system view
between a decomposed gateway, with distributed sub-components potentially on
more than one physical device, and a monolithic gateway such as described in
H.246. This protocol creates a general framework suitable for gateways,
multipoint control units and interactive voice response units (IVRs).

Packet network interfaces may include IP, ATM or possibly others. The interfaces
support a variety of SCN signalling systems, including tone signalling, ISDN,
ISUP, QSIG and GSM. National variants of these signalling systems are
supported where applicable.

1.1.5.3 MGCP

Media Gateway Control Protocol (MGCP) is used for controlling telephony

gateways from external call control elements called media gateway controllers or
call agents. A telephony gateway is a network element that provides conversion
between the audio signals carried on telephone circuits and data packets carried
over the Internet or over other packet networks.

MGCP assumes a call control architecture where the call control intelligence is
outside the gateways and handled by external call control elements. The MGCP
 5

assumes that these call control elements, or Call Agents, will synchronize with
each other to send coherent commands to the gateways under their control.
MGCP is, in essence, a master/slave protocol, where the gateways are expected
to execute commands sent by the Call Agents.

The MGCP implements the media gateway control interface as a set of

transactions. The transactions are composed of a command and a mandatory
response.

1.1.5.4 RVP over IP

RVP Over IP Specification, MCK Communications (Proprietary)

Remote Voice Protocol (RVP) is MCK Communications' protocol for transporting

digital telephony sessions over packet or circuit based data networks. The
protocol is used primarily in MCK's Extender product family, which extends PBX
services over Wide Area Networks (WANs). RVP provides facilities for
connection establishment and configuration between a client (or remote station
set) device and a server (or phone switch) device.

RVP/IP uses TCP to transport signalling and control data, and UDP to transport
voice data.

1.1.5.5 SAPv2

SAP is an announcement protocol that is used by session directory clients. A

SAP announcer periodically multicasts an announcement packet to a well-known
multicast address and port. The announcement is multicast with the same scope
as the session it is announcing, ensuring that the recipients of the announcement
can also be potential recipients of the session the announcement describes
(bandwidth and other such constraints permitting). This is also important for the
scalability of the protocol, as it keeps local session announcements local.

1.1.5.6 SDP

The Session Description Protocol (SDP) describes multimedia sessions for the
purpose of session announcement, session invitation and other forms of
multimedia session initiation.

On Internet Multicast backbone (Mbone) a session directory tool is used to

advertise multimedia conferences and communicate the conference addresses
and conference tool-specific information necessary for participation. The SDP
does this. It communicates the existence of a session and conveys sufficient
information to enable participation in the session. Many of the SDP messages
are sent by periodically multicasting an announcement packet to a well-known
multicast address and port using SAP (session announcement protocol). These
 6

messages are UDP packets with a SAP header and a text payload. The text
payload is the SDP session description. Messages can also be sent using email
or the WWW (World Wide Web).

The SDP text messages include:

 Session name and purpose

 Time the session is active
 Media comprising the session
 Information to receive the media (address etc.)

SDP messages are text messages using the ISO 10646 character set in UTF-8
encoding.

1.1.5.7 SIP

Session Initiation Protocol (SIP) is a application layer control simple signalling

protocol for VoIP implementations using the Redirect Mode.

SIP is a textual client-server base protocol and provides the necessary protocol
mechanisms so that the end user systems and proxy servers can provide
different services:
1. Call forwarding in several scenarios: no answer, busy, unconditional,
address manipulations (as 700, 800, and 900-type calls).
2. Callee and calling number identification
3. Personal mobility
4. Caller and callee authentication
5. Invitations to multicast conference
6. Basic Automatic Call Distribution (ACD)

SIP addresses (URL) can be embedded in Web pages and therefore can be
integrated as part of powerful implementations.

SIP using simple protocol structure, provides the market with fast operation,
flexibility, scalability and multiservice support.

SIP provides its own reliability mechanism. SIP creates, modifies and terminates
sessions with one or more participants. These sessions include Internet
multimedia conferences, Internet telephone calls and multimedia distribution.
Members in a session can communicate using multicast or using a mesh of
unicast relations, or a combination of these. SIP invitations used to create
sessions carry session descriptions which allow participants to agree on a set of
compatible media types. It supports user mobility by proxying and redirecting
requests to the user's current location. Users can register their current location.
SIP is not tied to any particular conference control protocol. It is designed to be
 7

independent of the lower-layer transport protocol and can be extended with

additional capabilities.

SIP transparently supports name mapping and redirection services, allowing the
implementation of ISDN and Intelligent Network telephony subscriber services.
These facilities also enable personal mobility which is based on the use of a
unique personal identity.

SIP supports five facets of establishing and terminating multimedia

communications:

1. User location
2. User capabilities
3. User availability
4. Call setup
5. Call handling

SIP can also initiate multi-party calls using a multipoint control unit (MCU) or
fully-meshed interconnection instead of multicast. Internet telephony gateways
that connect Public Switched Telephone Network (PSTN) parties can also use
SIP to set up calls between them.

SIP is designed as part of the overall IETF multimedia data and control
architecture currently incorporating protocols such as RSVP, RTP RTSP, SAP
and SDP. However, the functionality and operation of SIP does not depend on
any of these protocols.

SIP can also be used in conjunction with other call setup and signaling protocols.
In that mode, an end system uses SIP exchanges to determine the appropriate
end system address and protocol from a given address that is protocol-
independent. For example, SIP could be used to determine that the party can be
reached using H.323 to find the H.245 gateway and user address and then use
H.225.0 to establish the call.

1.1.5.8 SGCP

Simple Gateway Control Protocol (SGCP) is used to control telephony gateways

from external call control elements. A telephony gateway is a network element
that provides conversion between the audio signals carried on telephone circuits
and data packets carried over the Internet or over other packet networks.

The SGCP assumes a call control architecture where the call control intelligence
is outside the gateways and is handled by external call control elements. The
SGCP assumes that these call control elements, or Call Agents, will synchronize
with each other to send coherent commands to the gateways under their control.
 8

The SGCP implements the simple gateway control interface as a set of

transactions. The transactions are composed of a command and a mandatory
response. There are five types of commands:

 CreateConnection.
 ModifyConnection.
 DeleteConnection.
 NotificationRequest.
 Notify.

The first four commands are sent by the Call Agent to a gateway. The Notify
command is sent by the gateway to the Call Agent. The gateway may also send
a DeleteConnection.

All commands are composed of a Command header, optionally followed by a

session description. All responses are composed of a Response header,
optionally followed by a session description. Headers and session descriptions
are encoded as a set of text lines, separated by a line feed character. The
headers are separated from the session description by an empty line.
The command header is composed of:

 Command line.
 A set of parameter lines, composed of a parameter name followed by a
parameter value.

The command line is composed of:

 Name of the requested verb.

 Transaction identifier, correlates commands and responses. Transaction
identifiers may have values between 1 and 999999999 and transaction
identifiers are not reused sooner than 3 minutes after completion of the
previous command in which the identifier was used.
 Name of the endpoint that should execute the command (in notifications,
the name of the endpoint that is issuing the notification).
 Protocol version.

These four items are encoded as strings of printable ASCII characters, separated
by white spaces, i.e. the ASCII space (0x20) or tabulation (0x09) characters. It is
recommended to use exactly one ASCII space separator.

1.1.5.9 SCCP (Skinny)

Skinny Client Control Protocol (SCCP). Telephony systems are moving to a

common wiring plant. The end station of a LAN or IP- based PBX must be simple
to use, familiar and relatively cheap. The H.323 recommendations are quite an
expensive system. An H.323 proxy can be used to communicate with the Skinny
 9

Client using the SCCP. In such a case the telephone is a skinny client over IP, in
the context of H.323. A proxy is used for the H.225 and H.245 signalling.

The skinny client (i.e. an Ethernet Phone) uses TCP/IP to transmit and receive
calls and RTP/UDP/IP to/from a Skinny Client or H.323 terminal for audio. Skinny
messages are carried above TCP and use port 2000.
The messages consist of Station message ID messages.

1.2 Introduction to iPhonica

iPhonica is privately held, and is lead by a remarkable management team made

up of seasoned executives with telecom, Internet and finance experience.
iPhonica is a wholly owned subsidiary of Comcept (pvt) Ltd.

Comcept brings with it a decade of exposure in providing custom solutions to the

telecom industry. The systems architectured by Comcept cover a broad range of
public telephony networks, transaction terminals, call management systems,
billing and credit control solutions. Comcept has partnered with companies like
IBM, Ascend, Huawei and Lockheed Martin Global Telecom, in the process of
proposing and then implementing these solutions.

Comcept's client list includes over 80 telecom service providers, which includes
both public and private Telcos, including payphone operators, WLL service
providers and ISPs.

Comcept has grown into a vibrant workforce of 260+, generating an annual

turnover of 8M US$. For the last five years, the company has been posting
double and triple digit growth rates in all possible categories.

1.2.1 Problem Statement

iPhonica is the manufacturer of NetGate 4000. The NetGate 4000 (GoC) is a

VoIP Gateway providing toll quality voice calls over an IP network providing
users low cost for long distance and international calls. It offers secure
transmissions with built in firewall & VPN and connectivity via broadband access
media.

The task asked of us was to make a server capable of routing VoIP calls from
one end-point (GoC) to another as well as enable IP Phone users to make PSTN
calls through the gateway embedded into the server.

The server should offer both classical PBX functionality and advanced features,
and interoperates with traditional standards-based telephony systems and Voice
over IP systems. One would expect a large proprietary PBX system to have
features such as Voicemail, Conference Bridging, Call Queuing, and Call Detail
Records.
 10

1.2.2 Objectives of the Project

The following feature set was a must for the server:

 Voicemail System
o Password Protected
o Separate Away and Unavailable Messages
o Default or Custom Messages
o Multiple Mail Folders
o Web Interface for Voicemail Checking
o E-mail notification of Voicemail
o Voicemail Forwarding
o Visual Message Waiting Indicator
o Message Waiting Stutter Dialtone
 Auto Attendant
 Interactive Voice Response
 Overhead Paging
 Flexible Extension Logic
o Multiple Line Extensions
o Multi-Layered Access Control
o Direct Inward System Access
 Directory Listing
 Conference Bridging
o Unlimited Conference Rooms
o Access Control
 Call Queuing
 ADSI Menu System
o Support for Advanced Telephony Features
o PBX Driven Visual Menu Systems
o Visual Notification of Voicemail
 Call Detail Records
 Local Call Agents
 Remote Call Agents
 Protocol Bridging
o Provides seamless integration of technologies
o Offers a unified set of services to users regardless of connection
type
o Allows interoperability of VoIP systems

1.2.2.1 Call Features

 Music on Hold
 Music on Transfer
o Flexible mp3 based system
o Volume Control
o Random Play
o Linear Play
 11

 Call Waiting
 Caller ID
 Caller ID Blocking
 Caller ID on Call Waiting
 Call Forward on Busy
 Call Forward on No Answer
 Call Forward Variable
 Call Transfer
 Call Parking
 Call Retrieval
 Remote Call Pickup
 Do Not Disturb

1.2.2.2 Scalability

 TDMoE
o Allows Direct Connection of Asterisk PBX
o Offers Zero Latency
o Uses Commodity Ethernet Hardware
 Voice over IP
o Allows for Integration of Physically Separate Installations
o Uses commonly deployed data connections
o Allows a unified dialplan across multiple offices

1.2.2.3 Voice over IP Interoperability

Asterisk provides transparent bridging between Voice over IP protocols and

traditional telephony equipment. In addition, Asterisk can transfer calls from one
system to another via the Inter Asterisk Exchange protocol.

 Inter-Asterisk Exchange (IAX)

 H.323
 Session Initiation Protocol (SIP)
 Media Gateway Control Protocol (MGCP)

1.2.2.4 Traditional Telephony Interoperability

 Robbed Bit Signaling Types

o FXS and FXO
o Loopstart
o Groundstart
o Kewlstart
o E&M
o E&M Wink
o Feature Group D
 PRI Protocols
 12

o 4ESS
o Lucent 5E
o DMS100
o National ISDN2
o EuroISDN
o BRI (ISDN4Linux)

1.2.2.5 Codec Support

 GSM
 G.729 (available through purchase of commercial license(s))
 G.723.1 (pass through)
 Linear
 Mu-Law
 A-Law
 ADPCM
 G.726
 ILBC
 LPC-10
 MP3 (decode only)

1.3 Scope of the Project

As we had no past knowledge of VoIP systems or any of the protocols being

used for VoIP we had to research and study a lot before we could start even the
initial design of the required server system.

We were asked not to start making the server from scratch but to research and
try and find any open source VoIP software solutions which would have some of
the required functionality and the rest would them have to be incorporated by us
into that system.

All this required extensive research into the field of VoIP including voice over
data network programming. Firstly, we were required to find the various currently
available software solutions for our scenario, list down their pros and cons and
give a presentation to Mr. Rathore and convince him on allowing us to work on
the system which we thought would be most suitable for their GoC’s and would
give optimum performance even under the most worst conditions also they
should support the three protocols supported by the GoC’s which are:
1. H.323
2. SIP &
3. MGCP

After our preliminary research we were able to come up with the following VoIP
server systems:
1.4 VOCAL
 13

The Vovida Open Communication Application Library (VOCAL) enables

advanced telephony features, applications and services to be rapidly and
effectively deployed on converged datacom-telecom networks in carrier and
service provider environments. Among these advanced services is Voice over IP.

What works best from the business angle, however, does not always work best
from the technical point of view. At the end of the day, one cannot retain
customers without a reliable system. This means that the developer needs a
solid operating system, high-end hardware, and robust software. The Vovida
VoIP solution provides the scalability, reliability and performance to effectively
deliver converged voice and data applications on the data network.

1.5 OpenH323 Gatekeeper - The GNU Gatekeeper

It is an open-source project that implements an H.323 gatekeeper. A gatekeeper

provides call control services to the H.323 endpoints. It is an integral part of most
useful internet telephony installations that are based on the H.323 standard.

According to Recommendation H.323, a gatekeeper shall provide the following

services:

 Address Translation
 Admissions Control
 Bandwidth Control
 Zone Management
 Call Control Signaling
 Call Authorization
 Bandwidth Management
 Call Management

The GNU Gatekeeper implements most of these functions based on the

OpenH323 protocol stack.

1.6 SIP Express Router

SIP Express Router (ser) is a high-performance, configurable, free SIP

(RFC3261) server. It can act as SIP registrar, proxy or redirect server. SER
features an application-server interface, presence support, SMS gateway,
SIMPLE2Jabber gateway, RADIUS/syslog accounting and authorization, server
status monitoring, FCP security, etc. Web-based user provisioning, serweb,
available.

Its performance allows it to deal with operational burdens, such as broken

 14

network components, attacks, power-up reboots and rapidly growing user

population.

SER's configuration ability meets needs of a whole range of scenarios including

small-office use, enterprise PBX replacements and carrier services.

1.7 Asterisk

Asterisk is a complete PBX in software. It runs on Linux and provides all of the
features you would expect from a PBX and more. Asterisk does voice over IP in
three protocols, and can interoperate with almost all standards-based telephony
equipment using relatively inexpensive hardware.

Asterisk needs no additional hardware for Voice over IP. For interconnection
with digital and analog telephony equipment, Asterisk supports a number of
hardware devices, most notably all of the hardware manufactured by Asterisk's
sponsors, Digium. Digium has single and quad span T1 and E1 interfaces for
interconnection to PRI lines and channel banks as well as a single port FXO card
and a one to four-port modular FXS card.

Also supported are the Internet Line Jack and Internet Phone Jack products from
Quicknet.

Asterisk supports a wide range of TDM protocols for the handling and
transmission of voice over traditional telephony interfaces. Asterisk supports US
and European standard signalling types used in standard business phone
systems, allowing it to bridge between next generation voice-data integrated
networks and existing infrastructure. Asterisk not only supports traditional phone
equipment, it enhances them with additional capabilities.

Using the Inter-Asterisk eXchange (IAX) Voice over IP protocol, Asterisk merges
voice and data traffic seamlessly across disparate networks. While using Packet
Voice, it is possible to send data such as URL information and images in-line with
voice traffic, allowing advanced integration of information.

Asterisk provides a central switching core, with four APIs for modular loading of
telephony applications, hardware interfaces, file format handling, and codecs. It
allows for transparent switching between all supported interfaces, allowing it to
tie together a diverse mixture of telephony systems into a single switching
network.

Asterisk is primarily developed on GNU/Linux for x/86. It is known to compile and

run on GNU/Linux for PPC along with OpenBSD, FreeBSD, and Mac OS X
Jaguar. Other platforms and standards based UNIX-like operating systems
should be reasonably easy to port for anyone with the time and requisite skill to
 15

do so. Asterisk is available in the testing and unstable Debian archives,

maintained thanks to Mark Purcell.

1.8 Unimessaging Web Server

Uni-Messaging, quite simply, allows access to all your messages, whatever type
they may be, wherever you may be. Uni-Messaging keeps you in total contact
wherever you are—home, office, or traveling.

What you get in return is simplicity, more control, greater productivity, a better
image for your business and peace of mind. Thanks to Uni-Messaging's ability to
increase workplace efficiency. Uni-Messaging is fast becoming a mission-critical
application for mainstream business users.

Uni-Messaging has solutions to fit your every need.

Virtual PBX

* Hosted Solution
* No hardware or software required
* Web Management
* SIP IP Phone compatible
* FREE on-net calls
* Perfect for the Small Business with 1 - 50 users
* The most cost effective solution on the market

Corporate & Enterprise

* Enterprise solution
* Works with existing PBX or as stand alone solution
* FREE On-net calls
* SIP Talk Technology allows for the use of any SIP Compatible device or
phone
* Tie multiple locations together with one phone system
* Perfect for organizations requiring 30 or more users
* The most cost effective enterprise solution on the market

Out of all of the above we were to choose one which would be ideal for our
GoC’s. For this we also had to gain in depth of the GoC’s so as to understand
their complete functionality and usability, only after which we would be able to
choose and customize and develop on top of any existing VoIP server.
 16

Chapter 2: SYSTEM ANALYSIS

Gateways are the key to bringing IP telephony into the mainstream. By bridging
the traditional circuit-switched telephony world with the Internet, gateways offer
the advantages of IP telephony to the most common, cheapest, most mobile, and
easiest-to-use terminal in the world: the standard telephone. Gateways also
overcome another significant IP telephony problem: addressing. To address a
remote user on a multimedia PC, you must know the user's Internet Protocol (IP)
address. To address a remote user with a gateway product, you only need to
know the user's phone number.

2.1 How Does It Work?

Conceptually, Internet telephone gateways work like this.

 On one side, the gateway connects to the telephone world. It can

communicate with any phone in the world. A phone line plugs into the
gateway on this end.
 On the other side, the gateway connects to the Internet world. It can
communicate with any computer in the world. A computer network plugs
into the gateway on this end.

Figure 2.1 – Internet Telephony Gateway

 The gateway takes the standard telephone signal, digitizes it (if it is not
already digital), significantly compresses it, packetizes it for the Internet
using Internet Protocol (IP), and routes it to a destination over the Internet.
 The gateway reverses the operation for packets coming in from the
network and going out the phone.
 17

 Both operations (coming from and going to the phone network) take
place at the same time, allowing a full-duplex (two-way) conversation.

A number of configurations can be built from this basic operation. Phone-to-PC

or PC-to-phone operation can take place with one gateway. Phone-to-phone PC
operation can occur with two gateways. To offer international long distance
service using gateways, for example, an organization or service provider can
host one gateway in each country. By bypassing the international connect
charges - even paying in-country long distance rates - the configuration costs
significantly less than traditional circuit-switched service.

2.2 How Well Does It Work?

Nothing replaces trying it for yourself. However, we can make some general
observations. There are two main factors contributing to quality: voice quality and
turnaround time, or latency.

Figure 2.2 – Internet Telephony Gateway Deployment

 18

Voice quality has improved greatly from early versions of the technology, which
were characterized by distortions and disruptions in speech. Improved
technologies for voice coding and lost packet reconstruction have yielded
products where speech is easy to understand.

Latency affects the pace of the conversation. Humans can tolerate about 250
msec of latency before it has a noticeable effect. Today's IP telephony products
exceed this latency, so most connections sound like traditional calls routed over
a satellite circuit (which are usable, but require some getting used to). Even
today, the products are well suited to many applications. Moreover, the latency
will continue to improve, driven by three factors.

 Improved gateways. Developers are just beginning to squeeze latency

out of the first generation of products.
 Deployment over private networks. By deploying gateways on private
circuits, organizations and service providers can control the bandwidth
utilization and, hence, latency.
 Internet development. Today's Internet was not designed with real-time
communications in mind. The Internet Engineering Task Force (IETF),
together with Internet backbone equipment providers, is addressing this
with technologies like Reservation Protocol (RSVP), which will let
bandwidth be reserved. While it will take some time for the world's routers
to be upgraded and operational aspects (like how to bill for high quality of
service) to be resolved, the Internet word is moving fast - and in the right
direction.

2.3 Requirement Specifications

2.3.1 Purpose of the Product

The main objective is to develop a server proxy for making following types of
voice calls, using Internet, Intranet or PSTN networks:

a. Pure VoIP calls

b. VoIP to POTS ( Plain Old Telephone Service) Calls
c. POTS Call
i. Pure VoIP Call: A pure VoIP call is made from our IP phone to
another similar IP phone, both connected to Internet.
ii. VoIP to POTS Call: This type of call is made from our IP phone to
an ordinary standard PSTN phone using special purpose servers
called gateways. These servers have one foot in the IP world (i.e.
they have PSTN gateways circuitry). PSTN gateways allow phone
calls to jump the gap between Internet and PSTN.
iii. POTS Call: POTS is Plain Old Telephone Service. This call
connects two ordinary phones together over the Public Switched
Telephone Network (PSTN). The device has all the capabilities of a
 19

normal phone set like a handset, cradle switch, touch tone keypad
etc.

2.3.2 Registration

For registration we are going to use a SIP proxy for SIP module and a
gatekeeper for the H.323 module.

2.3.3 System Overview

We have suggested that for integrating our IP phones with PSTN we are going to
use an IP PBX. Then for dynamic registration and efficiency of H.323 module we
will use a Gatekeeper.

To get started some more technical exploration and requirements gathering

needed to be done which is formatted below :

2.3.4 Open vs. Proprietary Systems

One of the key factors for IP telephony gateway developers to consider is the
value of open systems versus proprietary systems. It is tempting to develop
proprietary versions of new technology where off-the-shelf components are not
readily available. However, component vendors have been able to respond to the
demands of IP telephony quickly, modifying existing products to address the
needs of the IP telephony gateway systems. These vendors are also continuing
to pour research and development money into enhancing their components.

The general advantages of open systems design are overwhelming. Competition

- at all levels - leads to lower prices, enhanced features and continual innovation.
Since system integrators need to excel in fewer aspects of system design, costs
fall even more.

The advantages of open systems are particularly compelling for IP telephony.

The impact of the Internet on telephony is not as a standalone system or feature.
It is fundamental and systemic. New generations of telephony systems will
evolve to better incorporate Internet capability. These new generations will be
built using open systems and standards.

2.3.5 Choosing a Component Supplier

To build open systems, system integrators must choose component vendors with
products that meet their technical requirements. Even more important, the
component vendor must be committed to this new market and must demonstrate
the ability to adapt to its changing requirements. And since so many IP telephony
systems are global, the vendor also needs a worldwide network of service.
 20

2.3.6 Telephone Interface

The telephone connection of the gateway needs to exhibit two critical features.

 There must be approved versions in all major countries, since the

largest cost savings for IP telephony is on international calls.
 It must be scalable. Depending on the design goals of the system
integrator, systems might range from two lines for small enterprises to
several thousand for service bureaus.

2.3.7 Call Control Protocol

The first IP telephony products used proprietary call control protocols. H.323,
however, is clearly emerging as the standard call control protocol. This
specification defines packet standards for terminal, equipment and services for
multimedia communications over large area networks (LANs) communicating to
systems connected to telephony networks such as ISDN. It will be supported by
successful IP telephony products.

2.3.8 Echo Cancellation

The Internet telephony gateways must perform echo cancellation.

Figure 2.3 – Echo Cancellation in LL

 21

Figure 2.4 – Echo Cancellation in Internet Telephony

In a typical configuration, two gateways are each connected to analog phones via
a digital, local central office (CO) switch. The phone system generally does not
perform echo cancellation on local circuits. Echo is present (caused by the four-
wire to two-wire hybrid), but is not a problem on local calls. The latency is not
long enough for the echo to come back as a separate transmission. The phone
system does perform echo cancellation on long distance circuits. By the time the
echo propagates through the network back to the speaking part, it is quite
disruptive.

Figure 2.5 – Echo Cancellation in LDI

IP telephony represents a unique case. Technically, local connections are being

used. Hence the phone system itself is not performing echo cancellation. But
long distance calls are being made. Hence, the echo will disrupt conversations if
it is not canceled. The IP telephony gateways, then, must supply the echo
cancellation.
 22

2.3.9 Full Duplex

Phone calls are full duplex, meaning both parties can speak at the same time.
Successful IP telephony products are also duplex. Surprisingly, not all voice
cards can support full-duplex operation.

2.3.10 DTMF Detection and Notch-Out

Dual-tone multifrequency (DTMF) digits do not travel well across the Internet.
Coding and packetization distorts and segments them, making them
unrecognizable on the remote end. IP telephony gateways, then, must detect
DTMF digits locally, suppress their transmission, then generate them on the
remote side.

2.3.11 Clear channel

Before exchange of the commercial traffic a network of a new IP-operator will be

tested. The result of it will influence the price for traffic termination in this
network. Whether this procedure is successful depends on 2 factors: a method of
connection to a dial-up Telephony Network of Common Use (TNCU) and quality
of a connecting IP-channel between gateways. The requirements to the delay
and the bandwidth of the network of a connecting operator are quite high.

1. IP-channel bandwidth - minimum 360 Kbit/s (E1 PRI)

2. Permanent clear channelfor a fixed IP-address
3. Round –Trip Latency - less than 400 ms, that is less than 200 ms in one
direction.
4. Losses of IP packets are not more than 7% when at peak load of the
channel.
5. PDD – Post Dial Delay – 10 seconds between dialing and receiving a
response tonal signal.
6. PDD must be higher or comparable with that of a traditional dial-up
telephony network.

Beside the mentioned, ITXC lays down some requirements concerning types and
configuration of the equipment, accessibility of the network for remote monitoring.

It's quite difficult to maintain a channel with such characteristics. If some

company is making its way to the IP-telephony market, it' better to organize a
clear channel n? 64 Kbit/s to join a Partner's IP-network.

The construction of n? 64 Kbit/s always takes much time and is expensive. The
expenditure depends on a bandwidth and a physical length. The efficiency of an
IP-channel depends on the traffic volume. In IP-telephony we can talk of a
maximum of simultaneously connected channels.
 23

2.3.11 Codecs

An algorithm of information coding/decoding influences much an effective usage

of IP-channel bandwidth.

All types of voice codecs can be divided in three groups:

1. Codecs with pulse-code modulation (PCM) and adaptive differential pulse-

code modulation (ADPCM)
2. Codecs with vocoder conversion of a voice signal
3. Combined codecs.

In voice gateways a concept of "codec" supposes not only coding/decoding

algorithms but their hardware realization. The most codecs in IP-telephony have
recommendations of "G" family H.323 standard.

2.3.11.1 G.711

The recommendation describes a codec, that uses PCM converting of an analog

signal accurate to 8 bit, 8 KHz clock frequency and simplest compression of a
signal amplitude. The data rate on a converter output constitutes 64 Kbit/s (8
Bit ? 8 KHz). To reduce quantization noise and improve a conversion of signals
with small amplitudes they use nonlinear quantization according to m - Law (see
fig.2)

First PCM codecs appeared in 60s. G.711 codec is widespread in systems of

traditional telephony with channel commutation. However, the codec is utilized
rare because of high requirements to the bandwidth and the delay in the channel.
It may be used when you need to provide a maximum of coding voice information
with a few simultaneous small talks.

2.3.11.2 G.723.1

G.723.1 recommendation introduces combined codecs which use MP-MLQ

(Multy-Pulse – Multy Level Quantization). This codec is a combination of
ADC/DAC and a vocoder. They appeared thanks to vehicular communication
systems. A vocoder allows decreasing a data rate in a channel, what is important
for an efficient use of a radio channel and an IP-channel. G.723 codecs convert
an analog signal to a data stream at 64 Kbit/s (PCM), and then define frequency
phonemes, analyze them and transfer the information on the current state of
phonemes in a voice signal. This algorithm allows decreasing coded information
speed to 5.3 – 6.3 Kbit/s without noticeable voice quality degradation. The
codec's scheme is shown in Figure 3. The codec has 2 speeds and 2 coding
variants: 6,3 Kbit/s with MP-MLQ algorithm and 5.3 Kbit/s with CELP. The first
variant is intended for packet voice transmission.
 24

The conversion process requires from DSP 16.4 – 16.7 MIPS (Million Instructions
Per Second) and makes 37 ms delay. G.723.1 codec is widely used in voice
gateways and other IP-telephony devices.

2.3.11.3 G.729 combined codecs

They include G.729, G.729 Annex A, G.729 Annex B. G.729 codecs are called
CS-ACELP (Conjugate Structure - Algebraic Code Excited Linear Prediction).
The conversion process uses 21.5 MIPS and brings in 15 ms delay. The coded
voice signal speed constitutes 8 Kbit/s.

2.3.11.4 G.726

G.726 recommendation offers a coding technology with usage of ADPCM with

the following speeds: 32, 24, 16 Kbit/s. The conversion process doesn't bring in
any delay and requires DSP 5.5 – 6.4 MIPS. Figure 4 demonstrates the structure
chart.

The codec may be utilized simultaneously with G.711 to decrease the coding
speed of the latter. The codec is intended for videoconference systems.

2.3.11.5 G.728

The combined codec relates to LD-CELP technology (Low Delay - Code Excited
Linear Prediction). The codec ensures 16 Kbit/s conversion speed, brings in 3-5
ms delay, and is intended for videoconference systems. The table below shows
H.323 codec characteristics.

2.3.11.6 NetCoderTM

AudioCodes company offers a new blessing - NetCoder codec. It has quality

much better than that of G.723.1 and G.729, and doesn't require significant
calculating resources. However, the manufacturers of voice gateways don't hurry
to integrate it in their products. Besides, it's not included in H.323 standard.
NetCoder works at 4.8 – 9.6 Kbit/s, brings in 20 ms delay, and it has an
integrated mechanism of optimal transmission of voice pauses and automated
data rate.

2.4 IP-channel bandwidth

Data rate in the gateway-gateway channel consists of several components. The

figure below demonstrates a structure of interaction of devices according to
H.323 standard.
 25

Figure 2.6 – H.323 Standard Interaction of devices

Here you can see that beside coded voice/fax data, which are controlled by Real
Transport Protocol (RTP), the network with usage of the interconnection
protocols (H.225) transfers the information on telephony alarm status (Q.931)
and the information on RAS (Registration Admission Status).

The structure below shows interconnection of high level protocols TCP and UDP
and H.323 components with IP.

Figure 2.7 – Interconnection of High Level Protocols

 26

The figure below shows basic stages of gateway-gateway interconnection under

the control of H.323 gatekeeper for a telephony call, which comes to "A" gateway
input from a telephony network, with a call, which is directed at the abonent
connected to "B" gateway.

Figure 2.8 – Stages of Gateway-Gateway Connection

Because of a complexity of a realization of H.323 multiprotocol structure, some

manufacturers started to support and develop alternative protocols of IP-
gateways interconnection, simulteneously with H.323. For example, Nuera,
Komode, Mediatrix and Ericsson with SIP (Session Initial Protocol), CISCO
Systems with MGCPs (Media Gateway Control Protocol) and SGCP (Simple
Gateway Control Protocol), and some others.

2.5 Market Analysis

The PBX market grew by 6.9 percent in 2003, and coming on the heels of three
consecutive down years, the rebound is welcome news. The improved economy
helped spark the turnaround, as it enabled some buyers who had postponed
purchase decisions in 2000–2002 to finally make their move. But the major driver
has been IP-telephony. While horror stories are still heard about implementations
gone wrong, there’s no question that the technology has matured.

The manufacturers also have taken proactive steps to stimulate the market.
Migration and upgrade paths to IP-telephony are smoother for all but the most
geriatric PBX models, and new, more functional IP-telephony products have
 27

become available. Moreover, the vendors have been more forthcoming about
their IP-telephony strategies, which, combined with lower prices for IP phones
and media gateways, reduces customer risk.

For 2003, PBX line shipments are estimated at 6.6 million stations, of which 4.6
million are for traditional circuit-switched stations (analog and digital), and two
million for packet-switched (IP) stations. The shipments of IP stations doubled
from 2002, while circuit-switched stations declined slightly more than 11 percent.
Circuit-switched port shipments will continue to drop for the remainder of the
decade, but increasing demand for IP peripheral equipment will offset this decline
and drive moderate overall market growth. But shipments of traditional analog
and digital lines will not disappear anytime soon, because many customers will
continue to purchase significant numbers of add-ons to their circuit-switched
PBXs, even as new IP stations are installed.

The PBX market forecast for line station shipments (TDM/PCM and IP) and total
system revenues for the remainder of the decade is shown in Figures 1–3. Note
that the shipment and forecast data presented in this article is based on PBXs,
and does not include KTS/Hybrid.

The growth rate for IP station shipments, while impressive, is still coming off a
small base. That’s starting to change — 2 million stations shipped is nothing to
sneeze at — and we’ll start to see truly significant numbers over the next two or
so years. By 2010, IP stations will account for more than 75 percent of annual
station shipments, while non-IP shipments will be evenly divided between analog
and digital endpoints (for the first time since the late 1980s).

There are several reasons why IP station shipments are increasing so strongly:
 The maturing of IP-telephony technology.
 Increased product availability from both newcomers and traditional PBX
vendors.
 Absence of development/promotion of circuit-switched products.
 Falling prices for IP telephone sets and media gateways.
 Greater customer acceptance and recognition of the performance benefits
of IP-telephony.
 Deployment of LAN/WAN infrastructures that can support quality of
service (QOS).
 Unrelenting marketing and promotion of IP telephony by suppliers,
distributors and the media.

IP-telephony is the natural evolutionary step for digital communications, and after
several bumpy years,the technology is going mainstream. The initial market
positioning emphasized cost savings— reduced long distance expenses via toll
bypass, reduced costs for wiring and cabling and, because of standardization,
lower equipment costs. Except for toll bypass, however, many of those claims
turned out to be overblown, in part because of the offsetting expenses to upgrade
 28

the LAN/WAN infrastructure with switches and routers that were equipped with
QOS and higher-security capabilities.

We then started hearing about all the new applications IPT would enable, but so
far few have materialized. Both users and vendors have a long way to go on the
IPT applications learning curve.

Ironically, the most important benefits that IP-telephony delivers to the enterprise
are the ones least advertised: Greater flexibility in system architecture
configurations and higher levels of redundancy and resiliency. Traditional circuit-
switched PBXs have numerous single points of failure, because of two inherent
design conditions: Major common control elements are centralized, and there is a
fixed, single control signaling transmission path for each unique station user port
(including the port circuit interface card and desktop telephone instrument).

By contrast, an IP-PBX can reduce single points of failure, because of its

distributed topology. For example:
 Redundant common control elements, such as active (primary) and
standby (secondary) call telephony servers, can be distributed.
 Each IP endpoint can register with multiple gatekeepers (usually an
embedded telephony server function).
 Voice signals between two IP endpoints can be transmitted via multiple
transmission paths.
 Multiple media gateway devices can be programmed for shared access by
an IP station or WAN trunk termination.

The extent to which those benefits are realized, however, vary based upon which
of three IP-PBX architectures is selected—IP-enabled, converged or
client/server. The latter two can be configured with distributed call telephony
servers in either active/standby or load-sharing mode.

On the applications front, much work remains to be done, as there are relatively
few applications that are unique to IP-telephony. Information services accessed
through intelligent display-based IP phones with browser-like capabilities, and a
number of either familiar or emerging applications are greatly facilitated by the
underlying technology. These applications include presence, conferencing and
collaboration, multimedia messaging, teleworking and mobility. Wireless
solutions also benefit, because wireless LANs support 802.11 handsets and
wireless PDA softphones.
 29

Chapter 3: SYSTEM ARCHITECTURE

3.1 System Overview

Open source software (OSS) has achieved a dominant role in the delivery of IP-
based content such as web data (Apache) and email (sendmail), and is making
serious headway in streaming media (icecast). As processors become less
expensive and more powerful, even jobs that were once relegated to specific
hardware (such as routing and load sharing) are now becoming possible on low-
cost OSS platforms running Linux or BSD-based operating systems. The last
bastion of hardware-specific functionality in the office environment has been the
phone system, or PBX (Private Branch Exchange). PBX installations range from
key systems with a few lines to large platforms fed by Primary Rate Interface
ISDN (PRI) that are complex and expensive to deploy, with hundreds or
thousands of extensions spanning several states or continents.

Until now, open source telephony applications have been at the periphery of the
PBX, and even then, they have not been PBX-specific: fax modem software,
simple voicemail software, and caller-identification software all work in
conjunction with standard phone lines, but rarely together in concert as a unified
platform.

Asterisk is both an open source toolkit for telephony applications and a full-
featured call-processing server in itself. It can be a standalone system, or used
as an adjunct to a previously existing PBX or Voice Over IP (VoIP)
implementation. It can be software only, moving calls around via IP, or it can
have a variety of hardware interfaces to directly tie in with existing TDM (Time
Division Multiplexing) equipment. Asterisk is not a VoIP platform; it is a
Computerized Telephony Integration platform, which just happens to have a
number of very useful input/output channels through VoIP. Asterisk can just as
easily be a server that has no Internet connectivity, but uses PCI-card-based
analog or digital trunks to process calls -- an important distinction between
Asterisk and many other systems.

3.2 Asterisk Architecture

Asterisk is carefully designed for maximum flexibility. Specific API's are defined
around a central PBX core system. This advanced core handles the internal
interconnection of the PBX, cleanly abstracted from the specific protocols,
codecs, and hardware interfaces from the telephony applications. This allows
Asterisk to use any suitable hardware and technology available now or in the
future to perform its essential functions, connecting hardware and applications.
 30

The Asterisk core handles these items internally

 PBX Switching - The essence of Asterisk, of course, is a Private Branch

Exchange Switching system, connecting calls together between various
users and automated tasks. The Switching Core transparently connects
callers arriving on various hardware and software interfaces.
 Application Launcher - launches applications which perform services for
uses, such as voicemail, file playback, and directory listing.
 Codec Translator - uses codec modules for the encoding and decoding
of various audio compression formats used in the telephony industry. A
number of codecs are available to suit diverse needs and arrive at the
best balance between audio quality and bandwidth usage.
 Scheduler and I/O Manager - handles low level task scheduling and
system management for optimal performance under all load conditions.

3.2.1 Loadable Module APIs

Four API's are defined for loadable modules, facilitating hardware and protocol
abstraction. Using this loadable module system, the Asterisk core does not have
to worry with details of how a caller is connecting, what codecs are in use, etc.

 Channel API - the channel API handles the type of connection a caller is
arriving on, be it a VoIP connection, ISDN, PRI, Robbed bit signalling, or
some other technology. Dynamic modules are loaded to handle the lower
layer details of these connections.
 Application API - the application API allows for various task modules to
be run to perform various functions. Conferencing, Paging, Directory
Listing. Voicemail, In-line data transmission, and any other task which a
PBX system might perform now or in the future are handled by these
seperate modules.
 Codec Translator API - loads codec modules to support various audio
encoding and decoding formats such as GSM, Mu-Law, A-law, and even
MP3.
 File Format API - handles the reading and writing of various file formats
for the storage of data in the filesystem.

Using these API's Asterisk achieves a complete abstraction between it's core
functions as a PBX server system and the varied technologies existing (or in
development) in the telephony arena. The modular form is what allows Asterisk
to seamlessly integrate both currently implemented telephony switching
hardware and the growing Packet Voice technologies emerging today. The ability
to load codec modules allows Asterisk to support both the extremely compact
codec neccesary for Packet Voice over slow connections such as a telephone
modem while still providing high audio quality over less constricted connection
types. The application API provides for flexible use of application modules to
perform any function flexibly on demand, and allows for open developement of
 31

new applications to suit unique needs and situations. In addition, loading all
aplications as modules allows for a flexible system, allowing the administrator to
design the best suited path for callers on the PBX system and modify call paths
to suit the changing communication needs of a going concern.

3.2.2 Embedded System Feature Set

It is difficult to describe the full feature set of Asterisk due to the number of fairly
complex topics that are incorporated into the system: multiple VOIP channel
types, hardware interfaces, a scripting language, an API, modules, and more
features than can be addressed in this short article. To provide a brief
introduction to Asterisk's capabilities, I will show an example that creates a very
simple PBX with two extensions and voicemail on each. There will be no external
connectivity to this PBX; we will simply be able to call from one line to the other.
This would allow, as an example, two users to be in separate parts of the country
but they could ring each other's desk phones.

VoIP has been around for a while, but has been fairly restricted to high-end users
such as phone companies and large enterprise phone networks; only recently
has VoIP gained momentum with end users and smaller shops. There have been
a small handful of proprietary long-distance solutions for some time, but these
were closed-source systems that did not lend themselves to any extensions by
the OSS community. The push of VoIP technology closer to the grasp of the
Linux/*BSD end user or administrator can be attributed to a combination of low-
cost, high-speed bandwidth and a recent agreement to standardize on open
protocols for call delivery.

Within the last eighteen months, it has become evident that the protocol that will
be leading the industry for VoIP deployments is Session Initiation Protocol (SIP)
-- see RFC3265. SIP is a simple, text-based description protocol that uses
interactions similar to HTTP and SMTP in order for two systems to describe a
media stream (in our case, voice traffic) that needs to get from point A to point B.
The description includes authentication, caller ID information, media stream
parameters, and a variety of other header information that is needed to fully
qualify a call between two endpoints.

While there are other VoIP protocols supported by Asterisk (such as H323 and
MGCP) I will only describe SIP, as there are a growing number of phones and
software stacks that support SIP as a method for call description, and for the
beginner, SIP is easier to debug due to its use of plaintext headers.

3.2.3 Call Flow: Starting Out

A call comes in on one of several channels (SIP in our case) and is "destined" for
a dialed number. The Asterisk process first deals with the call via whatever
channel it came in on, and learns what to do with it in that manner, and into what
 32

context to send the call in extensions.conf. In our example, calls inbound from
both of our SIP phones are sent to the context from-sip, which is where we are
going to start matching the dialed numbers. The called number is translated into
a variable called ${EXTEN}, and we'll refer to this variable from now on when
talking about the number being dialed. It is implicitly used in any matching
statements, so you don't have to worry about specifying it elsewhere. However,
for ease of reference, we will use it in this article whenever we talk about the
number that has been called.

3.2.4 Contexts

Now that sip.conf has told our call what context to go to, the control is handed
over to the definitions created by the file extensions.conf. The extensions.conf file
works by defining various "contexts," which are clusters of dialed-number
matching statements. The context is the central building block of Asterisk, and,
loosely, is used as one might use a subroutine. Within a context are a number of
matching statements that perform match tests against the number being
processed. The call is passed through the comparison list until a match is found.

A context can have "special" extensions, which are pre-defined and are reserved
for special behavior. The most commonly used extension is h, which means
hangup, and allows your dial plan to execute certain routines at the completion of
a call.

3.2.5 Extension Matching

Each context has a set of extension matches, which determine what applications
should be triggered by the call, and how the call should be routed. Matching is
performed in numerically ascending order, which can be tricky if you have many
matches that are similar; in our example we have a very simple match list. The
matching examination is done on the digits following the => up until the next
comma. Each match definition has at least one "priority," which simply is a
number that tells the server in what order to execute the applications when a
match for the matching string is found. Priorities must be sequential whole
numbers, which sometimes leads to headaches if you discover you need to insert
an application at the top of a priority list.

Each line is in the format:

exten => extension,priority,application

Here's an example:

exten => 3334,1,Answer

exten => 3334,2,Playback(welcome-to-foo-inc)
exten => 3334,3,Wait(1)
 33

exten => 3334,4,Playback(the-date-and-time-is)

exten => 3334,5,DateTime

The above example will match any inbound calls sent to extension 3334 and play
back a short welcome followed by a verbalization of the date and time. As long
as the caller hasn't hung up, the next application will be run and the results
played into the channel.

To give an idea of how this works in our mini-phone system, imagine an inbound
SIP call is headed towards extension 2001 from extension 2000. Thus, $
{EXTEN} would be equal to 2001. Using our example sip.conf file (see below), it
shows that any calls coming from extension 2000 should be passed into the
context from-sip. When the call is passed into from-sip, the first match statement
compares ${EXTEN} against the string "2000". That isn't a match, so the
matching process jumps to the next numeric extension definition, which is
"2001". In this comparison, it is true that ${EXTEN} equals "2001" -- we have a
match! At this point, the priority 1 application is executed, which is "Dial".

If the calling channel still exists and has not been terminated at the end of priority
1, then priority 2 is executed, and so on. If there are no matches for ${EXTEN},
then the user will be sent an "Invalid Extension" result, and most likely will hear a
re-order tone (fast busy) that would be generated from their phone.

Wildcards can be used in extension mapping, and match strings beginning with
the underscore character (_), meaning that the following portions of the match
string include wildcard characters. Commonly used wildcards are N (digits 2-9), X
(any digit), . (any number of digits), and a variety of regular-expression matching
methods. A valid example of a wildcarded matching string might be exten =>
_301.,1,Dial(Zap/1/${EXTEN}), which would match any of the following: 3013,
3015551212, 301543*999.

Much more extensive comparisons can be applied to the matching behaviors:

caller ID of calling party, time of day, detection of fax modems, string matching,
and more can all be used to determine call flow.

3.2.6 Applications

After a match is made on ${EXTEN}, the applications start to be executed in the

order in which they are listed by their priority values. There are a huge number of
applications that are available, and additional applications are fairly easy to
integrate. There is even an application called AGI that links to external programs,
and there are Perl and Python libraries that allow for easy development of tools
external to the applications built into Asterisk.

The most-used application is called Dial, and that is the application that rings a
remote channel and then connects the two different channels together if there is
 34

an answer. The Dial application has some special abilities due to its multiple
responses. If a Dial application gets an answer on the remote channel, then the
two callers are bridged together and the call proceeds. After an answer, the only
options are for one or both parties to hang up. When a hangup happens, the Dial
routine exits with a non-zero status, and the priority list stops executing because
we have lost the call -- this is a normal call termination.

If the Dial application rings the remote phone for 20 seconds (specified by the ,20
in our Dial statement) but there is no answer, Dial will exit and the next priority
will be executed -- in our case, that next priority is a command to run the
Voicemail application, which sends the caller to the "unavailable" greeting for the
called party. If the Dial application gets a "busy" answer back from the remote
phone, or the remote phone is not on-line, then the Dial application does
something special: it adds 101 to the existing priority, and jumps to that priority.
In our case, this means priority 102, which sends the caller to the "busy" greeting
for the called party. Dial is the only application that has this special priority
incrementing ability, though there are priority control applications that can give
the administrator direct control to the priority, context, and extension such as
Goto, and more sophisticated versions such as GotoIf, which can be used to
evaluate expressions.

To get a list of applications, just type "show applications" at the command

prompt, and then "show application xxxx," where xxxx is the application for which
you want more information.

3.2.7 Prerequisites

Asterisk currently runs on Linux > 2.4.x (various flavors) and OpenBSD 3.3. The
OpenBSD version has not been tested thoroughly and should be considered
"alpha" at the time of this writing (June 2003).

A SIP-capable phone is required, such as a Cisco 7960 or 7940, SNOM, Pingtel,

or Grandstream. Alternately, you could get a software client for Windows such as
the free client from Xten or a Linux SIP phone like kphone. Configuring these
various SIP clients is outside of the scope of this article, but I will describe what is
required to make them work with Asterisk as far as SIP login data is required.

We would strongly suggest a "hardphone" to start with, especially if you are using
this as a demonstration platform. Anecdotal evidence strongly suggests that
nobody except the most hardcore road-warrior wants to talk on the phone
through their computer -- they want a handset that looks and acts like a phone.
Plus, the SIP hardphones are usually debugged quite well, as the vendors
cannot simply expect to roll out a "patch" to upgrade their customers without
extensive preparation, so I have found that the hardphones are generally more
reliable than softphones.
 35

Two phones or phone clients should have at least 80 kilobits of capacity each
back to the Asterisk server, as we will be using G.711 codecs that take up quite a
bit of bandwidth. There are other voice encoding methods that get as low as
about 4kbps.

A complete kernel source tree is required symlinked to /usr/src/linux since

Asterisk requires certain header files from the kernel to compile correctly. If you
are running OpenBSD, this is not required. You will need to have the following
packages installed to complete a full installation: bison, cvs, gcc, kernel-source,
libtermcap-devel, ncurses-devel, newt-devel, openssl096b, and openssl-devel.

3.2.8 H323 Client Configuration

Configure your H323 clients so that they have their SIP gateway set to be the IP
address of your Asterisk server. The usernames and passwords are contained
below in the h323.conf file -- the username is the extension, and the password is
listed in the secret= line for each extension. The configuration of the clients is
often half the battle of getting VoIP to work, but once your particular client is
understood, it normally becomes plug-and-play to add more phones. Your client
must support registering with the H323 gatekeeper or Asterisk Server -- I would
suggest telling your client to register every 15 seconds or so during your
experiments, to keep things re-registering quickly after Asterisk restarts. Later,
you can take this back up to 1000 seconds or higher.

3.2.9 Designed System Architecture

To bring out design layout of our proposed scenario we have created some views
with the help of which we are going to implement our capabilities set.

Figure 3.1 – Asterisk Architecture

 36

Figure 3.2 – Asterisk – A big picture

Figure 3.3 – Asterisk – Black Box

 37

Figure 3.4 – Conventional Softswitch Network

Figure 3.5 – Where does Asterisk fit in

 38

Figure 3.6 – Example 1 * 1 PBX

Figure 3.7 – Example 8 * 16 PBX

 39

Figure 3.8 – Small Medium Businesses

Figure 3.9 – High Density IVR Conferencing

 40

Chapter 4: IMPLEMENTATION

We are giving here the description of the implementation stage of the software
development. The purpose of the development phase of a system is to transform
its design into executable computer software, which may be tested and
implemented as a new system. This chapter gives the implementation details of
the major modules of the proposed system. It describes what a module does and
what major tools are used to implement its functionality.

4.1 Techonology

Technologies selected for the proposed system are:

 C/C++
 Linux VoIP Telephony

4.1.1 C/C++

4.1.1.1 Changes in Existing System

The existing system does not support a lot of the functionalities required of a
PBX which were integrated/ developed by us and are listed below:

1. Peer-to-Peer calling using any standard codec.

2. Asterisk, GnuGK call bridging.

3. Dynamic registration

4. Voice mail with e-mail support

5. Conference room

6. Integration of Asterisk/ GnuGK with our GoC’s.

4.1.2 Linux VoIP Telephony

 Knowledge of work environment compatibility

 C/C++ IDE knowledge

4.2 Steps in Developing the System

The steps that we have taken in developing the system are given below:
 41

 In depth study into working of Asterisk

 In depth study into working of GnuGK

 In depth study into working of GoC’s

 Compatibility programming of Voice mail with GoC

 Compatibility programming of Conference room with GoC

 Compatibility programming of Asterisk with GoC

 Integration of GnuGK with Asterisk

 Adding support for G711uLaw in Asterisk for GoC

 Adding support for G729 in Asterisk for GoC

 42

Chapter 5: TESTING & EVALUATION

Testing is a set of activities that can be planned in advance and conducted

systematically. A software testing strategy is the road map for a developer and
quality assurance for both the organization and the user. It is a hypercritical
component of software quality assurance and represents a review of
specification, design and coding.

5.1 Objective of Testing

The two main objective of testing are as follows:

1. Search for errors

2. Rectification of errors

5.2 Testing Sessions

Test # Expected / Actual Action Expected Result Actual Output Remarks

1 GnuGK Start Up Normal start up Normal start up

without any run-time without any run-time
errors errors

2 Asterisk Start Up Starts Up and all Starts up and all

modules are loaded modules are loaded
without any errors without any errors

3 Asterisk / GnuGK Asterisk displays Asterisk displays

integration at run-time using GnuGK as using GnuGK as
GateKeeper GateKeeper
 43

4 IP Phones send GnuGK registers IP GnuGK registers IP

registration request to Phones and sends Phones and sends
GnuGK acknowledgement acknowledgement

5 Receiver of IP Phone is Dial tone is heard Dial tone is heard

picked up

6 User dials invalid GnuGK goes to GnuGK goes to

extension Asterisk, doesn’t Asterisk, doesn’t find
find number, gives number, gives busy
busy tone tone

7 User dials valid extension GnuGK goes to GnuGK goes to

Asterisk, gets IP of Asterisk, gets IP of
dialed number, calls dialed number, calls
the required the required
extension extension

8 User leaves voice mail for Asterisk e-mails the Asterisk e-mails the
someone message to the user message to the user
for whom the voice for whom the voice
mail has been left mail has been left

9 User 1 leaves voice mail Asterisk asks for his Asterisk asks for his
for User 2, user 2 has not password and plays password and plays
configured himself to all recorded all recorded
receive voice mail via e- messages messages
mail and tries to retrieve it
using his IP Phone by
dialing out to Asterisk’s
voice mail control system
10 Asterisk administrator uses On going calls are On going calls are
Asterisk CLI to forcefully dropped dropped
drop call
 44

11 User dials out a PSTN GnuGK sends the GnuGK sends the
number from his IP Phone request to Asterisk request to Asterisk
from where Asterisk from where Asterisk
routes the call routes the call
through its Digium through its Digium
card interface onto card interface onto
the PSTN network the PSTN network

12 GnuGK is switched off IP Phones give busy IP Phones give busy

tone and no calls tone and no calls (IP-
(IP-to-IP or IP-to- to-IP or IP-to-PSTN)
PSTN) can be made can be made

13 Asterisk is switched off No calls (IP-to-IP or No calls (IP-to-IP or

IP-to-PSTN) can be IP-to-PSTN) can be
made made

14 PSTN to Asterisk call is Call is received at a Call is received at a

made specific IP Phone specific IP Phone
connected to the connected to the
Asterisk / GnuGK Asterisk / GnuGK
server system server system

Table 5.1 – Testing Sessions

5.3 White Box Testing

Also known as glass box, structural, clear box and open box testing. A software
testing technique whereby explicit knowledge of the internal workings of the item
being tested are used to select the test data. Unlike black box testing, white box
testing uses specific knowledge of programming code to examine outputs. The
test is accurate only if the tester knows what the program is supposed to do. He
or she can then see if the program diverges from its intended goal. White box
testing does not account for errors caused by omission, and all visible code must
also be readable. White box testing, sometimes called glass box testing is a test
case design method that uses the control structure of the procedural design to
derive test cases.
5.4 Flow Graph for Call
 45

5 7

8
9
1 1
2 0
1 1
1 3
1
1
4

5.2.4 Cyclomatic Complexity

Edges = 13
Nodes = 14
Cyclomatic complexity = edges – nodes + 2 = 13 – 14 + 2 = 1

The seven independent paths are given below:

Path 1: 1-3
Path 2: 1-2-4-5
Path 3: 1-2-4-7
Path 4: 1-2-4-6-8-12
Path 5: 1-2-4-6-8-11
Path 6: 1-2-4-6-9-10
Path 7: 1-2-4-6-9-13-14
 46

5.2.5 Test Cases

Path Test Expected Actual Result Remarks

Result

1-3 Picked up Dial tone No dial tone

phone

1-2-4-5 Dialed Ring back Number does

number tone not exist

1-2-4-7 Dialed Conference Entered into

number room conference
room

1-2-4-6-8-12 Dialed Voice mail Voice mail

number no stored for stored for
one picks up retrieval retrieval

1-2-4-6-8-11 Dialed Voice mail Voice mail

number no sent via email sent via email
one picks up

1-2-4-6-9-10 Dialed Voice is heard Voice is not

number and on both ends heard on both
called party ends
picks up
1-2-4-6-9-13- Dialed Voice is heard Voice is heard
14 number and on both ends on both ends
called party
picks up
Table 5.2 – Test Cases

5.5 Black Box Testing

Also known as functional testing. A software testing technique whereby the

internal workings of the item being tested are not known by the tester. For
example, in a black box test on a software design the tester only knows the
inputs and what the expected outcomes should be and not how the program
arrives at those outputs. The tester does not ever examine the programming
code and does not need any further knowledge of the program other than its
specifications.
 47

The advantages of this type of testing include:

 The test is unbiased because the designer and the tester are independent
of each other.
 The tester does not need knowledge of any specific programming
languages.
 The test is done from the point of view of the user, not the designer.
 Test cases can be designed as soon as the specifications are complete.

The disadvantages of this type of testing include:

 The test can be redundant if the software designer has already run a test
case.
 The test cases are difficult to design.
 Testing every possible input stream is unrealistic because it would take a
inordinate amount of time; therefore, many program paths will go
untested.

Chapter 6: REFERENCES
 48

1. IP Telephony with H.323: Architectures for Unified Networks and

Integrated Services by V. Kumar, Markku Korpi, Senthil Sengodan, Vineet
Kumar

2. PBX Systems for IP Telephony by Allan Sulkin

3. Delivering Voice over IP Networks, 2nd Edition by Daniel Minoli, Emma

Minoli

4. Big Book of IP Telephony RFCs by Pete Loshin