Switching to VoIP

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

262

|

Chapter 11: Troubleshooting Tools

When, Not if, You Have Problems…

Each manufacturer of Voice over IP products, be they open or proprietary, has a cer-

tain amount of software and firmware code to maintain. Supporting Asterisk’s devel-

opment is a developer community with a mountain of C source code undergoing

constant revisions. Cisco has a core development team for Call Manager, a firmware

team that works on the IP phones, a developer staff for Call Manager Express, and

an open source development coordinator. Because your VoIP network is made of

software, it’s only as good as the software that runs it. At some point, through dili-

gent troubleshooting, you may pick up what you suspect is a bug.

For open source projects like Asterisk and VOCAL, the odds are good that another

user has also noted the bug. The odds are also good that the bug has already been

fixed. Then, it’s just a matter of downloading the correct source code revision, com-

piling, and installing the revised distribution. Visit these sites to sign up for mailing

lists where you can monitor the status of bug fixes and report bug-related issues and

get general troubleshooting problems:

http://lists.digium.com (Asterisk)

http://www.vovida.org (VOCAL)

http://www.openh323.org (Open H.323)

http://www.iptel.org/ser (SIP Express Router)

Commercial systems, like CallManager, Avaya’s Media Servers, Nortel Meridian,

Shortel’s IP-enabled PBXs, and others, have the traditional commercial approach to

bug catching. When enough customers complain, the development team ups the pri-

ority of a certain fix and then the company releases a patch. You, the user, down-

load the patch to your PBX, reset your system during off-hours, and (usually) the

problem is resolved.

Though a tech-head might prefer the freewheeling open source community’s quick-

ness in bug fixing, most IP telephone adopters go the commercial route for software

maintenance. Either way, the system administrator should report any bugs encoun-

tered to her system’s development community. After all, as the old saying goes, it’s

the squeaky wheel that gets the grease.

Simulating Media Loads

The bandwidth requirements of a VoIP call can be calculated by adding overhead

factors such as RTP and IP headers and Ethernet framing to the size of the actual

audio frame. That gives you the packet size, which you can multiply by packet rate in

order to figure out the bandwidth required for the call (this was expanded upon sig-

nificantly in Chapter 6). But that’s all academic.