Voice/Data Comm 101
 
 
home page general  website information contact me at lamarheller@earthlink.net copyright information
 

Next Generation Phone System

By CommWeb.com
Aug 2, 2001

What Is A Next-Gen Phone System?

This Solution Center deals specifically with "next-gen" phone systems, aka. communication servers and/or communication appliances and/or UnPBXs and/or server-based PBXs...; whatever you want to call it, there's no question that in the last few years a new breed of telephony system has risen that brings the LAN client/server model and its implied voice/data convergence to the basic business-class applications of "private branch" telephone-call switching/control as well as voice/fax messaging.

Naturally, there are some differences in the way vendors are creating systems under this rather broad technology heading, with the biggest dividing line being drawn between those systems founded on the traditional "Wintel" PC platform and those being created within the Cisco-like network-appliance form factor.

And while all of these systems plan on incorporating Voice over IP and IP Telephony (they all, of course, feature TCP/IP connectivity by definition), some platforms attempt to merge voice / data within business premises. The result is a brand new market for what some have awkwardly dubbed "one-wire wonders", i.e. platforms that put voice on the LAN via VoIP, regardless of what wide-area network (PSTN or IP or Internet or a combo therein) they presently employ to speak with the rest of the world.

Overall, unlike the architecture of traditional PBXs, these systems have programmed logic that can be modified by both end users and/or third parties. Because most supply desktop call-control GUIs, they also support full feature-access from generic analog telephone sets, i.e. no matter what kind of phone is used, the client/server link with these systems provides a well-defined signaling and control relationship with the system's common control equipment. Further, integration of LAN databases are actually expected to define system call-control parameters.

Why Would You Want One?

First and foremost, of course, you must need (to use or resell) a new business phone system (because you're starting a new business or opening up a new office, sick of or grown out of your old PBX/key, looking to resell one of these more modern platforms, etc.).

If this is the case, we absolutely recommend that you look at the systems included in this Solution Center; we think they offer definite benefits over traditional key telephone system (KTS) and private branch exchange (PBX) equipment.

The big reason why is, we think, fairly apparent: they give businesses much more intelligent, flexible and manageable control over their telephonic needs.

They also provide features that not even the most advanced PBX platforms can and they often do it at key-system prices (see the Interactive Comparison Tool).

Other inherent benefits:

  • Deep integration of call-control and media-processing functions.

This is because, unlike traditional phone systems -- where an "adjunct" PC usually handles the media processing and then works (as best it can) with the phone system via "CTI" (computer-telephone integration) to affect accompanying call control -- there is no "I" in these "computer" systems; instead, switching and media processing, e.g. auto attendant/voicemail, are meshed from the start, allowing for such advanced features as follow-me call-forwarding to multiple numbers and "boomerang" -- wherein callers can get dialtone and auto callback people out of voicemail queues, make a connections, then drop back into the queues exactly where they left off.

In most cases, we're also talking about telephony tightly integrated to the intelligence of the LAN. With the right software, this means first- and third-party call-control that a traditional standalone phone system could never match (unless it was equipped with very expensive CTI band-aids), including skills-based routing, screen-pops and complete GUI-based call handling.

  • No need for expensive and generally awkward feature phones.

Again, these systems usually work with inexpensive 2500 sets, since the concept of feature phones are made completely archaic by desktop call-control links and GUIs; some systems, especially those that send VoIP to the desktop, do offer traditional executive sets (albeit "IP" based).

  • They're more open.

These systems are generally further down the road towards affordable IP Telephony support and unified messaging. They also generally feature TAPI Call-Control API support for integrating in third-party apps and relatively feature-packed ACD out of box.

  • Cost-effective multi-functionality.

Some of the new designs we've seen include a single-box that acts as a LAN hub, router, PBX / voicemail / auto attendant and an IP Telephony gateway. Not only does the end user benefit from easier administration of this one-box-kills-many-apps paradigm, but the price for the single box is usually much less than purchasing multiple devices.

  • Distributed call-handling intelligence and fault tolerance.

In theory, you could set up multiple systems to handle multiple groups within an enterprise (all networked together on the corporate LAN / WAN via IP).

Not only does this make sense from a user perspective (why should sales have the exact same monolithic phone system as accounting?), but it would also mean that a hardware failure on one box would only affect users connected to that unit. The rest of the groups would continue to work on. You could also add and remove switches from your network without disrupting service to all users.

  • Multi-site networking.

Instead of pulling wire between local offices or leasing trunk lines for more distant connections, a system in each office, connected via IP LAN or WAN, can do the job simply and with little fuss.

The beauty here is being able to handle -- today, with no need for a peripheral gateway -- both circuit-switched and IP-based telephony out of a single unit, with calls going both ways depending on the circumstances and pretty much transparent to the desktop user.


What Should You Look For?

It's not out of the question to expect:

  • PBX-like reliability.

Conventional PBXs are still largely sold on their maximum reliability; they should be. But next-gen phone systems shouldn't be lacking here; nobody wants a fancy phone system that's not also extremely reliable.

Besides questioning the vendor deeply about reliability and fault tolerance, one other thing to note here are those features that are invoked if the system does in fact go down (it happens).

These include:

Automatic line bypass (aka. Power Fail Call Handling) -- This will let trunk lines still ring-through to stations as the system reboots. Several lines should be available for this kind of performance;

Fast Power Outage Recovery -- it shouldn't take 10 minutes to reboot a system either.

All systems should also have a Visual "Trunk-Okay" Indicator and a real-time monitor that shows overall system performance.

PBX-like Least Cost Routing.

Besides reliability, one of the more (still honest) barbs you can make against this new breed of phone system is its lack of sophisticated (at least when compared to 10-year-old switching platforms) LCR features.

PBX-like Call Accounting and Traffic Reporting.

The system should absolutely log call activity and include tracking/billing/accounting software to process this data. It should also generate reports on system performance/use and let third-party experts integrate their systems as well.

A very un-PBX-like desktop call-handling GUI.

All LAN-based phone systems should provide a desktop call-handling GUI that can be configured as a worldwide web interface and/or a native Windows client. This GUI should show a minimum of 20 line appearances and let you click to take calls, place calls on hold, send them to voicemail, send them to voicemail and monitor messages, conference calls by clicking on participants, conference calls by dragging and dropping participants, transfer calls by either clicking, or dragging and dropping call appearances, click on a last number redial key, put callers on hold, park calls, pick up parked calls, go on/off do-not-disturb and set up call forwarding.

The GUI should also let a user on a call put a second caller on hold without ever answering that call -- instead, the system will play a pre-rerecorded "I'll be right with you" sound file.

The GUI should also provide a Visual BLF that shows colleague status. Again, it should also let users drag and drop or click on these extensions to place, transfer and conference calls.

The GUI should provide visual unlimited speed-dial lists -- personal and system wide. It should also include pauses in speed-dial strings to get through distant auto attendants.

The system should provide some form of caller-ID screen pops upon capturing CLID or PINs from callers. The system should also provide third-party PIM Integration.

The GUI should provide PC screen Messaging Waiting Indications.

The system should include Visual Voicemail at a minimum, with GUI based auto callback from the inbox when caller is identified.

From messaging GUI, can should be able to dump someone into voicemail and listen to what they're saying. If you like what you hear, you should be able to pull the person out with an icon click. Callers can also mark their messages "Urgent", which automatically sends them to the front of the queue when callers dial into mailbox via TUI or to the top of the inbox when messages are checked visually.

Subscribers should be able to save, trash or forward multiple messages simultaneously by selecting them all and hitting a command.

The system should also provide browser access to messaging mailboxes and voice streaming to remote web clients.

Embedded Documentation / Help.

There should be no worries about about misplaced manuals. They should be stored on the server.

Scalability.

Like traditional PBXs, all of these systems have finite design limits and capacity limitations in terms of traffic, processors, memory, and line and trunk ports. Obviously, you want to make sure that the system is properly sized and, more importantly, can grow with you. Some of these systems are really only for very small (under 40 phones) businesses.

T-1 connectivity.

This is something you don't think about when it comes to modern day phone systems (they've been there and done that), but some of these systems haven't yet introduced digital (T-1 / E-1) interfaces. This is a glaring shortcoming and seriously affects a system's ability to scale up; analog trunk interfaces are also sketchy at best in terms of quality performance.

