Practical VoIP Using VOCAL

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We wrote this book to find a new set of motivated individuals to take our software, twist it into something new, and create their own important breakthroughs. Are you driven by the desire to discover how things work and the challenge to make them work better? If so, this book is for you.

This book, along with the Vovida.org web site (http://www.vovida.org), provides tools and knowledge to help you build a phone system, find out how it works, and then tinker with it to make it better. The source code and suggested operating system, Linux, are both open source. You can look "under the hood" down to the base code and protocol stack levels and discover not only how the system works, but also how common problems are being worked out in the development environment. We're hoping that you will be inspired to take this system to another level by implementing a feature or functionality that nobody has ever thought about before.

Maybe you have already devoted your professional career to the telecom field and have suffered through the glacial pace of change that characterizes the Public Switched Telephone Network (PSTN). Here is your opportunity to try out an idea that you can demonstrate after a few days of coding. Maybe you work as a software developer in another sector and have a new idea that would normally be discredited by telecom professionals. Here is your opportunity to prove them wrong. Maybe you have a general interest in technology and thought it would be cool to play around with Voice over IP (VoIP). Our invitation to you, to tinker with this system, is as sincere and open as it is to the professionals.

The software described in this book, the Vovida Open Communication Application Library (VOCAL), is not just another Internet Protocol (IP) softphone that connects to others over the Internet, but a full-blown system complete with call control, operations service support, and features. This system is scalable and limited only by the quantity and quality of the computing hardware and network resources at your disposal.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book, along with the Vovida.org web site (http://www.vovida.org), provides tools and knowledge to help you build a phone system, find out how it works, and then tinker with it to make it better. The source code and suggested operating system, Linux, are both open source. You can look "under the hood" down to the base code and protocol stack levels and discover not only how the system works, but also how common problems are being worked out in the development environment. We're hoping that you will be inspired to take this system to another level by implementing a feature or functionality that nobody has ever thought about before.

Maybe you have already devoted your professional career to the telecom field and have suffered through the glacial pace of change that characterizes the Public Switched Telephone Network (PSTN). Here is your opportunity to try out an idea that you can demonstrate after a few days of coding. Maybe you work as a software developer in another sector and have a new idea that would normally be discredited by telecom professionals. Here is your opportunity to prove them wrong. Maybe you have a general interest in technology and thought it would be cool to play around with Voice over IP (VoIP). Our invitation to you, to tinker with this system, is as sincere and open as it is to the professionals.

The software described in this book, the Vovida Open Communication Application Library (VOCAL), is not just another Internet Protocol (IP) softphone that connects to others over the Internet, but a full-blown system complete with call control, operations service support, and features. This system is scalable and limited only by the quantity and quality of the computing hardware and network resources at your disposal.

VOCAL is the software that enables a core network to support VoIP . On a scaled-down, single host in our lab, VOCAL has successfully supported more than 40 calls per second (cps), which translates into supporting about 72,000 users, depending on the available memory and the users' calling frequency. On a distributed network of 31 computers, this same software, downloaded from our community web site,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When we started designing VOCAL, we had three primary goals in mind:

Build a distributed architecture.
Build a system that was scalable.
Ensure no single point of failure.

A distributed architecture suited our aim to open source VOCAL as it provided components that developers from the community could build upon or build into their projects. Scaling the system meant assigning one type of server, which became known as the Marshal server, with the task of being a single point of contact for the subscribers and enabling duplicates of this server to be added to the system as the subscriber population grew. Our original idea was to achieve load balancing by assigning each additional Marshal server with a specific population of subscribers. Our original plan also called for a multihost system with redundancy for all call control servers to avoid a single point of failure.

In its most basic form, a Voice over IP system is a set of data combined with the capacity to process calls. There is persistent data , such as the provisioning databases of users and server configurations, as well as the dynamic data that is potentially different for each call. The call control servers handle the following types of data:

Registration: When a user connects to her service provider, the system needs to add her address to a list of active endpoints.
Security: The system requires a perimeter to allow qualified users in and keep intruders out. Security is multifaceted and includes, for example:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We believe that, as a result of our efforts, interoperability will be taken to new, higher levels, and the total cost of ownership of communication systems and solutions will be greatly reduced. In this end state, consumers will be the big winners, as they will be provided with the capability of reaching anyone, anywhere, anytime in the world in more ways, and for less money, than ever before. While this may not lead to immediate changes in the United States, where the investment into the PSTN over the past 100 years is widely estimated at $1 trillion, VoIP will contribute to providing communication services to areas of the globe where access to the PSTN is difficult and expensive. Third-world economies whose modernization has leapfrogged over the industrial revolution will continue leaping toward wireless systems that can provide services to far-flung customers at a fraction of the cost of traditional landline networks. Marshal McLuhan once spoke of a global village; will the new wave of communication technologies reduce our world to a global house?

Enabling this type of interoperability extends beyond working with other vendors; we are looking for opportunities for a broader range of implementations of our software. If you need assistance or if you want to participate in our community, you can subscribe to the mailing lists available on Vovida.org. While we may not be able to re-create every possible scenario in our lab, we are more than willing to help anyone who is experiencing trouble to the best of our ability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We're providing you with a functioning open source application that has been available on Vovida.org since March 2001. This code has been tested in our lab and in the labs of our community members all over the world. The Voice over IP community needs fresh ideas and new features. The ball is in your court.

The first thing that we suggest you do is go to our community web site , http://www.vovida.org, read through the site's resources, and sign up for the mailing lists. These lists give you access to the developers, and even though they may not be able to offer individual support like a help desk, they can point you toward information that may help you achieve more success with your system.

Besides VOCAL, the Vovida site also offers the following open source protocol stacks , each with its own mailing list:

Session Initiation Protocol (SIP)
Media Gateway Control Protocol (MGCP)
Real-time Transport Protocol (RTP)
Common Open Policy Service (COPS)
Telephony Routing over IP (TRIP)
Remote Authentication Dial-In User Service (RADIUS)
Real-time Streaming Protocol (RTSP)

Before you load the software on your PC, you should also flip through this book to get a better idea about what the VOCAL system is all about. Then, when you're ready, install VOCAL and start playing with it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter provides instructions about installing a phone system on a PC running the Linux operating system. If you prefer to install VOCAL on a machine running Sun Solaris , those instructions are available from the VOCAL home page at Vovida.org (http://www.vovida.org). From these instructions, you will be able to install VOCAL, configure a couple of IP telephony devices, and make calls to other phones over an IP network. Your IP telephony devices can be softphones running on PCs, analog phones plugged into translating devices, IP telephone sets, or any combination of these. If you don't have any IP phone devices, VOCAL provides a softphone that is useful for testing purposes, and most of the instructions in this chapter are directed toward using this device. Once you have your single-host system set up, you can use it as a hobby box at home, a test machine in a lab, and/or a demonstration machine at a trade show.

VOCAL has been designed to run on either a single PC or a multihost network. This can create some confusion in the networking terminology used to describe the system. As VOCAL is a distributed system, the term server is used to describe software modules, and the term host is used to describe the machines where those servers reside. In large networks, it is common for one type of server to be duplicated onto many hosts for redundancy. See Chapter 3 for more information about loading VOCAL onto larger systems.

This is not a user guide for Linux . If you are unfamiliar with Linux, you should look through some of the user guides and Frequently Asked Questions (FAQs) available on the Web. Some places to begin looking are http://www.linux.org and http://www.linuxdot.org/nlm.

You don't need to be a Linux guru to run VOCAL. What you need is some familiarity with Unix, some knowledge about commonly used shells, such as bash, and basic experience with installing and running software applications in the Linux environment. If you intend to contribute code to the VOCAL project or use the VOCAL code to build your own application, you should be familiar with the Concurrent Versioning System (CVS,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The requirements in the following sections are suggested configurations to help you achieve satisfying results from your installation. VOCAL may run on machines with less capacity, but slow processors or lack of available memory will hinder the system's performance.

Your machine can be a basic off-the-shelf unit from your local PC retailer. In order to run VOCAL, it should have at least the following attributes:

400 MHz, Intel Pentium II PC processor
128 MB of RAM
1 GB of hard disk space

To run a basic test system that doesn't make external calls, you don't need a gateway or an IP phone. VOCAL comes with all the components required to test the signaling between User Agents as calls are set up or torn down.

Later in this chapter, when we discuss adding users, you will need some or all of the following additional equipment depending on how much functionality you desire:

Two or more IP phone devices. They can be PCs loaded with softphones or IP phones.
A standard sound card.
Ethernet cable and hub to connect the IP phone devices to the host machine.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before the VOCAL system can be installed onto your machine, you must have the following software installed and running:

One of the following versions of Linux, Red Hat:
- Version 6.2; kernel: 2.2.14; compiler: g++ 2.91.66
- Version 7.1; kernel: 2.4; compiler: g++ 2.96
- Version 7.2; kernel: 2.4.9; compiler: g++ 2.96
Apache server (we tested with the version that came with Red Hat 6.2, Version 1.3.19-5)
Java Runtime Environment (JRE) Version 1.3.1_01 or higher
Any browser that supports the JRE version that is currently being offered by Sun Microsystems (see http://java.sun.com)

We tested with JRE Version 1.3.1_01. New versions of this software come out on a regular basis. Check with Vovida.org to see which versions are being supported today.

This section tells you how to acquire and install these products if you don't already have them. If you are familiar with Linux and Apache and have JRE Version 1.3.1_01 or later loaded on your machine, skip ahead to "Verifying Networking Requirements."

This material is being written in the fall of 2001 with respect to the current versions of VOCAL, Red Hat, and the JRE. By the time you read this, newer versions of these packages will be available, and if you are working with a later version of VOCAL than 1.3.0, different version numbers of the supporting software may be required in some of the following commands. We also have no control over the availability of either JRE 1.3.1_01 or Red Hat 7.1. As always, check the Vovida.org web site for information about the most current versions of VOCAL and the supporting software packages.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

VOCAL software is available on the Vovida.org web site as a Linux source file, vocal-1.3.0.tar.gz. The tarball is more than 21 MB in size and, depending on your connection speed, downloading this file could require a few minutes, a few hours, or, hopefully not, a few days. To find this file on Vovida.org, go to the VOCAL home page and look for the link under Source Code.

While we were completing the final draft of this book, Version 1.4.0 of VOCAL was released on Vovida.org. Version 1.4.0 gives you the option of installing VOCAL without a Java requirement: using a simple HTTP Provisioning interface to add users instead of the GUI described in Chapter 4. There are also RPM files available that enable you to bypass the compiling stage of the installation.

Go to Vovida.org for more information about installing Version 1.4.0 along with more commentary about some of the other changes found in that release. The majority of the effort that went into Version 1.4.0 was directed towards simplifying the installation process. No significant changes were made to the servers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once you have finished downloading the tarball, you need to untar it, recompile VOCAL, and run the deploy script before you can test it.

All of these steps should be done as root.

Extract the tarball, vocal-1.3.0.tar.gz, into a temporary directory on your machine.

To untar the tarball, as root, type:

               tar -xvzf vocal-1.3.0.tar.gz

After untarring this file, we suggest deleting vocal-1.3.0.tar.gz to free up some space.

The source code comes uncompiled, because if we offered it as binaries, the file size (267.8 MB) would be too large for most of our community to download over the public Internet. By the way, if you have both the JRE RPM file and the VOCAL tarball on your machine, you might want to move them to /tmp or delete them to free up some disk space for compiling.

Section 2.4.2.1: Optimizing the code

In the instructions, we recommend running make all with the CODE_OPTIMIZE=1 option. Running the make command with this option passes the -O option to the C++ compiler, which is shorthand for "enable optimization." This works on almost every C or C++ compiler that has a command-line interface.

The gcc compiler supports the -O, -O0, -O1, -O2, and -O3 options for different levels of optimization. If you were to compile VOCAL with CODE_OPTIMIZE=2, the command would pass the -O2 option, which is a GNU C++-specific variant of -O that means "optimize more than -O." Refer to the documentation for your compiler for more information about its optimization options.

We don't support compiling VOCAL with CODE_OPTIMIZE=2, although some people in the community like to compile it this way.

By default, make all compiles with debug turned on. If you choose to run make all and make allinone without CODE_OPTIMIZE=1, the command will not pass -O or -O2 to the compiler and therefore will not optimize the code. Nonoptimized code runs slower than optimized code, but it usually compiles more quickly and generally produces more straightforward code, which is helpful when debugging. In addition, we enable debugging symbols by passing

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The SIP User Agent may not be the most exciting application that you've ever run on your machine, but it is satisfying to see the call signaling working. You won't be able to talk or hear any audio during this test; this is only meant to prove that your installation is good and ready for more users. Once you get past this stage and start making real calls with a phone or a sound card, you will experience some of the excitement that we've experienced at Vovida.

The allinone deploy script has provisioned two User Agents (UAs)—1000 and 1001—for testing. From your Linux desktop, launch two terminal panels, and then size the panels so that they do not overlap each other. After submitting registration commands, these panels will become your two test UAs.

The configuration of the UAs is controlled by their respective configuration files. For these test units, the deploy script has created configuration files with names that contain the local numbers; for example, the file that controls ua1000 is called ua1000.cfg. See Appendix A for more information about editing these files.

Section 2.5.1.1: Registering ua1000

In the first panel, type:

                  cd /usr/local/vocal/bin

Press Enter, then type:

                  ./ua -f ua1000.cfg

The following appears:

Ready
01/09/22 14:46:51 Registration OK
Ready

This means that ua1000 has successfully registered with the Registration server. In VOCAL, the Redirect server acts as the SIP Registration server. For a diagram of how this signaling is processed, see Chapter 8. For an explanation of how the Redirect server was built, see Chapter 12.

If you have either a sound card or an Internet phone card from Quicknet (http://www.quicknet.com) installed in your host, you can run the UA with the -s option for sound (./ua -s -f ua1000.cfg

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

First, you must ensure that the Java plug-ins are in the correct location for use by provisioning . Set the environment variable for the NPX_PLUGIN_PATH to the location of ns4. With JRE 1.3.1_01, this path was:

            /usr/java/jre1.3.1_01/plugin/i386/ns4

Finally, launch Netscape (or your favorite browser, providing it supports JRE 1.3.1_01 or later).

Your browser appears. If you are using Netscape, you can check the status of your plug-ins by typing the following into the location field:

            about:plugins

You should see an obvious reference to JRE at the top of the listing.

You will need your browser to provision more users and servers to your system. To test your access to provisioning , type the following URL into the browser's location field:

            http://<hostname>/vocal/

A simple, text web page appears with the following title and menu:

VOCAL Configuration for <hostname>
Choose one:
. Provisioning
. System Status
. User Configuration

If this appears, you can reduce or close your browser for now. We have made it possible to test your VOCAL installation without having to learn about the provisioning screens. If you would like to learn about the Provisioning server, go to Chapter 4.

For the time being, you can test your installation with the two test users that the deploy script has provisioned for you from the command-line interface.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This is not as complex as you might think. All you have to do is copy some files from your allinone machine to another host. Besides the UA files, you will need the sound files from the /vocal1.3.0/sip/ua/Tone directory to enable dial tone and ring-back. In our lab, we used cheap headsets and microphones. The UAs by themselves support only the free G.711 codec .

These instructions show you how to distribute the UAs over additional hosts. See Chapter 3 for information about distributing VOCAL's servers over several hosts.

The simplest setup involves two Linux boxes running the same version of Linux Red Hat . To hear your call, you need a basic sound card and some form of microphone and speaker combination for both machines.

On the remote machine, from /usr/local, type mkdir vocal and from vocal, mkdir bin.
From /usr/local/vocal/bin, copy the UA and ua1000.cfg files to the /usr/local/vocal/bin directory on the other machine.
From /usr/local/vocal1.3.0/sip/ua, copy the complete Tone directory to the same directory on the other machine. Remember, /usr/local/vocal contains the binaries; /usr/local/vocall.3.0 contains the source code.
Following the instructions from the earlier section, "Testing Your Installation," register both users and make calls.

If you have a broadband Internet connection with a fixed IP address, you can send the ua and Tone files to someone else who also has broadband and is running the same version of Linux Red Hat. As this involves making a call over the Internet, the remote user will have to make a small change to his ua1001.cfg file.

Using a favorite text editor, make this change for the remote user:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As far as your network is concerned, adding a User Agent is much the same as adding any other Ethernet device. You need to configure an IP address, the net mask, and the address of the Domain Name Server (DNS). Normally, you would not have a DNS server at home; you would use the address of your ISP's DNS server.

You will also have to configure a default proxy—use the IP address of the UA Marshal server. As for your username, local numbers such as 1000 and 1001 are valid. Passwords are unnecessary unless you are testing digest authentication .

The following provides more detailed information about running two UAs in test mode.

Section 2.8.1.1: Configuring two UAs

The ua.cfg file is stored in /usr/local/vocal1.3.0/sip/ua/SampleConfigFiles; see Appendix A for a completely annotated copy of the file. Configure two SIP UAs, both with identical settings except for the following:

For ua1000:

Device_Name             string          /dev/phone0
User_Name               string          1000
Display_Name            string          Phone
Pass_Word               string          test
Local_SIP_Port          string          6060

Save the ua.cfg file for ua1000 as ua1000.cfg.

For ua1001:

Device_Name             string          /dev/phone1
User_Name               string          1001
Display_Name            string          Phone
Pass_Word               string          test
Local_SIP_Port          string          7060

Save the ua.cfg file for ua1001 as ua1001.cfg.

If you want to create more user agents, you will need to provision the new users; this is discussed later in this chapter.

Section 2.8.1.2: Launching two UAs

The options for running the UAs are as follows:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section describes how to start, restart, or stop VOCAL on a deployed system.

There are three methods for starting, stopping, and restarting servers:

Using the SNMP GUI (as explained in Chapter 17)
Using vocalstart
Using direct command-line instructions

Section 2.9.1.1: Using vocalstart

The syntax for restarting, starting, or stopping is:

/usr/local/vocal/bin/vocalstart [command] [server type or port number]

where:

[command] can be restart, start, or stop.
(Optional) [server type] can be rs, ms, fs, js, cdr, net, vm, pd, or hs:

rs = Redirect server
ms = Marshal server
fs = Feature server
js = JTAPI Feature server
cdr = Call Detail Record server
net = Network Management Station
vm = Voice Mail server
pd = Policy server
hs = Heartbeat server
(Optional) [port number] is the port number used by the server.

Some examples of this command in use:

This starts all VOCAL servers:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Since the summer of 2000, we have used our internal trial system as an office phone system. When we were working at Vovida Networks, just about everyone had a Cisco 7960 IP phone at their desk and had stored their analog phone away in a drawer for emergency use only. We liked to refer to our use of our development project for practical purposes as "eating our own dog food." This chapter speaks from our experience: we've been there, and we want to take you with us.

The instructions in Chapter 2 covered setting up a single-host phone system and running IP phones. This chapter covers how to run different servers from different hosts after setting up the allinone system.

There are three phases to setting up an internal trial system:

Configuring a gateway to permit calling to and from the PSTN: We will discuss configuring dial peers and show the complete configuration listing for a Cisco 5300 gateway for our setup as it was at Vovida Networks.
Deploying VOCAL onto a distributed, redundant network: We will give you an example of how to distribute VOCAL over a small system. You can extrapolate those instructions to match the system size and server distribution suggested later in the "Distributed Hosting Guidelines" section.
Provisioning your users: Provisioning users was demonstrated in Chapter 2 and is discussed in greater detail in Chapter 4.

Before we talk about expanding your deployment, we need to make a few remarks about some basic concepts of telephony.

While we use VoIP phone sets and systems in our offices, out in the real world most people still use the traditional phone system. Therefore, before we can order pizza or call our moms, we have to make our systems talk to the Public Switched Telephone Network (PSTN). Fortunately, many different gateways are available in today's market that translate IP packets into signals that the PSTN understands. The tricky part is configuring the gateway to make sure that the meaning of the messages doesn't get lost in the translation. This chapter shows you how to configure a Cisco gateway.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

While we use VoIP phone sets and systems in our offices, out in the real world most people still use the traditional phone system. Therefore, before we can order pizza or call our moms, we have to make our systems talk to the Public Switched Telephone Network (PSTN). Fortunately, many different gateways are available in today's market that translate IP packets into signals that the PSTN understands. The tricky part is configuring the gateway to make sure that the meaning of the messages doesn't get lost in the translation. This chapter shows you how to configure a Cisco gateway.

We are familiar with the PSTN as it exists in California; however, despite the international following that VOCAL has received, we have not had the opportunity to test with phone systems from other regions of the world. For those who make up our international community of developers, we hope that you can take our examples of configuring equipment for use with the PSTN and make the necessary adjustments to match the requirements of your local phone system. We would also welcome additions to Vovida.org Faq-o-matic and mailing lists discussing IP/PSTN connectivity issues from different parts of the globe.

Gateways link the PSTN to IP networks. They can take a VoIP call from a network interface and put it out onto a PSTN interface such as analog, Integrated Services Digital Network (ISDN), or Signaling System 7 (SS7). Gateways also enable incoming calls from the PSTN to be sent to the IP network.

When we talk about analog signaling , we're referring to a "dumb" phone set sending dual-tone multifrequency (DTMF) tones to a central office for interpretation and routing. There are two flavors of analog signaling: Foreign Exchange Office (FXO) and Foreign Exchange Station (FXS). The FXO port is offered on standard analog phone sets and provides an interface to the central office to permit calling out to the PSTN. The FXS port provides voltage, dial tone, and ringing and connects to a phone to enable it to make and receive calls but does not connect to the central office. For example, a Cisco ATA 186 Analog Telephone Adaptor has two FXS ports that you can plug phones into and an Ethernet port that you can connect to the Internet.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At its peak, our old office had about 60 people using the internal trial as their phone system. In terms of capacity, we could have handled all the office phone traffic through a single host. There were only five or six people who might have been considered power phone users. The rest could have been considered light users. Therefore, if we had been running a single host, capacity would not have been an issue.

The issue would have been availability. Although Linux is a stable operating system, to ensure system availability, we needed to build redundancy into the system.

A truly redundant network has no single point of failure within its system. For phone systems, the goal is to achieve what is known as carrier class reliability , in which the system is up and running 99.999% of the time. Another term used to describe this is five nines reliability. The difference between a system being 99.999% or 99% reliable translates into a potential downtime of just over 5 minutes compared to 3.5 days over an average year.

Availability is measured by:

(Total User Time - Total User Outage Time) x 100 / Total User Time

In this equation, Total User Time is equal to the total number of end users multiplied by the time that transpires during the reporting period.

Some organizations prefer to measure availability in Defects Per Million (DPM), which is measured by:

Total User Outage Time x 1,000,000 / Total User Time

In this equation, Total User Outage Time is equal to the number of end users multiplied by the time that transpires during the reporting period.

Another benefit of a redundant system is that it is usually easier to scale into a larger configuration than a nonredundant system is. System architects like to plan for redundancy early in their development because redundancy is difficult to add later when the system is operating. As a system grows to match a growing demand for capacity, it can be made more valuable if adding hosts also increases the system's availability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A wide variety of gateways is offered by a wide variety of manufacturers including Lucent, Nortel Networks, Sonus, and Cisco Systems. If you don't have access to a gateway, you can skip this section and go straight to the later section "Installing VOCAL onto a Multihost System."

In our lab, we use a Cisco 5300 gateway for its capacity: it can connect to four T1 lines. Other Cisco IOS gateways, such as the 26xx, 36xx, 5350, 5400, and 7200, have similar instructions. For official hardware and software configuration instructions, we suggest that you contact the manufacturer of whatever gateway you choose to install into your system. What we provide next is a description of how we configured the software on a Cisco 5300 gateway to match our requirements. At press time, Cisco recommended using IOS Version 12.2(2)XB.

We expect you to use the manufacturer's guides to help you set up your gateway and to make it available on your network. In this section, we will show you how we specifically configured a Cisco 5300 to work with VOCAL. Most of that work involved configuring dial peers. Dial peers make more sense with some background information about dial plans.

Section 3.3.1.1: Dial plans

A dial plan is a tool used by phone systems to make routing decisions. In its simplest form, a dial plan tells the routing software where to send calls that are not addressed to local subscribers. In VOCAL, dial plans consist of two parts, the key and the contact information.

The key is a variable that can match patterns of dialed numbers such as 7- or 10- digit dialing for North America or variable-length phone numbers in Europe. Dial plans can also signal the routing software that all numbers that start with 9 are intended for the PSTN. The keys are sorted in the order that the routing system searches for a matching variable.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As Table 3-1 showed, VOCAL is scalable and, in a network with 26 hosts or more, can support many thousands of users. Our recommended method for deploying a multihost system is to get VOCAL running on one host as shown in Chapter 2. Then, using your preferred file transfer routine, copy the binaries to the other hosts, edit a configuration file, reprovision some of the servers, and then restart VOCAL. Here is an example set of instructions that uses scp to copy the binaries from host to host. If you prefer to use copy or ftp, it's up to you.

Assume that there is a network with four hosts named Host1, Host2, Host3, and Host4. In the instructions, we have used the abbreviations for the different server types as they appear in the configuration file.

Table 3-2 provides a list of abbreviations found in the /usr/local/vocal/etc/vocal.conf file and their definitions.

Table 3-2: /usr/local/vocal/etc/vocal.conf abbreviations and definitions
Abbreviation	Definition
`snmptrapd`	Simple Network Management Protocol trap daemon (see Chapter 17)
`netMgnt`	Network Management Station (see Chapter 17)
`vmserver`	Voicemail server (see Chapter 14)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The difference between the system that you just tested and a full-blown trial system is simply scale. You need to provision the servers over a network that suits your needs (review Table 3-1), provision your users (see Chapters 2 and 4), configure their phone sets, and, if you want, run the Network Management utilities (see Chapter 17 and the readme files). If you have more than one gateway, you need to provision a separate Gateway Marshal server for each one and add each of these Marshal servers as separate contacts for each digital dial pattern that is intended for connecting to the PSTN (see Chapter 5).

This is pretty exciting stuff. In the summer of 2000, when we first started documenting our installation instructions, we compiled and deployed VOCAL onto a network of hosts and SIP/PSTN gateways. We then provisioned two IP phone sets, made them call each other, and then called home to our spouses.

Calling home from a phone system that we had just built was enormously satisfying. If you think about most people who work in industrial environments such as large-scale bakeries or automobile factories, many individuals receive rewards for a job well done, but they rarely, if ever, receive the satisfaction of participating in the entire assembly process from the component stage up to the completed end product. If you can imagine what it would be like to drive home in a new car that you had made at work that day, you can imagine how we felt the first time we got VOCAL working to the point where it could make real phone calls. The phrase, "Hi, Honey, I'm calling you from my brand-new phone system," has, for us, taken on a permanently new meaning.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Provisioning is a term used to describe the processes and procedures used for entering data into a phone system. The make allinone script that you read about, and perhaps ran, in Chapter 2 provisions system configuration data to the VOCAL servers. We are currently working on an automated process to add users to the system; at this time, however, they have to be entered by hand, one-by-one.

VOCAL was built with ISPs (Internet Service Providers) and ASPs (Application Service Providers) in mind as the installing customers. These organizations have on-site staff trained in managing user accounts and IP networks. Normally, personnel with different skill sets handle each of these responsibilities; therefore, the provisioning screens are organized into two major divisions, one for the administrators and the other for the technicians. This chapter covers the administrators' screens. Chapters 5 and 6 cover the technicians' screens.

While administrators can enter usernames and data into the system, individual users may also manage certain aspects of the accounts, such as blocking calls to specific phone numbers and telling the system where to send forwarded calls. These users could be individual subscribers or employees of subscriber organizations. This chapter provides a tour of the administrator screens and includes a description of the screen that end users see when they look up their account configuration through their web browsers.

The focus of this chapter is on the structure of the GUI environment, with only a few procedural instructions. We encourage you to play around with the different fields. If your aim is to add users to the system without assigning any attributes or permissions, all you need to do is add new users and fill in the Name field with a local number, such as 1000 or 1001. Everything else is optional.

This section provides instructions about adding users without going into great detail. The detail is provided by the remainder of the chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section provides instructions about adding users without going into great detail. The detail is provided by the remainder of the chapter.

Before you can run the Provisioning GUI, VOCAL must be compiled and installed, and, at least, the Provisioning server must be running. You must also have the Java Runtime Environment (JRE) Version 1.3.1_01 or later installed with the NPX_PLUGIN_PATH environment variable set and the Apache server running. See Chapter 2 for more information about all of these.

To run the Provisioning server, you can either run vocalstart to start VOCAL, as shown in Chapter 2, or, for testing purposes, you can run the Provisioning server by itself.

The make allinone script ends with VOCAL running. So, if you just finished your installation and you haven't stopped VOCAL, it's running.

If you want to run the Provisioning server by itself, from /usr/local/vocal/bin, type:

               pserver -vLOG_DEBUG_STACK ps-.log

The log file is found in /usr/local/vocal/log.

You must also set the environment variable in your ~/.bashrc or ~/.cshrc file to:

NPX_PLUGIN_PATH=<JRE path>/plugin/i386/ns4

For JRE 1.3.1_01, the JRE path was expressed as:

/user/java/jre1.3.1_01/

We cannot predict how this path will be changed by future versions of the JRE.

After compiling and installing VOCAL, as shown in Chapters 2 and 3, do the following to provision users:

In the browser's location or address toolbar, type:
```
                     http://<local host>/vocal/provisioning.html
                  
```
<local host> is the name of the host where the Provisioning server is running.

The provisioning page comes up with a login screen, as shown in Figure 4-1.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once you have brought up the login screen , follow the instructions in this section to access the provisioning system.

The VOCAL system provides password-protected access to the Provisioning server. The provisioning login screen is shown in Figure 4-1.

Figure 4-1: Provisioning login screen

Table 4-1 explains the screen items and fields.

Table 4-1: Login screen item and field description
Item	Description
Access level	Administrator As an Administrator, you can add, edit, or delete user entries. In addition, you can set up Feature servers for users. Technician As a Technician, you can edit the fields that control the servers as well as add or delete servers.
Login ID	The default is vovida.
Password	The default is vovida. See the next section, "Password Maintenance," for informatio

Table of Contents

Section 2.4.2.1: Optimizing the code

Section 2.5.1.1: Registering ua1000

Section 2.8.1.1: Configuring two UAs

Section 2.8.1.2: Launching two UAs

Section 2.9.1.1: Using vocalstart

Section 3.3.1.1: Dial plans