The Latest In Developer Resource Blades: Page 2 of 27

The mechanisms are complex, but the goals - at least in their expression - are relatively simple. Telecom apps are supposed to get to market fast. They're supposed to be highly available and robust. They're supposed to be upgradeable, scalable, centrally manageable, and affordably maintainable. And they're supposed to be cheap enough not to break the deployment business model.

The Devil, of course, is in the details.

FROM THE GROUND UP

Ten years ago, at the beginning of the "computer telephony" revolution, the dominant mental model was of a single-chassis system: a PC stuffed with ISA- or EISA-compliant line interface and DSP boards. Boards in such a first-generation "voice response unit" interoperated at the clock speed of the system bus, generating interrupts for CPU service and requests for direct memory access.

This worked fine for low-traffic applications like four- to twelve-port voicemail. But performance began to flag as line-counts climbed and digital (T1/E1) line interfaces entered the picture. Components of the system were caught in lockstep, too dependent on CPU service. Horsepower was wasted by the bus's sharing scheme, which permitted only one device at a time to communicate. Functionality residing on individual cards was unavailable to other resources in the system.