Making Hard Cash From Soft PBXs

Making Hard Cash From Soft PBXs
By Joe Rinde
Posted: 01/2000

Four years ago the IP telephony revolution promised cheap long distance. Today, we have cheap long distance without IP telephony. IP Telephony offers a different, more realistic, promise. The promise of new compelling local telephony services is in the form of new feature function, and lower cost of service delivery. This new promise is already starting to be delivered in the form of the soft PBX (iPBX).

Centrex

Several decades ago, phone companies offered businesses specialized services based on the switching equipment in their COs. Lines terminating the copper wires from desk phones at the Centrex enterprise were treated differently from normal terminations. This allowed separate numbering plans and access to features not normally offered to telephone subscribers. This allowed a three- or four-digit dialing plan to call other phones in the same office. Equally important, these calls were not treated as local calls for tariff purposes, but rather as internal calls.

The phones themselves were normal handsets with 12 keys, an ear piece and a microphone. Special features, such as call transfer, or call forwarding, were engaged by use of the flash hook and a key sequence typically involving the star or pound keys. This required users to memorize these key sequences or to keep handy an instruction sheet with these key sequences.

Two problems arose with Centrex service. First, every change (move an extension, add an extension, etc.) required action by the local phone company. This resulted in time delays and charges. The local phone company had real expenses associated with every change and passed on these expenses (appropriately marked up) to the enterprise.

The second problem was the possible services, and the key sequences that invoked them, were determined by the vendor of the telephone switch used by the local phone company to deliver this service. As a result, an enterprise with geographically dispersed offices served by different COs could have different features or different key sequences for the same functions in different offices. This even could happen if both offices were served by the same phone company in locations where the CO switches were from different vendors.

Another consequence of the service offering being limited to the local CO switch was that the private dialing plan of the enterprise was limited to one location (more locations if all were served by the same CO switch--a limited market space).

The PBX

Partly in response to the issues with Centrex, enterprises started to buy and operate their own PBXs, essentially their own CO switch. With a PBX the enterprise could train its own personnel to make changes to be executed on the enterprise's schedule and without per change costs.

PBXs also allowed for the use of special phones with extra lights and buttons, and, later, screens. The additional buttons allowed special functions like call transfer to be executed by pushing a button rather than a dial sequence using the pound or star keys. The extra lights could convey status information for the user, such as voice mail waiting. Additional features, such as camp-on (wait for a busy extension to become free and then notify the caller while connecting to the previously busy extension), became possible.

The PBX offered a level of independence from the phone company while offering new capabilities for calling within the organization. The price for these advantages was the enterprise became a small phone company from the standpoint of investment and staff. This brought about an industry to run the PBXs for the enterprises. However, the biggest price was the cost of the PBX itself and the proprietary handsets. These could only be purchased from the vendor of the PBX (or second hand units on the resale market). Handsets with only a few extra buttons and lights cost several hundred dollars, while handsets with screens could cost $1,000 or more.

In time, the PBX manufacturers added various capabilities. The manufacturer was, with very few exceptions, the only one who could add functionality to the PBX. The added features came on the vendor's schedule and came to the enterprise with a high price tag. In general, vendors were not responsive to requests for specific new features. Worse yet, many of the features already present were hard to use.

To appreciate the difficulty of feature use, consider how many executives, the guys with the expensive handsets on their desks, are able to transfer a call. The problem is they do not know the sequence of keystrokes needed to affect the transfer. This despite the presence of a button labeled transfer! The problem is the lack of a help screen. Is the correct sequence to press the flash button, key in the number to transfer to and then press the transfer button? Or should one press the "transfer" button, the transfer to number and press the transfer key a second time, or hang up, or something else? In place of a help screen, the executive is left with a help scream to his secretary to transfer the call for him.