IP Telephony Support.

You might not need this yet, but definitely find out what the vendor's plans are here. Most of the systems found in our Interactive Comparison Tool include VoIP/IP Telephony Support

War-Room Wiring.

How does the system connect to trunks? How does it connect to station wires? Are there any patch-panel-type strategies that make sorting this all out easier. Is there any special Automatic Line Bypass blocks that the vendor has developed.

Call Conferencing.

How many max parties (internal or external) can be added per call and how many simultaneous conference calls can be supported per system? It's not unreasonable for this technology to support up to 8 parties on a single call. This should all be configurable from call-handling GUIs, of course.

Music/Messaging On Hold.

How is this done exactly? Is there a standard RCA audio jack on the PC hardware / key service unit (KSU) to plug an audio source into? Does the system play files off the CT cards / proprietary guts themselves? Do you use up a station port for MOH and, if so, do you need a special cable / adapter box?

Make the system can reasonably provide MOH; it's important.

Paging Integration.

The system should be able to handle simple outdialing for message notification.

Voice Prompt Format.

What does the system use? Is there an included conversion utility for converting .wav files to appropriate formats? Can .wav files be used? It's shocking how proprietary systems limit choices and professionalism here.

These system should make it very easy. We like systems that use .wav files... or at least let you store voicemails as .wavs.

Automatic Speech Rec Support.

These systems should have definite plans for support of ASR auto-attendant at a minimum. It would be nice to make it available from the TUI too.

Text-To-Speech Support.

If the system supports -- and you need -- unified messaging, you'll need TTS. Great for remote e-mail reads.

Caller ID Support.

This should be standard -- knowing who's calling is often key to automated and intelligent processing.

Multiple Language Support.

You should be able to make each channel, trunk or mailbox language-selectable.

