The Hammer.323 Call Generator is a new stress testing and call analysis tool from
Hammer Technologies that specifically tests H.323 connections. Unlike the powerful Hammer
IT system and the LoadBlaster quality assurance tool, this new product requires only a
simple Windows NT setup and a finite amount of media-over-IP comprehension. Because sample
calls are trafficked directly across the data network, no telephony cards or other special
hardware is required. This is by far Hammer’s simplest tool, but also one of its most
powerful and innovative.
INSTALLATION
One: Install a stand-alone Windows NT Server with Service Pack 4. Two: Put it on the same
network as the application you’re testing. Three: Run the setup wizard and enter the
license code. Reboot. Done.
Installing the Hammer.323 is just about that simple. The software must be installed on
a Pentium II of at least 300 MHz, with 96 MB RAM. The software uses 10 MB of disk space,
plus one MB per call for the log files — for example, a 50-call test needs 50 MB of
free space for the logs. Of course, the computer must also be on a TCP/IP network, and
multimedia capabilities are needed to monitor the in-test progress. Since all outbound
“calls” are packet-based, there are no boards or lines to worry about. This
product definitely scores top marks for its installation, although we did encounter one
minor bug: Our client computer worked when we booted into Windows NT, but not when we
booted into Windows 98. We used a netstat command to analyze this problem, and the result
was that only the NT system was listening for inbound calls on port 1720, which is the
same port NetMeeting uses. For an unknown reason, the 98 machine was not using this port,
even though it should have been. Readers are invited to send us theories on this strange
behavior.
DOCUMENTATION
The manual we received was still in its beta version, and it had its own quirk: It was
originally sent to us as a .PDF file, but when we printed it, all the spaces between words
disappeared. We print .PDF files frequently without any problems, so a Hammer
representative sent us a Word version instead, and we were ready to go.
The Hammer technical writers did a great job here — they managed to explain in 30
pages what other companies might have needed 100 pages to do. But the manual makes a
healthy assumption of the user’s IP telephony knowledge, so we recommend brushing up
on your H.323 facts first. Basically, this document is a chronological guide that explains
everything from how to make a configuration file to how to write a testing script, to how
to analyze the log-file results. We anticipate that the production-version manual will
include more details and more extensive discussion of H.323 testing, but the manual as-is
was sufficient enough to get us started.
FEATURES
Hammer.323’s main GUI is extremely simple: Five pull-down menus, a toolbar, and a
status bar. Of the pull-down menus — file, edit, view, run, and help — edit and
run are the only two of real consequence (the online help wasn’t ready in time for
inclusion in our beta). Even so, the edit, run, and help tabs only have one option each,
the view tab has just two options, and the options under the file tab are redundant to the
toolbar icons. All of this makes Hammer.323 very easy to learn — it’s difficult
to choose the wrong option when the choices are so few. We also noticed that every feature
opens in a new window, which makes the large amount of GUI white space peculiar.
The behavioral quirks of this interface made us stop what we were doing to ponder
Windows interface design. As explained to us by a Hammer engineer, this first version of
Hammer.323 is designed to be functional, not fashionable. The program runs just as well
when it’s minimized to the size of a business card, and all the extra white space and
menu bars may serve future options well.
The file-new option and the edit-test configuration option both go to the same place.
Its tabs include basic test parameters, gatekeeper, audio, script, and destinations. In
the basic menu, you input the name or IP address of the target device, its E.164
first-channel telephone number if applicable, a pause-between-calls interval, the maximum
number of simultaneous calls, the number of script repeats, and error handling/logging
options. The gatekeeper tab includes selections for directly routed calls (call without a
gatekeeper involved), an auto-discovery feature, and a manual configuration —
obviously, the choice you make here is circumstantial to the device(s) you are testing,
and Hammer deserves credit for leaving the option to the user. The audio tab selects the
vocoder used to play prompts; its choices include none, G.711a-law and mu-law, G.723.1 and
G.729a. Next is the script tab, displayed in a four-column format. The columns here
include the step number (apparently limited to 30 steps), the step description, the step
duration, and associated files, if any. Clicking on each step’s description tab
reveals a drop-down menu, where the choices include place call, receive call, release
call, pause, play prompt, and send DTMF. In the duration tab, you select either a time
length in seconds, or the value of -1 which makes a step run until it completes
successfully, fails, or times out. Where relevant, the file tab calls up a typical Windows
Explorer browser interface. Finally, the destinations tab is where you can link scripts to
connection strings, SQL statements, etc., for more advanced scripting mechanisms.
Other features of the Hammer.323 software include the ability to place up to 50
simultaneous calls, or 5,000 calls per hour; multiple vocoders to choose from, including
G.711, G.723, and G.729a; adjustable call lengths and loop tests; a real-time status
display; detailed connection and tear-down reports in .TXT format; and template-based test
script saving.
OPERATIONAL TESTING
The actual H.323 functionality is version 2 compatible, and uses the protocol stack from elemedia. Of course, the most basic possible test is to
send a single call from the Hammer.323 to a NetMeeting 3.0 client. This doesn’t test
much, but it does generate a basic log file, which is useful for learning how to read and
analyze the software’s results.
Regardless of the level of complexity, every Hammer test begins with configuring a
script, discussed in the features section above. For this low-level test, we selected some
basic options. In the basic tab, we entered the destination machine’s IP address, and
a fictional telephone number for the E.164 parameter. We also selected options for one
script repeat and writing a log file. In the gatekeeper tab, we selected the
direct-routing option, and we chose the G.711 mu-law option under the audio tab. Next, we
made a simple three-step script, which included a three-second place call command, a
10-second play prompt command, and a release call command. To run the test, we set the
NetMeeting client on auto-answer, and we started the run test command. This test only
lasted for a few seconds, but it allowed us to see how the results display in real time,
and it generated a representative log file.
This file begins by showing the call number, destination address, and port number. The
next step is the H.225 connection (which includes call signaling protocols and media
stream packetization, plus the Q.931 setup), followed by the H.245 connection (control
protocol). The appropriate prompts are played with the appropriate vocoders, the call is
dropped, RTP packets are sent, and the call is complete. (For more detail about H.323 call
setup, see elemedia’s white paper at
www.elemedia.com/main/h323center/h323_overview.htm.) The actual text of the log file may
seem cryptic, but even if you’re not technical enough to understand the call setup,
it’s still easy to see at what point the call fails or takes some atypical action.
Real-world uses of Hammer.323 can be much more complicated. Imagine that company X
wants to implement an IP-enabled call center product like CosmoCom’s
(www.cosmocom.com) Universe system. This kind of product would surely increase the packet
levels flowing into and out of their call center, so you — the consultant, VAR, MIS
manager, etc. — are tasked with figuring out how this will affect the network. Or, if
you’re a developer, imagine that you’re working on a hot new H.323-compliant
killer application that will make your tiny startup the next Nortel or Cisco,
except that some mysterious glitch is preventing proper connections. You could use a
bit-level protocol analysis tool, but such tools are not appropriate for every user, and
they tend to rival the cost of a semester at Harvard.
ROOM FOR IMPROVEMENT
The main features that are missing from the Hammer.323 product — the ability to
measure packet loss, latency, jitter, etc. — are included with the VoIP suite for the
Hammer IT system. In concept, it makes sense for these products to be integrated, but in
reality, this would be very complicated … After all, there are good reasons why the
high-end Hammer.323 peaks at $5,000 and the low-end Hammer IT starts at five times that
amount. Future versions of Hammer.323 will probably allow the user to install the software
on existing Hammer boxes, so more comprehensive testing will be possible. Other changes
we’d like to see include a less intrusive user interface, a manual with better
discussions of why and how this tool can be used, and further discussion of how to
interpret test results.
CONCLUSION
We are very impressed with Hammer’s first software-only product. It is inexpensive,
it is powerful, it is easy to install, and it is easy to use. Combined with a WAN
emulation product like The Cloud (Shunra Software Ltd.,
see our review in the August
issue of Internet Telephony�), the Hammer.323 can be one of the most powerful weapons
in your IP telephony development arsenal. We highly recommend it, and we award it our
Editors’ Choice honor. |
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