The dilemma above is real. Each of the key sequences described can be the correct one for some PBX. For workers that travel between offices of an enterprise that uses PBXs from different vendors, this problem is ever present. Even within a single location, people are not sure their attempt to transfer a caller will work. Do you recall the last time you were transferred without the disclaimer "if I drop you this is the number to call"?

Enter the Soft PBX

Two years ago Selsius Corp. (recently acquired by Cisco Systems Inc. [www.cisco.com]) introduced an IP-based PBX running on a PC along with IP phones. It was the first entrant in this field with IP based phones. A few previous offerings for PC or workstation-based PBXs used standard phones connected to the PC through specialized cards from the computer telephony integration (CTI) industry.

The fully IP-based soft PBX, dubbed the iPBX, offered handsets with extra buttons and lights. More important, it provided an API for application software to access the various parts of the IP phone. The IP phone was connected to the office LAN on the presumption that every office has a LAN connection in the wall. The presumption was correct, but they forgot the reality that most offices had only one Ethernet outlet in the wall, and the PC in that office was already using that outlet. This was a problem that was quickly resolved by placing a second Ethernet connector on the phone as a pass-through similar to what is done with telephone connectors on answering machines.

Using Ethernet for phone access potentially reduces the wiring requirements for the office. It is not clear this will be a long-term cost saving. Operational experience may dictate two Ethernet connectors in the office as a way to provide better voice quality when PC users are doing large data transfers during a voice call. The jury is out on this issue. Nonetheless, the use of IP phones promises to have only one kind of communications system to all the offices, which may lead to some cost advantages on the operations side.

Another important impact of the introduction of IP phones talking to a PC--or workstation-based PBX--is the price of the hardware solution for the enterprise's voice service. PCs and workstations are cheap -- even if we require dual power supplies for reliability, and even if we require hot swapability using something like the compact PCI bus architecture. These are off-the-shelf products available from multiple vendors, compared to the proprietary PBXs currently in use.

Although IP phones are not off-the-shelf items from multiple vendors, the IP nature of the early entrants in this field oriented the marketplace to expect the same rapid cost reduction for the handsets as occurred in the PC marketplace. After all, the handsets are a plastic molding with a keypad, some lights and some electronic circuits. Functions such as IP communications are being built in silicon, processors are cheap, memory is cheap and small character-based liquid crystal displays (LCDs) are cheap. So why shouldn't the handset be cheap? Indeed, even the early IP phone handsets were less expensive than their proprietary PBX counterparts, and they are on a downward price curve that will accelerate as volume grows.

The biggest promise of the iPBX is the ability to add new features and functions easily. Using the APIs provided, new features can be created to use the buttons and lights in new ways. As an example, a help button coupled with the character screen to indicate the sequence to be followed could solve the problem for an executive transferring a call. The user could press the help button, followed by the transfer button (or the opposite order), and receive on-screen instructions. Alternatively, the instructions could automatically appear on the screen when the transfer button, or any other button, is pushed. Even though this helpful function may not come from the vendor of the iPBX, an innovative third party could deliver it using the published APIs.

Another option in the iPBX world is the addition of voice recognition and response. Several voice-based systems, such as Wildfire, have been brought to market in the last five years. Such functionality can be integrated into an iPBX. Although all these ideas could be applied to exiting proprietary PBXs, they have not been delivered. Only the PBX vendor is capable of delivering such services in an integrated manner, but the vendors have chosen not to do so. With the iPBX, an industry of third-party suppliers has begun to spring up to supply a variety of innovative new features and functions. Equally important, individual enterprises, and departments within those groups will be able to commission the creation of specific features to improve their productivity. Features such as selective find-me-follow-me services based on the calling party and time of day could be implemented.

