As many of our readers may already know, the company known as Praxon
closed its doors in early March. Whenever this type of occurrence takes
place within our genre of technology, it is often a subject of discussion
among TMC Labs' technology editors. We've noted that if the organization
isn't revived in some way, key people often move on to strengthen other
companies within the same circle of technology. This has also been a
subject of discussion, as we've seen it first hand meeting with engineers,
who at one time have worked for companies that are now no longer. They
have often brought innovative ideas to their new workplace and product,
strengthening the communication technology industry as a whole.
We haven't uncovered all the details of Praxon's demise, nor have we
chosen to speculate why or how the company shut down. Nevertheless, we
have decided to run the product review. In the same spirit that people
from one fallen corporation may go on to enhance another, we're hopeful
that this review may indeed provide some insight and perhaps a guideline
for both market-share leaders and prospective buyers to measure other
products against.
Last year the National Convergence Alliance (NCA) was organized in an
attempt to establish an industry voice and authority, while dually
prescribing the benefits and capabilities of converged communication
technology to both providers and non-industry outlets alike. A union of
industry leaders striving to create a platform for this new genre of
evolving technology, in our opinion, indicates the anticipation of greater
things to come. As of late, the use of such terms as
"next-generation" and "killer-apps" seems to indicate
a heavy marketing presence for these products. This further conveys the
fact that the once-separate disciplines of voice, data networking,
messaging, and Internet access no longer appear to be so separate. An
authorless quote on NCA's Web site captures the position and yet-to-be
ascertained range of this burgeoning genre by saying, "The
convergence debate is no longer about when it will happen; it is about how
fast it will occur, the extent of its impact, and how it will
revolutionize the way business is conducted."
Communication convergence is creating opportunities for small and
medium-sized businesses (SMBs) by allowing once out-of-reach,
state-of-the-art technologies to become tangible. Not only is equipment
becoming much more affordable because of consolidation and new
technologies, today's products are becoming much more accessible and easy
to use thanks to the Internet, remote access, and simplified GUIs. Still,
the "converged world" of communications is a very big place, and
the melding of voice and data technology is churning out many new and
different product hybrids. Some products may leave you wondering exactly
what their appeal is, while others may seem almost incomprehensible due to
their over measure of functionality.
Praxon made its contribution to this developing genre of technology
with the Phone Data eXchange (PDX), a stout, simple-looking black box
claiming to provide "a growing business with all of its communication
needs" by employing the functionality of a fully-integrated, complete
office communication system; including phone, networking, fax, voice mail,
e-mail, and Internet capability. We installed and configured the PDX in
the Lab so we could evaluate its performance, and evaluate whether or not
Praxon's PDX fit into the ever-changing "converged world" from
both a user's and administrator's perspective.
INSTALLATION
The optional client software called Virtual Console runs on a PC with a
hardware requirement of 5 MB of free disk space, 16 MB of RAM, and a
display resolution of 640 x 480 (1024 x 768 recommended). The operating
system requirement is Microsoft Windows 95 (with TAPI 2.1), Windows 98
Second Edition, Windows ME, Windows NT 4.0 (Service Pack 6), or Windows
2000 (Service Pack 1). Recommended Web browsers are Internet Explorer 4.0
and Netscape 4.0 and higher.
The PDX closely resembles a standard computer tower in almost all
proportions. Though the appearance is deceiving, it's about twice as heavy
as it looks. After clearing a countertop and unpacking the unit, we
hoisted it onto a lab table. The time to connect and configure the product
hinges directly on its indended use. It took us about a half hour to get
logged onto the unit and begin configuration. The documentation advises
that system boards should be installed first and that this procedure is
only to be performed by qualified personnel. The documentation we received
inferred that the interface cards do not arrive pre-installed, but our
unit was shipped directly from Praxon with the analog card already
installed. It is logical that the reseller would install the boards prior
to shipment, or on-site. There wasn't any hardware assembly to speak of,
just connecting the unit to our existing voice and data systems, which
consisted of the following: connecting to the LAN via an RJ-45 connection,
plugging in the "harmonica" (amphenol) adapter to the FXS/DID
port, and connecting at least one analog phone, adding an additional
amphenol connection to the FXO port for the analog POTS trunks, and
plugging in the AC adapter. Hardware connection completed. We still,
however, needed to assign an IP address to the unit to access the firmware
for configuration.
There are several methods of assigning an IP address to this machine,
both of which include using HyperTerminal or dialing into the system using
a touch-tone phone. We opted to use the touch-tone phone (that we had
already connected to the unit) to expedite the process. The documentation
and the automated menu were very clear, and we were able to complete IP
assignment quickly, without a problem. Using a terminal running Windows NT
and Internet Explorer 5.0, we entered the IP address, and the logon screen
appeared. The default logon is Admin with no password. We were in and
ready to configure.
DOCUMENTATION
The documentation written for our PDX consisted of both an Administrator
and User quick-start guide. Neither was terribly long or incredibly
detailed, but in both cases each guide provided the information necessary
to getting their target audience up and running. The Administrator's guide
explained how to make the proper hardware connections and assign an IP
address, which was enough for us to set up and gain access to the unit via
a browser. The User's guide explains how to set up a user account,
configure the browser, access different accounts, defines various
commands, and other features. Once the firmware is accessed, a much more
comprehensive set of instructions is available online for the
configuration process and end user setup.
FEATURES
In order to provide SMBs with "all of their communications
needs," Praxon must deliver a host of features to support each area
of its expertise (voice, data networking, messaging, and Internet access
capabilities). Praxon offers six different interface cards designed to
accommodate most LAN and WAN access methods, including: analog, T1/E1, and
ISDN, while supporting VoDSL, VoIP, and ATM capability. The unit can
handle up to 64 dedicated users with an unlimited amount of (virtual)
voice mailboxes. Acknowledging that businesses may have alternate
equipment and systems already in place, Praxon was utilizing a vendor
interoperability program (VIP) which afforded compatibility assurance
between VIP partners and Praxon.
Administration features are accessible using a browser interface
(Internet Explorer or Netscape 4.0 or higher is recommended), allowing the
premise equipment to be programmed, or reprogrammed from any remote
workstation with Internet access. The GUI on both the administrator and
client end are both intuitive and easy to use. Praxon has named its user
interface Virtual Console, which effectively allows end users to monitor
e-mail, voice mail, fax, and logs in addition to all user PBX functions
from a workstation with a sound card. PBX functions include: DTMF keypad,
DID, distinctive ring patterns, calling line identification, call
management capabilities, music on hold via audio input (looping a .WAV
file is also possible), speed dial, ACD, and more.
Other features include:
- Auto-attendant provides multiple-greeting capability, dial-by-name,
auto or hotkey transfer to receptionist, auto fax routing, and
voice-mail access.
- Personal auto-attendant allows users to employ multiple greetings
and routing to other extensions, external numbers, voice mail, or
pager.
- SMTP and POP3 server-compatible with "leading e-mail
programs," multimedia mailboxes, auto response, and message
forwarding.
- Voice mail includes over 50 hours of storage, unlimited number of
voice mailboxes, control and retrieval of mail via any of the unified
messaging mediums, notification via any of the unified messaging
mediums, compatibility with a CLASS-compatible analog phone with
message light, and many standard message commands.
- P1/P2 AUX ports provide outside line connections that bypass the PDX
during a power failure, to provide uninterrupted phone service in case
of emergency.
OPERATIONAL TESTING
Praxon was marketing the PDX as not requiring an in-house expert to
maintain and program the unit. Instead they offered up a qualified
reseller to solve technical issues. While the reseller may solve more
issues of the technical and integration nature, and probably in general
would be more apt to dispatch personnel for the "up and running"
types of issues, what about the everyday types of procedures (such as
adding and removing users, and changing their functionality)? Independent
vendors probably aren't going to be equipped with a call center type of
environment and staff system authorities to field these types of
questions. Usability of this system seemed to lie in its ease-of-use, so
naturally, TMC Labs further investigated programmability by not only
examining what the unit is capable of, but also how easily it is enabled.
We examined the Administrator and User interfaces to determine how
intuitive and comprehensive the GUI design is, and how well each is
married to its functionality.
System Configuration
After assigning IP and subnet mask addresses, an administrator can access
the unit via a browser. Once logged on, the Administration menu appears.
We began our system configuration on the Administration home page, which
is laid out in a hierarchal and intuitive manner, allowing an
administrator to set up the system quickly and logically, without having
to "learn" the software architecture. For example, on the home
page, there are a series of tabs (corresponding links are also included in
the body of the page) separating the areas of administration into nine
different categories, including the home page and a wizard's tab. To
dissect the hierarchy and present our case study in an efficient manner,
we'll use the Telephony tab as an example. A scenario was manufactured in
which two small companies (Company A and Company B) would share the PDX
(practical, economical, and a genuine capitalist idea), and could be
achieved easily by defining different trunk groups and assigning an access
digit for each dummy company. Within each trunk group an administrator can
define not only access digits, but a host of other options, including:
cost routing and prefix numbers, call types allowed (voice, data, fax),
call directions (incoming, outgoing), a specific extension or department
that receives incoming calls for the trunk group, and enabling caller-ID
support. In addition, the FXO channels (trunks) must also be defined for
each trunk group. All of these features are readily accessible and appear
to be easily understood, given that the administrator has a basic
understanding of phone systems in general, and in particular the existing
premise scenario. The general and analog lines links are also available
from this location to complete the telephony configuration process. All
told, it took us about 30 minutes to get some simple system rules in
place. Though it should be noted we didn't configure the e-mail server.
Next we had to add the users.
Population Control
Class of Service (COS) functions a template for creating new users. COS
categories are configurable allowing administrators to apply preferences
to define certain "types" of users. This can be done many
different ways, any of which will expedite the induction of new users into
the system once the templates are set up. The template setup consists of
choosing a name, selecting a template to work from initially, and manually
going through the eight areas of functionality to select the options
(phone, e-mail, voice mail, fax, privileges, remote access, and
notification). This is far less tedious than requiring the administrator
to go in and create a profile for each user, since each user's
"backbone" is already created by the templates. All that's
required for each user initially is a name and a few phone numbers
(extensions automatically assigned in order they are entered into the
system).
Configuration settings can be locked by the administrator or they can
be left unlocked so the users can adjust all or certain settings
themselves. Users can also be assigned to departments where, within only a
few clicks, the administrator can assign them to department hunt groups,
the auto-attendant, and so forth. Changing a user's information or service
level can be done by changing the COS selection to fit specification. If
an employee moves to a different department, the department values can be
added to his profile to expedite service from the PDX. Eliminating a user
is completed in a few steps also. Assuming we were configuring the system
for our lab personnel, we set up some users with most of the available
functionality using a COS template we'd created earlier. The actual time
it takes to create a new user and add him into the system is only about a
minute or two, provided he or she fits into an existing COS.
The User's Perspective
A great deal of the user's freedom depends on the administration, and what
liberties they choose to grant their users. Should a higher level of trust
be afforded -- as is often the case in a SMB -- users can fundamentally
characterize many of their own communications options, turning them on and
off at will, with the exception of certain functions such as access to the
FTP, resetting COS, and defining extensions. A "liberal"
administrator would enable users to make their own decision on whether or
not they wanted to enable the do not disturb feature, or any of the new
additions to this release, such as call pickup, paging notification, call
queuing, and additional voice mail functionality. We loaded the Virtual
Console onto several of the computers in the Lab and tested some of the
new end-user functionality. Here's what we found.
We tested the conferencing feature, taking notes on the GUI as we went
through the steps. It seems the conference initiator can use either the
Virtual Console or a telephone to conference others into the call. We
chose to use the GUI so we could monitor its functionality as the call
progressed. It's pretty simple, once the administration (us in this case)
has mapped the ports and extensions correctly. In any event, users can add
extensions to their Virtual Console to enable Speed Dial, which we did.
From our speed dial directory, we called extension 103, clicked
Conference, clicked extension 104, and clicked conference again. We had a
three-way call. It was noted that the virtual display on the console
listed the last user contacted, but not all users.
Conceptually the logistics should be the same whether you're calling
inside or outside the system, though more than likely you'd have to dial
the numbers as opposed to having them on the extension list. If the red
"receiver" status icon appears in front of an extension on the
list, it indicates that the receiver is off hook, the party may be on
another call, or in a conference call. Similarly, if a user's extension
appears in red, denoted by a circular icon with what seems to be a sad
face inside of it, that user has the do not disturb feature enabled. Other
Wingding-esque icons that may appear in front of an extension (depending
on its status) are the call forwarding and speed dial entry icons.
A new COS was then configured to enable all voice mail, call pickup,
forwarding, and unified messaging features, so we could test functionality
and GUI performance in relation to critical information delivery. Each
time a user picks up the receiver to make a call, any new voice mail is
immediately announced before the dial tone is initiated. Though we thought
this might create a practicality problem, we quickly realized that it's
possible to just dial out right away, without waiting for the dial tone.
Picking up an extension that has been forwarded greets the user with a
short announcement explaining that calls have been forwarded to a
different extension.
The main window on the Virtual Console indicates the call forward
feature is enabled when the icon is highlighted in red. Voice mail can be
configured either via browser interface or the user's extension. Dialing
into the system (default extension 899) allows a user to access the voice
mail menu to set options, change greetings, delete, forward, or send
messages. It's also possible to play voice mail over a PC's speakers,
though there isn't a progress bar to help control the message advancement.
We also had a problem using the virtual buttons to rewind, fast-forward,
and stop a voice mail message. They didn't seem to work for us. Messages
and calls were forwarded from one extension to another. Each produced
standard results. The message forwarding menu afforded users the option of
looking up an extension if a menu is established, access distribution
lists; add to distribution lists, and so forth. A preemptive message can
then be recorded prefacing the original message, and it can be marked
urgent over the phone as well.
ROOM FOR IMPROVEMENT
We don't want to seem "nit-picky" because this product did
possess a diverse and powerful skill set, but there were a few things we
may have done differently. By today's standards, the ACD feature is a
requirement in any customer service scenario. Praxon's ACD feature allows
calls to be put in queue on a departmental and individual level, based on
administration of the system. When the calls accumulate in either queue,
music on hold is available if enabled, and the customer can wait or choose
to leave and follow the "when busy" routing rules, defined
either by the Administrator or the user. The problem is that callers
aren't given any information to help make the decision on whether or not
they should stay in queue, or opt to step out and try another course of
action. That is, the "on hold" or queue message can be
customized, but it doesn't keep track of the caller's place in the queue,
or give an estimate as to how long they'll continue to hold for the next
available, or a particular agent. Instead the message is only capable of
conveying the same information repeatedly. For example, "Please
continue to hold, your call will be answered in the order it was
received," or something to that effect.
We think the COS feature is a great way to expedite and populate the
system with users, and at the same time, create different levels of
assigned functionality. However, something didn't seem quite right. At
first, it was difficult to pinpoint, and it wasn't until we began adding
multiple new users and decided to tailor their communication needs that we
discovered what is was. It wasn't the COS feature itself; rather, it was
something that didn't seem to exist. At least, if it does exist, we
couldn't gain access to this area specifically. What's being referred to
is the ability to change an individual's profile separately from the other
member's in the same COS. That is, if you want to change one facet of the
user's profile, it appeared that it must be done from the COS link.
However, locking a feature from the COS denies all members of that COS the
privilege of using that feature as well.
For example, let's assume two employees need to have the do not disturb
option removed from their basic phone options. One employee has a Basic
User COS and the other has an Advanced User COS, each with their
respective function set. Both COSs must be changed to have that feature
locked out, or removed from the users' profiles. Since all users are
assigned to a COS, the users assigned to the Basic User and Advanced User
COSs will also lose the do not disturb feature when it is removed. To
prevent this from happening, it appears a new COS must be created for each
with the same options for each profile, omitting the one feature. That's
just for one difference in service. The repercussions seem to be
exponential. Where eventually each user would have their own COS, unless
functionality for two or more individuals is identical, which is often the
case, the former may be a worse case scenario. Perhaps a small change in
design would eliminate this problem. An option devised to bring the
Administrator directly to a data sheet unique to each user, which would
inherit the initial COS settings. Changes could be made that wouldn't
globally affect the COS template or any other users, and still control
what functionality the user can see and change. Although much easier said
than done, it may add some valuable functionality to this application. It
should be mentioned that we do understand classes of service are devised
to maintain standard service levels for billing and tracking purposes,
however, it seems to us that providing alternate avenues to achieve these
levels of detail is also possible.
CONCLUSION
Despite the company's demise, Praxon's PDX with ICOS 2.0 software did
indeed reserve a spot in today's "newly converged world," even
if for only a time. The functionality of this unit does seem to capture
the convergence as we presently know it by providing a next-gen phone
system. Its administrative and end user GUIs made it easier to use than a
telnet or HyperTerminal interface and as a result did not harbor a
learning curve. Telephone keypad or a Web browser interface made the
initial configuration less complicated.
Countless factors can contribute to whether or not a SMB will require
an in-house technical expert to configure and maintain a system. One of
which may be what type of legacy or premise equipment is onsite, and how
Praxon's PDX would have been integrated with them. As a stand-alone
system, if the reseller can provide on-demand comprehensive support
(should it be needed), a SMB probably wouldn't have needed a dedicated
system's expert. As previously stated, the GUIs are intuitive and once the
system is up and running, it's easy to configure. Aside from a few small
usability issues, we think the product possesses many merits, and are
sorry to see Praxon leave our community as a PC-PBX provider.
[ Return
To The May 2001 Table Of Contents ] |