Packet telephony is revolutionizing the world’s telecommunications infrastructure, opening the way to previously unavailable communications services. Many of these services are built on a media server or value-adding service platform. But IP-only media servers run the risk of stranded investment if the rate of next-generation network deployment is slower than predicted. And PSTN-only media servers are not enjoying favorable procurement decisions. This has led to increasing investments in media servers that support both legacy and next-generation networks… the dual- network media server (DNMS). This white paper addresses how the DNMS is most effectively designed to minimize cost and time-to-market while producing a system with the media and service flexibility demanded in times of regulatory, standards, technology, and investment uncertainty.
Cost and flexibility depend, of course, on how the system is designed. Low-function telephony middleware can add greatly to the system’s application-development cost; high-function telephony middleware is able to make the target network transparent to the server application, making DNMS application development no more costly than for a single network. Fixed-function media-processing resources can add greatly to the system’s hardware cost if both PSTN and IP networks are supported by separate resources. But flexible-function media-processing resources, although marginally greater in cost than fixed-function, can reduce the incremental cost well below the increase in system value.
Telephony Middleware
High-function telephony middleware products hide the type of network from the application by exposing a network-neutral call-control API to the application. The API packages call-control commands into packets that are forwarded to the System Call Router (SCR). The SCR, as shown in the diagram above, routes commands to the proper network-interface resource based on routing rules, such as the destination address. The SCR, through a resource-management scheme, informs the system’s media-processing resource providers of the network selection so that they can create a resource graph that supports the network choice…all transparent to the application.
The argument is often advanced that cost-per-port is the overwhelming selection criterion, and fixed-function resources will always be lower in cost than flexible function. But the question is cost-per-port of what…voice, fax, data, video? Increasingly, carriers and enterprise network managers are moving to procurements that delay the media and network-support decision to the point of configuration, or, as discussed here, all the way to call placement or acceptance. For this to happen, the equipment designer must have control over both the media-processing hardware and software resources. A fixed-function resource is created whenever the equipment developer loses control of the technologies designed into the system to support media processing or does not implement a system architecture that supports media flexibility.
The fax system service manager utilizes the ITU T.30 recommendation for fax exchange. But the two networks require completely separate network-interface resources. The PSTN call requires analog fax modems; the packet-network call requires, for IP networks, a software entity that implements the T.38 protocol, but instead of relaying the fax data out to analog modems, as shown above for a gateway, it sends it to or receives it from, the server’s application, as shown below. This implementation of T.38 is called “terminating T.38” to distinguish it from the implementation found in gateways, which is called “fax relay”.
