IP telephony, while it promises to alter the way we use that hunk of plastic sitting on our desks, is still in search of its "killer app." Consequently, changing perceptions about IP-based telephones as an adequate replacement for  TDM -based systems has been slow going.

IP PBXs are here to stay because vendors are no longer committing significant research and development dollars to TDM-based platforms. Moreover, there is growing anecdotal evidence of cost savings being realized through voice/data convergence, a big chunk of that coming from reductions in leased-line charges.

Since first testing voice-over-IP systems in 1997, Miercom has seen VoIP mature, overcoming voice quality and reliability problems. Still, some criticize IP-based voice systems from a feature perspective, saying they lack many compared with TDM-based "systems.

Long-standing PBX powerhouses such as Alcatel, Avaya, NEC and Nortel itemize hundreds of features in their TDM systems. IP systems cannot make the same claims. The question is why should they? How many customers really need 450 features? Larger companies might require a larger set of features, but the small office-home office and small to midsize business market, which makes up more than 90% of all voice systems sold, probably doesn't.

End users need hold, transfer, voice mail, multiline, conference and forward functions. Attendants need station monitoring, blind and assisted transfers, paging and after-hours coverage. What else do users need?

While requirements depend - among many things - upon the customer, the industry, the size of the company and its style of business, Miercom thinks the overwhelming majority of companies can get by with the 50 or so features that most IP PBXs support. And when IP PBX vendors finally deliver some of the killer apps that will confer "gotta have it" status on IP-based systems (such as true Web and messaging server integration and follow-me, full-duplex speakerphones), customers won't miss unsupported legacy features, especially when phones are well-designed and intuitive.

Deploying a feature poorly is sometimes worse than not having it at all. Take call forwarding as an example. Users turn on call forwarding before they go on vacation, setting up calls to automatically transfer to an associate. When the user returns, does the IP PBX indicate that call forwarding is enabled on the phone, or will the user have to wait until noon before realizing that he has not received any calls because call forwarding had not been disabled?