Type of Telephone Instrument Support.

Generic 2500-set support is key. But some people like fancy business phones (and you know who you are); in this case, ask if the vendor has cut any OEM deals wherein they have "mock" PBX business phones with LCDs, feature keys, softkeys, message-waiting light, etc. Many do.

Number of Auto Attendants.

You should be able to develop a different auto attendant app for each incoming line into the system. This is very handy.

Auto Attendant Greetings.

There should be more and types -- based on hour of day, day of week, holidays, etc. -- than you'll need.

Fax Auto Detection.

The auto attendant(s) should detect CNG tones and route fax calls accordingly. Useful for saving lines in small offices.

Dial-By-Name.

Should be commonplace in any auto attendant.

CLID / PIN Routing.

The platform should offer system-wide custom call-routing based on CLID or PIN. After all, why should your phone system treat everybody (from your worst enemy to your best customer) the same?

Toll Restriction.

The system must restrict long distance calls, international and 900/976 number access on a per trunk, per extension and system-wide basis.

Automatic Call Distribution.

The system should provide simple ACD-like call distribution and reporting features.

Distinctive Ringing.

To distinguish between internal extensions and outside callers. Useful.

Personal Operator Support.

Every system should provide it. This is not just company-wide operator, in this case each user can program in special departmental secretary, assistant or any extension as the place to "zero" out calls.

Caller Screening.

Here, the caller is asked to say his or her name before getting routed. On the subscriber end, the system plays back the recorded name ID and asks if the call should be patched through or sent to voicemail. This should be standard on these systems.

It should also be standard that caller screening is turned off if CLID or PIN is captured and call ID is matched.

Call Waiting.

These systems should support call waiting tones and virtually unlimited call appearances (blocked only by overall system capacity) to desktop extensions.

Follow Me Call Routing to Multiple Numbers.

These systems should allow authorized users to "cascade-forward" (Joe isn't answering his desktop phone, would you like to try his cell phone...?) callers to up to four numbers. This should all be managed from both a system GUI and TUI, where users can set up follow-me schedules and establish special connection passwords.

On-Hold Outlet.

The system should callers on hold the option to go to voicemail at programmed time intervals ( 10 seconds, 30 seconds, etc.).

An excellent TUI.

Yes, the desktop GUI stuff is sexy and useful, but perhaps the most crucial aspect of a telephony / voicemail system for day in and day out use is the telephone user interface (TUI). Users and callers will spend many hours per month listening to prompts and pressing DTMF keys to navigate and control the system, both at their desks (if they're not running a Visual Voicemail client) and from remote locations.

Menu structures should be logically organized, with the most common functions listed first in each voice prompt. Consistency is key.

TUIs should allow DTMF digits to "punch through" voice prompts, which is good when it allows callers or users to rapidly navigate well-known paths.

Private Messaging.

Callers should be able to enter special PINs to get secret messages out of subscriber mailboxes.

Subscriber Greeting Parameters.

Mailboxes should support virtually unlimited greetings. These should be able to be recorded and managed through a TUI and a GUI. Hopefully, different greetings can be played per mailbox that are based on time of day, day of year, and automated caller identification.

Voicemail Scan.

This lets users get into voicemail queue, hit a DTMF command and hear just the first five seconds of each voicemail message until they hit something they want to really listen to, whereupon they hit another DTMF and the feature is turned off and plays that message in its entirety.

Messages Appending.

This lets people record a header onto a received message and forward it other users.

Auto Callback Messengers.

If the system captures CLID and associates it with a message, subscribers can hit a DTMF or callback icon and speed-dial the number.

Auto Re-Queue.

After an automatic callback from the message stack, this lets subscribers hit a touchtone sequence to drop back where they left off in their message queue -- ala AltiGen's excellent "Boomerang" feature... not really needed with visual voicemail GUI, but great for remote message or plain TUI access.

TUI Message Access.

Can users adjust the way messages are presented to them in the TUI -- or is it simply last in, first out. How 'bout playing urgent messages first, etc. or first in, first out? Can this be sorted according to subscriber taste?

Messaging Stats.

The system should generate reports on Mailbox Usage, Mailbox Status, etc.

Audiotext.

The system should allow creation of information-only media-processing "trees" that go as far down as you need.

Q&A Mailboxes.

The system should be able to ask callers virtually unlimited automated questions, with the answers given via voice, touchtone "0-9", or "1" for "Yes" / "2" for "No". When played back, one contiguous message heard should be heard.

App Creation Tool.

Some systems offer a GUI based app gen for creating advanced interactive voice / fax apps and audiotext for the platform. This is more important for call centers.

Multiple trunk support -- including TDM circuits.

Whether or not you want IP functionality, you should have multiple network transport options. Modern business phone systems should boast ISDN PRI/BRI, T-1/E-1, PSTN, frame relay, and (in some cases) ATM links.

Call Center functionality.

We sort of gloss over this here (we need another Solution Center to cover everything here). But many of the systems here do boast bundled or add-on contact center functionality -- from call logging, reporting, and billing to multimedia customer support; from skills-based routing to remote agent monitoring.