One of the options in the iPBX is the incorporation of the end user's PC for feature control. On the assumption that every desk has a PC as well as a phone, the PC could be used to set up the selective find-me-follow-me function. This takes advantage of the richer interface of the PC to point-and-click, as well as typed text to control the features. Text can be an important means of communication with the iPBX, as databases of names and numbers become available for the end users to tap. Rather than specify the calling extension of the party that will trigger the find-me-follow-me service, the name of that party could be entered. A name in the database could be associated with multiple numbers, such as an office extension, a home number, a cell number, or a pay phone at a favorite bar. Calling from other extensions could also work with a selective find-me-follow-me service. This would take advantage of a future ability for a user to log into a phone, making it his extension for a time. 3Com Corp. (www.3com.com) has demonstrated such a system using the infrared transmitter on a Palm unit to pass an identity authentication token to the phone.

What value is this to a CLEC?

The early iPBXs were oriented to a single organization. There was no way to partition the extensions into groups and bar access to each other. Firewall issues also needed to be addressed to allow the user datagram protocol (UDP, a TCP/IP protocol describing how messages reach application programs within a destination computer) voice traffic through without compromising the security of the enterprise's intranet. Functionality to address these issues now is becoming available. Coupled with the APIs, the CLEC can now create Centrex services attractive to small companies and to enterprises with many small offices.

The service will build on the ability to get low-cost, high-speed access to the user premises. IP phones then can be used on peoples' desks with the control off site. Multiple offices could be supported by a small set of iPBXs, which can back up each other. Each office uses its high-speed IP access to establish communications between the IP phones and the iCentrex. Unlike classic Centrex, special phones can be used. In addition, the functionality of the phones can be different for different customers. The CLEC could offer custom features as a service to improve the stickiness of its offering (stickiness refers to services or functions that help with customer retention).

The iCentrex also opens the possibility of a uniform service to an enterprise with offices distributed throughout the country, or even internationally. The only real requirements are to have a high-speed, low-latency connection to the Internet in each location and the ability for the CLEC to originate local calls in each office location. The former is generally not a problem if a major backbone provider is used (although this may not apply internationally).

With nationwide offices connected, a uniform internal numbering plan can be implemented. Thus, calling a person in another office could be accomplished by dialing his or her extension, possibly without any access code. If the enterprise users want to be able to dial three-digit extensions for local destinations while six digits are needed for distant destinations then an access code is required for distant destinations. Alternatively the user could use six digits in all cases with no access code. The same features, invoked the same way, will be available in every location. This can be achieved using multiple iCentrex machines for reliability and scalability.

Local calling in areas currently not served by the iCentrex CLEC can be provided by installing an IP to PSTN gateway in the distant city plus an interconnect agreement with one of the LECs. There will be some costs associated with becoming a CLEC in a new state, but the cost of the gateway is low. The enterprise could also take advantage of this presence to allow customers in the distant city to call any office location with a local call to the nearby office. This takes advantage of the uniform extension numbering scheme and achieves two positive results. First, it saves the enterprise 800 charges for customers calling from cities where there are offices. Second, it increases inbound calling, which increases the CLEC's income from reciprocal compensation.

The iCentrex provider easily can address the irritation associated with current Centrex service changes for adds and moves. A secure web interface can be used to allow the telecom manager at the enterprise to make moves and add changes on his or her own schedule and without added cost. In truth, classic Centrex providers could do the same (although it would be a larger effort), but none have chosen to do so. It is another difference in the mental approach of the "Net-heads" compared to the "Bell-heads".

The iPBX evolution opens the door for IP-oriented CLECs to provide a higher level of service than currently offered by all LECs. It provides a practical path to the value-added services we have all been talking about, but doing nothing about. It offers the best way yet to create a sticky-service offering. Will the custom features bring in more revenue or will they only provide a mechanism for customer retention? This answer will have to come from the marketplace. Either way it is an offering CLECs may ignore at their risk.

Joe Rinde is the director of Internet architecture for AT&T Labs (www.att.com). He can be reached at joerinde@att.com.

Share this article: Email, Slashdot, Digg, Del.icio.us, Yahoo!MyWeb, Windows Live Favorites, Furl
Add this article feed to: RSS, My Yahoo, Newsgator, Bloglines