This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
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: (Asterisk) (VOCAL) (Open H.323) (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.

Get Switching to VoIP now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.